🐳 Docker Networking — The Ultimate Guide (With Hands-On Labs)¶

• https://huzaima.io/blog/connect-localhost-docker

• Docker networking is one of the most important topics for real-world microservices, DevOps, and system design interviews.

• networks define the communication rules between containers, and between a container and the host.

• ✅ Bridge network (default) By default, Docker uses a networking mode called "bridge" to create a virtual network interface on the host machine. Each container that runs on the host is assigned a unique IP address within this network, allowing them to communicate with each other.

• ✅ Container virtual interface & IP When a container is started, it is assigned a virtual network interface that connects to the host's Docker bridge network. By default, this interface is given an IP address from the Docker bridge network subnet. This IP address is not accessible from outside the Docker host

• ✅ Common network zonesIf containers are placed in the same network, they can automatically discover and communicate with each other by name.

• ✅ Private network zones If containers are placed in separate networks, they are isolated and cannot see each other unless you explicitly connect them.

This guide explains Bridge, Host, Overlay, DNS-based service discovery, and Port Mapping, followed by practical labs to learn everything hands-on.

📌 Why Networking Matters in Docker¶

Every container is isolated — it has:

• its own network interface

  • A Docker container gets a virtual network card created just for that container. This virtual card behaves like a real network interface on a computer.
  • It can send and receive network traffic independently.
  • It is isolated from the host and other containers unless you connect them.

• its own private IP

• its own routing table

• its own firewall rules

Docker creates virtual networks to make containers talk to:

• each other

• the host

• the outside world

Understanding these networks makes you better at:

• Microservices architecture

• API communication

• Reverse proxies

• Scaling applications

• Distributed systems

1️⃣ Bridge Network (Default & Most Common)¶

Bridge networking is Docker’s default network mode.

When you run a container normally:

docker  run  -d  nginx 

Docker automatically puts it on the default bridge network (bridge):

docker network inspect bridge 

172.17.0.2 

This IP is private — isolated from your host.

🔹 Why Use Bridge Network?¶

• Best for single-host deployments

• Provides strong isolation

• Great for local development

• Gives containers private IP addresses

• Allows container-to-container communication

🚩 But Better: Use Custom Bridge Networks¶

Default bridge does NOT provide DNS discovery.

You should always use custom bridge networks:

docker  network  create  <network-name>mynet  

Now run two containers:

docker  run  -d  --name  app  --network=mynet  nginx

docker  run  -d  --name  redis  --network=mynet  redis  

Now app can ping redis by name:

docker  exec  app  ping  redis 

✔ No need for IPs

✔ Automatic DNS discovery

✔ Perfect for microservices

✅ Connect containers to already created network -->¶

docker network connect <network-name> <container-name>

✅To see network of your container -->¶

docker inspect [containerName] -f "{{json .NetworkSettings.Networks }}"

• docker inspect by default outputs a large JSON object with all details of a container.

• Using -f (format) allows you to extract specific fields in a readable format.

• {{ ... }} → Go template syntax for inserting or evaluating values.

• .NetworkSettings.Networks → .NetworkSettings → The network-related settings of the container.

• .Networks → Contains a dictionary of all networks the container is connected to.

• json → Converts the value into JSON format, making it structured and easier to read.

✅To see containers in particular network¶

docker network inspect bridge/host/network name

2️⃣ Host Network (Fastest Performance)¶

In host networking, the container shares the host's network stack.

docker  run  --network=host  -d  nginx

• No port mapping required

• Nginx is directly available on host port 80

• Almost zero network overhead

🔹 Use Cases¶

• Performance-critical apps

• Monitoring agents

• Apps needing broadcast/multicast

🔹 Disadvantages¶

❌ No network isolation

❌ Container can override host ports

❌ Not recommended for general usage

3️⃣ Overlay Network (Multi-Host Networking)¶

This is used when you want containers across multiple servers to communicate.

Overlay networking requires Docker Swarm.

Create overlay network:¶

docker  network  create  -d  overlay  <myoverlay> 

Deploy services:

docker  service  create  --name  api  --network  myoverlay  nginx
docker  service  create  --name  db  --network  myoverlay  redis  

Containers across different machines can now communicate securely.

🔹 Use Cases¶

• Multi-node clusters

• Distributed systems

• Swarm or Kubernetes-style networking

• Scaling microservices horizontally

4️⃣ DNS-Based Service Discovery¶

(Critical for Microservices & Interviews)

Docker provides built-in DNS.

Containers on the same network can resolve each other by name, not IP.

Example:

# First create network

docker network create mynet

docker  run  -d  --name  user-service  --network=mynet  app-image

docker  run  -d  --name  order-service  --network=mynet  app-image  

Inside order-service:

ping user-service 

# Inside `order-service`, you can call:
http://user-service:8080 

✔ Automatically resolved

✔ No need for IP addresses

✔ Works on custom bridge & overlay networks

This is the foundation for microservice communication.

5️⃣ Port Mapping — Exposing Containers to the Host¶

By default, containers are isolated.

💡No port mapping required for Host Network Mode

To expose a port:

docker run -p 8080<host port>:3000<container port> app  

Traffic flow:

Client → Host(8080) → Docker NAT → Container(3000)  

📌 Why Port Mapping Exists¶

• Because containers are in a private network.
• Without -p, the app is NOT reachable from outside.
• This is a frequently asked interview question.

🧪 Hands-On Lab1: Bridge Network + DNS Discovery¶

Step 1 — Create network:¶

docker  network  create  appnet  

Step 2 — Run containers:¶

docker  run  -d  --name  backend  --network=appnet  nginx

docker  run  -d  --name  database  --network=appnet  redis  

Step 3 — Ping by name:¶

docker  exec  backend  ping  database

docker  exec  -ti  <container-name-A>  ping  <container-name-B>

✔ Shows container-to-container communication

✔ Uses DNS discovery

🧪 Lab 2: Host Network Mode¶

No port mapping required for Host Network Mode. Now, Run Nginx using host network:

docker  run  --network=host  -d  nginx 

Now visit:

http://localhost 

🧪 Lab 3: Port Mapping (Host → Container)¶

Run an Express app:

docker  run  -p  5000:3000  myapp  

Access:

http://localhost:5000 

Check internal ports:

docker  exec  <id>  netstat  -tulnp

🧪 Lab 4: Multi-Host Overlay Network¶

Initialize swarm:

docker  swarm  init 

Create overlay network:

docker  network  create  -d  overlay  globalnet  

Deploy two services:

docker  service  create  --name  api  --network  globalnet  nginx

docker  service  create  --name  cache  --network  globalnet  redis 

Check communication across nodes (if you have multiple machines):

docker  exec  -it  <api-task>  ping  cache 

This is how Kubernetes-like networking works.

🧪 Lab 5: Inspect Networks¶

docker  network  ls

docker  network  inspect  bridge

docker  network  inspect  appnet 

Find:

• IP addresses

• DNS config

• Connected containers

• Routes

🔐 Interview Questions & Answers (Short, Crisp)¶

❓1. Why do we need -p in Docker?¶

Because containers sit in a private network and need explicit port forwarding to host.

❓2. What's the difference between bridge and host networking?¶

### ❓3. How do containers communicate?

By:

• internal private IP

• DNS discovery using container names

❓4. What is an overlay network?¶

A distributed virtual network for multi-host communication (Swarm mode).

🏁 Final Summary¶