Dockerがunhealthyでも再起動しない：異常検知と復旧方針は別
通常のDockerコンテナでは、unhealthyという表示だけでrestart policyが復旧を始めるとは期待しません。HEALTHCHECKは異常を見つける仕組み、restart policyは終了などの扱いです。生きたまま応答しない場合の対応を別に決めます。
公式資料確認日：。
runningとhealthyと成果完了を混ぜない
プロセスが動いていても応答しないケースをHEALTHCHECKは検出できます。healthyでも必要なデータを処理した証明にはなりません。起動状態、健康確認、仕事の成果という三つの記録を分けます。
どの状態を誰が直すかを書く
通常コンテナのDocker Engineを対象にします。SwarmやKubernetesなどが健康状態を扱う場合の復旧方針は別資料で照合します。外部監視を足した事実がないのに、自動回復済みとは扱いません。
| 観測するもの | 分かること | 次の行動 |
|---|---|---|
| 終了コードが非ゼロ | on-failureの対象候補 | 回数上限と終了理由を読む |
| runningだがunhealthy | 健康確認が連続で失敗 | 確認内容と対応担当を調べる |
| healthyだが成果なし | 監視だけでは見えない失敗 | 予定と成果の受入を照合 |
| 手動停止した | 意図した停止かもしれない | 停止理由を消さず再開条件を決める |
外部サービスの障害で、再起動を繰り返さない
APIの停止や認証失効を健康確認が見つける想定なら、アプリを再起動しても原因は残ります。初期化や送信が何度も走ると業務の重複も問題になります。どの失敗なら通知、どの失敗なら再開試験へ進むかを決めます。
健康確認の待ち時間を、起動時間と合わせる
初期起動の待機と、通常の応答期限を分けます。実際の起動条件を測らず固定の秒数を正解にしません。本番へ負荷や書込みを加える確認ではなく、許可された小さな読取りで検知条件を照合します。
再起動した後も、処理対象を受け入れる
異常表示が消えたことと、欠落した仕事の回収は別です。再開後の入力・保存先・二重処理を照合します。新しいVPSや監視SaaSの契約を先にせず、今の記録で検知と担当の不足を明らかにします。
公式資料と、判断例の境界
仕様の根拠は以下の公式資料です。本文の記入例は実測値ではありません。購入・設定変更時は、対象の型番・版・契約条件を照合します。
- Docker：HEALTHCHECK
プロセスが動いていても応答しない場合を検知し、通常状態とは別にstarting・healthy・unhealthyを持ちます。
- Docker：restart policy
通常コンテナのrestart policyは終了やDockerの再起動を扱います。Swarmサービスの方針は別です。