主管在docker中的使用

我不是在问码头工人如何使用监督员，只是想验证我的理解

我知道docker在运行时只运行一个进程。另外，当我们需要在容器中运行多个进程时，可以使用supervisor

我见过几个例子，其中一个容器是从基本映像启动的，安装了几个服务，并且容器承诺形成一个新映像，所有这些都没有管理器

因此，我的基本疑问是这两种方法之间的区别是什么

我的理解是，当docker容器停止时，它向PID为1的进程发送终止信号，PID为1管理子进程并停止所有子进程，这正是主管所做的，虽然我们可以安装多个进程，但在发出

docker run

时，只有一个进程可以运行，当容器停止时，只有PID 1会发送信号，其他运行进程不会正常停止

请确认我对使用

supervisord

的理解是否正确

虽然我们可以安装多个进程而无需管理器，但当docker run发出时，只能运行一个进程，当容器停止时，只发送PID 1信号，其他运行进程不会正常停止

是的，不过这取决于主进程的运行方式（前台或后台）以及它收集子进程的方式

这是在“”中详细介绍的内容

docker stop

通过发送

SIGTERM

信号停止正在运行的容器，让主进程对其进行处理，并在宽限期后使用

SIGKILL

终止应用程序

发送到容器的信号由正在运行的主进程（PID 1）处理

如果应用程序位于前台，这意味着应用程序是容器（PID1）中的主进程，那么它可以直接处理信号

但是：

要发送信号的进程可以是后台进程，您不能直接发送任何信号。在这种情况下，一种解决方案是将shell脚本设置为入口点，并在该脚本中协调所有信号处理

有关此问题的详细信息，请参见“”

Unix的设计方式是父进程必须显式地“等待”子进程终止，以便收集其退出状态。在父进程使用系统调用的

waitpid（）

系列执行此操作之前，僵尸进程一直存在

对子进程调用waitpid（）以消除其僵尸的操作称为“收获”

init

进程——PID 1——有一个特殊任务。它的任务是“采用”孤儿进程

操作系统希望init进程也能获得被收养的子进程。

Docker的问题：

我们看到很多人在他们的容器中只运行一个进程，他们认为当他们运行这个进程时，他们就完成了。
但最有可能的是，此进程的编写方式与正常的初始化进程不同。
也就是说，它可能期望另一个

init

进程来完成这项工作，而不是正确地收获所采用的进程，这是正确的

使用像这样的映像有助于管理一个（或多个）进程，同时保持主进程init兼容

对于多流程管理，它使用：

没有办法解决收成问题。相反，它需要支持多个流程。为了安全起见，鼓励使用多个进程（通过进程和用户隔离）。
Runit使用的内存比以前少，因为Runit是用C编写的，而Supervisord是用Python编写的。
在某些用例中，容器中的进程重启比整个容器重启更可取

该图像包括一个处理“收获”问题的图像

在baseimage docker中，我们鼓励在单个容器中运行多个进程。但不一定有多个服务。
一个逻辑服务可以由多个操作系统进程组成，我们提供了方便的工具

---

docker 1.12于2016年9月更新（2016年第4季度/2017年第1季度）

只是：

---

[Docker文档中的这篇文章展示了一个运行多个进程并使用supervisord的示例

我可以很好地处理这个问题，但我们可能只是将我们的工作进程卸载到另一个容器中，并且每个容器中只处理一个进程。

---

这是一种更简单的方法。

谢谢你详细的回答。我正在尝试phusion image，据我所知，每当容器启动时，它都会运行/etc/init.d中的任何内容。但是，我在init.d中有一个服务，它不是在容器启动时启动的。你能帮助我吗？当然，你能问一个新问题，并提供详细信息吗你的新设置是什么？这样，我（可能还有其他人）可以看一看。哦，我的错误是/etc/my_init.d这里的关键是更新2016年9月：见下面：docker守护进程可以在docker 1.12中为你处理那些僵尸进程。