Overlay Networks

Every network so far has been a Linux bridge on one host. An overlay network spans multiple hosts: it tunnels container traffic between machines over VXLAN so containers on different physical hosts share one virtual network and resolve each other by name, exactly as if they were on the same bridge. The address and the name resolution work across the machines.

This is the deliberate edge of this book — the moment networking stops being single-host. The honest move is to name the concept, show where the boundary is, and point across it to orchestration, not to half-teach a multi-host system this course was never scoped to cover. Docker builds and runs containers on one host; orchestrators run them across many.

container on host A

→

VXLAN tunnel

→

container on host B

The Single-Host Boundary

A bridge network connects containers on one machine, and that is the entire scope of everything in topics 39 through 44. The instant containers must talk across machines — web on one server reaching db on another — a bridge is not enough, because a bridge is host-local. You need a network that exists on several hosts at once, which is what an overlay provides and a bridge cannot.

VXLAN Tunneling, Briefly

An overlay encapsulates each container's ethernet frame inside a UDP packet — VXLAN — and sends it to the host running the destination container, where it is decapsulated and delivered. The containers behave as if they are on one LAN even though their hosts may sit in different racks or regions. The encapsulation is what makes the trick work, and it is also what makes an overlay heavier than a plain bridge.

Overlay Needs a Control Plane

An overlay does not exist for plain docker run. It requires Docker Swarm — or another orchestrator — to manage which container runs on which host, distribute the network state to every machine, and assign addresses across the cluster. Something has to coordinate the multiple hosts, and that something is the control plane an orchestrator provides. Without it, there is no overlay to join.

The Hand-Off to Orchestration

Multi-host networking is one piece of a much larger problem: scheduling containers onto machines, scaling them, health-checking them, and rolling out new versions. Single-host Docker does not solve that problem and does not pretend to. Swarm's overlay (Chapter 12, topic 75) and Kubernetes' cluster networking (Chapter 12, topic 76) are where multi-host networking is treated properly, as part of orchestration rather than as a networking flag bolted onto docker run.

Why Driftwood Stays Single-Host Here

Driftwood's three containers on driftwood-net are a one-machine bridge topology, and that is the whole scope of this book. Scaling web across several machines is an orchestration decision — where do the replicas run, how does traffic spread across them, what happens when a host dies — and it is deferred to Chapter 12, not retrofitted onto a bridge here. The bridge topology you built in topic 40 is the finished single-host shape; the multi-host version is a different course's worth of machinery.