docker为什么不运行同时使用–rm和-d的支持？

Docker的文档说–rm和-d不能一起使用： https ：//docs.docker.com/engine/reference/run/#detached-d

为什么？ 我似乎误解了“分离”的含义， 它似乎完全正交于–rm做什么。 他们为什么相互排斥？

通过类比，如果我在后台启动进程（例如启动my-service），并且进程退出，进程的资源将自动释放（通过init）。 它不坚持，等待我手动删除它。 为什么docker不允许我将-d和-rm结合起来，这样我的容器就可以以类似的方式工作？

我认为这将解决一个非常常见的用例。 似乎这将很好地避免以下解决方法： https : //thraxil.org/users/anders/posts/2015/11/03/Docker-and-Upstart/

我错过了什么？

Answer 1

因为--rm是作为客户端选项实现的：当你指定--rm ， --rm 客户端等待容器退出，然后删除它。

当你指定-d ，docker客户端退出 。 容器正在运行，并由Docker服务器进行pipe理。 不再有任何客户--rm运行来实现--rmfunction。

Answer 2

作为回答的一种方式，让我想象我使用-d和--rm启动一个容器，这是允许的。 docker run -d --rm --name=my_app my_container

如果我的应用按预期工作，它就会运行，当它到了死亡的时候，它就会死亡，并悄悄地移除，这意味着我可以用一点麻烦重新运行这个命令。 这似乎是理想的，你的问题是我为自己的项目设置了一些docker自动化的时候遇到的一个问题。

但是，如果出现问题，容器中运行的进程会遇到致命的错误并崩溃，导致容器死亡。 问题是，对于任何外部的观察者，无论是人类还是监控软件，都不能分辨出这两种情况的区别，除了容器有多长时间以外。

在不使用-d的情况下，在CLI中运行命令或使用upstart / initd / systemd / other，容器将写入输出，即使给出容器，该容器也将保留--rm ，从而允许发现错误或崩溃并解决。

在使用-d情况下，不将容器输出绑定到任何输出stream或文件，– --rm不允许确保有遗留的证据（以死容器的forms）存在错误/崩溃。

包装/ TL; DR：我相信这个有意识的select是由docker开发人员做的，以防止容器被完全不计算的情况下，权衡是需要添加两个更多的命令到您的自动化脚本。

Answer 3

从版本1.13开始，您现在可以使用--rm后台作业。 删除操作已从客户端移动到服务器以启用此操作。

有关更多详细信息，请参阅以下pull请求： https ： //github.com/docker/docker/pull/20848

这是一个新的行为的例子：

 $ docker run -d --rm --name sleep busybox sleep 10 be943302d668f6416b083b8b6fa74e254b8e4200d14f6d7743d48691db1a4b18 $ docker ps | grep sleep be943302d668 busybox "sleep 10" 4 seconds ago Up 3 seconds sleep $ sleep 10; docker ps | grep sleep