The Network Drivers

One Flag, Very Different Networks

So far every network you've created has quietly used the bridge driver - Docker's default private virtual switch. A driver is simply the underlying implementation a network uses; swapping it changes how containers connect to the world, without changing anything about how you write your app. Bridge covers almost every case in this track, but it's worth knowing the alternatives exist, because production infrastructure sometimes needs them:

Driver	What it does	When
`bridge`	private virtual switch + NAT (the default)	almost everything
`host`	container shares the host's network stack - no isolation, no `-p` needed	max network performance, port-scanning tools
`none`	no network at all	build jobs, security-sensitive batch work
`macvlan`	container gets its own MAC/IP on the physical LAN	legacy appliances that must see a "real" device
`overlay`	one virtual network spanning multiple hosts	Swarm/multi-host (Kubernetes has its own model)

$ docker run --network host nginx      # nginx binds host:80 directly
$ docker run --network none alpine     # loopback only

Warning: --network host means the container can reach everything the host can - localhost services, the metadata endpoint in cloud VMs, other containers' published ports. Treat it as a privilege, not a convenience.

Static addressing - firewalls and legacy systems sometimes require a fixed source IP. That needs a network with an explicit subnet:

$ docker network create --subnet 172.28.0.0/16 legacynet
$ docker run -d --network legacynet --ip 172.28.0.50 gateway