Docker — Php-Fpm С Nginx В Разных Контейнерах (Обмен Ответом Init.d Между Собой)

У меня есть настройка Docker для моего проекта с PHP-FPM, Nginx и многими другими службами, необходимыми приложению, но внутри приложения PHP мне нужно проверить init.d/nginx configtest for new dynamic Vhosts (which are shared by volumes) generated for a tenancy based service.

Главное, что я не хочу создавать единый контейнер с PHP-FPM и Nginx из соображений масштабируемости.

Моя идея состоит в том, чтобы использовать любой пакет Linux для просмотра любых изменений в папке (в моем случае это папка Vhosts), а также тестировать, а затем перезагрузить службу.

Есть предложения?

Примечание. У меня есть RabbitMQ в одном контейнере, который используется приложением PHP, но теперь мне нужно соединить его с контейнером на основе Nginx (я не знаю, есть ли для этого CLI или собственный клиент Linux).

#докер #nginx #php

Вот nginx и PHP сделано как образ s2i builder. По сути, вы можете иметь простой старый PHP в репозитории git и запустить s2i, чтобы создать образ времени выполнения, который запускает его с помощью nginx и php. Вы просто создаете этот файл docker и передаете полученный образ в качестве образа компоновщика в s2i вместе с исходным кодом.

Вы заметите, что я заархивировал этот проект. Это потому, что у Redhat есть исправленный образ безопасности для php по адресу https://access.redhat.com/containers/#/registry.access.redhat.com/rhscl/php-72-rhel7 они используют apache httpd, но поскольку я не вижу, чтобы я использовал команду s2i «создайте контейнер времени выполнения для моего php-кода в git», и это просто работает, и я получаю частые исправления безопасности, это намного проще, чем возиться с моим собственным файлом Docker. делать патчи безопасности.

Использование Apache v2.4+ с отключенным mod_php, включенным php-fpm и mpm_event (вместо mpm_prefork по умолчанию) обеспечивает лучшую производительность (и параметры настройки, IMO) для PHP/PHP-FPM и многопоточных процессов. Использование nginx в качестве интерфейсного веб-сервера в «выборочном обратном прокси-сервере для apache2/httpd для процессов PHP» по-прежнему будет предлагать дополнительные преимущества, такие как превосходное статическое обслуживание файлов, параметры кэширования + простой обратный прокси-сервер + набор функций балансировки нагрузки nginx и добавление превосходная многопоточная производительность Apache.

Мой «ответ» здесь будет:

Я рекомендую использовать Apache v2.4+ в качестве серверной части для процессов PHP с nginx в качестве общедоступного обратного прокси-сервера. Основная проблема, по-видимому, связана с масштабируемостью, поэтому я думаю, что мое предложение обеспечит большую масштабируемость и уменьшит потребление ресурсов «в масштабе» с минимальным увеличением потребления ресурсов в режиме ожидания.

=============================

Вот тут-то и проявляется мое любопытство (то есть чувство любопытства, возможно, удалю позже, я не знаю):Извините, если я занимаюсь некромантией в этой теме, но материал и контент по теме отделения PHP-FPM от веб-сервера в отдельный контейнер ограничены.

Я здесь спрашивал именно об этой теме

, а здесь в ОП есть смутное упоминание о "причинах масштабируемости".

Хотя мой «ответ» на самом деле не отвечает на вопрос, предложенный в ФП... Это я предлагаю решение, спрашивая: «Действительно ли это вообще правильный вопрос?»

Я согласен с основной мыслью, которую пытается донести @simbo1905. Просто используйте тот же контейнер для веб-сервера + php-fpm.

Но...

Что такого в том, что отключение PHP-FPM от веб-сервера (в данном случае: nginx) увеличивает масштабируемость приложения? Почему бы не использовать несколько экземпляров совпадающих контейнеров с nginx+php-fpm, работающими вместе? Как предполагает ответ @simbo1905 с apache2+php-fpm?

Я вижу, что высказываются мнения о безопасности и масштабируемости. Я понимаю концепцию масштабирования экземпляров контейнеров php-fpm при большой нагрузке, но nginx позволяет ОЧЕНЬ легко балансировать такую ​​нагрузку. Почему бы не получить дополнительное преимущество в виде дополнительных ресурсов с балансировкой нагрузки, если вы обеспокоены масштабируемостью использования ресурсов php-fpm?

Я не уверен, какие преимущества дает запуск отдельного экземпляра PHP-FPM, если вы можете просто «потратить» дополнительные крошечные КБ дискового пространства и оперативной памяти для более стабильного и производительного приложения. Если происходит сбой процесса(ов) PHP-FPM или процесса(ов) nginx, происходит сбой приложения.