我们希望将当前的Nginx / Gunicorn / Django堆栈移植到Docker中，并使用Docker Swarm将其部署为高可用性。我们一直在努力的决定之一是将Nginx放在与Gunicorn / Django相同的容器中。以下是场景以及我们如何查看它们：
场景1 ：将Nginx放入应用程序的容器中。这违背了＆＃34;每个服务都有自己的容器＆＃34;方法，但它允许Nginx直接通过unix套接字而不是端口与Gunicorn通信。这显然不是很大，但值得一提。主要优点如下。这里潜在的缺点是从太多的Nginx实例中获得额外的开销（请对此进行权衡）。
场景2：将Nginx放在自己的容器中。虽然这遵循上述方法，但似乎更有缺陷。在Docker Swarm场景中，Nginx和App容器的分布可能不一致。一些节点最终可能有更多Nginx容器，而其他节点有更多的app容器（甚至可能有0个Nginx容器）。这意味着Nginx最终会完全反向代理不同主机上的应用容器。
现在我确定Docker Swarm支持特殊配置，即每个节点上必须至少运行一个Nginx容器，但这会让我感到反模式。即便在这种情况下，是否值得在场景1中付出努力？
答案 0 :(得分：4)
根据生产经验，最好是与docker docs one container for one process对应的规则。您正在发布带有泊坞窗图像的（微）服务，如果需要在其中包含nginx，则将其包含在内。
所以基本上django应用程序有：
在将nginx添加到容器时没有看到任何性能问题，但很少注意到docker图像大小。在ubuntu上：16.04 / debian：jessie通过添加nginx-full你可以增加你的图像大小~100mb左右。 （在第一次拉图像时有一些开销）。
所以第二种情况没有争议，因为你也可以在你的docker镜像后面添加nginx以达到平衡目的（或者是proxy_pass管理）。