Почему правило «один процесс на контейнер» работает не везде

MAATRIX

Рано или поздно любой, кто пишет Dockerfile, слышит фразу «один процесс на контейнер» — обычно с интонацией непреложного закона. И в большинстве случаев это действительно верный ориентир: он экономит часы отладки и упрощает эксплуатацию. Но у правила есть граница применимости, и когда её не видят, вместо простой системы получают россыпь микроконтейнеров, которые сложнее старого монолита. Разберём, что правило реально даёт, где оно перестаёт работать и как принимать решение осознанно, а не по привычке цитировать лучшие практики.

Что на самом деле означает правило и откуда оно взялось

Формулировка «один процесс на контейнер» появилась не как догма, а как побочный эффект того, как устроен сам Docker. Контейнер — это не lightweight-VM с полноценной init-системой, а изолированное окружение вокруг одного дерева процессов, которое живёт, пока жив процесс с PID 1. Когда в качестве PID 1 запускают сразу несколько независимых сервисов через самодельный shell-скрипт, всплывают классические проблемы: сигналы от docker stop не долетают до нужного процесса, зомби-процессы не пожинаются, а падение одного сервиса не роняет контейнер и не запускает перезапуск — система продолжает жить в наполовину сломанном состоянии, только это не видно снаружи. Подробнее о механике сигналов и PID 1 разобрано в статье PID 1 в контейнере и потерянные сигналы, а о том, чем опасны непожатые зомби — в зомби-процесс: почему не ест память, но опасен.

Отсюда и родилось эмпирическое правило: пусть в контейнере живёт один управляемый процесс, а связями между сервисами занимается оркестратор снаружи — Docker Compose, Kubernetes, Swarm. Это не архитектурный принцип уровня «единственной ответственности» из ООП, а скорее защита от конкретных технических граблей плоской модели процессов в контейнере. Важно понимать именно это происхождение — тогда становится ясно, в каких ситуациях правило перестаёт что-либо защищать, потому что грабля, из-за которой оно появилось, там просто не встречается.

Что правило реально даёт, когда работает как задумано

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

• Независимое масштабирование. Если под нагрузкой упирается именно веб-слой, вы поднимаете реплики только веб-контейнера, не трогая базу и кэш. С одним процессом на контейнер это делается декларативно — replicas: 3 в Compose или Deployment в Kubernetes — без дополнительной логики внутри образа.
• Прозрачные логи. docker logs <container> показывает stdout/stderr одного процесса, а не перемешанный вывод трёх демонов. Это резко упрощает и ручной разбор инцидентов, и агрегацию через Loki, Graylog или ELK — подробнее в статье Docker logging: лучшие практики.
• Точный healthcheck. Когда в контейнере один процесс, health-проверка однозначно отвечает на вопрос «жив ли сервис». Когда их несколько, приходится решать, что считать «здоровым» состоянием контейнера — подробности в статье настройка Docker healthcheck.
• Независимые обновления. Обновили образ веб-приложения — пересобрался и передеплоился только он. База и кэш не тронуты, даунтайм и риск регрессии минимальны.
• Понятный жизненный цикл. Один процесс — одна причина падения контейнера. Не нужно разбираться, какой из трёх демонов внутри уронил health-проверку.

Всё это — реальная эксплуатационная выгода, а не карго-культ. Именно поэтому правило и стало стандартом по умолчанию: в подавляющем большинстве случаев архитектура «один сервис — один контейнер — один процесс» действительно проще в сопровождении, чем любая альтернатива. Вопрос в том, что происходит, когда сущность в контейнере — не «сервис», а что-то более тесно связанное.

Легитимный сценарий 1: обязательный вспомогательный процесс

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

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

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

• нужен общий volume только для передачи файлов между двумя контейнерами;
• нужно синхронизировать порядок старта и остановки (depends_on в Compose не гарантирует, что зависимость реально готова, а не просто запущена);
• нужен отдельный healthcheck, сеть, лимиты ресурсов, мониторинг — на сущность, которая никогда не будет жить и масштабироваться отдельно от основного процесса.

Если два процесса физически не могут существовать по отдельности — не масштабируются независимо, не обновляются независимо, не имеют смысла друг без друга — разделение их на два контейнера не даёт ни одного из преимуществ из предыдущего раздела, зато добавляет всю сложность межконтейнерной координации. В таком случае технически корректный подход — держать оба процесса в одном контейнере, но не через самодельный bash-скрипт с & в конце строки, а через легкий супервизор процессов (например, s6-overlay или tini + небольшой supervisord), который правильно транслирует сигналы, пожинает зомби и следит за тем, что оба процесса живы. Именно эта грамотная реализация снимает исходную техническую проблему, из-за которой правило вообще появилось — а значит, формальное нарушение правила не создаёт тех рисков, ради которых оно писалось.

Легитимный сценарий 2: dev- и тестовые окружения

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

Если для интеграционных тестов нужен один контейнер, в котором поднимается всё необходимое окружение целиком — например, тестовая база с уже накатанными миграциями плюс небольшой сервис-заглушка — держать это в двух отдельных контейнерах с оркестрацией через Compose оправдано только тогда, когда сама оркестрация не добавляет трения. Для CI-пайплайна, который поднимает и убивает окружение сотни раз в день, каждая лишняя сущность — это лишняя точка отказа: не поднялась сеть между контейнерами, не успел стартовать зависимый сервис, флейковый тест из-за гонки при старте. Один контейнер с двумя процессами внутри, поднятый через docker run за секунды, в таком контексте может быть просто прагматичнее и надёжнее.

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

Когда исключение маскирует реальную проблему архитектуры

Стоит отдельно проговорить, где граница легитимного исключения заканчивается и начинается обычный технический долг под красивым оправданием. Если внутри одного контейнера уживаются веб-сервер, очередь задач и планировщик cron, потому что «так исторически сложилось» и «пока не было времени разнести» — это не осознанное архитектурное решение, а миграция монолита в Docker без пересмотра границ ответственности. Такой контейнер обычно можно опознать по симптомам: он масштабируется целиком, хотя нагрузку создает только один из компонентов; обновление любой части требует пересборки и передеплоя всего; лог-вывод — нечитаемая смесь трёх источников; healthcheck либо ничего не проверяет по-настоящему, либо завязан на самый капризный из трёх процессов.

Отличие от легитимных сценариев простое: в оправданном случае разделение процессов на контейнеры не даёт архитектурных преимуществ, потому что процессы неразделимы по своей природе. В неоправданном случае преимущества есть и они значимые, просто их отложили ради сиюминутной экономии времени. Честный вопрос, который стоит задать себе: «если бы я сейчас начинал эту систему с нуля, я бы специально собрал эти процессы в один контейнер?» Если ответ «нет, но переписывать лень» — это технический долг, а не оправданное отклонение от правила, и стоит хотя бы зафиксировать его как задачу на бэклог, а не маскировать формулировкой «у нас так исторически».

Как оценить компромисс, а не следовать правилу вслепую

Правило «один процесс на контейнер» — это не цель, а инструмент для конкретной цели: упростить эксплуатацию системы. Когда следование букве правила эту эксплуатацию усложняет, а не упрощает, стоит явно взвесить компромисс, а не подчиняться правилу автоматически. Практический чек-лист для такого решения:

Если по большинству пунктов ответ говорит в пользу «это один неразделимый юнит» — не бойтесь держать оба процесса в контейнере, но делайте это технически грамотно: полноценный init-процесс (tini или s6-overlay) вместо голого shell-скрипта, явная пересылка сигналов, отдельные health-проверки на каждый вложенный процесс через скрипт-обёртку, а не общий флаг «жив/не жив». Такой контейнер закрывает исходную проблему правила — потерянные сигналы и непожатые зомби — не будучи форматически «одним процессом».

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

Частые вопросы