Docker Networking Guide for Developers


In our Docker journey so far, we’ve built and run containers for everything from Express applications to lightweight BusyBox shells. But one thing we haven’t really explored in detail is this: how do Docker containers actually connect to the internet or to each other?
In this blog, we'll break down Docker networking in a developer-friendly way.
Let’s dive in.
🧪 Does My Container Have Internet Access?
Let’s find out the answer by actually doing it. We'll run a BusyBox container and try to ping Google:
docker run --rm -it busybox sh
Once inside the container:
ping google.com
Boom! We get a response. That means our container has internet access ✅
This is made possible by Docker's default bridge network.
🧠 What is the Bridge Network?
By default, Docker assigns containers to a bridge
network. This creates a virtual Ethernet interface (veth) on your host machine, and your container connects through it like this:
Run this command to view it:
ifconfig
You’ll see interfaces like eth0
or docker0
— that’s your container being connected to the host’s network via Docker’s bridge.
⚙️ Docker Networking Types (with Cheat Sheet)
Docker supports different network drivers. Here’s a quick summary:
Driver | Use Case |
bridge (default) | Containers on the same host can communicate and external access needs port mapping |
host | The container shares the host's networking namespace (No isolation). |
none | No network connectivity (Fully isolated). |
overlay | Enable multiple-host networking for swarm services. |
macvlan | Assigns a real MAC address to the container (acts like a physical device). |
🛠️ Essential Docker Network Commands
Let’s get hands-on. These are the commands you’ll use often:
🔍 List all networks
docker network ls
🔎 Inspect a specific network
docker network inspect <network_name>
🧱 Create a custom bridge network
docker network create <network_name>
🚀 Run a container in a custom network
docker run --network <network_name> --name <container_name> -d <image_name>
🔗 Connect an existing container to a network
docker network connect <network_name> <container_name>
🧼 Disconnect a container from a network
docker network disconnect <network_name> <container_name>
🗑️ Remove a network
docker network rm <network_name>
🤝 Container-to-Container Communication
Let’s try it out!
# Create custom bridge network
docker network create my-bridge-network
# Start container 1 using nginx
docker run -d --name container1 --network my-bridge-network nginx
Then check if container 1 is up and running:
docker ps
# Start container 2 using alpine (lightweight Linux)
docker run -d --name container2 --network my-bridge-network alpine sleep 3600
# From container2, ping container1 using container name
docker exec -it container2 ping container1
If you're using Docker's default bridge, container names won’t resolve—only IPs work. But in custom bridge networks, Docker gives you automatic DNS resolution. 🎉
🖥️ Host Networking Example
docker run -d --network host nginx
This container now shares your host machine’s IP address. It’s faster and leaner, but there’s no isolation — use with caution!
🔐 MacVLAN Networking (Assigning Real MAC + IP)
Want your container to appear like a physical device on the network?
docker network create -d macvlan I am running a few minutes late; my previous meeting is running over.
--subnet=192.168.1.0/24 \
--gateway=192.168.1.1 \
-o parent=eth0 \
my-macvlan
This sets up a network where containers have their own MAC address and can appear directly on your LAN. Great for advanced setups or legacy systems that require MAC-level identity.
📚 Don't Memorize, Understand
Remember, it's not about memorizing every Docker command. It's about understanding the structure of commands:
docker network <action> [options]
For example:
docker network ls
docker network create <nework_name>
docker network inspect <network_name>
docker network connect <nework_name> <container_name>
They're all intuitive once you get the hang of it.
📝 Summary
Docker networking isn’t as scary as it looks. Just remember:
Bridge is the default.
Custom bridge gives DNS resolution.
Host removes isolation (be careful).
None means no network.
Macvlan makes your container feel like a physical device.
And most of all: don’t overthink it. For 95% of developer use cases, custom bridge networks with simple port mappings are more than enough.
If you found this helpful, please share it with your fellow developers.
Thanks for reading! 🙌
Happy learning! 🐳
Subscribe to my newsletter
Read articles from Om Prakash Pandey directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
