Docker Compose

Docker Compose — это инструмент для описания и запуска приложений, состоящих из нескольких Docker-контейнеров. Вместо ручного запуска каждого контейнера отдельной командой разработчик описывает все компоненты системы в одном YAML-файле, а затем запускает их как единый стек.

Например, веб-приложение может состоять из backend, базы данных PostgreSQL, Redis и Reverse Proxy. Без Docker Compose каждый контейнер пришлось бы создавать и связывать вручную. С Compose все сервисы, сети, тома и параметры можно описать в одном файле compose.yaml и запустить одной командой.

Docker Compose особенно удобен для локальной разработки, тестовых окружений, небольших серверных установок, демонстрационных стендов и CI/CD. Он помогает сделать окружение воспроизводимым и уменьшает количество ручных действий.

Что такое Docker Compose простыми словами

Docker запускает отдельные контейнеры. Docker Compose позволяет описать сразу несколько связанных контейнеров и управлять ими как одной системой.

Представим интернет-магазин. Для его работы нужны веб-приложение, база данных и Redis. Разработчик может вручную создать сеть, запустить PostgreSQL, затем Redis, затем backend и передать каждому контейнеру нужные параметры.

Docker Compose позволяет записать всю эту конфигурацию один раз.

Главная идея Docker Compose — хранить описание многоконтейнерного приложения в одном декларативном файле и воспроизводимо запускать весь набор сервисов.

Для чего нужен Docker Compose

Compose решает задачу координации нескольких Docker-контейнеров.

• запуск многоконтейнерных приложений;
• создание одинаковых локальных окружений;
• настройка сетей между контейнерами;
• подключение постоянных томов;
• передача переменных окружения;
• определение зависимостей между сервисами;
• массовый запуск и остановка контейнеров;
• упрощение тестовых стендов;
• использование в CI/CD;
• документирование состава приложения.

Как работает Docker Compose

Разработчик создает YAML-файл с описанием сервисов. Каждый service обычно соответствует одному типу контейнера.

В конфигурации можно указать Docker image, порты, volumes, environment variables, сети и другие параметры.

После запуска Compose читает файл и создает необходимые ресурсы Docker.

1. Читается compose.yaml.
2. Создаются необходимые сети.
3. Создаются volumes.
4. При необходимости собираются Docker images.
5. Создаются контейнеры сервисов.
6. Контейнеры подключаются к нужным сетям и томам.
7. Приложение запускается как единый стек.

Что такое compose.yaml

compose.yaml — основной конфигурационный файл Docker Compose. В нем описываются сервисы и связанные с ними ресурсы.

Простейший пример может выглядеть так:

services:
 web:
 image: example/web
 ports:
 - "8080:80"
 db:
 image: postgres
 environment:
 POSTGRES_DB: app

В этом примере определены два сервиса: web и db. После запуска Compose создаст два связанных контейнера.

Что такое Service в Docker Compose

Service — логическое описание одного компонента приложения.

Например, backend, database, redis и nginx могут быть отдельными сервисами.

Service содержит параметры, по которым Docker Compose создает контейнер: image, build, ports, volumes, environment, networks и другие настройки.

При необходимости один сервис может быть запущен в нескольких экземплярах, хотя Compose не заменяет полноценный оркестратор контейнеров.

Service и Container — в чем разница

Service можно сравнить с шаблоном, а container — с объектом, созданным по этому шаблону.

Что такое image

Параметр image указывает, какой Docker image должен использовать сервис.

Например, база данных может запускаться из готового образа PostgreSQL, а Redis — из соответствующего контейнерного образа.

Для собственного приложения можно указать образ из Container Registry.

Что такое build

Параметр build позволяет Docker Compose самостоятельно собрать image на основе Dockerfile.

Это особенно удобно в разработке. Исходный код приложения находится рядом с Dockerfile, а Compose перед запуском создает актуальный образ.

Например, backend может собираться локально, а база данных использовать готовый image.

Docker Compose и Dockerfile

Dockerfile и Docker Compose решают разные задачи.

В одном проекте обычно используются обе технологии.

Что такое ports

Ports позволяют публиковать сетевые порты контейнера на хостовой машине.

Например, контейнер Nginx слушает порт 80 внутри Docker-сети. Чтобы открыть сайт через порт 8080 компьютера разработчика, можно настроить сопоставление 8080:80.

Не каждый сервис необходимо публиковать наружу. База данных часто должна быть доступна только другим контейнерам во внутренней сети.

Внутренняя сеть Docker Compose

Compose автоматически упрощает сетевое взаимодействие между сервисами.

Контейнеры одной сети могут обращаться друг к другу по имени service.

Например, backend может подключаться к базе не по жестко заданному IP-адресу, а по имени db.

DATABASE_HOST=db

Это важно, потому что IP-адрес контейнера может измениться после его пересоздания.

Что такое networks

Networks позволяют явно определять виртуальные сети Docker.

Например, frontend и backend можно подключить к одной сети, а backend и база данных — к другой.

Так можно ограничить ненужную сетевую связанность между компонентами.

Для небольших проектов достаточно автоматически создаваемой сети Compose, но более сложные схемы можно описывать вручную.

Что такое volumes

Volume — механизм постоянного хранения данных Docker.

Контейнеры по своей природе могут удаляться и пересоздаваться. Если база данных хранит всю информацию только внутри файловой системы контейнера, при удалении контейнера данные можно потерять.

Volume хранится отдельно и подключается к контейнеру.

services:
 db:
 image: postgres
 volumes:
 - db_data:/var/lib/postgresql/data

volumes:
 db_data:

В этом случае данные PostgreSQL сохраняются независимо от жизненного цикла контейнера.

Bind Mount и Volume

Docker Compose может подключать к контейнерам как Docker volumes, так и директории хостовой системы.

В development часто используют bind mount для мгновенного обновления исходного кода внутри контейнера.

Переменные окружения

Environment variables позволяют передавать настройки приложения без изменения image.

Например, контейнеру можно передать адрес базы данных, имя окружения или номер порта.

environment:
 DATABASE_HOST: db
 APP_ENV: development

Так один и тот же image можно запускать с разной конфигурацией.

Файл .env

Для параметризации Compose можно использовать переменные из файла .env и окружения системы.

Например, номер порта или имя image можно вынести из основной конфигурации.

Это упрощает переиспользование одного compose-файла.

Однако файл .env не следует автоматически считать безопасным хранилищем секретов.

Секреты в Docker Compose

Пароли и API-ключи не следует без необходимости хранить прямо в compose.yaml и отправлять в Git.

Даже использование обычного .env не решает проблему, если файл попадает в репозиторий или доступен посторонним пользователям.

Для production-среды необходимо использовать подходящие механизмы управления секретами и ограничивать доступ к конфигурации.

Compose-файл должен описывать инфраструктуру приложения, но не становиться открытым хранилищем паролей и токенов.

Что такое depends_on

depends_on позволяет описать зависимость запуска одного сервиса от другого.

Например, backend зависит от базы данных.

services:
 app:
 image: example/app
 depends_on:
 - db

При этом сам факт запуска контейнера базы еще не означает, что СУБД полностью готова принимать соединения.

Поэтому для реальной проверки готовности часто используются Healthcheck и логика повторных подключений в приложении.

Что такое Healthcheck

Healthcheck позволяет Docker проверять состояние контейнера.

Например, для базы данных можно выполнять периодическую команду, которая подтверждает, что сервис действительно отвечает.

Это полезнее простой проверки существования процесса.

Контейнер может быть запущен, но приложение внутри него еще загружает конфигурацию или находится в ошибочном состоянии.

Restart Policy

Restart Policy определяет поведение контейнера после остановки.

Например, можно настроить автоматический перезапуск приложения после аварийного завершения.

Это повышает устойчивость небольшого стенда, но не превращает Compose в полноценную систему высокой доступности.

Если физический сервер полностью недоступен, локальный Docker Compose не сможет автоматически перенести контейнеры на другой узел.

Команда docker compose up

docker compose up — одна из основных команд. Она создает и запускает сервисы, описанные в Compose-файле.

Если нужный image отсутствует или используется build, Compose может предварительно подготовить контейнерные образы.

При изменении конфигурации повторный запуск может пересоздать только необходимые контейнеры.

Запуск в фоновом режиме

В development иногда удобно видеть логи контейнеров непосредственно в терминале.

Для длительной работы сервисы часто запускают в detached mode, чтобы они продолжали работать в фоне.

После этого состояние и журналы можно просматривать отдельными командами.

Команда docker compose down

docker compose down останавливает и удаляет контейнеры и часть ресурсов, созданных Compose.

Это удобно для полного завершения тестового окружения.

С постоянными volumes необходимо обращаться осторожно: данные базы не всегда нужно удалять вместе с контейнерами.

Stop и Down — в чем разница

Остановка и удаление окружения — разные действия.

Логи Docker Compose

Compose позволяет централизованно просматривать стандартный вывод нескольких сервисов.

Это удобно в локальной разработке: вместо открытия отдельных терминалов для backend, Nginx и worker можно видеть журналы компонентов в одном потоке.

Для production-инфраструктуры важные журналы лучше отправлять в централизованную систему логирования.

Docker Compose и логирование

Контейнеры должны записывать основные технические события в стандартный вывод или в поддерживаемую систему журналирования.

Compose упрощает просмотр логов небольшого набора контейнеров, но при десятках серверов этого становится недостаточно.

Тогда используют централизованные системы, например ELK Stack или другие решения Observability.

Docker Compose и Nginx

Nginx часто включают в Compose как Reverse Proxy.

Например, только контейнер Nginx публикует порт 80 или 443 наружу, а backend доступен исключительно внутри Docker-сети.

Nginx получает запросы пользователей и передает их приложению по внутреннему имени service.

Это упрощает сетевую архитектуру небольшого приложения.

Docker Compose и база данных

Базы данных часто запускаются через Compose в локальной разработке.

Разработчику не нужно отдельно устанавливать PostgreSQL или MySQL в операционную систему. Нужная версия СУБД запускается в контейнере.

Данные при этом следует хранить в volume.

Для production критичных систем необходимо отдельно оценивать резервное копирование, отказоустойчивость и требования к производительности базы.

Docker Compose и Redis

Redis, очереди сообщений и другие вспомогательные сервисы удобно подключать как отдельные services.

Например, приложение обращается к Redis по имени redis во внутренней сети Compose.

Так разработчик запускает весь необходимый стек без ручной установки каждого компонента на компьютер.

Docker Compose в локальной разработке

Локальная разработка — один из основных сценариев Docker Compose.

Вместо инструкции установить PostgreSQL определенной версии, настроить Redis и изменить десять параметров новый разработчик получает репозиторий и запускает готовое окружение.

Это снижает различия между компьютерами участников команды.

Docker Compose и проблема Works on My Machine

Фраза Works on My Machine описывает ситуацию, когда программа работает на компьютере одного разработчика, но не запускается у другого.

Причиной могут быть разные версии СУБД, библиотек и системных компонентов.

Docker Compose помогает стандартизировать сервисы окружения. Если все используют одинаковые images и конфигурацию, вероятность расхождений уменьшается.

Полностью проблема не исчезает, поскольку различия могут оставаться на уровне архитектуры процессора, Docker Engine, файловой системы и других факторов.

Docker Compose для тестирования

Compose удобно использовать в интеграционных тестах.

Перед тестом можно автоматически поднять базу данных, очередь и другие зависимости, выполнить проверку и затем удалить окружение.

Так тест не зависит от вручную установленного сервиса на CI-сервере.

Docker Compose и CI/CD

Compose можно применять в CI/CD для создания временного тестового окружения.

Pipeline запускает приложение и его зависимости, выполняет интеграционные тесты, а затем удаляет контейнеры.

Такой подход делает тестовую инфраструктуру воспроизводимой.

Для непосредственного production deployment крупные проекты часто используют специализированные оркестраторы.

Docker Compose и GitLab CI/CD

GitLab Runner может запускать Docker Compose в рамках pipeline, если инфраструктура Runner это поддерживает.

Например, перед интеграционными тестами создаются backend, PostgreSQL и Redis.

После завершения pipeline тестовый стек удаляется.

compose.yaml при этом хранится в том же Git-репозитории и проходит Code Review.

Docker Compose и Kubernetes

Docker Compose и Kubernetes предназначены для работы с контейнерами, но решают задачи разного масштаба.

Compose удобен для небольшой системы и development, а Kubernetes — для масштабирования, распределения по узлам и сложного управления production-нагрузкой.

Docker Compose и Helm

Helm используется для пакетного управления приложениями в Kubernetes, а Docker Compose — для многоконтейнерных приложений Docker.

В небольшом проекте разработчики могут использовать Compose локально, а production-развертывание выполнять в Kubernetes через Helm.

При этом конфигурации не являются прямыми заменами друг друга: модели ресурсов Docker Compose и Kubernetes отличаются.

Docker Compose и Infrastructure as Code

Compose использует декларативное описание сервисов и поэтому имеет общие идеи с Infrastructure as Code.

Конфигурация хранится как файл, может находиться в Git и использоваться повторно.

Однако Compose сфокусирован прежде всего на контейнерах и связанных Docker-ресурсах одного приложения, тогда как Terraform и другие IaC-инструменты управляют более широким набором инфраструктуры.

Docker Compose и Terraform

Terraform может создать виртуальную машину, сеть или Kubernetes-кластер. Docker Compose запускает контейнеры на уже подготовленном Docker-хосте.

Например, Terraform создает облачный сервер, Ansible устанавливает Docker, а Docker Compose запускает приложение.

Такая комбинация особенно понятна в небольших инфраструктурных проектах.

Профили Docker Compose

Иногда не все сервисы нужны при каждом запуске.

Например, обычному разработчику достаточно backend и базы данных, а дополнительный административный интерфейс требуется только время от времени.

Профили позволяют логически разделять необязательные части Compose-конфигурации и запускать их по необходимости.

Несколько Compose-файлов

Конфигурацию можно разделять между несколькими файлами и использовать разные значения для различных сценариев.

Например, общий файл описывает основную архитектуру, а дополнительная development-конфигурация подключает исходный код через bind mount и публикует отладочные порты.

Это помогает не создавать несколько полностью независимых копий одной архитектуры.

Development и Production

Один и тот же Compose-файл не всегда оптимален для development и production.

В development важны удобство отладки, bind mounts и открытые порты. В production требуется более строгая безопасность, централизованные логи, Backup и контроль ресурсов.

Поэтому конфигурации следует проектировать с учетом назначения окружения.

Ограничение ресурсов

Контейнеры могут конкурировать за CPU и оперативную память хоста.

Для стабильной эксплуатации полезно заранее понимать потребление каждого сервиса и применять доступные механизмы ограничения ресурсов.

Особенно это важно, если на одном сервере одновременно работают база данных, приложение и фоновые задачи.

Порядок запуска сервисов

Приложение может зависеть от других компонентов, но жестко рассчитывать только на порядок запуска контейнеров опасно.

База данных может стартовать как процесс, но еще несколько секунд не принимать подключения.

Поэтому приложение должно корректно обрабатывать временную недоступность зависимостей, использовать повторные попытки и проверки здоровья.

Docker Compose и масштабирование

Compose может запускать несколько экземпляров некоторых stateless-сервисов, но возможности распределенной оркестрации ограничены.

Если требуется автоматически распределять десятки экземпляров по нескольким серверам, обеспечивать самовосстановление узлов и сложное балансирование, обычно выбирают Kubernetes или другую кластерную платформу.

Compose лучше всего подходит там, где простота важнее сложной оркестрации.

Высокая доступность

Docker Compose сам по себе не обеспечивает полноценную High Availability между несколькими физическими серверами.

Если единственный Docker-хост выходит из строя, контейнеры на нем также становятся недоступны.

Можно резервировать сам сервер и данные внешними средствами, но для автоматического распределения приложения между узлами необходима дополнительная архитектура.

Резервное копирование

Compose-файл легко восстановить из Git, но это не означает восстановление данных приложения.

Особенно важно создавать резервные копии volumes с базами данных и пользовательскими файлами.

Обновление приложения через Compose

Для обновления можно получить новый image и пересоздать соответствующий контейнер.

Если изменился только backend, остальные компоненты не обязательно пересоздавать.

При этом обновления базы данных и миграции схемы необходимо планировать отдельно.

Простая замена Docker image не гарантирует совместимость с уже существующими данными.

Docker Compose и Registry

Для production-развертывания собственные images часто хранятся в Container Registry.

CI/CD собирает новую версию приложения и публикует image с определенным тегом.

Сервер затем получает image из Registry и запускает его через Docker Compose.

Желательно использовать контролируемые версии, а не полагаться только на изменяемый тег latest.

Безопасность Docker Compose

Compose упрощает запуск приложения, но не отменяет базовые правила безопасности контейнеров.

• не запускать контейнеры с лишними привилегиями;
• не публиковать ненужные порты;
• не хранить секреты в Git;
• использовать проверенные images;
• регулярно обновлять базовые образы;
• ограничивать доступ к Docker Engine;
• разделять внутренние и внешние сети;
• контролировать права на mounted directories.

Почему доступ к Docker Engine критичен

Пользователь, способный свободно управлять Docker на сервере, часто получает очень широкие возможности над хостовой системой.

Поэтому доступ к Docker Socket и административным командам необходимо строго ограничивать.

Не следует без необходимости подключать Docker Socket внутрь контейнера.

Опасность privileged-контейнеров

Режим с расширенными привилегиями значительно увеличивает возможности контейнера по взаимодействию с хостом.

Использовать его следует только при реальной технической необходимости.

Для обычного веб-приложения, базы или Redis такие полномочия чаще всего не нужны.

Преимущества Docker Compose

• простой запуск нескольких контейнеров;
• единый YAML-файл конфигурации;
• воспроизводимое окружение;
• удобное управление сетями и volumes;
• простая локальная разработка;
• подходит для интеграционных тестов;
• может храниться в Git;
• упрощает onboarding новых разработчиков;
• хорошо интегрируется с Dockerfile;
• сокращает количество ручных команд.

Недостатки и ограничения Docker Compose

• не является полноценным кластерным оркестратором;
• не обеспечивает автоматический перенос контейнеров между серверами;
• ограниченно подходит для крупных распределенных production-систем;
• секреты требуют отдельного подхода;
• состояние databases нужно резервировать самостоятельно;
• зависимость запуска не гарантирует готовность приложения;
• сложный compose-файл со временем может стать трудным для сопровождения.

Типичные ошибки при использовании Docker Compose

1. Хранить базу данных без постоянного volume.
2. Записывать пароли прямо в compose.yaml.
3. Публиковать наружу все порты.
4. Использовать фиксированные IP контейнеров вместо DNS-имен сервисов.
5. Считать depends_on полноценной проверкой готовности.
6. Не создавать Backup volumes.
7. Запускать контейнеры с лишними привилегиями.
8. Использовать только latest для критичных images.
9. Считать Compose заменой Kubernetes для любой нагрузки.
10. Не централизовать логи production-приложения.

Как правильно организовать Docker Compose проект

Шаг 1. Разделить приложение на сервисы

Нужно определить, какие компоненты должны работать в отдельных контейнерах.

Шаг 2. Создать compose.yaml

В нем описываются images, build, сети, volumes и параметры сервисов.

Шаг 3. Настроить внутренние сети

Не следует публиковать базы и внутренние сервисы наружу без необходимости.

Шаг 4. Вынести конфигурацию

Переменные, отличающиеся между окружениями, лучше отделить от основного описания.

Шаг 5. Настроить volumes

Состояние баз данных и других постоянных сервисов должно храниться отдельно от контейнеров.

Шаг 6. Добавить Healthcheck

Для важных зависимостей полезно контролировать реальную готовность сервиса.

Шаг 7. Исключить секреты из Git

Необходимо определить безопасный механизм передачи учетных данных.

Шаг 8. Продумать Backup

Конфигурация контейнеров не заменяет резервное копирование данных.

Практический пример

Команда разрабатывает CRM-систему. Для ее локального запуска нужны backend на Python, PostgreSQL, Redis и Nginx.

Раньше каждый новый разработчик устанавливал PostgreSQL и Redis вручную. Версии компонентов отличались, а настройка окружения занимала несколько часов.

Команда создала Dockerfile для backend и compose.yaml с четырьмя services.

PostgreSQL получил отдельный volume, backend подключается к нему по имени db, Redis доступен как redis, а Nginx публикует единственный внешний HTTP-порт.

Исходный код backend подключается через bind mount, поэтому изменения сразу доступны внутри development-контейнера.

Теперь новый разработчик устанавливает Docker, получает репозиторий и запускает весь стек одной командой.

Тот же Compose-файл используется в CI для интеграционных тестов. Production при этом работает в Kubernetes, поскольку системе требуется кластерное масштабирование и высокая доступность.

Docker Compose для малого проекта

Для небольших приложений Compose может использоваться не только локально, но и на отдельном сервере.

Например, корпоративный внутренний сервис состоит из Nginx, backend и PostgreSQL и обслуживает ограниченное количество пользователей.

Compose позволяет просто обновлять и сопровождать такой стек.

Однако даже при небольшом масштабе необходимо обеспечить Backup, мониторинг и защиту Docker-хоста.

Docker Compose для бизнеса

Практическая ценность Docker Compose заключается прежде всего в стандартизации окружений и сокращении ручных операций.

Разработчики получают одинаковые версии баз данных и сервисов, тестовые стенды быстро создаются и удаляются, а состав приложения становится явно описан в репозитории.

Это облегчает onboarding сотрудников и уменьшает количество локальных расхождений.

Для больших production-систем Compose обычно становится частью более широкой контейнерной стратегии, а не единственным инструментом эксплуатации.

Когда нужен Docker Compose

• приложение состоит из нескольких контейнеров;
• нужно одинаковое локальное окружение;
• разработчикам необходимы PostgreSQL, Redis и другие зависимости;
• нужно быстро создавать тестовые стенды;
• используются интеграционные тесты в CI/CD;
• требуется небольшой контейнерный стек на одном сервере;
• не хочется запускать каждый контейнер вручную;
• конфигурацию приложения нужно хранить в Git.

Когда Docker Compose может быть недостаточно

Если приложение должно работать на десятках серверов, автоматически масштабироваться, переживать отказ отдельных узлов и распределять контейнеры по кластеру, возможностей Compose обычно недостаточно.

В таких случаях используются Kubernetes или другие системы оркестрации.

Compose остается полезным даже тогда: разработчики могут использовать его локально, а production работать на Kubernetes.

Связанные термины

Краткий итог

Docker Compose — инструмент для декларативного описания и запуска приложений из нескольких Docker-контейнеров. В compose.yaml можно определить services, images, сети, volumes, переменные окружения, порты и другие параметры.

Compose особенно полезен для локальной разработки, тестовых окружений, CI/CD и небольших контейнерных установок на одном сервере. Он позволяет запускать весь стек одной командой и делает состав приложения воспроизводимым.

При этом Docker Compose не является полноценным кластерным оркестратором. Для больших production-систем с высокой доступностью и автоматическим распределением контейнеров между узлами обычно используют Kubernetes. Независимо от масштаба необходимо отдельно защищать секреты, резервировать данные volumes и ограничивать доступ к Docker Engine.