我们希望将当前的Nginx / Gunicorn / Django堆栈移植到Docker中,并使用Docker Swarm将其部署为高可用性.我们一直在努力的决定之一是将Nginx放在与Gunicorn / Django相同的容器中.以下是场景以及我们如何查看它们:
场景1:将Nginx放在应用程序的容器中.这违反了“每个服务都有自己的容器”方法,但它允许Nginx直接通过unix socket而不是端口与Gunicorn进行通信.这显然不是很大,但值得一提.主要优点如下.这里的一个潜在缺点是从太多的Nginx实例中获得额外的开销(请加以考虑).
场景2:将Nginx放在自己的容器中.虽然这遵循上述方法,但似乎更有缺陷.在Docker Swarm场景中,Nginx和App容器的分布可能不一致.一些节点最终可能有更多Nginx容器,而其他节点有更多的app容器(甚至可能有0个Nginx容器).这意味着Nginx最终会完全反向代理不同主机上的应用容器.
现在我确定Docker Swarm支持特殊配置,这些配置说每个节点上必须至少运行一个Nginx容器,但这让我觉得它是反模式.即使在那种情况下,是否值得在场景1中付出努力?
所以基本上对于django应用程序有:
> Nginx(例如:用于静态文件)
> gunicorn或uwsgi
> django代码本身
将Nginx添加到容器时没有看到任何性能问题,但很少注意到docker图像大小.在ubuntu上:16.04 / debian:jessie通过添加Nginx-full你可以增加你的图像大小~100mb左右. (首先拉动图像的一些开销).
因此,对于第二种情况,这不是争议,因为您还可以在您的docker映像后面添加Nginx以实现平衡目的(或proxy_pass管理).