为什么建议只在容器中运行一个进程？

Question

在许多博客文章中，以及一般的观点中，有句谚语说“每个容器都有一个过程”。

为什么会有这样的规则？为什么不在单个容器中运行ntp、nginx、uwsgi和更多的进程？

博客文章提到了这条规则：

• “单进程容器是码头应用程序推荐的设计模式”
• “码头只用于创建单进程或单一服务容器”
• “最好每个容器使用一个进程”
• “以容器形式运行单个服务”
• “每个集装箱一个过程”
• “每个集装箱一个过程”

Answer 1

让我们暂时忘掉高层建筑和哲学上的争论吧。虽然在某些边缘情况下，单个容器中的多个函数可能是有意义的，但有一些非常实际的理由可以让您考虑遵循“每个容器一个函数”作为经验规则：

• 如果容器被隔离到单个函数中，横向缩放容器就容易多了。需要另一个apache容器吗？把一个转到别的地方。但是，如果我的apache容器也有我的DB、cron和其他嵌在鞋里的碎片，那么事情就变得复杂了。
• 每个容器都有一个功能，可以方便地将容器重新用于其他项目或目的。
• 它还使devs将组件从生产中拉下来，用于本地而不是整个应用程序环境的故障排除，具有更好的可移植性和可预测性。
• 修补/升级(包括操作系统和应用程序)可以以更加隔离和控制的方式进行。在您的容器中杂耍多个位和块不仅可以生成更大的图像，而且还可以将这些组件连接在一起。为什么只有关闭应用程序X和Y才能升级Z？
  • 以上也适用于代码部署和回滚。

• 从安全和隔离的角度来看，将函数拆分到多个容器可以提供更大的灵活性。您可能希望(或要求)服务在网络级别上被隔离--无论是物理上还是在覆盖网络中--以保持强大的安全态势或遵从PCI之类的东西。
• 其他更次要的因素，如处理stdout/stderr和将日志发送到容器日志，保持容器尽可能短暂等等。

注意，我说的是函数，而不是进程。这种语言已经过时了。正式的码头文档已经搬走了从说“一个过程”改为推荐每个容器“一个关注点”。

Answer 2

在几天前杀死了一个“两个进程”容器之后，我有一些痛苦之处，这使我不得不使用两个容器，而不是一个启动两个进程的python脚本：

1. 码头工人擅长识别坠毁的集装箱。当主进程看起来很好时，它无法做到这一点，但其他一些进程却死了，令人毛骨悚然。当然，您可以手动监视您的流程，但是为什么要重新实现呢？
2. 当多个进程将它们的日志释放到控制台时，docker日志就不再那么有用了。同样，您可以将进程名写入日志，但docker也可以这样做。
3. 关于容器的测试和推理变得更加困难。

Answer 3

推荐来自于操作系统级虚拟化的目标和设计。

容器被设计为通过为进程提供自己的用户空间和文件系统来隔离其他进程。

这是chroot的逻辑发展，它提供了一个独立的文件系统，下一步是将进程与其他进程隔离开来，以避免内存覆盖，并允许从多个进程中无冲突地使用相同的资源(例如，TCP端口8080 )。

容器的主要兴趣在于它可以为流程打包所需的库，而不必担心版本冲突。如果您在同一个用户空间和文件系统中运行两个版本的相同库的倍数进程，则必须至少为每个进程调整LDPATH，以便首先找到适当的库，并且某些库不能这样调整，因为它们的路径在编译时是在可执行文件中硬编码的，有关更多细节，请参阅这个问题。

在网络级别，您必须配置每个进程以避免使用相同的端口。

在同一个容器中运行多个进程需要一些很大的调整，而且在一天结束时，如果您可以在同一个用户空间内运行多个进程，共享相同的文件集和网络资源，那么为什么不在主机本身上运行它们呢？

以下是我能想到的重大调整/陷阱的非详尽清单：

• 使用挂载卷或在stdout上交错处理日志，这会带来一些管理。如果使用装入的卷，您的容器应该在主机上有自己的“位置”，或者两个相同的容器将争夺相同的资源。当在stdout上交织以利用docker logs时，如果不能很容易地识别源，就会成为分析的噩梦。
• 如果容器崩溃中的某个进程无法清理处于僵尸状态的子进程，则要小心僵尸进程，并且主机init将永远不会继承它们。一旦耗尽了可用的pids数量(2^22，大约400万)，很多事情就会失败。
• 如果您运行两个分离的东西(比如apache服务器和同一个容器中的logstash )，可能会简化日志处理，但您必须关闭apache才能更新logstash。(实际上，您应该使用Docker的日志驱动程序)，等待当前会话结束会不会是一个优雅的停止呢？如果这是一个优雅的停留，它可能需要一些时间和时间来推出新的版本。如果你杀了一个人，你会影响一个日志发货人的用户，这应该避免IMHO。

最后，当您有多个进程时，您正在复制一个OS，在本例中，使用硬件虚拟化听起来更符合这一需要。