Manage Docker Networks

You've built Docker images, run containers, and maybe even volume-mounted your code. But put two containers on the same host and they can't talk to each other — unless you understand Docker networking. Out of the box, every container gets an IP, but how they find each other, whether they're isolated, and how they reach the outside world depends entirely on the network you attach them to. This lesson gives you the mental model and the CLI commands to manage Docker networks basics with confidence.

The problem this lesson solves

When you run docker run nginx, Docker automatically creates a 'bridge' network, the default bridge called bridge (older systems) or docker0. That sounds helpful — and it is — but the default bridge has limits:

• Containers on the default bridge can only communicate by IP address, not by container name.
• There is no built-in DNS that resolves container names to IPs.
• All containers on the default bridge can talk to each other, which is often too permissive.
• You have no control over subnet or IP range.

As soon as your project involves multiple services — a web server and a database, or a microservice with a message queue — you need custom networks to enable clean, predictable communication. That's the problem: default networking is a trap for the unwary, and manual IP management is fragile.

Core concept / mental model

Think of a Docker network as a virtual switch or a virtual LAN (VLAN). Containers plugged into the same virtual switch can see each other. Containers on different virtual switches are completely isolated unless you explicitly connect them.

Key definitions

• Bridge network (default): A private internal network on your host. Containers attached to the same bridge can communicate. The default bridge (docker0) uses NAT to allow outbound traffic to the host and internet, but inbound traffic isn't forwarded from the outside.
• Host network: The container shares the host's network stack — no network isolation, full performance, but risky.
• Overlay network: Spans multiple Docker hosts (nodes) in a swarm. Containers on different hosts can communicate as if they were on the same virtual switch.
• Macvlan / IPvlan: Assign a MAC/IP from the physical network directly to the container — useful for legacy apps that expect to be on the same subnet.

Pro tip: For most multi‑container apps, a user‑defined bridge network is the sweet spot: automatic DNS resolution, isolation, and clean IP management.

How it works step by step

1. Create a custom bridge network docker network create my-net This creates a new bridge network with a private subnet (typically 172.x.0.0/16). Docker also creates a DNS resolver that maps container names to their IPs.

2. Start containers on that network docker run -d --name web --network my-net nginx The container gets an IP within my-net's subnet. Docker registers the container name 'web' in the network's DNS.

3. Connect a second container docker run -d --name db --network my-net postgres Now web can reach db using the hostname db (or web from db). No IP hunting.

4. Connect an existing container If a container already exists on the default bridge, you can attach it to your custom network without restarting: docker network connect my-net existing-container The container now has two interfaces: one on the default bridge, one on my-net.

5. Disconnect a container docker network disconnect my-net existing-container Removes the interface from that network.

6. Inspect networks docker network inspect my-net shows all containers attached, subnet, gateway, and more.

Hands-on walkthrough

Let's build a realistic scenario: a Flask web app talking to a Redis cache. Both must communicate securely and predictably.

Step 1: Create a custom bridge network

docker network create app-net

Expected output (your ID will differ):

7a3f9b2c1d0e...

Step 2: Run Redis on app-net

docker run -d --name redis-cache --network app-net redis:alpine

Check that it's running:

docker ps --filter name=redis-cache

Step 3: Run a simple Python app on the same network

# app.py
import redis
import time

cache = redis.Redis(host='redis-cache', port=6379, decode_responses=True)
cache.set('visits', 1)
print(f"Visits: {cache.get('visits')}")

# Build and run the container
docker run -d --name web-app \
  --network app-net \
  -v $(pwd):/app \
  python:3.10-slim \
  python /app/app.py

Check the logs:

docker logs web-app
# Output: Visits: 1

Step 4: Connect a container to multiple networks

Sometimes you need a container that is both on a backend network (for databases) and a frontend network (for reverse proxy). Create a second network and connect:

docker network create frontend-net
docker network connect frontend-net web-app

Now web-app has two IPs and can communicate with containers on both networks.

docker inspect web-app --format '{{range .NetworkSettings.Networks}}{{.IPAddress}} {{end}}'
# Output: 172.18.0.3 172.19.0.2  (different IP for each network)

Pro tip: Use docker network ls to list all networks. Use docker network prune to delete unused networks, but be careful — it removes all networks not used by at least one container.

Compare options / when to choose what

Rule of thumb: Start with a user‑defined bridge for any project with more than one container. Only switch to host or macvlan when you have a concrete need.

Troubleshooting & edge cases

Container can't reach another by name

• Symptom: ping other-container fails.
• Cause: The container is on the default bridge, which has no automatic DNS.
• Fix: Create a user‑defined network and attach both containers to it.

Two containers can't communicate even on the same network

• Check: docker network inspect <network> to verify both are listed. If a container shows no IP, it may be misconfigured.
• Fix: Disconnect and reconnect: docker network disconnect <net> <container> then docker network connect.

Port already allocated (binding conflict)

• Symptom: docker: Error response from daemon: driver failed programming external connectivity...
• Cause: Another container or host process is already listening on that port.
• Fix: Use a different host port (e.g., -p 8080:80 instead of -p 80:80) or stop the conflicting container first.

Containers on different user‑defined bridges can't talk

• This is by design — they are isolated.
• Solution: Create a common network and connect both containers to it, or use a reverse proxy (like Traefik / Nginx) as a router.

docker network prune removed a network you needed

• Prevention: A network is pruned only if no container is attached to it. If one container is stopped but still referenced, the network survives. Use docker network ls --filter dangling=true to preview.

What you learned & what's next

You now understand the three core Docker network modes (bridge, host, overlay) and how to:

• Create custom bridge networks (docker network create)
• Attach containers at start or on the fly (--network, docker network connect)
• Inspect network topology (docker network inspect, docker inspect with format)
• Compare when to choose each type
• Troubleshoot common connectivity issues

These skills are the foundation for running multi‑service applications, which is exactly where Docker Compose shines. In the next lesson, you'll learn how to define all your services, networks, and volumes in a single docker-compose.yml file — no more typing long docker run commands. You'll also see how Compose automates network creation with DNS resolution out of the box.

Ready to simplify your workflow? Let's go.