Docker Networking
Docker Networking Overview — Bridge, Host, None, Overlay
Understanding how Docker isolates networks on a host.
Interview: A core concept in container systems architecture. Interviewers will test your understanding of docker network namespaces, local bridge ports, and the performance differences between bridge and host drivers.
Introduction
Containers are designed to be isolated, which includes their network environments. Docker achieves this using Linux **Network Namespaces**, creating isolated TCP/IP stacks for each container.
To allow containers to communicate with each other, the host machine, or external systems, Docker provides pluggable **Network Drivers**. These drivers determine how packet routing is configured on the host.
Why It Matters
Choosing the wrong driver can cause major issues: it can expose internal databases to the public internet, add network latency overhead, or prevent multi-node cluster configurations.
The Four Core Network Drivers
Docker ships with four primary built-in network drivers:
1. Bridge Network (Default)
Creates a private virtual subnet (e.g., 172.17.0.0/16) on the host managed by a virtual bridge interface (usually named docker0). Containers get their own private IP addresses and communicate via virtual ethernet (veth) cable pairs. External ports must be mapped.
2. Host Network
Bypasses network isolation completely. The container shares the host's network namespaces directly. If the containerized application binds to port 80, it binds directly to port 80 on the host's physical network card.
3. None Network
Places the container inside an isolated network namespace with only a loopback interface (127.0.0.1) and no external network card. Ideal for secure batch processes or calculations that must not touch external interfaces.
4. Overlay Network
Enables multi-host container communication. It builds a virtual subnet across different host nodes (using VXLAN tunnels), which is the underlying routing driver for Docker Swarm and Kubernetes cluster overlays.
Practical Example
Let's list our local Docker networks and inspect the configuration of the default bridge:
What just happened? We verified that the default bridge network creates a local private subnet. Any container started without network parameters automatically receives an IP allocation inside this range.
Quick Quiz
Q1: Which Docker network driver is best suited for high-throughput microservices where network latency must be identical to bare metal performance?
A) Bridge
B) Host
C) None
D) Overlay
Answer: B — Host networking bypasses all namespace routing overhead, writing packets directly to the host's network card.
Scenario-Based Challenge
Production Scenario:
You run multiple microservices inside containers on a single host. One of the services is a database container, and another is a web api container. You want the web api to talk to the database, but you want to make sure the database cannot be reached from the host's external network ports or external clients. Which network configurations should you apply?
View Solution
To achieve this secure isolation:
1. Deploy both containers on a private **User-Defined Bridge network** (e.g., docker network create my-secure-net).
2. Start both containers on this network:
docker run --network my-secure-net --name web-api ...
docker run --network my-secure-net --name database ...
3. **Crucial step:** **Do NOT** use the -p or --publish flags for the database container. By omitting port mapping, the database port is exposed *only* to other containers inside the virtual bridge network, leaving it completely hidden and unreachable from the host's physical network ports.
Interview Questions
1. How does Host networking affect port availability on a machine?
Because containers share the host's network stack directly, two containers using the Host network driver cannot bind to the same port. If both try to bind to port 8080, the second container will fail to start due to a port conflict.
2. What is the default docker network bridge interface called on a Linux host filesystem?
It is called docker0. You can inspect it natively in Linux commands using ip addr show docker0 or brctl show.
Production Considerations
Avoid using the default bridge network for production workloads. Default bridge networks share a single subnet where all containers can talk to each other without constraints, increasing attack vectors if one container is compromised. Create isolated user-defined networks to define logical firewall boundaries between microservice layers.