обратный прокси-сервер nginx к php-fpm

Question

У меня возникли некоторые проблемы с конфигурацией Nginx. Начиная с обратного прокси-сервера SSL-терминатора nginx , я использую настройку docker-compose.yml с несколькими контейнерами, каждый из которых предоставляет виртуальный сервис. Эти сервисы предоставляются в виде подкаталогов под одним именем хоста:

net --443--> nginx
             | | `--- ContainerA "https://example.com/serviceA/"
             | `----- ContainerB "https://example.com/serviceB/"
             `------- ContainerC "https://example.com/serviceC/"

Фрагменты списков процессов:

nginx:~$ ps fax
127285 ?        Ss     0:00  nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf -g daemon off;
127419 ?        S      0:00   \_ nginx: worker process
127420 ?        S      0:00   \_ nginx: worker process
127421 ?        S      0:00   \_ nginx: worker process

ContainerA:~$ ps fax
127132 ?        Ss     0:09  php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
234053 ?        S      8:27   \_ php-fpm: pool www
236952 ?        S      8:12   \_ php-fpm: pool www
259123 ?        S      6:42   \_ php-fpm: pool www

Я думал, что эффективность будет достигнута за счет запуска одного экземпляра nginx и использования php-fpm в каждом из контейнеров.

Я думаю, что предпосылка php-fpm такова, что контейнерам не нужны свои собственные процессы nginx ; процессы nginx связываются с каждым контейнером через порт 9000 (сетевая часть работает). На практике, однако, у меня возникают проблемы, поэтому я должен проверить, что моя предпосылка обоснована:

Является ли это предположение базовой архитектуры nginx и php-fpm правильным? В качестве альтернативы, является ли надлежащая инфраструктура nginx/php-fpm предназначенной для использования php-fpm в прямом согласии (тот же хост и файловая система), или разумно и эффективно ли мультихостинг /мультифайловая система?

(Недавно я обратился за помощью, и их первым ответом было «вам нужно запустить nginx в каждом контейнере», что не имело смысла для моего понимания php-fpm .)

(Здесь есть множество вопросов, которые задают конкретные вопросы по nginx.conf , а не об этой заведомо высокоуровневой архитектуре.)

Answer 1

Это слабый ответ, но я верю:

Да, это в целом правильная философия, но с некоторыми оговорками. php-fpm предназначен для обработки файлов .php , но я думаю, что не для обслуживания всех (не-php) файлов. Для этого передний процесс nginx должен видеть все файлы, даже если он не выполняет фактическую обработку PHP.

Чтобы это происходило с использованием docker, файлы в контейнере php-fpm должны быть явно предоставлены в общий доступ к контейнеру nginx . Предпочтительный способ сделать это в Docker - предоставить именованный том и использовать его для обоих контейнеров. Например, файл docker-compose.yml :

version: '2'
services:
  serviceA:
    image: ... # something served with php-fpm
    volumes:
    - tmpvolA:/path/to/serviceA
  serviceB:
    image: ... # something served with php-fpm
    volumes:
    - tmpvolB:/path/to/serviceB
  nginx:
    image: ...
    volumes:
    - tmpvolA:/var/www/serviceA
    - tmpvolB:/var/www/serviceB
volumes:
  tmpvolA:
  tmpvolB:

(Многие много полей не включены ...) Два тома, перечисленные в конце, являются "именованными томами", о которых говорит докер, и они по какой-то причине пусты: они должны быть пустыми при запуске сценария и будут заполнены одним из контейнеров. (На самом деле, он может быть заполнен обоими или ни одним, в зависимости от нескольких факторов.)

Одним из побочных эффектов этого является то, что объемы сохраняются.

• "Это хорошо" для эффективности, потому что оно не воссоздается без необходимости.
• "Это плохо", потому что одним из преимуществ виртуализированных сервисов является то, что вы можете перезапустить его и получить гарантию на чистую доску. С постоянными именованными томами вы (автоматически) не получите чистого листа, так как файлы, использованные в предыдущем примере, будут использоваться вместо строгой версии на нижнем слое fs.

Способ обойти это "плохое" - это сбросить громкость вручную. Это можно сделать либо при завершении работы с помощью docker-compose down -v , что в справке:

    -v, --volumes       Remove named volumes declared in the `volumes` section
                        of the Compose file and anonymous volumes
                        attached to containers.

Это также можно сделать вручную с помощью docker volume rm <volume-id> или docker volume prune (которое удаляет все неиспользуемые в настоящее время тома, временные или именованные или что-либо еще).