Docker Stop と Kill の比較：各コマンドの使用場面
Dockerコンテナを管理する上で、コンテナをどのように終了させるかのニュアンスを理解することは、アプリケーションの安定性とデータの整合性にとって非常に重要です。コンテナを停止するための主なコマンドには docker stop と docker kill があります。どちらも実行中のコンテナを停止するという目的を達成しますが、動作は大きく異なり、それぞれに明確なユースケースがあります。適切なコマンドを選択することで、データ損失を防ぎ、アプリケーションの正常なシャットダウンを保証し、トラブルシューティングを支援することができます。
この記事では、docker stop と docker kill の根本的な違いを探り、それらの基盤となるメカニズムを掘り下げ、最適なコンテナ管理のために各コマンドをいつ使用すべきかについての明確なガイダンスを提供します。これらの違いを理解することで、Dockerワークフローを改善し、シャットダウンシーケンス中でもアプリケーションが予測どおりに動作することを保証できます。
docker stop の理解
docker stop コマンドは、コンテナの正常なシャットダウンのために設計されています。docker stop <コンテナID> を実行すると、Dockerはコンテナ内で実行されているメインプロセスに SIGTERM シグナルを送信します。SIGTERM シグナルは、プロセス自体にクリーンに終了するように要求するものです。これは、コンテナ内のアプリケーションが以下の機会を持つことを意味します。
- 現在の状態を保存する。
- 開いているネットワーク接続を閉じる。
- 保持しているリソースを解放する。
- 進行中の操作（ディスクへのデータ書き込みなど）を完了する。
SIGTERM シグナルを送信した後、Dockerはデフォルトの猶予期間（10秒）を待ちます。コンテナ内のプロセスがこの期間内に終了した場合、コンテナは正常に停止したと見なされます。しかし、プロセスが猶予期間内に終了しない場合、Dockerは強制的に終了させるために SIGKILL シグナルを送信します。
docker stop の仕組み：
SIGTERMの送信：Dockerは、コンテナ内のプライマリプロセス（PID 1）にSIGTERMシグナルを送信します。- 猶予期間の待機：Dockerは設定可能な時間（デフォルトは10秒）待ちます。
- （必要な場合）
SIGKILLの送信：猶予期間の終了までにプロセスが終了しない場合、DockerはSIGKILLシグナルを送信します。
docker stop を使用する場面：
- 通常のアプリケーションシャットダウン：データベース、Webサーバー、または重要な書き込みを行うアプリケーションなど、クリーンにシャットダウンする必要があるアプリケーションを停止するための推奨される方法です。
- 開発環境：開発中の日常的な停止において、
docker stopは進行中のプロセスを誤って中断しないことを保証します。 - 計画メンテナンスのための本番環境：サービスを再起動したり、アップデートを実行したりする必要がある場合、
docker stopはアプリケーションが作業を完了できるようにします。
例：
# 'my-web-server' という名前のコンテナを開始します
docker run -d --name my-web-server -p 80:80 nginx
# コンテナを正常に停止します
docker stop my-web-server
# コンテナが停止したことを確認します
docker ps -a | grep my-web-server
docker kill の理解
一方、docker kill コマンドは、コンテナの即時かつ強制的な終了のために設計されています。docker kill <コンテナID> を実行すると、Dockerはコンテナ内で実行されているメインプロセスに直接 SIGKILL シグナルを送信します。SIGTERM とは異なり、SIGKILL シグナルはプロセスによって捕捉、無視、または処理されることはありません。オペレーティングシステムに、クリーンアップの機会を与えることなく、プロセスを即座に終了するように指示します。
これは、保存されていないデータ、開いている接続、または進行中の操作がすべて突然停止することを意味します。これにより、このような突然のシャットダウンに対応するように設計されていないアプリケーションでは、データ破損や状態の不整合が生じる可能性があります。
docker kill の仕組み：
SIGKILLの送信：Dockerは、コンテナ内のプライマリプロセス（PID 1）に直接SIGKILLシグナルを送信します。- 即時終了：プロセスはオペレーティングシステムによって即座に終了されます。
docker kill を使用する場面：
- 応答しないコンテナ：コンテナがハングアップし、
docker stopが猶予期間後も終了に失敗した場合。 - 緊急停止：セキュリティインシデントや重大な障害など、結果に関係なくコンテナを即座に停止する必要がある状況。
- 耐障害性のテスト：突然の終了条件でアプリケーションがどのように動作するかを理解するため（ただし、これは一般的な使用よりもテスト向けです）。
例：
# 'my-test-app' という名前のコンテナを開始します
docker run -d --name my-test-app ubuntu sleep infinity
# コンテナを強制的にキルします
docker kill my-test-app
# コンテナが停止したことを確認します
docker ps -a | grep my-test-app
主な違いの要約
| 特徴 | docker stop |
docker kill |
|---|---|---|
| 送信シグナル | SIGTERM（猶予期間満了の場合は SIGKILL） |
SIGKILL |
| 終了 | 正常終了、クリーンアップを許可 | 即時、強制終了、クリーンアップなし |
| データ整合性 | 一般的にデータ整合性を維持する | データ破損または状態の不整合のリスクがある |
| ユースケース | 通常のシャットダウン、計画メンテナンス | 応答しないコンテナ、緊急停止 |
| 猶予期間 | あり（デフォルト10秒） | なし |
ベストプラクティスと考慮事項
- 常に
docker stopを最初に試す：日常的な操作では、docker stopをデフォルトの選択肢とすべきです。これにより、アプリケーションとデータを保護できます。 - アプリケーションのシグナルを理解する：アプリケーションは
SIGTERMシグナルを処理するようにプログラムできます。アプリケーションのエントリーポイントスクリプトまたはプロセス管理者が、SIGTERMを捕捉して正常に処理するように設定されていることを確認してください。 docker stopの猶予期間を調整する：-tまたは--timeフラグを使用して、docker stopのカスタム猶予期間を指定できます。たとえば、docker stop -t 30 my-containerは、コンテナにシャットダウンするための30秒を与えます。docker killは最後の手段として使用する：docker stopが効果がない場合や、緊急性が高い状況でのみdocker killを使用してください。- コンテナのヘルス状態を監視する：Docker設定にヘルスチェックを実装することで、応答しなくなっているコンテナを特定し、
docker killが必要になる前に問題を解決できる可能性があります。
結論
docker stop と docker kill はどちらもDockerコンテナを管理するための不可欠なツールですが、それぞれ異なる目的を果たします。docker stop は、正常なシャットダウンを可能にし、データ整合性を維持し、クリーンアップの機会を提供することで、アプリケーションのヘルスを優先します。docker kill は、即時かつ強制的な終了を提供し、応答しないコンテナや、データ損失のリスクを伴っても速度が最優先される緊急の状況に最適です。
特定のシナリオに基づいて適切なコマンドを理解し適用することで、より堅牢で信頼性の高いコンテナ化されたアプリケーションを維持できます。常に docker stop の穏やかなアプローチを好み、docker kill は他のすべてのオプションが失敗した場合、または即時終了が絶対に必要不可欠な場合にのみ予約してください。