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.