![使用 ALB 定位 PHP-FPM ECS 容器](https://linux22.com/image/769456/%E4%BD%BF%E7%94%A8%20ALB%20%E5%AE%9A%E4%BD%8D%20PHP-FPM%20ECS%20%E5%AE%B9%E5%99%A8.png)
我很想知道这是否真的可行,但我确信我已经看到我们的一位旧 AWS TAM 演示了这一点。
我在托管 PHP 应用程序的 ECS 中提供 PHP-FPM 容器(端口 9000)。我正在考虑用 ALB 替换 nginx 盒。
本质上,通过端口 80 进入 ALB 的请求应该使用原始请求数据在端口 9000 处执行应用程序的入口点。
我曾尝试摆弄目标群体,但无法弄清楚如何执行 nginx 提供的相同 ProxyPass 功能。
这可能吗?如果可能的话,怎么做呢?
答案1
我很想知道这是否真的可行,但我确信我已经看到我们的一位旧 AWS TAM 演示了这一点。
我期待这个解决方案。
根据我的理解,我得出的结论是,NGINX 背后的 PHP-FPM 是最简单的解决方案。原因:
- 快速CGI是用于将交互式程序与 Web 服务器对接的二进制协议。因此,PHP-FPM 公开的端口 9000 不适合直接在 AWS ELB 后面使用。
- PHP 的内置 Web 服务器不应在生产环境中使用。
- 让同一台服务器同时充当 Web 服务器和应用服务器是一种不好的做法。应用服务器的资源将被 Web 服务器占用,反之亦然。每台服务器都有其优点。我们使用 NGINX,因为它作为 Web 服务器经过了实战测试。我们使用 PHP-FPM 作为其主要的 PHP FastCGI 实现。我们不应该用 AK-47 来杀老鼠,我们应该使用捕鼠器。
- AWS ELB 后面的 Django + Gunicorn 应用程序运行顺畅,直到慢速客户端开始发送请求。NGINX 可以轻松处理慢速客户端,因为它会缓冲并将完整的请求(所有 TCP 数据包)转发到 Gunicorn。参考:Gunicorn 部署。这也适用于 PHP-FPM。
- NGINX 可轻松提供静态文件,并使用 GZIP 对其进行压缩。话虽如此,静态文件应使用 S3 等对象存储来提供。