Docker Compose в продакшене: честный разговор

Где Compose в проде — норм, а где пора переходить на оркестратор. И пять правил, если оставляем.

---

Docker Compose — отличный инструмент для разработки, но «у нас так в проде стоит» — отдельный жанр трагедии. Разберем, где compose оправдан, а где пора переходить на оркестратор.

Когда Compose в проде — норм

Одиночный сервер на 3–10 сервисов, который не планируется масштабировать: лендинг, внутренний инструмент, gateway. Compose дает:

• простоту — один файл описывает всю систему
• воспроизводимость окружения
• docker compose up -d вместо десятка systemd-юнитов

services:
  app:
    image: app:1.4.2
    restart: unless-stopped
    depends_on:
      - db
    environment:
      DATABASE_URL: postgres://app:pass@db:5432/app
  db:
    image: postgres:16
    volumes:
      - dbdata:/var/lib/postgresql/data

volumes:
  dbdata:

Когда пора уходить

• Нужен горизонтальный масштабирование реплик
• Требуется автоскейлинг и self-healing по ресурсам
• Несколько нод и вопросы балансировки
• Деплой должен быть blue/green, а не docker compose pull && up -d

Правила, если оставляем

1. Фиксируйте версии образов тегом, а не latest
2. restart: unless-stopped у каждого сервиса — обязательно
3. Секреты — через env_file с правами 600, а не в compose-файле в git
4. Мониторинг: без healthcheck'ов и алертов compose в проде — слепая зона
5. Бэкап — отдельная задача в cron, не «а оно ж в volume'е»

Итог: compose в проде допустим осознанно, а не потому что «так проще начать».