Docker Networking
Container-to-Container Communication — Same Host
Direct communication via user-defined bridge networks.
Interview: Very common in system integrations. Interviewers will check if you know why default bridge networks fail at DNS resolution and how custom user-defined bridges enforce network boundaries.
Introduction
When microservices run on the same physical host, they must communicate. While you could hardcode container IP addresses (e.g., 172.17.0.3), this is fragile. Container IPs are dynamic and change whenever a container restarts.
To enable reliable container-to-container communication, Docker utilizes virtual switches on the host. By placing containers on a shared **User-Defined Bridge Network**, they can resolve each other's endpoints automatically.
Why It Matters
Using the default Docker bridge is an anti-pattern: it does not support automatic name resolution. If you place a web container and database container on the default bridge, they cannot ping each other using hostnames.
Default Bridge vs User-Defined Bridges
The differences between default and custom bridges are critical:
| Feature | Default Bridge | User-Defined Custom Bridge |
|---|---|---|
| Automatic DNS | No (must hardcode IPs or use outdated links) | Yes (resolves container name to dynamic IP) |
| Security Isolation | No (all default containers share same network) | Yes (containers on separate bridges are firewall blocked) |
| Hot-Plug Interfaces | No (cannot disconnect at runtime) | Yes (can connect/disconnect networks on the fly) |
Practical Example
Let's build a custom bridge network, launch a database container, and verify that a web container can communicate using its name:
What just happened? Docker's internal DNS server intercepted the ping request for database-server, looked up the active container IP in the network namespaces registry, and routed the ICMP packets automatically.
Quick Quiz
Q1: What happens if container A is on custom network "net-1" and container B is on custom network "net-2"?
A) They communicate using hostnames automatically.
B) They cannot communicate directly; Docker isolates them unless you bridge them by connecting one container to both networks.
C) The host kernel merges them.
D) The daemon crashes due to routing loops.
Answer: B — Separate custom networks are completely isolated at the system bridge level, creating secure boundaries.
Scenario-Based Challenge
Production Scenario:
You have an Nginx reverse proxy container that needs to route traffic to both a Java backend container and a Python API container. The Java backend and Python API should remain isolated from each other. How do you design the networks?
View Solution
You can solve this by utilizing Docker's ability to attach a single container to multiple networks:
1. Create two custom networks:
docker network create net-java
docker network create net-python
2. Start Nginx on the first network:
docker run -d --name nginx-proxy --network net-java nginx
3. Connect Nginx to the second network as well:
docker network connect net-python nginx-proxy
4. Start the Java app on net-java and the Python app on net-python.
Now, Nginx can route traffic to both backends because it resides in both namespaces. However, the Java and Python containers remain fully isolated since they share no common subnet.
Interview Questions
1. How do you connect a running container to a network on the fly?
You use the command: docker network connect [network-name] [container-name]. This instantly plugs a new virtual network card (veth interface) into the container namespace without restarting the process.
2. Can containers resolve each other using container IDs instead of names?
Yes. Docker's embedded DNS server supports hostname lookups for both the container's user-defined name and its 12-character short container ID (e.g., pinging d18fbc8d3120 works).
Production Considerations
When orchestrating containers locally, use **Docker Compose**. Docker Compose automatically creates a dedicated user-defined bridge network for your application stacks and hooks all services into it, enabling name-based discovery out of the box without manual network scripts.