在使用Docker Swarm进行部署时,是否应将nginx打包到与Django相同的容器中?

前端之家收集整理的这篇文章主要介绍了在使用Docker Swarm进行部署时,是否应将nginx打包到与Django相同的容器中?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

我们希望将当前的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中付出努力?

最佳答案
根据生产经验,最好从docker docs对应一个容器的规则来处理一个进程.您正在发送带有泊坞窗图像的(微)服务,如果需要在其中包含Nginx,则将其包含在内.

所以基本上对于django应用程序有:

> Nginx(例如:用于静态文件)
> gunicorn或uwsgi
> django代码本身

Nginx添加到容器时没有看到任何性能问题,但很少注意到docker图像大小.在ubuntu上:16.04 / debian:jessie通过添加Nginx-full你可以增加你的图像大小~100mb左右. (首先拉动图像的一些开销).

因此,对于第二种情况,这不是争议,因为您还可以在您的docker映像后面添加Nginx以实现平衡目的(或proxy_pass管理).

原文链接:https://www.f2er.com/nginx/434480.html

猜你在找的Nginx相关文章