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

Question

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

Answer 1

根据生产经验，最好从docker docs对应one container for one process规则来one container for one process 。 您正在发送带有泊坞窗图像的（微）服务，如果需要在其中包含nginx，则将其包含在内。

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

1. nginx（例如：用于静态文件）
2. gunicorn或uwsgi
3. django代码本身

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

因此，对于第二种情况，这不是争议，因为您还可以在您的docker映像后面添加nginx以实现平衡目的（或proxy_pass管理）。