DockerMiddleSystem design

Зачем нужен docker-compose, если есть docker run? В каком случае compose в проде — нормальная история, а в каком — нет?

Compose описывает multi-container приложение декларативно — удобно версионировать и воспроизводить. В prod нормален для single-host deployment малого масштаба. Недостаточен при нужде в multi-node scheduling, auto-rescheduling, rolling deployments и autoscaling.

docker run vs Docker Compose

docker run — императивная команда для запуска одного контейнера. Параметры (порты, volumes, env, network) передаются в командную строку. При перезапуске нужно помнить все флаги. Docker Compose — декларативное описание набора сервисов в YAML: версионируется, ревьюируется, воспроизводится одинаково на всех машинах.

# docker run: всё в одной строке, сложно воспроизвести
docker run -d \
  --name api \
  --network app-net \
  -p 8000:8000 \
  -e DATABASE_URL=postgresql://... \
  -e REDIS_URL=redis://redis:6379 \
  --restart unless-stopped \
  registry.example.com/team/api:1.4.2
# docker-compose.yml: то же самое, но читаемо и версионируемо
services:
  api:
    image: registry.example.com/team/api:${TAG:-latest}
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgresql://postgres:postgres@postgres:5432/app
      REDIS_URL: redis://redis:6379
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_started
    restart: unless-stopped

  postgres:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: postgres
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "postgres"]
      interval: 5s
      retries: 10

  redis:
    image: redis:8-alpine
    volumes:
      - redisdata:/data

volumes:
  pgdata:
  redisdata:

Когда Compose в prod — нормально

  • Небольшой single-host deployment: VPS с 1–4 vCPU, стартап, internal tool, self-hosted сервис.
  • Простая failure model: один сервер, ручной failover допустим, RTO в часах.
  • Edge deployment: IoT, retail box, on-premise инсталляция без Kubernetes.
  • Demo / staging environment: быстрый старт, не критична высокая доступность.
  • Нет команды DevOps для поддержки кластера.

Когда Compose недостаточен

  • Multi-node scheduling: нужно распределить контейнеры по нескольким хостам.
  • Automatic rescheduling: при падении ноды сервисы должны переехать на другую.
  • Rolling deployments без downtime с readiness probes.
  • Horizontal autoscaling по CPU/RPS метрикам.
  • Policy-driven secrets и RBAC (Vault, Kubernetes Secrets с encryption at rest).
  • Service mesh (mTLS, traffic shaping, circuit breaking).
  • Тогда нужен Kubernetes, Nomad, AWS ECS или managed platform.

Production Compose без discipline — риск

# Плохо: без pinning тега
image: my-api:latest  # разные машины могут получить разный image

# Хорошо: pinning digest или semver tag
image: registry.example.com/team/api:1.4.2
# или с digest
image: registry.example.com/team/api@sha256:abc123...

# Deploy workflow
git pull
docker compose pull
docker compose up -d
docker compose ps  # проверить что все сервисы healthy

Подводные камни

  • Тег :latest в production: разные ноды или перезапуски могут получить разные версии image без явного обновления.
  • Отсутствие backup стратегии: Compose управляет контейнерами, но не данными. Volumes нужно бэкапить отдельно.
  • Log rotation не настроена: контейнеры пишут в docker json-file driver по умолчанию, логи растут без ограничений. Настройте logging.options.max-size.
  • docker compose up на сервере без CI/CD — ручная операция без audit trail и rollback.
  • Secrets в .env файле на сервере: если файл попадёт в git или получит широкие permissions — утечка.
  • restart: unless-stopped не означает HA: при перезагрузке сервера Docker сам стартует (если --restart always), но порядок старта сервисов может нарушиться.
  • depends_on контролирует порядок старта, но не readiness: используйте condition: service_healthy с healthcheck.
  • Накопленные dangling images и volumes: периодически запускайте docker system prune или настройте cron.

Common mistakes

  • Переписывать длинные docker run команды вместо versioned compose.yaml.
  • Использовать Compose для HA кластера с требованиями autoscaling и self-healing.
  • Пускать production compose без pinning images, backups и log rotation.

What the interviewer is testing

  • Объясняет declarative multi-service model.
  • Различает single-host deployment and orchestration.
  • Учитывает operations вокруг Compose in production.

Sources

Related topics