How Does Docker Networking Work?
Understand Docker networking — bridge networks, container DNS, port publishing, host and overlay drivers — explained for DevOps interviews.
Expected Interview Answer
Docker networking connects containers using virtual network drivers — most commonly the bridge driver, which creates an isolated virtual network on the host where containers get their own IP addresses and can reach each other by container name via built-in DNS, while host and overlay drivers serve different isolation and multi-host needs.
By default, Docker creates a bridge network per host, and every container attached to a user-defined bridge network can resolve other containers on that same network by name through Docker’s embedded DNS server, without needing hardcoded IP addresses. Port publishing (-p 8080:80) maps a container’s internal port to a host port through iptables NAT rules, making the container reachable from outside the host, while unpublished ports remain reachable only from other containers on the same network. The host network driver removes network isolation entirely, giving a container direct access to the host’s network stack for maximum performance at the cost of isolation, and the overlay driver extends a virtual network across multiple Docker hosts, which is how Docker Swarm and similar multi-host setups let containers on different machines communicate as if local. Docker Compose automatically creates a dedicated bridge network per project, so services defined in one compose.yml can reach each other by service name out of the box.
- Containers discover each other by name via built-in DNS, no manual IP wiring
- Bridge networks isolate unrelated container groups from each other
- Port publishing controls exactly what is exposed to the outside world
- Overlay networks extend connectivity across multiple hosts for clustering
AI Mentor Explanation
Docker’s bridge network is like an internal team radio channel set up just for one squad’s dressing room, where every player can call another player by name and be heard, but outsiders cannot tune in. If the coach wants one specific message broadcast to the stadium public address system, that is like publishing a container port — deliberately opening one channel outward. Two different squads sharing the same ground but on separate radio channels cannot hear each other unless explicitly bridged. This keeps team communication clear and outsiders locked out unless intentionally let in.
Step-by-Step Explanation
Step 1
Create or use a bridge network
Docker Compose auto-creates a project bridge network; standalone containers can join docker network create networks.
Step 2
Attach containers
Containers on the same network get their own IP and can resolve each other by container/service name via Docker DNS.
Step 3
Publish ports selectively
-p host:container maps a port through NAT to make it reachable from outside the host.
Step 4
Choose the right driver
Use bridge for single-host isolation, host for direct performance, overlay for multi-host clustering.
What Interviewer Expects
- Understanding of the default bridge network and container name resolution via DNS
- Clear grasp of what port publishing does versus internal-only connectivity
- Awareness of host and overlay drivers and when each is appropriate
- Knowledge that Compose creates an isolated network per project by default
Common Mistakes
- Hardcoding container IP addresses instead of using DNS-based service names
- Assuming an unpublished port is reachable from outside the host
- Confusing the host network driver with the default bridge driver
- Not realizing containers on different Compose projects cannot reach each other by default
Best Answer (HR Friendly)
“By default, Docker gives containers their own private virtual network where they can find and talk to each other just by name, without us managing IP addresses manually. We only expose a container to the outside world when we explicitly publish a port, which keeps our internal services private while still letting us open exactly the door we need, like a web server’s port 443.”
Code Example
# Create an isolated bridge network
docker network create app-net
# Start a database, no port published (internal-only)
docker run -d --name db --network app-net postgres:16
# App container reaches the database by its name “db”
docker run -d --name api --network app-net -p 8080:8080 myapi:1.0
# Inside the api container: DATABASE_HOST=db resolves via Docker DNSFollow-up Questions
- What is the difference between the bridge and host network drivers?
- How does Docker resolve a container by name instead of by IP?
- What does an overlay network add for multi-host setups like Swarm?
- How would you isolate two groups of containers on the same host?
MCQ Practice
1. How do containers on the same user-defined bridge network find each other?
Docker runs an embedded DNS server so containers on the same user-defined network resolve each other by name automatically.
2. What does publishing a port with -p 8080:80 do?
Port publishing sets up NAT rules that forward traffic from the specified host port to the container port.
3. Which Docker network driver is designed to span multiple hosts?
The overlay driver creates a distributed virtual network across multiple Docker hosts, used by Swarm and similar clustering setups.
Flash Cards
Default Docker network driver? — The bridge driver, creating an isolated virtual network per host.
How do containers find each other by name? — Docker’s embedded DNS resolves container/service names on the same network.
What does -p 8080:80 do? — Publishes container port 80 to host port 8080 via NAT, exposing it externally.
Which driver spans multiple hosts? — The overlay network driver, used in Swarm and multi-host clustering.