docker stopとdocker killの違いは何ですか？
docker stopとdocker killの違いは何ですか？
Afaik、両方とも実行中のコンテナを停止します。 docker stopがkillシグナルを送信している間、docker killが正しい方法でコンテナー内で実行されているプロセスを停止しようとしているのでしょうか。もしそうなら、docker stopは実行中のプロセスを正しく停止する方法をどのように知っているでしょうか。 （これはプロセスによって異なりますので）
Docker killがkillシグナルを送信している間、docker stopがコンテナ内で実行されているプロセスを正しい方法で停止しようとしているのでしょうか。
基本的にそうです、違いは微妙ですが、 コマンドライン のリファレンスで概説されています。
- docker stop ：実行中のコンテナを停止します（SIGTERMを送信し、猶予期間の後にSIGKILLを実行します）[...]コンテナ内部のメインプロセスはSIGTERMを受け取り、猶予期間が過ぎるとSIGKILLを受け取ります。 [私の強調]
- docker kill ：実行中のコンテナを強制終了する（SIGKILLを送信、または指定したシグナル）[...]コンテナ内部のメインプロセスにSIGKILL、またはオプション--signalで指定されたシグナルが送信されます。 [私の強調]
そのため、stopは標準の POSIXシグナルSIGTERMを送信することでグレースフルシャットダウンを起動しようとしますが、killjustはデフォルトでプロセスを強制終了します（ただし他のシグナルの送信も可能） ）：
SIGTERMシグナルはプロセスに送信され、その終了を要求します。 SIGKILLシグナルとは異なり、プロセスによって捕捉され解釈されたり無視されたりする可能性があります。これにより、プロセスはリソースを解放し、適切な場合は状態を保存しながら、Nice終了を実行できます。 SIGINTはSIGTERMとほぼ同じです。
とにかく強制されるわけではありませんが、プロセスはSIGTERMを適切に処理し、それぞれの責任に応じて適切な処理を実行することが一般的に期待されています。最優先事項です（データベース用など）。例えば参照ヘイデン少佐の SIGTERMとSIGKILL のより詳しい説明は：
SIGTERMが受信されると、アプリケーションは何をしたいのかを決定できます。ほとんどのアプリケーションはリソースをクリーンアップして停止しますが、そうでないものもあります。 SIGTERMを受信したときにアプリケーションがまったく異なる動作をするようにアプリケーションを構成することができます。また、アプリケーションがディスクI/Oを待っているなどの悪い状態にある場合、送信されたシグナルに基づいて動作することができない場合があります。
docker killは、メインのエントリポイントプロセス/プログラムを突然停止します
docker stopは優雅にそれを止めようとします（丁寧に尋ねます：P）
どちらの場合もファイルシステムの変更は（stopやkillの時点で）保持されますので、docker start <container>ならばそこから継続します。
そして先に追加された答えへの追加
docker eventsの後にdocker stopを実行するとイベントが表示されます
- kill（signal 15）：signal 15 = SIGTERM
- 死ぬ
- やめる
docker eventsの後にdocker killを実行するとイベントが表示されます
- kill（signal 9）：signal 9 = SIGKILLの場合
- 死ぬ（出口コード137）
docker stopはプロセスを終了する前にタイムアウトします。デフォルトは10秒です。
この表 にはさらに詳細があります。
これはデスクトップからプラグを抜くおよびコンピュータをシャットダウンすると似ています。
プラグオフを引くことがハードパワーオフを意味するのと同様に、docker killはmy_containerを強制終了する直接的な方法を意味します。これは最初にプロセスを正常にシャットダウンすることを試みません。
コンピュータをシャットダウンするとは、すべてのプロセスをシャットダウンするためにOSにシグナルを送信することを意味し、docker stopは実行中のコンテナにSIGTERMシグナルを送信してプロセスを適切に停止することを意味します。