コンテナのヘルスチェックが失敗しているのに、アプリは開けるのはなぜですか？

ヘルスチェックが失敗していても、コンテナは使用可能な状態を保つことがあります。これは、プローブがブラウザーで使用する経路とは異なるコマンド、アドレス、ユーザー、または準備完了条件をテストしている可能性があるためです。

ホームサーバーでは、Dockerがコンテナ内でヘルスチェックコマンドを実行する際、localhost、存在しないユーティリティ、誤ったポート、一時的に利用できない依存サービスなどを対象にしている一方で、アプリはリバースプロキシ経由で開けることがあります。まず、コンテナ内で正確なプローブを再現し、その対象と期待される結果を実際のユーザー経路と比較してから、リトライ回数を増やすか、ヘルスチェックを無効にしてください。

ブラウザーがテストする対象とヘルスチェックがテストする対象を比較する

アプリケーションを正常に開けるURLとネットワーク経路を記録します。ブラウザーがリバースプロキシ、公開されたホストポート、ローカルIP、またはコンテナへ直接接続しているかを確認してください。

Dockerは設定されたプローブをコンテナ内で実行するため、ブラウザーとは異なるエンドポイントをテストする場合があります。Dockerコミュニティの事例では、サービスプロセス自体は動作していたにもかかわらず、イメージにプローブで使用するcurlコマンドが含まれていなかったため、ヘルスチェックが失敗していました。

ブラウザーで成功する経路が別のプロキシやポートを経由している場合、その結果だけで内部プローブの対象が正しいと判断しないでください。両方の経路を書き出し、最初に異なるコンポーネントを特定します。

コンテナ内で正確なヘルスチェックコマンドを実行する

シェル形式、URL、フラグ、認証情報、環境変数を含め、ヘルスチェックコマンドを正確にコピーします。実行中のコンテナ内で同じユーザーとして実行し、終了コードと出力を取得してください。

ヘルスチェックでunhealthyと判定されたコンテナでも、プロセスが動作していることがあります。ヘルスステータスはユーザーがページを読み込めるかどうかではなく、プローブの結果を反映するためです。Netdataの診断手順では、再起動動作を変更する前に、プローブの失敗とプロセスの失敗を区別しています。

手動でコマンドが成功する場合は、自動チェックで使用される実行ユーザー、シェル、作業ディレクトリ、環境、タイミングを比較します。手動でも失敗する場合は、次に確認すべき層がエラーから分かるため、次のヘルスチェック間隔を待つ必要がありません。

プローブのツール、シェル、PATH、ユーザーを確認する

ヘルスチェックコマンドで使用するすべての実行ファイルが現在のイメージ内に存在し、コンテナユーザーで実行できることを確認します。最小構成のイメージには、curl、wget、bash、DNSツール、証明書ストアなどが含まれていない場合があります。

シェル形式とexec形式のプローブは動作が異なります。引用符、パイプ、変数展開、複合コマンドには利用可能なシェルが必要です。一方、直接コマンドを実行する場合は、ヘルスチェック環境のPATHが限定されているとき、実行ファイルの完全なパスが必要になります。

絶対パスと想定するサービスユーザーを指定してコマンドを実行します。対話的にツールをインストールするのではなく、イメージまたはプローブを修正してください。手動で行ったコンテナの変更は、次回の再ビルド後に失われるためです。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

内部アドレス、ポート、プロトコルを確認する

コンテナ内でアプリケーションが待ち受けている場所を確認し、プローブURLと比較します。8080:80のようにホストポートを公開していても、コンテナ内のサービスがポート8080で待ち受けているとは限りません。

ヘルスチェックでは、コンテナが管理するアプリケーションの状態をテストする必要があります。Dash0の実践ガイドでは、プローブはHTTPエンドポイントを呼び出したり、プロセスを検査したりできますが、そのエンドポイントは外部プロキシ経由でのみ利用できるルートではなく、実際のコンテナの準備完了状態を反映する必要があると説明しています。

127.0.0.1、コンテナのリスナーアドレス、サービス名を、それぞれ適切な場合にのみテストします。アプリがUnixソケットまたは別のインターフェースでのみバインドしている場合は、プローブを実際の内部エントリーポイントに変更してください。

起動の遅さと恒久的な失敗を切り分ける

アプリケーション、データベースのマイグレーション、キャッシュのウォームアップ、モデルの読み込みが完了し、正しいエンドポイントが応答するまでの時間を測定します。その時間をstart_period、interval、timeout、retriesと比較してください。

依存サービスがまだunhealthyと判定されている場合、後で準備完了になるとしても、Composeが依存するサービスの起動をブロックすることがあります。報告されたComposeのリグレッションでは、依存サービスの失敗によってスタックが停止した後になって初めてサービスがhealthyになっており、ヘルスチェックの起動猶予時間が短すぎることが明らかになりました。

ログからアプリが正常に処理を進めていることが確認できる場合にのみ、タイミングを延長してください。リトライ時間を長くしても、誤ったポート、失敗したマイグレーション、証明書の不足、到達できないデータベースを隠してはいけません。

プローブを絞り込み、復旧を確認する

ヘルスチェックがプロセスの生存性、ローカルアプリケーションの準備完了状態、またはより深い依存関係まで含む状態のどれを表すべきかを決めます。任意の外部APIが利用できないだけで、ローカルコンテナをunhealthyにしないでください。

データベース、キャッシュ、ネットワークサービスがないとアプリケーション自体が準備完了にならない場合は、ZimaSpaceの最初に失敗した依存サービスを見つける方法に進んでください。

通常の起動後に自動プローブが正確に成功し、依存サービスの再起動中もコンテナがhealthyを維持し、実際のアプリワークフローも利用できれば、問題は解決しています。サービスの故障を検出できる厳密さを保ちながら、無関係なシステムによる誤判定を避けられるよう、プローブの対象は絞り込んでください。