Перейти к содержимому

Docker Compose для локальной разработки

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

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

Для правок есть bind mounts и Compose Watch. Bind mount напрямую связывает каталог хоста с контейнером и удобен для простой разработки, но поведение и скорость файловой системы могут различаться между ОС. Compose Watch позволяет задать точечные правила синхронизации, перезапуска или пересборки. Например, исходный код можно синхронизировать, а пересборку запускать при изменении файла зависимостей.

Не синхронизируйте каталоги зависимостей, содержащие собранные под конкретную ОС или архитектуру бинарные компоненты. Установите зависимости внутри целевого окружения и исключите такие каталоги из синхронизации. Пересборку образа оставьте для изменений, которые действительно влияют на образ, например Dockerfile или списка системных пакетов.

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

Разделяйте конфигурацию приложения и секреты. .env помогает задавать локальные значения, но его нужно исключить из Git, если там есть реальные ключи. Compose поддерживает secrets, которые подключаются только к явно указанным сервисам как файлы. Не считайте локальный Compose secret полноценным хранилищем секретов для production: способы выдачи и защиты секретов там зависят от платформы.

  • Закрепляйте конкретные версии образов; обновляйте их осознанно и проверяйте совместимость.
  • Добавляйте healthcheck для сервисов, от готовности которых зависит приложение. Сам факт запуска контейнера не означает, что база уже принимает соединения.
  • Не публикуйте сервисные порты на внешний интерфейс хоста без необходимости.
  • Используйте непривилегированного пользователя в прикладном контейнере и выдавайте только необходимые тома и права.
  • Проверяйте Compose-конфигурацию перед запуском, особенно если она взята из незнакомого репозитория: bind mounts и параметры контейнера могут предоставить доступ к файлам хоста.
  • Убедитесь, что приложение корректно сообщает об ошибках соединения и повторяет попытку подключения, когда зависимости готовы позже.

Compose удобен, если стек включает несколько сервисов, команда хочет видеть конфигурацию в репозитории и готова поддерживать Dockerfile, тома и правила разработки. Специализированная среда может быть проще для типовых PHP-проектов, где важны автоматические домены, версии PHP и готовые сервисы. Сравните Lerd и общий обзор локальной разработки, прежде чем закреплять подход для команды.

Для конкретной конфигурации WordPress на Docker Compose см. Docker для WordPress.