docker compose up/down/exec

docker compose up собирает (если нужно), создаёт и запускает всё из compose.yaml; -d — запуск в фоновом режиме, --build — принудительная пересборка образов, --remove-orphans — удаление сервисов, которых уже нет в файле. Команда down останавливает и удаляет контейнеры и дефолтную сеть; добавьте -v, чтобы удалить именованные тома (что приведёт к потере данных!). exec запускает команду внутри уже работающего сервиса, например docker compose exec db psql. Типичная ловушка: up не подхватит изменённые переменные окружения, пока не будет выполнена команда up -d снова или restart.

Как это работает

docker compose up/down/exec — это YAML-формат и CLI для описания многоконтейнерных приложений как кода. Файл compose.yml перечисляет сервисы, сети, тома и их связи; команда docker compose up поднимает весь стек; docker compose down останавливает и удаляет все контейнеры и сети. Compose создаёт изолированную сеть для каждого проекта, позволяет сервисам находить друг друга по имени, поддерживает переопределение через файл .env и переменные ${VAR}. Профили (profiles: [dev]) позволяют включать или выключать опциональные сервисы в зависимости от требований.

Когда применять

Compose полезен для разработки, маленьких single-host production-деплоев, интеграционных тестов в CI/CD. Он не подходит для многоконтейнерных оркестраций, где требуется распределённая оркестрация, такая как Kubernetes (или Nomad, или Docker Swarm). Секреты не следует хранить в compose.yml (используйте .env через env_file: или Docker secrets). В production-среде следует закреплять теги образов по digest, чтобы избежать неопределённости при запуске.

Типичные ошибки

Основные ловушки при использовании docker compose up/down/exec включают путаницу между версионными схемами: v1 (docker-compose, отдельная Python-утилита, EOL) и v2 (docker compose, Go-плагин, актуальная). Также следует избегать коммита файла .env в git (там могут содержаться секреты). Ошибка depends_on: ожидает только запуск контейнера, а не его готовности к работе (используйте healthcheck: с condition: service_healthy). При переименовании проекта важно не забывать о том, что именованные тома также должны быть переименованы, чтобы избежать потери данных.

Связанные понятия

• Переменные окружения & .env
• Профили и их использование
• Docker Compose
• Структура docker-compose.yml
• Сервисы, depends-on & restart
• Мониторинг состояния с помощью Compose
• Docker Containers: Основы и внутренности
• Docker Containers: Пространства имен
• Docker Containers: ОСИ
• Docker Containers: Виртуальные машины vs контейнеры
• Docker Containers: Почему контейнеры?
• Docker Security: AppArmor и SELinux
• Docker Basics: CLI
• Docker Bind Mounts
• Docker Build
• Docker Buildkit
• Docker Capabilities
• Docker CI/CD
• Docker Containerd
• Docker Daemon
• Docker Data Patterns
• Docker Desktop
• Docker DNS
• Docker Exec
• Docker Health and Liveness
• Docker Hub
• Docker Image Manifest
• Docker Image Pull
• Docker Image Size
• Docker Images
• Docker Inspect
• Docker Install
• Docker Install (Linux)
• Docker Internals
• Docker Layers
• Docker Logging Drivers
• Docker Logs
• Docker Multi-Arch
• Docker Multi-Host
• Docker Multi-Stage
• Docker Named Volumes
• Docker Network CLI
• Docker Network Modes
• Docker Networking
• Docker Plugins
• Docker Port Mapping
• Docker Private Registry
• Docker Production
• Docker PS
• Docker Push and Pull
• Docker Read-Only
• Docker Registry
• Docker Resource Limits
• Docker Restart Policies
• Docker Rootless
• Docker Run
• Docker Scan
• Docker Seccomp
• Docker Secrets
• Docker Security
• Docker Stats
• Docker Tags and Semantic Versioning
• Docker tmpfs
• Docker Volume CLI
• Docker Volumes
• Docker vs Podman
• Dockerfile Advanced
• Dockerfile ARG and ENV
• Dockerfile Best Practices
• Dockerfile Healthcheck
• Dockerfile Instructions
• Dockerfile Intro
• Dockerfile Non-root