veth pairs) connected to a software bridge.TL;DR (Quick Summary)#
- Default Bridge (
docker0): Standard single-host network. Containers can reach each other via IP address, but NOT by container name! - User-Defined Bridge: Custom user networks. Provide Embedded DNS Resolution (containers can communicate using container names e.g.,
http://database:5432). - Host Network (
--network host): Bypasses network isolation. Container shares the host IP directly (fastest performance, no port mapping needed). - Overlay Network: Enables multi-host container networking across Swarm or Kubernetes clusters.
1. Docker Network Architecture#
graph TD
subgraph HostNetworkNamespace ["Host Network Namespace"]
Eth0["Host Physical Interface: eth0"]
IPTables["iptables NAT Rules"] <--> Eth0
DockerBridge["docker0 / Custom Bridge: 172.19.0.1"] <--> IPTables
end
subgraph Container1 ["Container 1"]
Veth1["veth1a"] <--> DockerBridge
App1["Web Container (172.19.0.2)"] <--> Veth1
end
subgraph Container2 ["Container 2"]
Veth2["veth2a"] <--> DockerBridge
App2["Database Container (172.19.0.3)"] <--> Veth2
end
2. Comparison: Network Drivers#
| Network Driver | Isolation | DNS Resolution by Name | Performance | Typical Use Case |
|---|---|---|---|---|
| Default Bridge | Isolated | No (IP address only) | Standard | Basic legacy containers. |
| User-Defined Bridge | Isolated | Yes (Embedded DNS) | Standard | Microservices on a single host. |
| Host | None | No (Uses Host DNS) | Maximum (No NAT overhead) | High-throughput web servers, proxy instances. |
| Macvlan | Isolated | No | High | Assigns physical MAC addresses directly to containers. |
3. Step-by-Step Lab: Building a Custom User-Defined Network#
Let’s prove that User-Defined Bridge networks provide automatic DNS resolution between microservices.
Step 1: Creating a Custom Network#
Create a custom bridge network named app-net:
docker network create --driver bridge app-netInspect the network configuration:
docker network inspect app-netStep 2: Launching Containers on the Custom Network#
Launch a Redis database container:
docker run -d --name my-redis --network app-net redis:alpineLaunch a Node container connected to the same network:
docker run -d --name my-app --network app-net alpine sleep 3600Step 3: Testing Embedded DNS Name Resolution#
Ping my-redis by container name from inside my-app:
docker exec my-app ping -c 2 my-redisExpected Terminal Output:
PING my-redis (172.19.0.2): 56 data bytes
64 bytes from 172.19.0.2: seq=0 ttl=64 time=0.089 ms
64 bytes from 172.19.0.2: seq=1 ttl=64 time=0.095 msThe embedded Docker DNS engine resolved my-redis to 172.19.0.2 automatically!
4. Troubleshooting & Common Errors#
Error 1: Name or service not known in Default Bridge#
The Cause: You ran two containers on the default docker0 network without creating a custom network, and tried to connect via container name (http://backend:8080). Default bridge does NOT support name resolution!
The Fix: Create a custom bridge: docker network create my-net and run both containers with --network my-net.
Summary & Next Steps#
In this episode:
- We analyzed Docker network drivers (Bridge, Host, Overlay).
- We created user-defined bridge networks.
- We tested embedded container DNS resolution by container name.
Next, we move to Episode 4: Docker Volumes and Data Persistence!

