自从 Docker 出世后应用容器化便成为了未来开发运维一体化的趋势。Docker 推荐的理念是一个容器只跑一个进程，但是现在大家倾向于把它理解为广义上的单进程——即一个容器只运行一个应用服务，将所有服务模块化。
在这里遇到了一个问题，Nginx 这厮到底需不需要容器化？
强行容器化
Nginx 是有官方镜像的，那么说明 Nginx 官方也支持将其容器化，但是问题来了，Nginx 的配置文件要怎么放进容器中。
- VOLUME 机制
将所有站点的配置文件放在同一个目录里，然后将其 VOLUME 进去，那么 Nginx 容器在启动的时候就能自动找到这些配置文件并全部加载。但是问题又来了，如果有时候你改错了一个配置文件，你不得不频繁地 restart 容器来调试。
应该没人说写个 Dockerfile 重新生成一个镜像吧？
使用 nginx-proxy
nginx-proxy 是一个非常有意思的镜像，你可以通过 docker pull jwilder/nginx-proxy:latest 来得到它。
查阅下文档你会发现它通过宿主机上的 /var/run/docker.sock 来自动代理所有需要反代的容器。
当你启动了 nginx-proxy 之后，在你任何需要反代的容器上设置对应的几个环境变量就可以被 nginx-proxy 容器捕获并自动反代，这么一来就没有繁杂的配置文件，而变成了一个个容器里的环境变量。
缺点就是启动其他容器的过程变得相对较复杂，但是我们还有 docker-compose 这些工具，因此可以更好地使用这个 nginx-proxy。
干脆不将 Nginx 容器化
其实也可以不将 Nginx 容器化。Docker 本身为了缓解的是软件交付时部署人员的痛苦经历，但是对于 Nginx 而言，其实并没有多少学习成本，或者说你当你不会配置 Nginx 时，即使把 Nginx 容器化，你也不得不去手动调整 Nginx 的各项参数。
索性干脆不将其容器化，而是作为所有容器的统一反代进行服务。Nginx 作为一个比较通用的软件，安装 Nginx 大部分情况下可能就是一个包管理语句，因此这么做也是可以接受的。
