使用 docker 设置 puma、rails 和 nginx 的正确方法是什么？

Question

我有一个使用 Puma 的 Rails 应用程序。我正在使用 nginx 进行负载平衡。我想进行 dockerize 并部署到 DigitalOcean (Docker) Droplet。

在阅读了大量博客和示例之后（其中大部分已有一年的历史，这在 Docker 世界中已经很长时间了），我仍然对两件事感到困惑。假设我选择了带有 4 个 CPU 的 DigitalOcean 盒子。我应该如何设置 Rails 容器？我应该设置 4 个不同的容器，其中 Puma 配置有 1 个工作进程吗？或者我应该设置 1 个容器，其中 Puma 配置有 4 个工作进程？

我感到困惑的第二件事是：我应该在 Rails 容器内运行 nginx，还是应该在单独的容器中运行它们？

这 2 个问题允许 4 种排列，如下图所示。

选项1

选项2

选项3

选项4

Answer 1

Docker 喜欢推动每个容器单一进程的设计风格。当在单个容器中运行多个进程时，Docker 和底层进程之间存在额外的服务管理器层，这会导致 Docker 失去真实服务状态的可见性。这通常会使使用 Docker 及其相关工具管理服务变得更加困难。Puma 管理工作人员不会像运行多个进程的通用服务管理器那么糟糕。

您可能还需要考虑应用程序中的下一步，跨多个 Droplet/主机进行托管，以及如何轻松地进入下一步。

选项 1 和 3 遵循 Docker 的首选设计。如果您使用 MRI，Puma 可以在集群模式下运行，因此这仅取决于您是想自己管理 Ruby 进程 (1) 还是让 Puma 进行工作管理 (3)。nginx 和 Puma 在工作进程之间分配请求的方式会有所不同。Puma 还可以安排零停机时间更新，这需要一些努力才能通过 Docker 进行工作。如果您使用 Rubinius 或 JRuby，您可能会倾向于选项 3，让线程完成工作。

选项 1 可以让您使用 Docker 工具更轻松地跨不同大小的主机进行扩展。

选项 2 看起来添加了不必要的应用程序跃点，并且 Docker 不再维护应用程序层中的服务状态，因为您需要容器中的其他内容来启动 nginx 和 Puma。

由于本地套接字，选项 4 的性能可能比其他选项好一些，但 Docker 不再了解服务状态。

无论如何，请尝试几种解决方案，并使用 JMeter 之类的工具对它们进行基准测试。您将很快了解在绩效和管理方面什么有效、什么无效。