How do Docker networks work in depth?

Question

Accepted Answer

Docker provides several **network drivers** (bridge, host, overlay, macvlan, none) for different connectivity needs, plus features like **user-defined networks** with DNS-based service discovery. Understanding networking in depth is important for connecting multi-container and multi-host applications correctly.

## Network drivers

```text
BRIDGE (default) → a private internal network on a single host; containers communicate;
  isolated from the host except via published ports. USER-DEFINED bridges add DNS
  (containers reach each other by name) — preferred over the default bridge.
HOST → the container uses the host's network stack directly (no isolation, no port
  mapping needed) — max performance, less isolation.
OVERLAY → spans MULTIPLE hosts → containers on different machines communicate
  (for Docker Swarm / multi-host clusters).
MACVLAN → gives a container its own MAC/IP on the physical network (appears as a
  physical device).
NONE → no networking (fully isolated).
```

## User-defined networks and service discovery

```bash
docker network create app-net
docker run -d --name db --network app-net postgres
docker run -d --name api --network app-net myapi
# → on a user-defined network, Docker's embedded DNS resolves container NAMES
#   the "api" reaches the database at hostname "db" → automatic service discovery
```

User-defined networks provide **automatic DNS-based service discovery** (containers reach each other by name) and better isolation than the default bridge — the recommended approach for multi-container apps.

## Network isolation and segmentation

```text
→ Containers can be placed on DIFFERENT networks to isolate them (segmentation):
  e.g. a frontend network and a backend network; only certain containers bridge both
→ Improves security (a container only reaches what it's networked with)
→ Published ports (-p) are the controlled boundary to the outside world
```

## Why it matters

Understanding Docker networking in depth is important for **connecting multi-container and multi-host applications correctly and securely**, so it's valuable practical knowledge beyond the basics.

Knowing the **network drivers** and their purposes — **bridge** (single-host container communication, with user-defined bridges being preferred), **host** (using the host network directly for performance, sacrificing isolation), **overlay** (spanning multiple hosts, essential for clustered/Swarm deployments where containers on different machines must communicate), **macvlan** (giving containers physical-network identities), and **none** (full isolation) — lets you choose the right networking for each scenario, from single-host apps to multi-host clusters.

Understanding **user-defined networks with DNS-based service discovery** (containers automatically reaching each other by name via Docker's embedded DNS) is particularly important, as it's the recommended approach for multi-container applications — enabling clean service-to-service communication by name without managing IPs, and providing better isolation than the default bridge.

Knowing about **network isolation and segmentation** (placing containers on different networks to control what can communicate, e.g. separating frontend and backend networks, with published ports as the controlled external boundary) is valuable for **security** — limiting a container's reachability reduces attack surface.

Since real applications involve multiple communicating containers (and sometimes span multiple hosts), and since correct, secure networking (choosing drivers, using service discovery, segmenting networks) is essential for connecting them properly, understanding Docker networking in depth — the drivers, user-defined networks with DNS service discovery, and network segmentation for security — is valuable, practically-relevant knowledge for building real containerized applications, important for both functionality (connectivity) and security (isolation) in multi-container and distributed deployments.