Question

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

为什么呢？我似乎误解了什么＆＃34;分离＆＃34;手段;它似乎与--rm完全正交。他们为什么互相排斥？

通过类比，如果我在后台启动进程（例如启动my-service），并且进程退出，则进程的资源将自动释放（通过init）。它并没有停留，等我手动删除它。为什么没有docker允许我将-d与-rm结合使用，以便我的容器以类似的方式工作？

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

我缺少什么？

Answer 1

因为--rm是作为客户端选项实现的：当您指定--rm时，docker 客户端会等待容器退出，然后将其删除。

指定-d时，泊坞窗客户端退出。容器正在运行，由Docker服务器管理。不再有任何客户端运行来实现--rm功能。

Answer 2

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

如果我的应用程序按预期工作，它将会运行，当它到时间死亡时，它会死亡并悄然消失，这意味着我可以轻松地重新运行此命令。这似乎是理想的，你的问题是我在为我的项目设置一些docker自动化时遇到的问题。

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

如果未使用-d，在CLI中运行命令或使用upstart / initd / systemd / other，则容器会写入输出，即使容器被赋予--rm，也会保留输出，从而允许出错或崩溃以引起注意和解决。

如果使用-d，不将容器输出绑定到任何输出流或文件，则不允许--rm确保以死容器的形式留下遗留的证据，错误/崩溃。

结束/ TL; DR：我相信这个有意识的选择是由码头工人开发的，以防止容器完全下落不明的情况需要再加两个容器命令自动化脚本。

Answer 3

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

有关详细信息，请参阅以下提取请求：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

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

3 个答案: