Hardening Production Multi-Container Topologies with Docker Compose v2
restart: always is not a resilience strategy. It is a retry loop that hides an ordering bug until the night it doesn't. A Compose stack that survives production treats startup order, network reachability, credentials, and resource ceilings as explicit, testable contracts. This piece takes a typical four-service stack (Nginx, a FastAPI app, PostgreSQL 16, Redis 7) and hardens each of those contracts in turn.
1. The Fragility of Naive Stacks
Most Compose files start life like this:
services: api: build: ./api ports: ["8000:8000"] depends_on: [postgres, redis] postgres: image: postgres:16-alpine environment: POSTGRES_PASSWORD: devpassword redis: image: redis:7-alpine ports: ["6379:6379"]
It works on a laptop and fails in four predictable ways elsewhere:
- Bootstrap latency. On an empty volume, the Postgres entrypoint runs initdb, starts a temporary server, applies init scripts, stops it, and starts the real server. That takes seconds. Short-form depends_on only waits for the container to start, so the API's...
Copyright of this story solely belongs to hackernoon.com. To see the full text click HERE
