我有一个使用 Puma 的 Rails 应用程序。我正在使用 nginx 进行负载平衡。我想 dockerize 并部署到 DigitalOcean (Docker) droplet。
在阅读了大量博客和示例(其中大部分是一年前的，并且在 Docker 世界中已经很长时间了)之后，我仍然对两件事感到困惑。假设我选择了一个带有 4 个 CPU 的 DigitalOcean 盒子。我应该如何设置 Rails 容器？我应该设置 4 个不同的容器，其中 Puma 配置有 1 个工作进程吗？或者我应该设置 1 个容器，其中 Puma 配置了 4 个工作进程？
我感到困惑的第二件事是:我应该在 Rails 容器中运行 nginx，还是应该在单独的容器中运行它们？
这两个问题允许我在下面绘制的 4 个排列。
选项1
选项 2
选项 3
选项 4
最佳答案
Docker 喜欢按容器的设计风格推送单个进程。当在单个容器中运行多个进程时，在 Docker 和底层进程之间有一个额外的服务管理器层，这会导致 Docker 失去对真实服务状态的可见性。这通常会使服务更难使用 Docker 及其相关工具进行管理。 Puma 管理 worker 不会像运行多个进程的通用服务管理器那么糟糕。
您可能还需要考虑应用程序的下一步，跨多个 Droplet/主机托管，以及如何轻松地移动到下一步。
选项 1 和 3 遵循 Docker 的首选设计。如果您使用 MRI，Puma 可以在集群模式下运行，因此这取决于您是要自己管理 Ruby 进程 (1) 还是让 Puma 进行工作人员管理 (3)。 nginx 和 Puma 在 worker 之间分配请求的方式会有所不同。 Puma 还可以安排零停机时间更新，这需要一些努力才能通过 Docker 工作。如果您正在使用 Rubinius 或 JRuby，您可能会倾向于选项 3 并让线程来完成工作。
选项 1 可能允许您使用 Docker 工具更轻松地跨不同大小的主机进行扩展。
选项 2 看起来像是添加了一个不必要的应用程序跃点，并且 Docker 不再维护应用层中的服务状态，因为您需要容器中的其他内容来启动 nginx 和 Puma。
由于本地套接字，选项 4 的性能可能比其他选项好一点，但 Docker 不再知道服务状态。
在任何情况下，尝试几个解决方案并使用 JMeter 之类的工具进行基准测试。您将很快了解在绩效和管理方面什么有效，什么无效。
关于ruby-on-rails - 使用 docker 设置 puma、rails 和 nginx 的正确方法是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40878753/