Мне бы хотелось узнать, возможно ли это на самом деле, но я уверен, что видел, как это демонстрировал один из наших старых AWS TAM.
Я обслуживаю контейнеры PHP-FPM (порт 9000) из ECS, размещая приложение PHP. Я рассматриваю замену ящика(ов) nginx только на ALB.
По сути, запросы через порт 80 в ALB должны выполнять точку входа приложения на порту 9000 с исходными данными запроса.
Я пробовал экспериментировать с целевыми группами, но не смог понять, как реализовать ту же функциональность ProxyPass, которую предоставляет nginx.
Возможно ли это? И если да, то как?
решение1
Мне бы хотелось узнать, возможно ли это на самом деле, но я уверен, что видел, как это демонстрировал один из наших старых AWS TAM.
Я с нетерпением жду этого решения.
Насколько я понимаю, я пришел к выводу, что PHP-FPM за NGINX — самое простое решение. Причины:
- FastCGIэто бинарный протокол для сопряжения интерактивных программ с веб-сервером. Поэтому порт 9000, предоставляемый PHP-FPM, не подходит для использования непосредственно за AWS ELB.
- Встроенный веб-сервер PHPне следует использовать в производственных условиях.
- Плохая практика — позволять одному и тому же серверу быть веб-сервером и сервером приложений. Ресурсы сервера приложений будут захвачены веб-сервером и наоборот. У каждого сервера есть свои преимущества. Мы используем NGINX, так как он прошел боевые испытания в качестве веб-сервера. Мы используем PHP-FPM в качестве основной реализации PHP FastCGI.Нам не следует использовать АК-47, чтобы убить мышь, нам следует использовать мышеловку.
- Приложения Django + Gunicorn за AWS ELB работают гладко, пока медленный клиент не начнет отправлять запросы. NGINX упрощает работу с медленными клиентами, поскольку он буферизует и пересылает полные запросы (все пакеты TCP) в Gunicorn. Ссылка:Развертывание Gunicorn. Это применимо и к PHP-FPM.
- NGINX помогает обслуживать статические файлы с легкостью и сжимает их с помощью GZIP. При этом статические файлы должны обслуживаться с использованием объектного хранилища, например S3.