我们希望将当前的 Nginx/Gunicorn/Django 堆栈迁移到 Docker 中，并使用 Docker Swarm 部署它以实现高可用性。我们一直在努力做出的决定之一是是否将 Nginx 与 Gunicorn/Django 放在同一个容器中。以下是这些场景以及我们如何看待它们:
场景 1:将 Nginx 放置在应用的容器中。这违背了“每个服务都有自己的容器”的方法论，但它允许 Nginx 直接通过 unix 套接字而不是端口与 Gunicorn 通信。这显然不是很大，但值得一提。主要优点如下。这里的一个潜在缺点是过多的 Nginx 实例会产生额外的开销(请权衡一下)。
场景 2: 将 Nginx 放在自己的容器中。尽管这遵循了上述方法，但似乎存在更多缺陷。在 Docker Swarm 场景中，Nginx 和 App 容器的分布可能不统一。一些节点可能最终拥有更多的 Nginx 容器，而其他节点则拥有更多的应用程序容器(甚至可能有 0 个 Nginx 容器)。这意味着 Nginx 最终会在完全不同的主机上反向代理应用程序容器。
现在我确信 Docker Swarm 支持特殊配置，即每个节点上必须至少运行一个 Nginx 容器，但这让我觉得这是一种反模式。即使在那种情况下，是否值得为场景 1 付出努力？
最佳答案
根据生产经验，最好从docker docs one container for one process中对应规则。您正在使用 docker 镜像发送(微)服务，如果需要在其中包含 nginx，则将其包含在内。
所以基本上对于 django 应用程序有:
- nginx(例如:静态文件)
- gunicorn 或 uwsgi
- django 代码本身
在将 nginx 添加到容器时没有看到任何性能问题，但很少注意 docker 镜像大小。在 ubuntu:16.04/debian:jessie 上，通过添加 nginx-full 可以将图像大小增加约 100mb。 (第一次拉取图像时会产生一些开销)。
所以它对第二种情况没有争议，因为你也可以在你的 docker 镜像后面添加 nginx 以达到平衡目的(或 proxy_pass 管理)。
关于django - 使用 Docker Swarm 部署时，nginx 是否应该与 Django 打包到同一个容器中？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40871089/