Q8: Docker Compose in Production & Staging: Service dependencies, healthchecks, and volume management. - DevOps & Kubernetes (50 Qs)

Architecture & Production Blueprint

In modern Docker Compose (Compose v2), orchestrating multi-container stacks requires declarative healthchecks and conditional start sequences to prevent startup race conditions (e.g., an API crashing because PostgreSQL has not finished its initial vacuum and socket binding).

yaml

version: '3.8'

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: app_user
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      POSTGRES_DB: app_production
    volumes:
      - postgres_data:/var/lib/postgresql/data
    secrets:
      - db_password
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app_user -d app_production"]
      interval: 5s
      timeout: 5s
      retries: 5
      start_period: 10s

  api:
    image: registry.example.com/api:v1.4.0
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      DATABASE_URL: postgres://app_user:app_password@db:5432/app_production
    depends_on:
      db:
        condition: service_healthy
    networks:
      - internal_net

volumes:
  postgres_data:
    driver: local

secrets:
  db_password:
    file: ./secrets/db_password.txt

networks:
  internal_net:
    driver: bridge

Critical Compose Best Practices

condition: service_healthy: Standard depends_on only waits for the container process to be spawned, not for the application inside to be ready. Healthcheck conditions guarantee readiness.
Named Volumes vs. Bind Mounts: Use named volumes for production database persistence because they are isolated from host OS permissions and managed natively by the Docker storage engine.
Docker Secrets: Injected into /run/secrets/ inside temporary ramdisk storage (tmpfs), preventing passwords from leaking into environment variables and build logs.