Docker Compose profiles: как запускать отладочные сервисы отдельно

В Compose-файле рядом с приложением появились панель диагностики, почтовая заглушка и контейнер с сетевыми утилитами. Обычный up запускает их все, занимает дополнительные порты и затрудняет понимание минимального состава окружения. Profiles позволяют оставить описание рядом с основным приложением, но включать выбранные сервисы по необходимости. Это удобно, пока нужно управлять составом одного проекта.

Основной сервис оставляем доступным по умолчанию

Сохраним минимальный пример в compose.yaml. Nginx представляет основной web-сервис. Контейнер inspect использует Alpine и периодически запрашивает web по внутренней сети. Это диагностика HTTP-доступности из контейнера, а не проверка бизнес-логики. Published port привязан к loopback хоста, чтобы учебная страница не открывалась на всех интерфейсах.

services:
  web:
    image: nginx:stable-alpine
    ports:
      - "127.0.0.1:8080:80"
  inspect:
    image: alpine:3.22
    profiles: [debug]
    depends_on:
      - web
    command:
      - /bin/sh
      - -c
      - "while true; do wget -S -O /dev/null http://web:80/; sleep 5; done"

У web нет profiles, поэтому он входит в обычный запуск. inspect помечен debug и при обычном up не выбирается. Зависимость объявлена в сторону основного сервиса: диагностике нужен web. Обратная связь, когда основной сервис требует выключенную отладочную зависимость, лишила бы окружение смысла и могла сделать модель некорректной.

docker compose -p profileslab config --quiet
docker compose -p profileslab up -d
docker compose -p profileslab ps

После обычного запуска ожидается работа web без inspect. Указанный тег Nginx подвижен, потому что здесь проверяется состав сервисов, а не воспроизводимость релиза. Для закреплённого учебного стенда используйте проверенные вашей командой версии или digest. Перед запуском убедитесь, что локальный порт 8080 свободен: profiles не устраняют конфликт портов у выбранных сервисов.

Включаем отладку для текущей задачи

docker compose -p profileslab --profile debug up -d
docker compose -p profileslab logs --tail 20 inspect

Теперь выбираются и обычные сервисы, и сервисы активного debug. В журнале inspect ожидаются HTTP-заголовки и результат запроса к web. В начале возможна ошибка соединения: короткий depends_on задаёт порядок запуска контейнеров, но не готовность HTTP-сервера. Цикл повторяет запрос через пять секунд, поэтому можно увидеть переход к ответу. Если требуется ждать проверенной готовности, добавьте осмысленный healthcheck и соответствующее условие зависимости.

Профиль можно передать через COMPOSE_PROFILES, но настройка окружения shell сохраняется дольше одной команды и иногда становится причиной неожиданного запуска. Для ручной диагностики явный --profile легче заметить в истории. Несколько флагов включают несколько профилей; --profile "*" выбирает все. Использовать звёздочку как повседневный способ запуска неудобно: будущий тяжёлый сервис тоже окажется включённым.

Явный выбор сервиса обходит необходимость включать профиль

docker compose -p profileslab up -d inspect

При таком запуске inspect выбран по имени и запускается, хотя --profile debug не указан. Его зависимость web тоже учитывается. Другие сервисы с тем же профилем автоматически не выбираются только потому, что запущен inspect. Это полезно для одноразовых утилит, но означает, что profiles не являются ограничением доступа. Любой оператор с правом управления Docker может явно запустить описанный сервис.

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

Останавливаем отладку явно

docker compose -p profileslab stop inspect
docker compose -p profileslab ps --all

Повторный обычный up без --profile не означает, что уже работающий inspect обязательно остановится. Состав выбранных для запуска сервисов и состояние ранее созданных контейнеров — разные вещи. Поэтому после диагностики явно остановите дополнительный сервис и проверьте ps. Команда down для всего проекта имеет гораздо более широкий эффект и не нужна, если требуется только убрать отладочный процесс.

Не используйте profiles для передачи секретов или изоляции production от теста. Это способ выбора сервисов, а не граница безопасности и не отдельный проект. Сервис debug по-прежнему использует сети и тома, которые ему объявлены. Если он подключён к рабочей базе с правами записи, профиль не уменьшит эти права. Для разделения окружений нужны отдельные ресурсы и проверенные подключения.

Для одноразовой проверки можно явно запустить inspect через compose run, но это создаёт отдельный контейнер с жизненным циклом run. Не смешивайте его с постоянным сервисом, запущенным через up, когда проверяете ps и журналы. Выберите один способ для инструкции команды и укажите, что считается завершением задачи. Для длительного наблюдения цикл из примера удобен, для разового теста лучше команда, которая заканчивается осмысленным кодом возврата.

Если проект использует несколько Compose-файлов, проверяйте profiles после их объединения с теми же -f, что и при запуске. Дополнительный файл может изменить команду, сеть и опубликованные порты отладочного сервиса. Видимый в одном исходнике профиль ещё не описывает окончательную модель; её показывает config.

Полезная итоговая проверка состоит из трёх состояний: обычный запуск, запуск с debug и остановка inspect при сохранённом web. Запишите ожидаемый состав каждого состояния в инструкции проекта. Тогда новый разработчик сможет включить диагностику и убрать её без редактирования общего файла.

Ещё по теме

• Обновление приложения в Docker Compose: фиксируем версию и готовим откат
• Резервная копия PostgreSQL в Docker Compose: проверяем восстановление

Продолжить изучение

Хотите разобраться в контейнеризации целиком, от образа до работающего окружения? Сборка, сети, данные и запуск приложений входят в программу «Docker и Docker Compose: контейнеризация приложений».