在runit/daemontools监督下运行坞进程是否合理？

Question

我一直在运行停靠程序(应用程序)

docker run …

但是在runit supervision (runit就像daemontools)下--所以runit确保进程保持不间断，传递信号等等。

这合理吗？Docker似乎想要运行它自己的妖魔化--但它没有runit那么彻底。此外，当runit重新启动应用程序时--每次都会创建一个新容器(很好)，但它会留下旧容器的痕迹--这似乎意味着我做的方式不对。

码头不应该这样经营吗？

我是否应该从映像中设置一个容器，只设置一次，然后让runit一直运行/监督该容器？

Answer 1

Docker确实做了一些守护容器的管理:如果系统关闭，那么当Docker守护进程启动时，它也会重新启动系统关闭时正在运行的任何容器。但是，如果容器自己退出，或者内核(或用户)在容器运行时杀死它，那么Docker守护进程就不会重新启动它。在需要重新启动的情况下，流程管理器是有意义的。

我不知道runit，所以我不能给出具体的配置指导。但是，您可能应该让流程管理器与docker守护进程通信，并检查给定的容器id是否正在运行(docker ps | grep container_id或等效的，或者直接使用Docker )。如果容器已停止，请使用Docker重新启动它(docker run container_id)，而不是运行新容器。或者，如果每次都需要一个新容器，那么从docker run -rm开始，在它退出或停止时自动清理它。

如果您不希望您的流程管理器进行轮询，您可以运行一些监视docker events的程序。

您可以在启动容器作为启动守护进程的返回值时获得container_id，也可以要求Docker将其写入文件(docker run -cidfile myfilename，类似于PID文件)。

我希望这能帮助或帮助另一位runit大师提供更详细的建议。

Answer 2

是的，我认为在runit下经营码头是有道理的。通常，当您启动一个进程时，有一种方法可以告诉它在默认情况下不要去守护它，因为从runit run脚本到进程的一般方法是通过run脚本的最后一行的exec。对于停靠者来说，这意味着确保不设置-d标志。

例如，对于docker，您可能希望运行脚本如下所示：

#!/bin/bash -e
exec 2>&1
exec chpst -u dockeruser docker run -a stdin -a stdout -i ...

使用exec和chpst应该可以解决大多数问题，当您关闭runit服务时，进程没有正确终止。