Running containers: ports, networks and volumes

An image is a sealed box. To be useful, a running container must receive traffic, talk to other services and store data that outlives it. Docker gives each of these a simple mechanism, and the same ideas reappear — at larger scale — in Kubernetes.

Publishing ports

Every container gets its own network namespace, so a server listening on port 80 inside a container isn’t reachable from outside by default. Publishing a port creates a forwarding rule from the host:

docker run -d --name web -p 8080:80 shop-web:1.4.2
#                          host:container

Now http://localhost:8080 on the host (or the host’s IP from elsewhere) reaches port 80 in the container. Only publish what should be reachable — a database, for instance, usually should not be.

Who can actually connect depends on two settings: how the port is published, and which address the app listens on inside the container. Try the combinations:

Networks: containers talking to containers

Containers attached to the same user-defined network can reach each other directly, using the container name as a hostname. Docker’s built-in DNS resolves it to the container’s current IP address, which changes every time the container is recreated.

docker network create shop-net
docker run -d --name db  --network shop-net -v pgdata:/var/lib/postgresql/data postgres:16
docker run -d --name web --network shop-net -p 8080:80 \
  -e DATABASE_URL=postgres://db:5432/shop shop-web:1.4.2

Step through the setup below: traffic from a browser to the web container, a private network, name-based discovery, and a volume.

Volumes: data that survives

A container’s file system is ephemeral: writes go to a thin writable layer that is deleted with the container. That’s perfect for stateless services and fatal for databases. The options:

Named volume

Storage managed by Docker (-v pgdata:/var/lib/postgresql/data). The usual choice for databases and persistent app data.

Bind mount

A host directory mounted into the container (-v ./src:/app). Handy in development for live code reloading.

tmpfs

In-memory storage that disappears when the container stops — for scratch files and sensitive temporary data.

Describing the whole app with Compose

Typing long docker run commands doesn’t scale. Docker Compose describes services, networks and volumes in one file:

services:
  web:
    image: shop-web:1.4.2
    ports:
      - "8080:80"
    environment:
      DATABASE_URL: postgres://db:5432/shop
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

docker compose up -d      # create the network, volume and both containers
docker compose logs -f web
docker compose down       # stop and remove containers (volumes are kept)

Compose creates a private network for the project automatically, so web reaches db by name.

Run the lifecycle yourself and watch which objects survive each command:

Compose is excellent on a single machine. When you need many machines, automatic recovery and zero-downtime releases, you need an orchestrator. Next: Kubernetes.