Production-Grade Docker Compose Patterns(Продакшн-патерни конфігурації Docker Compose)

1. Огляд концепції та системна проблема

Багато розробників використовують Docker Compose лише локально, вважаючи його "інструментом для розробки", а на продакшені намагаються розгортати важкі кластери або, навпаки, запускати все на хості вручну через pm2 або nohup:

• Без лімітів пам'яті один завислий процес витікає і викликає Linux OOM-killer, який вбиває базу даних.
• Логи одного контейнера за 3 місяці розростаються до 50 ГБ і забивають весь вільний простір кореневого розділу /, паралізуючи сервер.
• Контейнери знаходяться в одній спільній мережі bridge, тому зламаний веб-сервіс має прямий доступ до внутрішніх портів бази даних.

Production-Grade Docker Compose — це збірка перевірених інженерних патернів, які перетворюють один файл docker-compose.prod.yml на надійну, безпечну та катастрофостійку платформу.

2. Архітектурна таксономія та ментальна модель

┌─────────────────────────────────────────────────────────────┐
│              PRODUCTION DOCKER COMPOSE TOPOLOGY             │
├─────────────────────────────────────────────────────────────┤
│ 1. SEPARATED INTERNAL NETWORKS                              │
│    • `public-network`: Лише Traefik/Caddy ➔ Web App (Port 80/443)│
│    • `backend-network`: Лише Web App ➔ Postgres DB & Redis  │
│    ➔ База даних фізично ізольована від зовнішнього світу!   │
├─────────────────────────────────────────────────────────────┤
│ 2. RESILIENCE & LIFECYCLE CONTROLS                          │
│    • `restart: unless-stopped` (Автостарт після ребуту VPS) │
│    • Healthchecks: `test: ["CMD", "curl", "-f", "/health"]` │
│    • Depends_on with condition: `service_healthy`           │
├─────────────────────────────────────────────────────────────┤
│ 3. RESOURCE HARD CAPS (Preventing Host Crash)               │
│    • Memory limit: `max: 2G` | CPU: `1.5` cores             │
│    • Log Rotation: `max-size: 10m` | `max-file: 3`          │
└─────────────────────────────────────────────────────────────┘

3. Практичні інженерні сценарії в продакшені

01. Еталонний production-фрагмент для бази даних PostgreSQL

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB_FILE: /run/secrets/db_name
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_name
      - db_password
    volumes:
      - pgdata:/var/lib/postgresql/data
    networks:
      - internal-tier
    deploy:
      resources:
        limits:
          memory: 1536M
          cpus: "1.0"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

4. Підводні камені, типові помилки та безпека

• Публікація портів бази даних у світ: Використання директиви ports: ["5432:5432"] автоматично відкриває порт на всіх публічних інтерфейсах, обходячи навіть фаєрвол UFW (через специфіку Docker iptables). Використовуйте expose: ["5432"] або прив'язуйте порт суто до localhost: 127.0.0.1:5432:5432.
• Втрата даних через неіменовані томи (Anonymous Volumes): Якщо забути вказати іменований том (volumes: pgdata:/data), під час команди docker compose down -v база даних буде безповоротно знищена.

5. Стратегічний висновок для інженера 2026 року

Правильно налаштований Docker Compose — це швейцарський ніж практичного девопсу. Він забезпечує максимальну відмовостійкість без операційних витрат на Kubernetes, дозволяючи команді сфокусуватися на швидкості розвитку продукту.