DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

Docker StopとKillの比較：それぞれのコマンドを使用するタイミング

「docker stop」と「docker kill」の重要な違いを理解し、Dockerコンテナ管理を習得しましょう。データの整合性を維持するための優雅なシャットダウンに「SIGTERM」を使用するタイミング、そして応答しないコンテナを即座に終了させるために「SIGKILL」が必要な場合を学びます。このガイドでは、最適なアプリケーションの安定性と効率的なワークフローのために正しいコマンドを選択するための実践的な例とベストプラクティスを提供します。

Docker Stop vs. Killの比較：各コマンドの適切な使用タイミング

コンテナをシャットダウンする必要がある場合、docker stopとdocker killは互換性がありません。その違いは、アプリがデータを書き込んだり、ネットワーク接続を保持したり、終了前にクリーンアップ時間を必要とする場合に最も重要です。

通常のシャットダウンにはdocker stopを使用します。コンテナが正常な停止を無視した場合や障害動作をテストしている場合など、即座のシグナルが必要な場合はdocker killを使用します。

docker stopの理解

docker stopコマンドは、コンテナのメインプロセスに正常に終了するよう要求します。デフォルトでは、Dockerはコンテナ内のPID 1にSIGTERMを送信し、猶予期間を待ってから、プロセスがまだ実行中の場合はSIGKILLを送信します。

最初のシグナルは、イメージのSTOPSIGNAL命令や、コンテナ作成時に使用される--stop-signalオプションで変更できます。ただし、ほとんどの日常的なケースでは、docker stopは「アプリにシャットダウン要求を送信し、終了しない場合のみ強制する」と考えることができます。

  • 現在の状態を保存する。
  • 開いているネットワーク接続を閉じる。
  • 保持しているリソースを解放する。
  • 進行中の操作（ディスクへのデータ書き込みなど）を完了する。

Linuxコンテナでは、コンテナに異なる停止タイムアウトが設定されていない限り、デフォルトの待機時間は通常10秒です。Windowsコンテナではより長いデフォルト値が使用されます。コマンドごとに-tまたは--timeで待機時間を上書きできます。

docker stopの動作方法

  1. SIGTERMを送信: Dockerはコンテナ内のプライマリプロセス（PID 1）にSIGTERMシグナルを送信します。
  2. 猶予期間を待機: Dockerはプロセスが終了するのを待ちます。
  3. 必要に応じてSIGKILLを送信: 猶予期間の終了時にプロセスがまだ終了していない場合、DockerはSIGKILLシグナルを送信します。

docker stopを使用するタイミング

  • 通常のアプリケーションシャットダウン: データベース、ウェブサーバー、重要な書き込みを行うアプリケーションなど、正常にシャットダウンする必要があるアプリケーションを停止するための推奨方法です。
  • 開発環境: 開発中の定期的な停止では、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 stop --time 30 my-web-server

docker killの理解

docker killコマンドは、コンテナのメインプロセスに即座にシグナルを送信します。デフォルトでは、そのシグナルはSIGKILLです。SIGTERMとは異なり、SIGKILLはプロセスによってキャッチ、無視、または処理できません。オペレーティングシステムは、クリーンアップの機会を与えずにプロセスを終了します。

つまり、保存されていないデータ、開いている接続、進行中の書き込みが中断される可能性があります。ステートレステストコンテナでは問題にならないかもしれませんが、データベース、キュー作業者、ファイル処理ジョブではおそらく問題になります。

また、docker kill --signalを使用してSIGHUPなどの異なるシグナルを送信することもできますが、正常なシャットダウンが目的の場合は、通常docker stopの方が明確です。

docker killの動作方法

  1. SIGKILLを送信: Dockerはコンテナ内のプライマリプロセス（PID 1）に直接SIGKILLシグナルを送信します。
  2. 即時終了: プロセスはオペレーティングシステムによって終了されます。

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
終了方法 正常、クリーンアップを許可 即時、強制、クリーンアップなし
データ整合性 一般的にデータ整合性を維持 データ破損や不整合状態のリスク
使用ケース 通常のシャットダウン、計画メンテナンス 応答しないコンテナ、緊急停止
猶予期間 あり なし

ベストプラクティスと考慮事項

  • 常に最初に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が必要になる前に対処できる可能性があります。
  • PID 1の動作を確認する: シェルラッパースクリプトは、実際のアプリプロセスにシグナルを転送しない場合、シグナルを飲み込む可能性があります。エントリポイントスクリプトではexecを使用して、アプリがシャットダウンシグナルを直接受信できるようにしてください。

実践的なポイント

特にステートフルなものについては、docker stopを通常の習慣にしましょう。コンテナが応答しない場合、スピードがクリーンアップよりも重要な場合、またはクラッシュ動作を意図的にテストしている場合にのみ、docker killを使用してください。