Почему в одном контейнере не запускают несколько процессов?

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

Причины:

• Изоляция и управление жизненным циклом: Контейнер должен отвечать за один конкретный процесс. Это упрощает управление, масштабирование и оркестрацию. Если один из процессов в контейнере падает, весь контейнер может быть перезапущен, что приводит к ненужному перезапуску других работающих процессов. Orchestrators (Kubernetes, Docker Swarm) заточены под управление отдельными процессами в контейнерах.
• Логирование и мониторинг: Собирать логи и метрики для нескольких процессов в одном контейнере сложнее. Каждый процесс имеет свой поток вывода (stdout/stderr). Разделение на отдельные контейнеры позволяет легче собирать и анализировать данные.
• Безопасность: Изоляция на уровне процессов повышает безопасность. Если один процесс скомпрометирован, потенциальное воздействие на систему ограничено в пределах этого контейнера. При работе нескольких процессов в одном контейнере, у скомпрометированного процесса может быть доступ к другим.
• Обновление и отладка: Обновлять и отлаживать отдельные компоненты (процессы) гораздо проще, если они находятся в разных контейнерах. Можно обновить или перезапустить конкретный контейнер без влияния на другие сервисы.
• Размер образа: Образ контейнера становится меньше и более специализированным, если он содержит только необходимые файлы для одного процесса.
• Сложность ENTRYPOINT/CMD: Правильное управление несколькими процессами в ENTRYPOINT или CMD требует написания сложных обвязок (init systems like tini or supervisord), что добавляет ненужную сложность.

Пример Dockerfile для одного процесса:

FROM alpine:latest
CMD ["nginx", "-g", "daemon off;"] // Запускаем только nginx

Пример (плохой) с несколькими процессами:

FROM ubuntu:latest
COPY start.sh /start.sh
CMD ["/start.sh"] // start.sh пытается запустить несколько процессов

В start.sh пришлось бы реализовывать логику управления жизненным циклом, что по сути дублирует функциональность оркестратора.

В редких случаях, для вспомогательных процессов (например, sshd для отладки), можно использовать init system внутри контейнера, но это исключение, а не правило. Основная идея - один главный процесс на контейнер.