docker - docker内部有多少代理（nginx）层被认为太多了？

Question

我已经设置了 1 台机器。目前它看起来像这样：

• 证书 - Letecrypt 证书
• static # - react 应用的静态文件
• 应用程序 - api 后端

我不喜欢这个设置有几个原因：

• 证书由 certbot 控制，为了更新它们，我需要停止我的应用程序，在主机上启动 nginx 并进行更新。
• 所有 react 应用程序都在一个 nginx 容器中，但它们在逻辑上是分开的，应该在单独的容器中。也可能会考虑构建时间，但在多阶段构建中，每个阶段都很好地缓存，所以没关系。
• 应用路由逻辑与 React 应用相结合

这就是为什么我想出另一种设计：

一个 nginx 实例在主机上，它由 certbot 控制并将所有流量重定向到 docker 容器。

每个反应应用程序都位于单独的容器中，并带有自己的 nginx 服务静态文件。

唯一暴露的容器是“nginx 路由器”，它控制应如何分配流量。

我真的很喜欢这种设置，它很好而且模块化，但它可能有两个问题：

• 潜在的性能问题，因为 nginx 东西太多。
• 使用 docker 时，在主机上运行除 docker 之外的东西可能是不好的做法。

标签： dockernginx

Answer 1

如您所想，容器传统上应该是单进程的。还要避免混合主机/容器上下文，它确实不是一个可维护/可扩展的解决方案。容器应尽可能无状态。

对于生产，您可能希望顶层（路由）是一些托管负载平衡服务，它将为您处理 SSL 终止，具有无限可扩展性，并且足够便宜（考虑到设置很容易且无需维护）。在您的场景中，除非您需要对某些部分进行完全手动控制的非常非常非常具体的东西，否则设置和维护会非常痛苦。

如果可以的话，静态资产也应该托管在 CDN 后面（如果您喜欢 AWS，则 S3 + CloudFront，但任何其他选项都可以）。

对于本地发展，谁在乎 :-) 性能不会很快成为问题。

此外，如果你真的想走这条路，你可能想要检查 haproxy，如果你想做的只是基本路由，它比 nginx 轻得多。