Ответ
Я использую Docker Compose в основном для двух целей: локальной разработки и запуска интеграционных тестов в CI/CD. Это позволяет быстро поднять весь стек зависимостей (БД, кэш, очередь) единой командой.
Структура и практики:
- Базовый
docker-compose.ymlописывает сервисы, их образы, порты, volumes и зависимости (depends_on). - Переопределение для окружений: Использую файлы
docker-compose.override.ymlдля разработки (монтирование исходного кода, отладочные порты) иdocker-compose.ci.ymlдля CI (использование готовых образов, другие переменные). - Переменные окружения: Все конфигурации (пароли, адреса) выносятся в
.envфайл, который исключается из Git.
Пример docker-compose.yml для типового веб-приложения с БД и кэшем:
version: '3.8'
services:
postgres:
image: postgres:15-alpine
environment:
POSTGRES_DB: app_db
POSTGRES_USER: app_user
volumes:
- postgres_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U app_user"]
interval: 10s
redis:
image: redis:7-alpine
command: redis-server --appendonly yes
volumes:
- redis_data:/data
app:
build: .
depends_on:
postgres:
condition: service_healthy
redis:
condition: service_started
environment:
DATABASE_URL: postgresql://app_user@postgres/app_db
REDIS_URL: redis://redis:6379
ports:
- "8080:8080"
volumes:
postgres_data:
redis_data:
Интеграция с CI/CD: В пайплайне GitLab CI я запускаю интеграционные тесты следующим образом:
integration_tests:
stage: test
script:
- docker-compose -f docker-compose.yml -f docker-compose.ci.yml up -d
- docker-compose exec -T app pytest /tests/integration # Запуск тестов в контейнере
- docker-compose down -v # Остановка и удаление volumes
Важные моменты:
- Docker Compose — не для продакшена. Для production-оркестрации использую Kubernetes или Docker Swarm.
- Всегда настраиваю
healthcheckдля сервисов, чтобы правильно управлять зависимостями. - Для сборки многоконтейнерных приложений в продакшене использую
docker-composeтолько как этап подготовки образов, которые затем пушатся в реестр и деплоятся через Helm-чарты в K8s.