ヘルスチェックとローリング更新

Nanocl は Docker コンテナのヘルスチェックを使い、Cargo レプリカ内の必須アプリケーションコンテナが準備できたか判断します。名前付きアプリケーションコンテナにヘルスチェックを定義するか、イメージに含まれるものを利用してください。

ApiVersion: v0.18
Cargoes:
- Name: api
  Containers:
  - Name: api
    Image: ghcr.io/example/api:1.2.0
    Healthcheck:
      Test: ["CMD-SHELL", "curl -fsS http://127.0.0.1:8080/health || exit 1"]
      Interval: 5000000000
      Timeout: 3000000000
      Retries: 3
      StartPeriod: 10000000000

時間のフィールドは Docker のナノ秒表現を使用します。イメージに定義されたヘルスチェックを再度定義する必要はありません。Docker の NONE ヘルスチェックは、継承したチェックを無効にします。

コンテナの起動と Cargo の準備完了は別の状態です。有効なヘルスチェックがない必須アプリケーションは、Docker が稼働中と報告すると準備完了になります。ヘルスチェックがある必須アプリケーションは、healthy を報告する必要があります。複数コンテナで共有するレプリカでは、サンドボックスも稼働している必要があります。必須ではないアプリケーションコンテナは、準備完了の判定に影響しません。

ローリング更新

Nanocl は置き換え用のレプリカを順番に準備し、各候補に必要な構成が準備完了になるまで最大 5 分待ちます。ネットワークとホストポートが許す場合、保持された旧世代は候補の準備が整うまで稼働とサービス提供を続けます。ncproxy は確定した置き換え先の準備が完了してからルートを引き継ぎます。

候補が昇格前に失敗すると、Nanocl はその候補を削除して保持した旧世代を復元します。確定後の更新が失敗した場合も、以前のマッピングとプロセスの復元を試み、Cargo を unhealthy または failed として記録します。

無条件に停止時間がなくなる保証ではありません。固定のホストポートバインドでは、候補が同じポートにバインドする前に、保持した旧世代を削除する必要があります。ホストネットワークでは、まず旧世代を停止する必要がありますが、候補が失敗した場合は Nanocl が旧世代を再起動できます。ヘルスチェックのないプロセスは、稼働すると準備完了とみなされるため、アプリケーションレベルの準備状態の確認には Docker のヘルスチェックが必要です。

Cargo の再起動時も同じ準備完了のルールが適用されます。再起動はレプリカのサンドボックスと完了した初期化コンテナを保持し、アプリケーションコンテナを再起動して、必須アプリケーションの準備完了を待ちます。