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:

DriverUse Case
bridge (default)Containers on the same host can communicate and external access needs port mapping
hostThe container shares the host's networking namespace (No isolation).
noneNo network connectivity (Fully isolated).
overlayEnable multiple-host networking for swarm services.
macvlanAssigns 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! 🐳

0
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

Om Prakash Pandey
Om Prakash Pandey