☰

nginx обратный прокси для php-fpm

tag-icon • tag-icon php nginx docker reverse-proxy
nginx обратный прокси для php-fpm

У меня возникли некоторые концептуальные проблемы с конфигурацией Nginx. Начиная с nginxSSL-terminator reverse-proxy, я использую 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-fpmphp-fpm

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

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

решение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:

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

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

  • «Это хорошо» для эффективности, поскольку не создается заново без необходимости.
  • "Это плохо", потому что одно из преимуществ виртуализации сервисов заключается в том, что вы можете перезапустить его и гарантированно получить чистый лист. С постоянными именованными томами вы не получаете (автоматически) чистый лист, поскольку файлы, использованные в предыдущем экземпляре, будут использоваться вместо строгой версии в нижнем слое 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(что удалит все неиспользуемые в данный момент тома, будь то временные, именованные или какие-либо еще).

Связанный контент