Dockerの再起動ポリシーをデータベース、ワーカー、Webアプリに適用する方法

Composeファイル内のすべてのコンテナにunless-stoppedを割り当てるのではなく、サービスのライフサイクルと終了時の意味に合わせてDockerの再起動ポリシーを設定します。

再起動ポリシーは、コンテナのメインプロセスが終了したときに反応します。ヘルスチェックは、プロセスが実行中でもサービスをunhealthyと判定できますが、自動的に再起動するわけではありません。そのため、データベース、ワーカー、Webアプリ、マイグレーション、スケジュールジョブでは、常駐させるのか、正常終了が何を意味するのか、繰り返し発生する障害をどのように通知するのかに応じて、異なる選択が必要です。

再起動動作とヘルスチェック・準備完了状態を分ける

再起動ポリシーは、プロセス停止後にDockerがコンテナを再び起動するかどうかを決めます。ヘルスチェックは、実行中のサービスが定義された操作を実行できるかどうかを判定します。依存関係の準備完了状態は、別のサービスが起動を開始してよいかどうかを判断します。これらは関連していますが、異なる問題を解決します。

2026年のヘルスチェックと再起動は別物という解説では、この違いを説明し、Composeのヘルス条件によって、サービスが実際に準備完了するまで依存サービスの起動を遅らせる方法を紹介しています。

restart: alwaysによって、終了しないままunhealthyになったWebプロセスが修復されると期待してはいけません。また、ヘルスチェックだけでそのプロセスが再起動されると考えてもいけません。継続が安全でない場合はアプリケーションを終了させるか、外部の復旧メカニズムを追加するか、サービス設計に応じてunhealthy状態を通知します。

長時間稼働するデータベースには永続的な再起動ポリシーを使う

ホームサーバーのデータベースは通常、ホストやDockerデーモンの再起動後に復帰することが期待されます。管理者が意図的に停止した状態を尊重したい場合、unless-stoppedは実用的なデフォルトです。設計上、再起動時に手動停止状態を無視したい場合はalwaysが適しています。

2026年7月の再起動ポリシーはプロセス終了に従うという解説では、no、on-failure、always、unless-stoppedの違いに加え、ポリシーがヘルス状態ではなくプロセス終了に反応することを詳しく説明しています。

データベースには、実際のヘルスチェックと永続ストレージも必要です。PostgreSQLを繰り返し再起動しても、ディスク容量不足、設定ミス、状態の破損、互換性のないマイグレーションは解決できません。再起動を回復成功とみなすのではなく、再起動が繰り返されたら通知します。

ワーカーのポリシーはキューと終了時の意味に合わせて選ぶ

常時ジョブを処理する長時間稼働のキューワーカーには、常に処理を続ける必要がある場合、unless-stoppedが適しています。有限時間で終了するワーカーやバッチ処理では、on-failure:Nを使うことで、一時的なエラーには上限付きの再試行を行い、継続的な障害は明確に停止させられます。

最近の上限付きのon-failure再試行に関する解説では、プロセスを恒久的に稼働させるのか、正常に終了させるのかに応じて、再試行動作を合わせるべきだと強調しています。

ワーカーイメージで終了コード0が何を意味するのかを把握してください。「ジョブ完了」を意味する場合、alwaysによって、正常終了するはずのワンショットジョブが無限ループになる可能性があります。ワーカーをデーモンとして動かす設計なら、予期しない正常終了であっても、unless-stoppedによる自動復帰が適切な場合があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Webアプリは長時間稼働させつつ、実際の依存関係を満たすまで起動させない

ほとんどのセルフホスト型Webアプリは継続的な可用性を目的としているため、上限付きの失敗時のみのポリシーよりも、unless-stoppedのほうが通常は理解しやすくなります。ただし、再起動設定によって、データベース、キャッシュ、DNS、シークレット、マウントパスが準備できている必要性がなくなるわけではありません。

関連するZimaSpaceのコンテナ依存関係による再起動ループの診断記事では、表示上のアプリを繰り返し再起動すると、最初に発生したデータベース、キャッシュ、マウント、マイグレーション、メモリの障害が見えにくくなる理由を説明しています。

適切な場合は依存サービスのヘルスチェックを使って起動順序を制御し、アプリケーションの再試行動作には上限を設けます。PostgreSQLが起動するまで5秒ごとにクラッシュするWebサービスよりも、準備完了状態を待ってから起動し、明確な起動ログを1回出すサービスのほうが、問題を把握しやすくなります。

マイグレーションとワンショットジョブには有限のライフサイクルを与える

マイグレーションコンテナ、インポーター、メンテナンスタスク、一度だけ実行する初期化ジョブは、通常のデーモンではありません。成功状態は「終了コード0で終了し、停止したまま」であることが多く、alwaysやunless-stoppedを使うと、完了済みの処理を意図せず再実行する可能性があります。

ワンショットの運用ツールは、常時稼働する隠れたサービスにならないよう、明示的に管理します。マイグレーションやインポーターには、コマンド終了後も確認できる有限の成功状態を持たせます。

失敗時に調査のため停止させたい場合はrestart: "no"を使います。コマンドを安全に再試行できる場合に限り、上限付きのon-failureを使用してください。スキーママイグレーションでは、再試行を自動化する前に、途中まで適用されたマイグレーションを繰り返し実行できることを確認します。

実際の障害パターンでポリシーをテストする

各サービスについて、プロセスの正常終了、ゼロ以外の終了コードによるクラッシュ、ホストの再起動、Dockerデーモンの再起動、手動停止、実行中だがunhealthyの状態、依存サービスの利用不能をテストします。設定を堅牢だと判断する前に、それぞれの事象後に期待される状態を記録してください。

再起動回数を追跡し、一定時間内に少ない回数のしきい値を超えたら通知します。自動再起動は一時的な障害からの復旧時間を短縮するためのものであり、新しいコンテナを延々と生成して継続的なクラッシュを見えなくするためのものではありません。

優れたポリシーマトリクスは明確です。長時間稼働するデータベースとWebアプリはインフラの再起動後に復帰し、デーモン型ワーカーはキューの動作に応じて復旧し、有限のジョブは完了時に停止し、ヘルスチェックと準備完了チェックは再起動ポリシーでは検知できない障害を明らかにします。