Networking & storage

Networks: how containers find each other

Docker creates a Linux bridge (docker0) and gives each container a virtual interface and a private IP (by default from 172.17.0.0/16). Containers reach the internet through NAT on the host.

The important detail: create your own network. On a user-defined bridge network, Docker runs an embedded DNS server, so containers find each other by name. On the old default bridge they can't.

$ docker network create shopnet
$ docker run -d --name db  --network shopnet -e POSTGRES_PASSWORD=devonly postgres:16
$ docker run --rm --network shopnet alpine:3.20 nslookup db
Name:      db
Address:   172.18.0.2
$ docker run --rm --network shopnet postgres:16 pg_isready -h db
db:5432 - accepting connections

Your app's connection string becomes postgres://db:5432/...: no IP addresses anywhere. Docker Compose (next level) creates a network like this for every project automatically.

Publishing ports

Containers are unreachable from outside the host until you publish a port:

$ docker run -d --name web -p 8080:80 nginx:1.27            # host 8080 -> container 80, all interfaces
$ docker run -d --name admin -p 127.0.0.1:9000:80 nginx:1.27 # only from the host itself
$ docker port web
80/tcp -> 0.0.0.0:8080

EXPOSE in a Dockerfile is documentation only. It doesn't publish anything.

Exposing an app to other machines

"It works on my machine" and "my colleague can open it" are different things. Three layers must all allow the traffic:

$ docker run -d --name web -p 8080:80 nginx:1.27      # 1. publish on all interfaces
$ ss -ltnp | grep 8080
LISTEN 0 4096 0.0.0.0:8080 0.0.0.0:* users:(("docker-proxy",...))
$ sudo ufw allow 8080/tcp                              # 2a. Ubuntu with ufw
$ sudo firewall-cmd --permanent --add-port=8080/tcp && sudo firewall-cmd --reload   # 2b. RHEL family
$ hostname -I                                          # 3. the address to give your colleague
192.168.56.20 172.17.0.1

From the other machine: curl -I http://192.168.56.20:8080 should return HTTP/1.1 200 OK. Test from outside, not from the host itself: the host can reach its own published ports even when the firewall blocks everyone else.

Work through it in order when it fails:

1. Does it work inside the network? docker run --rm --network <net> curlimages/curl http://web:80 (tests the app itself).
2. Does it work on the host? curl localhost:8080 (tests publishing). If not, check docker port and that the app listens on 0.0.0.0 inside the container, not 127.0.0.1.
3. Does it work from another machine? If not, it's the firewall, the security group or routing.

Storage: data that survives

Anything a container writes goes into its writable layer, which disappears with docker rm. For data that must survive, mount storage:

$ docker volume create pgdata
$ docker run -d --name db --network shopnet -e POSTGRES_PASSWORD=devonly \
    -v pgdata:/var/lib/postgresql/data postgres:16
$ docker rm -f db                                     # container gone
$ docker run -d --name db --network shopnet -e POSTGRES_PASSWORD=devonly \
    -v pgdata:/var/lib/postgresql/data postgres:16    # data still there

The longer --mount syntax does the same and is clearer in scripts: --mount type=volume,source=pgdata,target=/var/lib/postgresql/data.

Recap

• Create a user-defined network; containers on it reach each other by name.
• -p host:container publishes a port on all interfaces unless you give an IP. Keep databases unpublished.
• Exposing to other machines = publish + firewall/security group + route. Test from the other machine, and put HTTPS in front of anything public.
• Named volumes for data, bind mounts for host files and config, tmpfs for scratch.
• The writable layer dies with the container. Anything important goes in a volume.