Docker and Docker Compose

Docker is straightforward until something is running in front of users. At that point the interesting questions are networking, storage and lifecycle, and none of them are covered by the getting-started guide.

Reach for Compose on a single host for almost any self-hosted application. It is declarative, the file lives in git, and it handles multi-service dependencies without any orchestrator to operate. Reach for something larger only when you genuinely need scheduling across machines.

The networking behaviour that surprises people is port publishing. Docker manipulates iptables directly, and its rules run before the ones UFW manages. A container published with -p 5432:5432 is reachable from the internet even when the firewall shows a default-deny policy. The fix is to bind published ports to loopback and add an explicit rule to the DOCKER-USER chain.

Storage catches people twice. Named volumes are invisible until you need to back one up, and a tar of a live database directory restores into a corrupt cluster. Databases must be dumped by their own tooling; file volumes can be copied.

Lifecycle is the third. Without a health check, docker compose up reports success the moment a container is created, which means a crash-looping deploy goes green. With one, --wait gives you a deploy step that fails when it should.

Everything here assumes Compose v2 and a recent Docker Engine, states versions explicitly, and verifies the result rather than asserting it.