Dockerコンテナのネイティブヘルスチェックメカニズムの詳細な説明

なぜヘルスチェックメカニズムが必要なのでしょうか?

ヘルスチェックメカニズムは、サービスの可用性をチェックし、サービスが利用できない場合は、可用性を回復するためにサービスを適時に再起動するために使用されます。前回の記事「Kubernetes で livenessProbe、readinessProbe、startupProbe を構成する」では、Kubernetes のさまざまなヘルスチェックの種類と構成方法について説明しました。この記事では、Docker コンテナのヘルスチェックのメカニズムについて説明します。

上記の記事を読んだ人なら、サービス自体のヘルスチェックを実行する必要がある理由をきっと理解できるでしょう。 Docker を例にして説明しましょう。 Docker デーモンはコンテナの実行と管理に使用されます。コンテナ内の PID 1 のプロセスを監視します。実際、実際のシナリオでは、PID 1 のプロセスだけを監視するだけでは不十分です。たとえば、コンテナ内のサービスでデッドロックが発生した場合、サービスはユーザー要求を処理できませんが、PID 1 のプロセスは引き続き実行されています。

Docker ヘルスチェックメカニズム

Docker の健全性を確認するには 2 つの方法があります。

ヘルスチェック戦略を構成するには、Dockerfile で HEALTHCHECK コマンドを使用します。
コンテナを起動するときにヘルスチェックポリシーを構成します (docker run コマンド)。

DockerfileのHEALTHCHECKコマンドを使用してヘルスチェック戦略を設定します。

HEALTHCHECK を使用して Dockerfile でヘルスチェックポリシーを宣言すると、コンテナの起動後にヘルスチェックが自動的に実行されます。 HEALTHCHECK は次のオプションをサポートしています。

--interval=<interval>: 2 つのヘルスチェック間の間隔。デフォルト値は 30 秒です。
--timeout=<timeout>: ヘルスチェックコマンドを実行するためのタイムアウト。この時間を超過すると、ヘルスチェックは失敗とみなされます。デフォルト値は 30 秒です。
--retries=<再試行回数>: 指定された回数連続して再試行すると、コンテナのステータスが異常に設定されます。デフォルトは3回です。
--start-period=<interval>: アプリケーションの起動時間（起動時のヘルスチェックの失敗を除く）。デフォルトは 0 秒です。

以下に使用例をいくつか示します。

 from elasticsearch:latest HEALTHCHECK --interval=5s --timeout=2s --retries=3 \ CMD curl --silent --fail localhost:9200/_cluster/health || exit 1

Dockerfile には HEALTHCHECK を 1 つだけ記述するのが最適です。複数の HEALTHCHECK を記述した場合、最後のものだけが有効になります。

CMDコマンドの戻り値には次の3種類があります。

0、成功;
1. 失敗
2. 値を予約し、使用しないでください。

docker run を実行すると、コンテナの初期状態が起動します。設定された間隔時間を待機した後、ヘルスチェックが開始されます。単一のチェックの戻り値が 0 でない場合、またはチェック時間がタイムアウトを超えた場合、チェックは失敗したとみなされます。ヘルスチェックが再試行回数を超えて連続して失敗すると、状態が「不正常」に変わります。ヘルスチェックの結果が成功すると、コンテナは正常状態に設定されます。

コンテナの起動時にヘルスチェックポリシーを構成する（docker runコマンド）

次に例を示します。

 $ docker run --rm -d \ --name=es \ --health-cmd="curl --silent --fail localhost:9200/_cluster/health || exit 1" \ --health-interval=5s \ --health-timeout=2s \ --health-retries=3 \ elasticsearch:latest

パラメータは最初の方法と同じ意味を持ちます。ヘルスチェックコマンドの出力はヘルスステータスに保存され、docker inspect コマンドで表示できます。