Container networking basics

bridge, host, none, and publishing ports.

When Docker starts, it creates networks, and every container joins one and gets its own IP address on it. The default network is a bridge — a private virtual network on the host — so containers can reach each other by IP, and reach the outside world, but are isolated from your host’s network unless you publish a port. Understanding the drivers is what turns container networking from mysterious to obvious.

User-defined networks give you names

The default bridge lets containers talk by IP, which is fragile because IPs change. Create your own bridge network instead and Docker adds automatic DNS: containers on that network can reach each other by container name. This is the key to multi-container apps — the web container connects to “db” by name, and Docker resolves it, no IPs or links required.

$ docker network create appnet
$ docker run -d --name db --network appnet postgres:16
$ docker run -d --name web --network appnet myapp:1.0
$ docker exec web ping -c1 db        # resolves by name, thanks to the user-defined network
PING db (172.18.0.2): 56 data bytes

Publishing versus internal traffic

Keep two ideas separate. Containers on the same user-defined network reach each other directly by name and port, with no -p needed — that traffic never touches the host. Publishing with -p is only for exposing a container to the outside world through the host. So a database that only your app talks to should not be published at all; only the public-facing web server needs -p.