Network drivers and when to use them

Docker ships bridge, host, none, overlay and macvlan; pick a driver by who the container needs to talk to.

Every Docker network uses a driver that decides how containers are connected. A fresh Docker install has three networks: bridge, host, none.

Driver	Use when
`bridge` (default)	Several containers on one host need to talk to each other
`host`	You do not need network isolation from the host (process and filesystem stay isolated)
`overlay`	Containers/services on several Docker hosts need one shared network (Swarm)
`macvlan`	A container must look like a physical machine with its own MAC on the LAN (legacy apps, VM migrations)
`none`	Networking is off; only loopback remains

flowchart TD
  Q1{"Containers on several hosts?"} -- Yes --> OV["overlay"]
  Q1 -- No --> Q2{"Need own MAC/IP on the LAN?"}
  Q2 -- Yes --> MV["macvlan"]
  Q2 -- No --> Q3{"Need network isolation?"}
  Q3 -- No --> HO["host"]
  Q3 -- Yes --> BR["user-defined bridge"]

If docker run has no --network, the container joins the default bridge network (the docker0 interface on Linux).

Two common traps

Choosing overlay for containers on one host: a bridge is enough, and overlay needs Swarm and more setup.
Thinking macvlan connects several hosts like overlay: macvlan plugs a container straight into the physical network; it builds no virtual network between hosts.

Command	Meaning
`docker network ls`	List networks with driver and scope
`docker network inspect bridge`	Show subnet, gateway and attached containers

The model behind Docker networking

Docker's networking follows the Container Network Model: each container has a sandbox (its network namespace), joins networks through endpoints (virtual interfaces), and each network is implemented by a driver. A network's scope is local (one host, such as bridge) or swarm (cluster-wide, such as overlay); docker network ls shows it.

Third-party network plugins can add drivers, but Kubernetes does not use Docker's drivers at all: it uses CNI plugins such as Calico, Cilium, or Flannel, covered later in this track.

DNS options per container

Flag	Effect
`--dns 192.0.2.53`	Use a specific DNS server
`--dns-search example.com`	Search domain for short names
`--add-host api.local:192.0.2.20`	Add an entry to the container's `/etc/hosts`
`--hostname web01`	Set the container's hostname

On the default bridge, containers copy the host's /etc/resolv.conf; on user-defined networks they use the embedded DNS server, which still forwards to the same upstream servers.

Reaching the host from a container

Docker Desktop provides the name host.docker.internal, which resolves to the host. On Linux Engine you add it yourself with --add-host host.docker.internal:host-gateway. This is handy when a containerised app needs a database that runs directly on your laptop.

Picking drivers in real projects

Situation	Typical driver
Local development with Compose	User-defined bridge (created automatically)
Single production host running a few services	User-defined bridge plus a reverse proxy publishing 80/443
Several hosts with Swarm	Overlay
Network appliance or monitoring agent	Host
Legacy app that must appear on the office LAN	macvlan or ipvlan

Whatever the driver, publish only the ports users need, usually through one reverse proxy such as Nginx or Traefik, and keep databases on internal networks.