ドッカーが--rmと-dを同時に使用してサポートを実行しないのはなぜですか？

Question

ドッカーのドキュメントによれば、--rmと-dを一緒に使うことはできません：https://docs.docker.com/engine/reference/run/#detached-d

なぜですか？私は「切り離された」ということを誤解しているようです。それは--rmがするものとは完全に直交しているようです。なぜ彼らは互いに排他的ですか？

例として、バックグラウンドでプロセスを開始し（my-serviceを開始するなど）、プロセスが終了すると、プロセスのリソースはinitによって自動的に解放されます。それは私が手動でそれを削除するのを待って、周りにはいません。なぜ私のコンテナが類似の方法で動作するように-dと-rmを組み合わせることができないのですか？

私はそれが非常に一般的な使用例に対処すると思います。次のような問題を回避するには非常にうまくいくと思われます。https://thraxil.org/users/anders/posts/2015/11/03/Docker-and-Upstart/

私は何が欠けていますか？

Answer 1

答えの方法として、私は-dと--rmを使ってコンテナを打ち上げることができますが、これは許されています。 docker run -d --rm --name=my_app my_container

私のアプリが期待どおりに動いたら、それが実行され、死ぬと死ぬと死んで静かに自分自身を取り除くので、このコマンドを少しでもやり直すことができます。これは理想的ですね、あなたの質問は、自分のプロジェクトのドッカーの自動化を設定している間に私が直面した問題でした。

何か問題が起こった場合、コンテナ内で実行されているプロセスで致命的なエラーが発生し、クラッシュしてコンテナが消滅する場合があります。問題は、外部の観察者には、人間や監視ソフトウェアであろうと、コンテナがどれくらいの期間生存していたかを除いて、これらの2つのシナリオの違いを伝えることができないことです。

-dを使用しない場合、CLIでコマンドを実行するか、upstart/initd/systemd/otherを使用すると、コンテナに出力が書き込まれます。コンテナに--rmが指定されても残ります。気づき、解決される。

が使用されている場合、出力ストリームまたはファイルへのバインディングコンテナの出力ではなく、--rmは、デッドコンテナの形でエラー/クラッシュが残っていることを保証することはできません。/TLをラップする

; DR：私はこの意識的な選択は、コンテナがトレードオフは、あなたの自動化にさらに2つのコマンドを追加する必要があることとのための完全に行方不明されたケースを防ぐために、ドッキングウィンドウの開発者によって作られたと考えていますスクリプト。

Answer 2

--rmは、クライアント側のオプションとして実装されているため：あなたは--rmを指定し、終了するコンテナの周りに待機し、それを削除しドッカクライアント。

-dと指定すると、ドッカークライアントはを終了します。コンテナは実行中で、Dockerサーバーによって管理されます。 --rmの機能を実装するクライアントは、もはや存在しません。

Answer 3

バージョン1.13では、バックグラウンドジョブで--rmを使用できるようになりました。これを可能にするために、削除操作がクライアントからサーバーに移動されました。

詳細については、以下のプルリクエストを参照してください：https://github.com/docker/docker/pull/20848

ここでは、この新しい動作の例です：これはドッキングウィンドウ1.12に変更される可能性があること

$ 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