Docker Compose для локальной разработки: чек-лист перед продакшеном

Docker Compose поднимает приложение на ноутбуке — но переносить этот же набор настроек на сервер без проверки рискованно. В разработке удобно монтировать исходники, публиковать порт базы и читать секреты из локального файла; в продакшене эти решения могут открыть сервис наружу, потерять данные или оставить приложение без восстановления после сбоя. Ниже — практический чек-лист для Docker Compose v2 и Compose Specification: он поможет подготовить конфигурацию к реальному окружению, не превращая локальный файл в случайную продакшен-сборку.

Сначала выберите способ запуска

Есть три разумных сценария. Первый — отдельный production-файл поверх базового Compose. Второй — самостоятельный файл для сервера. Третий — собирать неизменяемый образ через Compose, а запускать его средствами платформы, например оркестратора. Последний сценарий особенно уместен, если у вас уже есть централизованное управление секретами, сетью и масштабированием.

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

Продакшен — это не «тот же compose.yaml, только на сервере». Это предсказуемый образ, контролируемые данные и понятный сценарий восстановления.

Чек-лист перед выкладкой

1. Зафиксируйте, что именно запускаете

Проверьте образ каждого сервиса. Для приложения в продакшене предпочтительнее собранный образ с конкретной версией или digest, а не исходники, примонтированные с компьютера разработчика. Тег вроде latest не говорит, какой именно код запустится после следующей сборки. Убедитесь, что образ собирается из нужного Dockerfile и не включает тестовые данные, локальные конфиги и лишние файлы.

Проверка: выясните, можно ли повторить сборку из репозитория и определить, какой именно образ выпущен. Сопоставьте настройки приложения с тем образом, который будет развёрнут, а не с содержимым рабочей папки.

2. Уберите привязку к рабочей станции

Bind mount исходников удобен для разработки, но зависит от структуры файлов на конкретном хосте. В production-конфигурации проверьте все записи вида локальный-путь:путь-в-контейнере. Оставляйте только те, которые действительно нужны серверу, например явный каталог данных. Исходники приложения обычно должны находиться в образе.

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

3. Закройте ненужные порты

В локальной разработке публикация порта базы данных на хост часто помогает подключиться из графического клиента. На сервере такой порт не должен становиться общедоступным, если это не требуется архитектурой. Проверьте секцию ports у каждого сервиса: публикация порта связывает контейнерный порт с хостом. Для внутренних соединений сервисы Compose обычно могут общаться по имени сервиса в общей сети без публикации порта наружу.

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

4. Перенесите секреты из файла конфигурации

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

Важно проверить не только основной файл, но и override-файлы, переменные CI/CD и историю репозитория. Если секрет уже попал в Git, простого удаления строки из текущей версии недостаточно: значение следует заменить.

5. Проверьте запуск и восстановление

Поле depends_on задаёт порядок запуска, но само по себе не означает, что зависимость уже готова принимать запросы. Если приложение требует готовой базы данных, настройте проверку её состояния и убедитесь, что приложение умеет повторить соединение после временной ошибки. Проверьте поведение после остановки контейнера и перезапуска хоста: restart policy помогает запускать контейнер снова, но не заменяет мониторинг и процедуру восстановления.

Проверьте обработку сигналов завершения: приложение должно корректно остановить запросы и закрыть соединения, а не бросать работу при выключении контейнера. Если в сервисе есть healthcheck, выясните, что именно он проверяет. Проверка процесса не всегда означает, что приложение обслуживает запросы или доступно по нужному маршруту.

6. Учтите логи, обновления и доступы

Определите, куда уходят логи, кто их читает и как ограничивается их объём. У контейнера с бесконечно растущими логами есть шанс заполнить диск сервера. Уточните, где собираются метрики и как вы узнаете о недоступности приложения. Не запускайте контейнер с избыточными правами без необходимости: отдельно проверьте пользователя внутри образа, доступ к Docker daemon и примонтированные каталоги.

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

Сверьте итог, а не только исходный файл

Compose объединяет базовый файл и дополнительные файлы конфигурации. Поэтому глазами по одному compose.yaml нельзя надёжно понять, что попадёт в запуск. Для проверки используйте Docker Compose v2: команда docker compose config показывает итоговую конфигурацию. Если применяете override, передайте файлы в том же порядке, в котором собираетесь запускать сервисы: docker compose -f compose.yaml -f compose.prod.yaml config. Перед публикацией результата убедитесь, что в выводе не раскрылись секреты.

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

Когда что выбирать и что обычно ломается

Оставляйте базовый файл с override, если сервис небольшой и вы готовы проверять результат слияния. Выбирайте отдельный production-файл, если так проще явно отделить локальные тома и порты от серверных параметров. Переносите запуск на платформу, если вам нужны централизованные секреты, масштабирование или единый контроль выкладок. Цена последнего варианта — дополнительные настройки и необходимость сопровождать отдельный процесс деплоя.

• На сервере остался bind mount исходников. Контейнер зависит от файловой системы хоста, а нужных файлов может не оказаться после переноса. Проверьте каждый путь и оставьте в образе код приложения.
• Порт базы опубликован наружу. Проверьте список ports, сетевые правила и необходимость внешнего доступа. Внутренний обмен сервисов не требует автоматически открывать порт для всего интернета.
• Контейнер запускается раньше базы. Порядок старта не равен готовности принимать соединения. Настройте проверку готовности и повтор подключения в приложении.
• Обновление прошло, а откат не спасает. Причиной может быть несовместимая миграция данных. Репетируйте миграции и восстановление на копии данных, прежде чем обновлять основной сервис.
• Секрет оказался в Git. Удалите его из доступной конфигурации и замените значение; проверьте историю и доступы к репозиторию.

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

Следующий шаг

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