コンテナのどの依存関係が再起動ループの原因になっているかを特定する方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Identify Which Container Dependency Is Causing a Restart Loop

アプリが終了する前に利用できなくなった最初の依存関係を特定し、再起動を繰り返すすべてのコンテナを根本原因とみなさないようにします。

Docker Compose スタックでは、データベースの起動中、Redis に到達できない、DNS が誤ったサービスを返す、バインドマウントが存在しない、シークレットが変更された、マイグレーションに失敗した、またはメモリプレッシャーによってアプリが強制終了されたことが原因で、目に見えるアプリケーションがループする場合があります。最も迅速な診断方法は、最初の終了と依存関係エラーを記録し、自動再起動を一時停止してから、失敗したコンテナが使用するものと同じネットワークおよび認証情報で、必要な各サービスをテストすることです。

最も目立つコンテナではなく、最初に失敗したコンテナを見つける

スタック内のすべてのサービスについて、再起動回数、現在の状態、ヘルス状態、直近の終了コード、起動時刻を一覧表示します。タイムラインを並べ替え、後続のコンテナが再接続や再起動を始める前に、最初の障害が表示されるようにします。

Netdata の再起動ループガイドでは、終了コードと状態から、OOM キル、セグメンテーションフォルト、正常終了、ヘルスチェック関連の停止を区別する方法を説明しています。OOMKilled または終了コードのシグナルにより、実際にはアプリがメモリ不足になっている、または内部でクラッシュしている場合に、依存関係のトラブルシューティングを省けます。

依存関係のいずれかが先に失敗している場合は、アプリケーションよりも先にその依存関係を調査します。アプリが先に終了し、接続拒否、タイムアウト、認証、またはファイル不足のエラーが出ている場合は、そのメッセージをアプリが使用しようとした正確な依存関係に対応付けます。

再起動の嵐を止め、クリーンな失敗を一度だけ記録する

影響を受けているサービスの再起動ポリシーを一時的に無効化または上書きし、フォアグラウンドで一度だけ実行するか、1回の起動試行における完全なログを確認します。Docker デーモンとすべての依存関係から取得したタイムスタンプを保持します。

自動再起動が繰り返されると、最初の意味のあるエラーが後続の接続エラーによって上書きされることがあります。また、数秒ごとに再起動するコンテナは、データベース、DNS リゾルバー、ログボリュームに過剰な負荷をかけ、二次的な症状を引き起こす可能性があります。

この記録中にコンテナ、ボリューム、データベースを削除しないでください。再起動の嵐だけを止めて一度再現し、設定を変更する前に、環境変数、マウント、ネットワーク接続、コマンド、終了状態を保存します。

コンテナが準備完了するために必要なすべての依存関係を整理する

アプリに必要なデータベース、キャッシュ、メッセージキュー、オブジェクトストレージ、DNS リゾルバー、ID プロバイダー、マウントされたファイル、シークレット、外部 API を書き出します。想定されるサービス名、ポート、プロトコル、ユーザー名、データベース、パスも含めます。

Dash0 は、Compose の起動順序が依存関係内部のプロセスの準備完了を自動的に意味するわけではないと説明しています。Postgres の初期化中でもアプリは起動できます。修正方法は、単に起動中であることではなく、依存関係が正常な状態になるまで待つことです。

依存関係を必須と任意に分類します。任意のメトリクスサービスが利用できなくてもメインアプリを再起動させるべきではありませんが、データベースが利用できない場合は、制御された待機、再試行、または停止が必要になることがあります。

Featured

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

ZimaCube2

失敗したコンテナのネットワークから各依存関係をテストする

同じネットワークに接続した一時的な診断コンテナを使用するか、アプリが終了する前に利用可能なシェルを実行します。サービス名の DNS、TCP ポート、TLS、認証、データベースクエリ、必要なパスの順にテストします。

Last9 の Compose ヘルスチェックガイドでは、重要なコンポーネントが実際に応答できるようになるまで依存サービスの起動を防ぐ、準備完了チェックについて説明しています。効果的なチェックでは、プロセスの存在だけを確認するのではなく、クライアントが必要とするサービス操作を検証します。

DNS が失敗する場合は、ネットワークへの所属とエイリアスを確認します。TCP 接続は確立するものの認証に失敗する場合は、シークレットとユーザーを比較します。ログインできても、必要なスキーマ、バケット、キュー、ディレクトリが存在しない場合は、ネットワークではなく初期化を修復します。

マウント、シークレット、マイグレーションを依存関係として確認する

現在のバインドマウント、名前付きボリューム、権限、所有者、環境ファイル、シークレットファイル、アプリケーションのバージョンを、最後に正常に動作したデプロイと比較します。コンテナがデータベースに到達できても、設定ファイルが読み取り専用である、またはマイグレーションで書き込みができないために再起動することがあります。

あるコンテナ起動の事例では、ヘルス状態に基づく依存関係の順序制御により、データベースの準備が完了する前にアプリケーションがクラッシュするのを防いでいます。条件付きの起動シーケンスは、初回起動やマイグレーション時に特に重要です。

ログを確認できる状態でマイグレーションを一度実行し、破壊的な手順を再試行する前にデータベースをバックアップします。アプリのバージョンを変更した場合は、依存関係のバージョンとスキーマのアップグレード経路がサポートされていることを確認します。

依存関係の順序でサービスを再有効化し、安定性を検証する

最下層の依存関係から起動し、実際のヘルスチェックが正常になるまで待ってから、次の層、最後にアプリケーションを起動します。複数のチェック間隔にわたって、再起動回数とヘルス状態の遷移を記録します。

ZimaSpace のコンテナ側の DNS 障害に関するガイドでは、アプリ環境内でのみ発生することがある依存関係の経路について説明しています。

アプリケーションが一度で起動し、すべての必須依存関係が正常な状態を維持し、マイグレーションが完了し、意図的に依存関係を再起動した際にも、再びループするのではなく制御された再試行または復旧が行われて初めて、問題は解決したと言えます。根本原因を把握し、その影響範囲を限定できるようになってから、再起動ポリシーを復元します。