Intermediate

Zombie processes in your containers? Slow shutdowns? Your app shouldn’t run as PID 1. Here’s the simple fix. The problem When your app runs as PID 1, it has special responsibilities: Handle system signals (SIGTERM, SIGINT) Reap zombie processes Forward signals to child processes Most apps (especially Node.js, Python) don’t handle these well. The solution Add init: true to your service: services: app: image: node:20 init: true # Adds Tini as PID 1 command: node server.js Docker automatically injects a tiny init system (Tini) that handles PID 1 responsibilities properly. ...

Package your entire Docker Compose application as an OCI artifact and share it through any container registry. No more complex installation instructions. The basics Publish your Compose configuration as an OCI artifact: # Publish your compose.yml to a registry docker compose publish myusername/myapp:v1.0 # Users run it directly with oci:// prefix docker compose -f oci://docker.io/myusername/myapp:v1.0 up The compose.yml (and any included files) are stored as an OCI artifact alongside your container images. ...

Stop doing docker compose down && docker compose up for every code change. Docker Compose lets you restart individual services while keeping the rest running. The solution Restart just what changed: # Restart only the web service docker compose up -d web # Your database, cache, and queue keep running! This simple command saves minutes per restart. Your database keeps its data, Redis maintains its cache, message queues preserve their state. ...

Hardcoding IP addresses in your containers? Docker Compose provides automatic DNS-based service discovery. Each service can reach another using just the service name. How it works Docker Compose creates a default network and registers each container with an internal DNS server. The DNS name matches the service name in your compose.yml. services: web: image: nginx environment: # Just use the service name! API_URL: http://api:3000 DB_HOST: postgres api: image: myapi environment: DATABASE_URL: postgres://user:pass@postgres:5432/mydb postgres: image: postgres:15 No configuration needed. The web service connects to api using http://api:3000, and api connects to postgres using the hostname postgres. ...

“Connection refused” errors? The app starts before the database is ready. Here’s the fix. What doesn’t work This only waits for the container to start, not for it to be ready: services: app: depends_on: - db # Container starts, but database isn't ready yet What actually works Add health checks: services: db: image: postgres:16 environment: POSTGRES_PASSWORD: secret healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 10s timeout: 5s retries: 5 start_period: 10s app: image: myapp depends_on: db: condition: service_healthy # Now it actually waits for the database Common health checks PostgreSQL: ...