Рекомендации Docker: единый процесс для контейнера

Question

Рекомендации Docker: единый процесс для контейнера

Докер лучшие практики Руководство гласит, что:

«… вы должны запускать только один процесс в одном контейнере …»

Должны ли Nginx и PHP-FPM работать в отдельных контейнерах? Или это означает, что микросервисные архитектуры запускают только один сервис или «приложение» в контейнере?

Наличие этих сервисов в одном контейнере проще в развертывании и обслуживании.

6

docker dockerfile nginx php virtual-machine

Решение

Другие решения

Это означает процесс в смысле слова Linux / Unix. Тем не менее, ничто не мешает вам запускать несколько процессов в контейнере, это просто не рекомендуемая парадигма.

2

Мы обнаружили, что мы можем запустить несколько служб, используя Supervisord. Это делает архитектуру довольно простой, требуя только наличия дополнительного файла supervisor.conf. Например:

supervisord.conf

[supervisord]
nodaemon=true

[program:apache2]
command=/bin/bash -c "source /etc/apache2/envvars && exec /usr/sbin/apache2 -DFOREGROUND"
[program:udpparser]
command=bin/bash -c "exec /usr/bin/php -f /home/www-server/services/udp_parser.php"

Из Dockerfile:

FROM ubuntu:14.04

RUN apt-get update
RUN apt-get install -y apache2 supervisor php5 php5-mysql php5-cli

RUN mkdir -p /var/lock/apache2 /var/run/apache2 /var/log/supervisor

RUN a2enmod rewrite
RUN a2enmod ssl

COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf

ADD 000-default.conf /etc/apache2/sites-enabled/
ADD default-ssl.conf /etc/apache2/sites-enabled/
ADD apache2.conf /etc/apache2/
ADD www-server/ /home/www-server/

EXPOSE 80 443 30089

CMD ["/usr/bin/supervisord"]

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

1

Источник

Accepted Answer

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

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

Так:

У меня есть один контейнер с nginx, который открыт для внешнего мира (: 443,: 80). На этом уровне легко управлять конфигурациями, сертификатами TLS, параметрами балансировки нагрузки и т. Д.
Один (или несколько) контейнер (ы) с приложением. В этом случае контейнер php-fpm с приложением. Образ Docker не имеет состояния, контейнеры монтируются и совместно используют тома для статических файлов и так далее. На этом этапе вы можете в любой момент уничтожить и заново создать контейнер приложения, поддерживая балансировщик нагрузки в рабочем состоянии. Кроме того, вы можете иметь несколько приложений за одним прокси (nginx), и управление одним из них не повлияет на другие.
Один или несколько контейнеров для базы данных … Применяются те же преимущества.
Redis, Memcache и т. Д.

Имея эту структуру, развертывание является модульным, поэтому каждый «сервис» отделен и логически независим от остальной системы.

В качестве побочного эффекта, в данном конкретном случае, вы можете сделать развертывания без простоев (обновления) к приложению. Идея этого проста. Когда вам нужно выполнить обновление, вы создаете образ докера с обновленным приложением, запускаете контейнер, запускаете все тесты и сценарии обслуживания и, если все идет хорошо, вы добавляете вновь созданный контейнер в цепочку (балансировщик нагрузки) и тихо убей старого. Вот и все, у вас есть обновленное приложение, а пользователи даже не заметили этого.

5