用docker设置puma，rails和nginx的正确方法是什么？
我有一个使用Puma的Rails应用程序。 我正在使用nginx进行负载平衡。 我想dockerize和部署到DigitalOcean（docker）滴。
在阅读了大量的博客和例子（其中大部分都是一年，在Docker世界里已经很长时间了）之后，我仍然对2件事感到困惑。 假设我select一个带有4个CPU的DigitalOcean盒子。 我该如何设置Rails容器？ 我应该设置4个不同的容器，Pumaconfiguration了1个工作进程吗？ 还是应该在Pumaconfiguration4个工作进程的地方设置一个容器？
第二件事我很困惑：我应该在Rails容器中运行nginx，还是应该在不同的容器中运行它们？
这两个问题允许我在下面列出的4个排列组合。
选项1 
选项2 
选项3 
选项4 
Docker喜欢推动单容器风格的devise。 在单个容器中运行多个进程时，Docker和底层进程之间会存在额外的服务pipe理器层，导致Docker失去对实际服务状态的可视性。 这往往会让服务更难以pipe理Docker及其相关工具。 Pumapipe理人员不会像运行多个stream程的通用服务经理那样糟糕。
您可能还需要考虑应用程序中的下一个步骤，跨越多个小滴/主机进行托pipe，以及如何轻松移动到下一步。
选项1和3遵循Dockers首选devise。 如果您正在使用MRI，Puma可以运行在集群模式下，这取决于您是要自己pipe理Ruby进程（1）还是让Puma进行工作pipe理（3）。 Nginx和Puma如何在工作人员之间分配请求将会有所不同。 彪马还可以安排零停机时间更新，这将需要一点努力，通过docker工作。 如果你使用Rubinius或JRuby，你可能会倾向于选项3，并让线程完成这项工作。
选项1可能允许您使用Docker工具更轻松地跨不同大小的主机进行扩展。
选项2看起来像添加了不必要的应用程序跳转，并且Docker不再在应用程序层中维护服务状态，因为您需要容器中的其他内容来启动nginx和Puma。
由于本地套接字的原因，选项4可能会比其他的更好一些，但是Docker不再知道服务状态。
在任何情况下，尝试一些解决scheme，并用JMeter等东西进行基准testing。 在绩效和pipe理方面，您将很快了解什么是有效的，哪些不是。