自从 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 大部分情况下可能就是一个包管理语句,因此这么做也是可以接受的。