ヘルスチェック

ヘルスチェックは、インスタンスがトラフィックを受けられる状態になったことを Zenavo に伝えます。デプロイでは新しいインスタンスを古いものの隣で起動し、新しいものがチェックに合格してからトラフィックを切り替えます。これがダウンタイムなしの展開を実現しています。

チェックは Service → Settings → Health Check で選びます。

• Port（デフォルト）：サービスの最初の TCP または HTTP ポートが接続を受け付けるかを、10 秒ごと、タイムアウト 5 秒、失敗 3 回まで許容して確認します。そのようなポートのないサービスにはチェックがなく、起動した時点で準備完了とみなします。
• HTTP：サービスの最初の TCP または HTTP ポート（または指定したポート）で、/healthz などのパスにリクエストします。2xx か 3xx の応答なら準備完了です。リクエストはクラスターから送られるので、イメージに curl や wget は不要です。Web アプリにはこれが最適です。
• Command：コンテナ内で実行するコマンド（例：pg_isready -U postgres）。終了コードが 0 なら準備完了です。シェルを通さずに実行されるので、&&、|、$VARIABLES を使うなら sh -c "…" と書いてください。コンソールから追加したデータベースや多くのテンプレートにはこれが含まれています。

HTTP とコマンドのチェックでは、間隔、1 回のチェックのタイムアウト、unhealthy とみなすまでに許容する失敗回数（デフォルト 6）、コンテナ起動後に待つ開始猶予時間（デフォルト 10 秒）を調整できます。Java アプリや起動時にマイグレーションを実行するアプリなど、起動の遅いアプリでは開始猶予時間を延ばしてください。

マニフェストでは：

"healthcheck": { "http": { "path": "/healthz" }, "interval": 10, "timeout": 5, "retries": 6, "start_period": 10 }

または "http" の代わりに "command": ["pg_isready", "-U", "postgres"] を使います。

チェックに失敗したとき

• デプロイ中： 新しいインスタンスがチェックに失敗し続けると、それが明らかになった時点でデプロイは失敗します。最後のチェックの理由（例：HTTP probe failed with statuscode: 404）とインスタンスの最新ログが表示されます。古いインスタンスは応答を続けます。
• デプロイ後： チェックに合格しなくなったインスタンスにはトラフィックが送られず、サービスは Unhealthy と表示されます。Zenavo はチェックの失敗を理由に再起動はしません。ログを確認してから、再デプロイか再起動をしてください。

クラッシュ上限

サービスがクラッシュを繰り返す場合、Zenavo は無限に再起動する代わりに、一定回数（クラッシュ上限）再起動したところでサービスを一時停止できます。サービスにはお知らせが表示されます。ログを確認してから、再開するか修正をデプロイしてください。