Docker's Default Bridge Network

LEVEL 0

The Problem

You understand port mapping now. That solves the “external world → container” problem.

But what about container-to-container communication?

You run a web application in one container and a database in another container. The web container needs to connect to the database.

Without Docker networking, you’d have to:

Find the database container’s IP address
Hardcode it into the web container’s configuration
Every time you restart the database, its IP might change, breaking the web container

There must be a better way.

LEVEL 2

The Mechanics — The docker0 Bridge

The Mechanics

When Docker is installed, it creates a virtual bridge called docker0.

See the bridge:

ip link show docker0

You’ll see:

docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    link/ether 02:42:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

This is a virtual switch managed by the Linux kernel.

See bridge’s IP:

ip addr show docker0

You’ll see an IP like 172.17.0.1. This is the gateway for containers on this network.

How containers connect:

When you start a container without specifying a network, Docker:

Creates a veth pair (virtual ethernet cable)
Plugs one end into the container (appears as eth0)
Plugs the other end into the docker0 bridge (appears as vethXXXXXX)
Assigns the container an IP from the bridge’s subnet (e.g., 172.17.0.2)

List containers on the default bridge:

docker network inspect bridge

Under “Containers”, you’ll see all containers attached to this network with their IPs.

LEVEL 3

Container-to-Container Communication on the Default Bridge

Start two containers:

docker run -d --name web nginx
docker run -d --name db mysql:8

Find their IPs:

docker inspect web --format='{{.NetworkSettings.IPAddress}}'
# e.g., 172.17.0.2

docker inspect db --format='{{.NetworkSettings.IPAddress}}'
# e.g., 172.17.0.3

Test connectivity:

From the web container, ping the db container:

docker exec web ping -c 3 172.17.0.3

It works! They can reach each other.

But there’s a problem:

The default bridge doesn’t provide automatic DNS. You have to use IP addresses.

If you restart the db container, it might get a different IP. The web container’s configuration would need to be updated.

That’s why custom networks (next chapter) are better for most use cases.

LEVEL 4

Limitations of the Default Bridge

No automatic DNS:

On the default bridge, containers can’t resolve each other by name.

docker exec web ping db
# ping: db: Name or service not known

You must use IP addresses, which are fragile.

All containers share it:

Every container you start (without specifying a network) joins the default bridge. This means:

All your projects’ containers are on the same network
No network isolation between projects
Increased risk of accidental connections

Can’t be removed:

The default bridge is built-in. You can’t delete it or change its subnet easily.

Solution: Use custom networks (Chapter 8.4).