我应该在Docker容器内运行init进程吗？

Question

我最近研究了一些有关Docker的最佳实践，并发现了处理init进程的不同意见。

如此处所指出的，根本不应运行init进程。我可以理解容器应该模拟单个进程而不是整个操作系统的想法。

另一方面，正如这里所述，如果我忽略基本的操作系统服务，如syslog等，则可能会出现问题。

通常情况下，可能没有绝对的答案来处理这些情况。您能分享一些有关此主题的经验或更多见解吗？对我来说，这两种方法都合理。

- soupdiver

---

我不明白这个问题与编程主题有什么关系。 - Andy

Answer 1

作为处理这些情况的绝对答案可能并不常见。您能分享一些经验或更多关于这个话题的见解吗？对我来说，两种方法都是合法的。

非常准确。这个问题没有绝对的答案。

现在，话虽如此，我认为单进程每个容器模型有很大优势，因为这真的鼓励您创建可组合的容器（像乐高积木：您可以将它们以不同的组合方式放在一起来解决问题），并且是可伸缩的（您可以轻松地启动特定服务的更多实例）。通过不做疯狂的事情，比如在容器内运行ssh守护程序，您会受到阻碍，不会“就地”编辑东西，并且希望更多地依赖Dockerfiles生成映像，从而导致更加强大、可重复的过程。

另一方面，有些应用程序不适合这种模型。例如，如果您有一个应用程序分叉了很多子进程，并且没有正确地wait()它们，那么您最终会得到一组僵尸进程。您可以运行一个完整的init进程来解决这个特定的问题，或者您可以运行一些简单的东西像这样（免责声明：我写过）或者这个。

有些应用程序非常紧密耦合，虽然通过大量使用Docker卷和--net=container:...可以将它们运行在单独的容器中，但让它们在同一个容器中运行更容易。

登录Docker是特别具有挑战性的。在容器内运行某种日志收集器以及您的应用程序可能是解决这个问题的一种方法，但也有其他解决方案。Logspout是一个有趣的解决方案，但我也一直在研究在容器内运行systemd以利用journald进行日志记录。因此，虽然我仍在每个容器中运行一个应用程序进程，但我也有一个init进程和一个journald进程。

因此，最终情况实际上取决于情况：取决于您的需求以及您尝试运行的特定应用程序的需求。即使在单个容器每个进程不可能的情况下，设计容器以提供单个服务仍然会带来我在第一段中提到的许多优点。

- larsks