Skip to main content

Docker Ep 3: Docker Networking Deep Dive

Rachmat Hidayat
Author
Rachmat Hidayat
Learn & sharing insights on TypeScript, Go, Kubernetes, DevOps, DevSecOps, SRE, Platform Engineering, AI/ML Engineering, and MLOps.
docker - This article is part of a series.
Part 3: This Article
How do two containers on the same host talk to each other without exposing ports to the public internet? Docker uses Linux virtual network interfaces (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 DriverIsolationDNS Resolution by NamePerformanceTypical Use Case
Default BridgeIsolatedNo (IP address only)StandardBasic legacy containers.
User-Defined BridgeIsolatedYes (Embedded DNS)StandardMicroservices on a single host.
HostNoneNo (Uses Host DNS)Maximum (No NAT overhead)High-throughput web servers, proxy instances.
MacvlanIsolatedNoHighAssigns 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-net

Inspect the network configuration:

docker network inspect app-net

Step 2: Launching Containers on the Custom Network
#

Launch a Redis database container:

docker run -d --name my-redis --network app-net redis:alpine

Launch a Node container connected to the same network:

docker run -d --name my-app --network app-net alpine sleep 3600

Step 3: Testing Embedded DNS Name Resolution
#

Ping my-redis by container name from inside my-app:

docker exec my-app ping -c 2 my-redis

Expected 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 ms

The 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!

docker - This article is part of a series.
Part 3: This Article