Docker Networking: How Containers Talk to Each Other

WHY IT EXISTS Before containers, running multiple applications on one server meant constant port conflicts and complex network configurations. Docker networking was created to give isolated containerized processes a way to communicate with each other and the outside world in a predictable, controlled manner, without interfering with one another.

THE MENTAL MODEL Think of Docker networking like an apartment building's phone system. Each apartment (a container) gets its own private phone line and number (network interface and IP address). Calls between apartments in the same building (on the same Docker network) are direct and simple. To call outside the building (access the internet or be accessed externally), you must go through the building's main switchboard (the Docker host's port mapping).

HOW IT WORKS Docker manages networking through drivers. The most common is the bridge driver. When Docker is installed, it creates a default network named bridge. Any container you run without specifying a network gets attached here, receiving a private IP address. To expose a container's service, you map a port on the host to a port in the container (e.g., host:8080 -> container:80). The key is to create your own user-defined bridge networks. These are superior because they provide an internal DNS service, allowing containers on the same network to find each other by name, which is essential for multi-service applications.

WHEN TO USE IT Use a user-defined bridge network for nearly all single-host development and production scenarios where multiple containers need to communicate (e.g., a web server and a database). Use an overlay network for multi-host communication, typically managed by an orchestrator like Docker Swarm. Use host networking only for niche, performance-sensitive applications where you must eliminate the network virtualization overhead and can accept the loss of isolation.

WHEN NOT TO USE IT Avoid using the default bridge network for applications. Its lack of DNS-based service discovery makes it brittle; if a container restarts, its IP address can change, breaking any hardcoded connections. Avoid host networking unless you have a specific, tested reason, as it breaks port isolation and increases security risks by giving the container direct access to the host's network interfaces.

ONE CANONICAL EXAMPLE Consider a web app with a frontend container (Nginx) and a backend container (Python API). First, you create a network: docker network create my-app-net. Then, you run both containers attached to it: docker run --network my-app-net --name backend ... and docker run --network my-app-net --name frontend -p 80:80 .... The Nginx configuration inside the frontend container can now simply proxy requests to http://backend:5000. Docker's internal DNS resolves backend to the correct private IP, no matter how many times the backend container restarts.