🍉 Meditations - Docker Networking

Welcome to the world of Docker networking! What seems like a complex and intimidating topic is, at its core, a series of elegant solutions designed to make your applications work reliably in any environment. Whether you’re running a simple app on your laptop or a massive service across a data center, understanding how Docker handles network traffic is key.

This guide will take you from the basics of single-host networking all the way to advanced multi-host architectures and the cutting-edge of container technology on new platforms like macOS.

⛰️ Part 1: The Foundation — Single-Host Networks

At its simplest, Docker networking is about providing a safe, isolated space for your containers while still allowing them to talk to the world. On a single machine, there are three main network types you’ll encounter.

The Bridge Network | The Default & Most Common

This is the network you’re using almost every time you run a container without specifying a network flag. It’s the standard for isolated containers on a single host.

How it works

• Docker creates a virtual software switch on the host, imaginatively named docker0.
• Each container gets its own isolated network stack, with a unique IP and MAC address, and connects to this virtual bridge.
• The host then acts as a router, performing NAT (Network Address Translation) to forward traffic between the containers and the outside world.

Routing & ARP

• From a LAN perspective, no one on your network sees your containers. They only see the host’s IP address.
• When a container sends a packet, its source IP is rewritten to the host’s IP by the NAT rules.
• When an external client needs to reach a container, they must hit the host’s IP on a specific published port (-p 8080:80), and the host forwards that traffic to the container’s private IP.

---

The Host Network | Zero Isolation, Maximum Performance

This network type is for when you need to squeeze out every bit of performance and don’t care about isolation.

How it works

• The container shares the host’s entire network stack.
• It doesn’t get its own IP address, and its processes bind directly to the host’s ports.

Routing & ARP

• There is no NAT.
• An application listening on port 80 inside the container is directly accessible on port 80 of the host’s IP.
• The host and the container are network-wise indistinguishable. This is great for high-performance apps but can lead to port conflicts if multiple containers try to use the same port.

---

Macvlan/IPvlan | Containers on Your LAN

These are advanced drivers for when you want your containers to behave like first-class citizens on your physical network, bypassing the host’s networking.

How it works

• Instead of a virtual bridge with NAT, these drivers connect the container’s virtual network interface directly to a physical interface on the host. Each container gets its own unique IP address from the same subnet as your LAN.

Routing & ARP

From a LAN perspective, these containers are discoverable and directly addressable.

• Macvlan gives each container its own unique MAC address, making it appear as a separate physical device on your network.
• IPvlan is similar, but all containers share the host’s MAC address, with traffic differentiated at the IP layer. This avoids flooding network switches with too many new MAC addresses.

---

🐸 Part 2: Scaling Up — Multi-Host Networks with Docker Swarm

Single-host networks are great for development, but modern applications are built to scale across many machines. This is where Overlay networks come in, forming the backbone of multi-host clusters like Docker Swarm.

The Overlay Network | The Magic of VXLAN

An overlay network creates a virtual Layer 2 network on top of a physical Layer 3 network. It’s like building a secure, private tunnel between multiple hosts.

How it works

• Docker uses a protocol called VXLAN (Virtual eXtensible LAN). When a container on Host A needs to talk to a container on Host B, the packet is encapsulated. This means the original Ethernet frame is wrapped in a new UDP packet, with the source and destination being the public IPs of the two hosts. The packet travels across the physical network, and the destination host unwraps it and delivers the original frame to the correct container.

Routing & VIPs

This is where the routing mesh and Virtual IPs (VIPs) come into play.

• VIPs (Internal)
  • Every service in a Docker Swarm gets a stable, internal VIP. Containers on the same overlay network can use the service name to reach this VIP, which then load balances traffic across all the container instances (tasks) of that service. This is only for inter-container communication.
• Routing Mesh (External)
  • This is Docker’s built-in Layer 4 load balancer. When you publish a port for a service, all hosts in the Swarm listen on that port. If an external client sends a request to any of these hosts, the routing mesh intelligently forwards the request to a healthy container running that service, regardless of where it is in the cluster. This is what provides out-of-the-box high availability.

⚡ Part 3: The Cloud & Local Host Dilemma

With the rise of non-Linux systems for development and cloud-based container orchestration, networking needs have evolved.

Docker Desktop on Mac/Windows

Docker Desktop is an application that runs on your Mac or Windows machine. It uses a single, persistent Linux virtual machine to run the Docker daemon. This is why you must publish ports to access your containers from your host. Its networking model is essentially a classic Docker bridge network running inside a VM.

Apple Containers (The New Kid on the Block)

Apple’s new, native containerization framework on Apple Silicon takes a different approach. It runs each container in its own lightweight, ephemeral Linux micro-VM.

• Networking
  • This is much more like the Docker bridge network. Each micro-VM has a dedicated private IP, and the macOS host performs NAT and port forwarding to and from the container. This model prioritizes isolation and performance but means you can’t access the containers directly from your LAN without explicit port forwarding.
• Comparison
  • The key difference from Docker Desktop is the architecture: one VM for every container versus one VM for all containers. Apple’s model offers better security and resource efficiency but lacks the mature tooling of Docker Compose and Swarm (for now).

Part 4: Beyond the Built-in Tools

While Docker’s native networking is powerful, there are other methods for load balancing, especially at scale.

• DNS Round-Robin
  • The simplest load balancing method. You add multiple IP addresses to a DNS record, and the DNS server rotates between them. It’s easy to set up but lacks server health checks, so it could send traffic to a failed host.
• Anycast Routing
  • A global-scale routing technique where a single IP address is announced from multiple locations. The network’s routing protocols automatically send traffic to the “closest” location, providing geographical load balancing and redundancy. This is not practical for a home network but is a cornerstone of how the internet’s largest services (like CDNs) operate.
• Dedicated Load Balancers
  • Whether a physical box or a cloud service (like Google’s Network Load Balancer), these are intelligent systems that perform active health checks and distribute traffic based on sophisticated algorithms like least connections or weighted round-robin.

Summary