Docker From Scratch – Day 4: Docker Networking Explained with Real-World Examples

🐳 Docker From Scratch – Day 4: Understanding Docker Networking

In the previous article, we learned how Docker Images are built using Dockerfiles and how containers are created from those images. At this stage, you can successfully build your own Docker Image and launch a container using commands such as docker build and docker run. However, another important question naturally arises. Once a container starts running, how does it communicate with the outside world? How does your browser access a web application running inside a container? How do multiple containers communicate with each other when building real-world applications? The answer lies in Docker Networking.

Networking is one of the most fundamental concepts in Docker because almost every application requires communication. Whether it is a frontend connecting to a backend API, an application connecting to a database, or a microservice communicating with another service, networking is what makes these interactions possible. Without networking, containers would exist as isolated environments that could not exchange information with each other or with users.

Imagine a modern city filled with thousands of houses. Every house has a unique address that allows people to visit it or send mail. Roads connect every house, making communication and transportation possible. If roads did not exist, each house would be completely isolated regardless of how beautiful or functional it was. Docker Networking works in a very similar way. Every container receives its own network interface and IP address, while Docker creates virtual roads that allow containers to communicate safely and efficiently.

Whenever a container starts, Docker automatically connects it to a network. If no custom network is specified, Docker connects it to the default Bridge Network. This network acts like a private neighborhood where containers can communicate with each other while remaining isolated from the outside world unless specific ports are exposed.

Developer
      │
      ▼
 Docker Engine
      │
      ▼
 Docker Network
      │
 ┌───────────────┐
 │   Container A │
 └───────────────┘
      │
      │
 ┌───────────────┐
 │   Container B │
 └───────────────┘
      │
      ▼
 Internet / Host Machine

To better understand Docker Networking, consider a real-world application such as an online shopping website. The application consists of multiple services working together. The frontend displays products to customers, the backend processes business logic, and the database stores product information and customer orders. Instead of running everything inside one container, modern applications separate these services into different containers.

Frontend Container
        │
        ▼
Backend Container
        │
        ▼
Database Container

Each container performs a specific responsibility. The frontend sends requests to the backend, while the backend communicates with the database. Docker Networking enables this communication without requiring developers to manually configure complex networking rules.

Docker provides multiple types of network drivers, each designed for different scenarios. Understanding when to use each network is an important skill for every DevOps Engineer.

Bridge Network

The Bridge Network is Docker's default networking mode. Whenever you install Docker, a bridge network is automatically created. Unless you explicitly specify another network, every new container joins this bridge network.

Think of the Bridge Network as a private residential colony. Every house inside the colony can communicate with neighboring houses because they are connected by internal roads. However, people outside the colony cannot directly access these houses unless there is a security gate that allows entry. Docker behaves in exactly the same way. Containers inside a bridge network can communicate with each other, but external users cannot access them unless ports are published.

To view available Docker networks, execute the following command:

docker network ls

The output usually looks similar to this:

NETWORK ID      NAME      DRIVER

7e4d3f8a1      bridge     bridge
9abf1c72e      host       host
f7c2d0a91      none       null

Each entry represents a Docker network. The bridge network is the default network used for most containerized applications running on a single host.

Suppose you start an Nginx container using:

docker run -d nginx

Docker automatically connects the container to the default bridge network and assigns it a private IP address. This IP address is only accessible within the Docker network and cannot be reached directly from your browser.

This brings us to one of the most commonly misunderstood concepts in Docker—Port Mapping.

Imagine living in a large apartment complex. Your apartment number might be 105, but visitors never directly enter Apartment 105. Instead, they first enter through the building's main entrance. A security guard then directs them to the correct apartment. Docker Port Mapping works exactly the same way.

When Nginx runs inside a container, it listens on Port 80 internally. However, your computer has no idea how to reach that internal port. Docker solves this problem using the -p option.

docker run -d -p 8080:80 nginx

Many beginners memorize this command without understanding what it actually means. Let's break it down.

8080 → Host Port

↓

80 → Container Port

Whenever someone opens http://localhost:8080, Docker receives the request on Port 8080 of the host machine. It then forwards that request to Port 80 inside the running container where Nginx is listening. This forwarding happens automatically through Docker's networking layer.

Without port mapping, your container would continue running successfully, but nobody outside the Docker network would be able to access it.

Another interesting feature of Docker Networking is automatic IP allocation. Every container receives a unique IP address from Docker's internal subnet. Although this might seem useful, experienced engineers rarely communicate using container IP addresses. The reason is simple. Container IP addresses change whenever containers are recreated.

Imagine saving your friend's house address, only to discover that the address changes every time they renovate their house. It would become impossible to visit them reliably. Docker solves this problem using container names and built-in DNS resolution, which we'll explore in the next section.