🌐 Docker Networking A2Z – Masterclass for Developers & DevOps

📦 What is Docker Networking?

🧠 Docker networking allows containers to communicate with:

• Each other 📞
• The host machine 🖥️
• The external internet 🌍

Docker automatically creates networks and connects containers based on mode.

🧠 Key Terms

🌉 Bridge Mode (Default)

🧱 Bridge network is like a private switch where containers talk to each other.

🧵 Created Automatically:

docker network ls 

Look for: bridge

🛠 How it works:

• Containers get private IPs (like 172.17.0.x)
• They can access the internet via NAT
• But cannot be accessed from outside without -p port mapping

🧪 Try it:

docker run -d --name container1 nginx docker run -d --name container2 busybox sleep 9999 # Ping container1 from container2 by IP docker exec -it container2 ping 172.17.0.x 

❌ By default, they can’t talk by name unless in custom network

🧱 Custom Bridge Network (Recommended)

🎯 Custom networks support container name resolution (DNS)!

📦 Create a custom bridge:

docker network create my-network 

🚀 Launch containers into it:

docker run -d --name app1 --network my-network nginx docker run -it --name app2 --network my-network busybox sh 

Now, inside app2:

ping app1 

✅ Works! 🎉 Containers can ping by name!

✅ Why Use Custom Bridge?

🏠 Host Network Mode

Shares the host’s network stack directly.

🚀 Use:

docker run --network host nginx 

✅ Pros:

• 🔥 Super fast — no NAT or port mapping
• 🧪 Useful for monitoring tools (Prometheus, Grafana)

❌ Cons:

• ⚠️ No isolation
• 🧱 Cannot run 2 containers on same port!

🚫 None Network Mode

Container has no networking at all.

docker run --network none busybox 

• 🔒 Fully isolated
• Useful for security testing or offline compute jobs

🌐 Overlay Network (Advanced – Docker Swarm)

🕸️ Enables containers on different hosts to communicate

Use Case:

• Docker Swarm
• Distributed Microservices

docker network create --driver overlay my-overlay 

Requires Swarm mode:

docker swarm init 

🔌 Connect Containers to Multiple Networks

docker network create frontend docker network create backend docker run -d --name api \ --network frontend \ --network-alias api \ nginx 

Then attach to another network:

docker network connect backend api 

🧠 Inspect a Network

docker network inspect my-network 

Shows:

• Container list
• IPs
• Aliases
• Subnets

🧰 CLI Recap

🎯 Best Practices for Docker Networking

🧾 Summary Table

🧠 Final Analogy

Bridge network = Private Wi-Fi router 🌐
Custom bridge = Guest Wi-Fi with name tags 🏷️
Host mode = Ethernet cable directly into host 💻
None mode = Airplane mode ✈️
Overlay = Corporate VPN connecting multiple offices 🏢🏢

🌐 Docker Networking Overview

📦 Container networking is the foundation of container communication. Every container is equipped with a network interface, IP address, routing table, DNS config, etc.

✅ By default, containers can:

• Make outbound connections (internet)
• Be connected to default or custom networks
• Be isolated or exposed, depending on the configuration

🚦 Types of Docker Network Drivers

🧱 Default Bridge Network vs 🧩 User-Defined Bridge Network

Both are based on the bridge driver, but they differ significantly in features & behavior.

🧱 Default bridge Network

Created automatically by Docker when installed.

docker network ls # OUTPUT will contain: # bridge bridge local 

Example:

docker run -d --name app1 nginx docker run -d --name app2 busybox sleep 999 

📛 Limitations:

🧩 User-Defined Bridge Network

Created with:

docker network create my-custom-net 

✅ Advantages:

⚖️ Comparison: Default vs User-Defined Bridge

🔍 Inspecting Networks

docker network inspect my-custom-net 

📊 Output includes:

• Subnet
• Gateway
• Connected containers
• DNS aliases

🧪 Example Test

1. Default Bridge (no DNS):

docker run -d --name alpha nginx docker run -it --rm busybox # ping alpha – ❌ fails 

2. User-defined Bridge:

docker network create testnet docker run -d --name alpha --network testnet nginx docker run -it --rm --network testnet busybox # ping alpha – ✅ works 

🧱 Other Drivers – Quick Overview

🔐 When to Use What?

🎯 Key Docker Networking Commands Cheat Sheet 🐳

✅ Real-World Example: Create and Use a Custom Bridge Network

# 1️⃣ Create a custom bridge network docker network create my-bridge # 2️⃣ Run a container (nginx) attached to that network docker run -d --name my-app --network my-bridge nginx # 3️⃣ Run another container (busybox) in the same network docker run -it --name client --network my-bridge busybox # 4️⃣ Inside 'client', you can ping 'my-app' by name ping my-app 

🎉 Result: client can resolve and communicate with my-app using container name thanks to Docker’s internal DNS in custom bridge networks.

🧠 Bonus Tip: Disconnect & Reconnect

docker network disconnect my-bridge my-app # Disconnect from network docker network connect my-bridge my-app # Reconnect to same or new network 

🧠 Final Takeaways

• 🧱 Default bridge is basic → no name resolution, low security
• 🧩 User-defined bridge is preferred for real-world apps
• 🌍 Use overlay for distributed microservices
• 🧰 Know when to use each driver to optimize performance & security
• 🧪 Always test communication with tools like ping, curl, netcat

🌐 Docker Networking Logic – Container Communication

✅ 1. User-Defined Bridge Network = Container DNS Heaven 🧠

🧩 When you create a user-defined bridge network, Docker automatically enables an internal DNS service.

📦 That means containers can talk to each other by name! 🎉

Example:

docker network create my-net docker run -d --name db --network my-net mongo docker run -d --name web --network my-net node-app 

🎯 Now, inside web, you can:

ping db 

✅ Boom! It works because Docker auto-resolves db → container's IP inside the same network.

❌ 2. Default Bridge Network = Only IP-Based Access 🔢

Containers in the default bridge cannot resolve each other by name.

Example:

docker run -d --name app1 nginx # default bridge docker run -it --name app2 busybox # default bridge 

Inside app2:

ping app1 # ❌ FAILS 

Why? Because DNS resolution doesn’t work in the default bridge without using the old --link option (now deprecated 🚫).

📛 Legacy --link (Avoid Using It)

docker run -d --name db mongo docker run -d --name web --link db node-app 

⚠️ Works — but deprecated & removed in newer Docker versions.

🔄 3. Containers in Different Networks = 🚫 No Communication

Example:

docker network create net-a docker network create net-b docker run -d --name app1 --network net-a nginx docker run -d --name app2 --network net-b busybox 

Inside app2:

ping app1 # ❌ FAILS – isolated networks 

🧱 Networks are isolated by default. Containers on different bridge networks cannot talk to each other unless you connect one container to both using:

docker network connect net-a app2 

Now, app2 belongs to both networks!

🧠 Real-World Analogy

🧪 Recap – Container Communication Matrix

✅ Summary

• 🧩 User-defined networks allow name-based communication via Docker's built-in DNS.
• 🧱 Default bridge networks don't support DNS — only IPs.
• 🔐 Each network is isolated — containers inside a network can talk, but can't reach containers in other networks unless manually connected.
• 💡 Use docker network connect to join a container to multiple networks if needed.

🌐 Overview of Advanced Docker Network Drivers

1️⃣ 🌍 Overlay Network

🔍 What It Is:

Allows containers on different Docker hosts to securely communicate as if they were on the same LAN.

💡 Requires Docker Swarm (or other orchestrators).
Creates an encrypted VXLAN tunnel between hosts.

🧠 Real-world Analogy:

Like a VPN that connects branch offices (containers) across cities (hosts).

✅ Use Cases:

• Multi-host microservices
• Docker Swarm services
• HA + distributed architecture

🚀 How to Use (with Swarm):

# 1. Initialize Swarm docker swarm init # 2. Create overlay network docker network create --driver overlay my-overlay # 3. Deploy service to use overlay docker service create \ --name webapp \ --replicas 3 \ --network my-overlay \ nginx 

🔐 Key Features:

2️⃣ 🪪 Macvlan Network

🔍 What It Is:

Allows containers to appear as physical devices on the host’s network, each with their own IP and MAC.

💡 The container bypasses Docker’s NAT, appearing directly on your LAN.

🧠 Real-world Analogy:

Like plugging a new computer (container) directly into your office switch with its own IP.

✅ Use Cases:

• Legacy apps that require static IPs or MACs
• IoT, embedded, or bare metal simulation
• When containers must be reachable from the LAN directly

🚀 How to Use:

# 1. Create macvlan network docker network create -d macvlan \ --subnet=192.168.1.0/24 \ --gateway=192.168.1.1 \ -o parent=eth0 \ macvlan-net # 2. Run a container on that network docker run -d --name myrouter \ --network macvlan-net \ busybox sleep 3600 

📌 parent=eth0: your physical host’s network interface

⚠️ Limitations:

🛠 Tip to Enable Host ↔ Container Communication (Workaround):

Create a dummy interface on the host:

ip link add macvlan-shim link eth0 type macvlan mode bridge ip addr add 192.168.1.200/24 dev macvlan-shim ip link set macvlan-shim up 

3️⃣ 🧬 IPvlan Network

🔍 What It Is:

Similar to macvlan, but no extra MACs per container.
All containers share host’s MAC, just get different IPs.

⚙️ More compatible with cloud and DHCP setups where duplicate MACs are not allowed.

🧠 Analogy:

Multiple workers using one ID card (MAC) but different phone numbers (IP).

✅ Use Cases:

• Performance-sensitive systems
• Cloud infra with MAC restrictions
• Advanced network routing with minimal overhead

🚀 How to Use:

docker network create -d ipvlan \ --subnet=192.168.1.0/24 \ --gateway=192.168.1.1 \ -o parent=eth0 \ ipvlan-net docker run -it --rm --network ipvlan-net alpine 

🧪 IPvlan supports two modes:

• l2: Same subnet, like macvlan
• l3: Different subnet, routing via host

✅ Benefits:

📊 Advanced Network Drivers Comparison Table

🔐 Security Considerations

🔁 When to Use What?

🧠 Summary

• overlay: Best for Swarm, cross-node services, scalable infra
• macvlan: Best for LAN visibility, legacy hardware, IP-bound apps
• ipvlan: Best for performance and controlled environments (e.g., cloud)

🚫 Docker none Network Driver – Ultimate Guide

❓ What is the none Network?

The none network is a special Docker network driver that completely disables networking for a container.

🚫 No IP address
🚫 No routing
🚫 No DNS
🚫 No internet access
🚫 No communication with host or other containers

🔐 Use Case:

When you want your container to run in complete isolation, especially for:

• ✅ CPU-intensive or file-only tasks
• ✅ Secure environments with no external communication
• ✅ Containers that interact only via volume sharing or IPC
• ✅ Avoiding network-related attacks (like SSRF, port scanning, etc.)

🧠 Real-World Analogy

It’s like putting a person in a soundproof, windowless room 🧍‍♂️🔇
They can compute, read, or write files – but cannot talk or hear the outside world.

🧪 How to Use It

docker run -it --rm --network none alpine 

Then inside the container:

ping google.com # ❌ Fails ip addr # Shows no IP 

✅ The container runs, but it’s completely cut off from any kind of networking.

🔍 Check from the Host

docker inspect <container-id> | grep -i "NetworkMode" # Output: "NetworkMode": "none" 

🧰 Useful Scenarios

📛 Warning

• You cannot ping, curl, apt update, or download anything inside containers using --network none
• Any tools that require internet or inter-container access will fail
• It's not usable for most microservices or web APIs

🧠 Tip: Combine with Volumes or IPC

If you want to exchange data without a network:

# Create a shared volume docker volume create shared-data # Use it with the isolated container docker run -it --rm --network none -v shared-data:/data alpine 

✅ This lets you read/write to shared storage without needing any network access.

🧾 Summary Table

🔐 Final Verdict

If you need absolute network isolation, --network none is your zero-trust go-to option.
It’s perfect for:

• 🔐 Security-first workloads
• 🧪 Testing internal-only logic
• 🚫 Disabling all remote calls