为什么Docker要将ngnix与PHP拆分为独立容器？二者如何协同工作？

为什么Nginx与PHP拆分独立服务的方案更普遍 #

拆分部署是Docker场景下的行业通用实践，比单整合镜像适用范围广的核心原因有这些：

• 符合Docker单进程最佳实践：Docker原生设计推荐单个容器仅运行一个主进程，进程异常退出时编排工具可直接感知并触发重启、迁移等操作。如果把两个服务打包在同一个镜像，需要额外引入supervisor等进程管理工具维护双进程运行，不仅增加配置复杂度，也会提高故障排查的难度。
• 运维解耦：Nginx和PHP的迭代、配置更新、故障修复的节奏完全独立，拆分后可以单独升级PHP版本、调整Nginx路由规则，单个服务故障重启也不会影响另一个服务的运行。
• 资源调度灵活：可以根据业务压力单独扩容对应服务的实例数，比如动态请求压力大时仅扩容PHP实例，静态资源请求压力大时仅扩容Nginx实例，大幅提升资源利用率。
• 镜像复用性高：官方维护的Nginx、PHP镜像稳定性、安全性都有保障，直接使用不需要自行维护整合镜像，避免了自定义镜像的配置错误、安全漏洞等风险。

两个容器挂载相同代码目录的协同运行逻辑 #

示例配置中两个服务加入了同一个默认网络，本身就可以互相通信，协同流程如下：

1. 用户请求首先到达Nginx容器的80端口，Nginx根据本地配置判断请求类型：如果是静态资源（css、js、图片、静态html等），直接从自身挂载的代码目录中读取对应文件，返回给用户即可，全程不需要和PHP服务交互。
2. 如果请求是PHP动态接口/页面，Nginx会通过FastCGI协议把请求转发给同网络下PHP服务的9000端口（PHP-FPM默认监听端口，不需要对外映射宿主机端口，同Docker网络内可直接访问）。
3. PHP容器收到请求后，从自身挂载的和Nginx同源的代码目录中找到对应PHP文件执行，把执行后的结果返回给Nginx，再由Nginx封装后返回给用户。
4. 两个容器挂载的是宿主机上的同一个目录，所以两边读取的代码版本完全一致，不会出现代码不一致的异常。

内容的提问来源于stack exchange，提问作者Oriam