Azure Container Apps の変更を更新してデプロイする

クラウドでコンテナー化されたアプリケーションを開発する場合、変更管理は困難な場合があります。 最終的には、変更を追跡し、アップタイムを確保し、スムーズなロールバックを処理するメカニズムを備えるサポートが必要です。

Azure Container Apps での変更管理には、コンテナー アプリの各バージョンのスナップショットであるリビジョンによって強化されています。

リビジョンの主な特性は次のとおりです。

• 不変: 確立されると、リビジョンは変更できません。

• バージョン管理: リビジョンは、コンテナー アプリのバージョンのレコードとして機能し、さまざまな段階でその状態をキャプチャします。

• 自動プロビジョニング: コンテナー アプリを初めてデプロイすると、初期リビジョンが自動的に作成されます。

• スコープの変更: リビジョンは静的なままですが、アプリケーション スコープの変更はすべてのリビジョンに影響する可能性があります。一方、リビジョン スコープの変更により、新しいリビジョンが作成されます。

• 履歴レコード: 既定では、100 個の非アクティブなリビジョンにアクセスできますが、このしきい値は手動で調整できます。

• 複数のリビジョン: 複数のリビジョンを同時に実行できます。 この機能は、異なるバージョンのアプリを同時に管理する必要がある場合に特に便利です。

ライフサイクル

各リビジョンは、その状態と可用性の影響を受け、特定の状態になります。 コンテナー アプリは、そのライフサイクル中に、異なるプロビジョニング、実行中、非アクティブ状態を経ます。

プロビジョニング状態

新しいリビジョンを作成すると、コンテナー アプリは起動と準備のチェックを受けます。 このフェーズでは、プロビジョニングの状態が、コンテナー アプリの進行状況を追跡するためのガイドとして機能します。

実行ステータス

コンテナー アプリが正常にプロビジョニングされると、リビジョンは動作フェーズに入ります。 実行中の状態は、コンテナー アプリの正常性と機能を監視するのに役立ちます。

非アクティブ ステータス

リビジョンは非アクティブな状態になる場合もあります。 これらのリビジョンには、プロビジョニングまたは実行中の状態はありません。 ただし、Azure Container Apps では、これらのリビジョンの一覧が保持され、最大 100 個の非アクティブなエントリに対応できます。 リビジョンはいつでもアクティブ化できます。

非アクティブなリビジョン制限の変更

パラメーターとコマンドを --max-inactive-revisions containerapp create containerapp update 使用して、Container Apps によって追跡される非アクティブなリビジョンの数を制御できます。

この例では、50 個の非アクティブなリビジョンを追跡する新しいコンテナー アプリを作成する方法を示します。

az containerapp create --max-inactive-revisions 50

リビジョン モード

Azure Container Apps では、2 つのリビジョン モードがサポートされています。 モードを選択すると、同時にアクティブになっているアプリのリビジョンの数が決まります。

Labels

外部 HTTP トラフィックを含むコンテナー アプリの場合、ラベルはトラフィックを特定のリビジョンに転送します。 ラベルによって、ラベルが割り当てられているリビジョンにトラフィックをルーティングするために使用できる一意の URL が提供されます。

リビジョン間でトラフィックを切り替えるには、あるリビジョンから別のリビジョンにラベルを移動します。

• ラベルは、あるリビジョンから別のリビジョンに移動されても、同じ URL を保持します。
• ラベルは、一度に 1 つのリビジョンにのみ適用できます。
• ラベルを含むリビジョンでは、トラフィック分割の割り当ては必要ありません。
• ラベルは、アプリが "複数リビジョン" モードの場合に最も有用です。
• ラベル、トラフィック分割、またはその両方を有効にできます。

ラベルは、新しいリビジョンをテストするのに役立ちます。 たとえば、一連のテスト ユーザーにアクセス権を付与する場合、ラベルの URL を通知できます。 その後、ユーザーを別のリビジョンに移動する場合は、そのリビジョンにラベルを移動できます。

ラベルは、トラフィック分割とは独立して機能します。 トラフィック分割では、トラフィックの割合に基づいて、コンテナー アプリのアプリケーション URL に送信されるトラフィックがリビジョンに振り分けられます。 トラフィックがラベルの URL に誘導されると、このトラフィックは 1 つの特定のリビジョンにルーティングされます。

ラベル名は次の条件を満たしている必要があります。

• 小文字の英数字またはダッシュ (-) で構成される
• 英字で始まる
• 英数字で終わる

ラベルは次の条件を満たしてはなりません。

• 2 つの連続したダッシュ (--) がある
• 64 文字を超える

ラベルは、Azure portal のコンテナー アプリの [リビジョン管理] ページから管理できます。

ラベル URL は、リビジョンの詳細ウィンドウで使用できます。

ダウンタイムなしのデプロイ

単一リビジョン モードでは、Container Apps によって、新しいリビジョンを作成するときにアプリにダウンタイムが発生しないように設定されます。 既存のアクティブなリビジョンは、新しいリビジョンの準備ができるまで非アクティブ化されません。

イングレスが有効になっている場合、新しいリビジョンの準備ができるまで、既存のリビジョンはトラフィックの 100% を引き続き受信します。

新しいリビジョンは、次の場合に準備ができていると見なされます。

• リビジョンが正常にプロビジョニングされました
• リビジョンは、以前のリビジョンのレプリカ数に合わせてスケールアップされました (新しいリビジョンの最小レプリカ数と最大レプリカ数を考慮)
• すべてのレプリカが起動プローブと準備プローブに合格しました

複数リビジョン モードでは、リビジョンをアクティブ化または非アクティブ化するタイミングと、イングレス トラフィックを受信するリビジョンを制御できます。 を に設定してlatestRevisionトラフィック分割ルールtrueが構成されている場合、準備ができるまでトラフィックは最新のリビジョンに切り替わりません。

複数リビジョンを使用する

単一リビジョン モードが既定ですが、リビジョンの管理方法を完全に制御したい場合があります。

複数リビジョン モードを使用すると、リビジョンを手動で柔軟に管理できます。 たとえば、複数リビジョン モードを使用すると、各リビジョンに割り当てられるトラフィックの量を正確に決定できます。

トラフィックの分割

次の図は、2 つのリビジョンを持つコンテナー アプリを示しています。

このシナリオでは、コンテナー アプリが次の状態であることが想定されています。

• イングレスが有効になっており、コンテナー アプリは HTTP または TCP 経由で利用できます。
• 最初のリビジョンは、"リビジョン 1" としてデプロイされました。
• コンテナーが更新された後、新しいリビジョンが "リビジョン 2" としてアクティブ化されました。
• トラフィックの分割ルールは、"リビジョン 1" が要求の 80% を受信し、"リビジョン 2" が残りの 20% を受信するように構成されています。

直接リビジョン アクセス

ルーティング規則を使用してトラフィックをリビジョンに転送するのではなく、特定の URL の要求でリビジョンを使用できるようにする必要がある場合があります。 複数リビジョン モードを使用すると、ドメインに入ってくるすべての要求を最新のリビジョンに送信できますが、古いリビジョンの要求は直接アクセスの ラベルを介して使用できます。

アクティブ化の状態

複数リビジョン モードでは、必要に応じてリビジョンをアクティブ化または非アクティブ化できます。 アクティブなリビジョンは運用可能であり、要求を処理できますが、非アクティブなリビジョンは休止状態のままです。

Container Apps は、非アクティブなリビジョンに対して課金されません。 ただし、使用可能なリビジョンの合計数には上限があり、最も古いものは 100 を超えると消去されます。

変更の種類

コンテナー アプリに加えられた変更は、"リビジョンスコープ" または "アプリケーションスコープ" の変更の 2 つのカテゴリに分類されます。 アプリをデプロイするときに、"リビジョンスコープ" の変更では新しいリビジョンがトリガーされ、"アプリケーションスコープ" の変更ではトリガーされません。

リビジョンスコープの変更

新しいリビジョンは、コンテナー アプリが "リビジョンスコープ" の変更で更新されると、作成されます。 変更はデプロイされているリビジョンに限定され、他のリビジョンには影響しません。

"リビジョンスコープ" の変更とは、コンテナー アプリ リソース テンプレートの properties.template セクションのパラメーターに対するあらゆる変更です。

これらのパラメーターには、以下のものがあります。

• リビジョン サフィックス
• コンテナーの構成とイメージ
• コンテナー アプリケーションのスケール ルール

アプリケーションスコープの変更

"アプリケーションスコープ" が変更されたコンテナー アプリをデプロイする場合、次のようになります。

• 変更はすべてのリビジョンにグローバルに適用されます。
• 新しいリビジョンは作成されません。

"アプリケーションスコープ" の変更は、コンテナー アプリ リソース テンプレートの properties.configuration セクションのパラメーターに対するあらゆる変更と定義されます。

これらのパラメーターには、以下のものがあります。

• シークレット値 (コンテナーが新しいシークレット値を認識する前にリビジョンを再起動する必要があります)
• リビジョン モード
• 以下を含むイングレス構成:
  • イングレスのオンとオフを切り替える
  • トラフィックの分割ルール
  • Labels
• プライベート コンテナー レジストリの資格情報
• Dapr 設定

リビジョンをカスタマイズする

リビジョン名とラベルをカスタマイズして、名前付け規則やバージョン管理戦略に合わせて調整できます。

名前サフィックス

Container Apps のすべてのリビジョンには、一意識別子が割り当てられます。 名前は自動的に生成されますが、リビジョン名をカスタマイズできます。

リビジョン名の一般的な形式は次のとおりです。

<CONTAINER_APP_NAME>-<REVISION_SUFFIX>

たとえば、album-api という名前のコンテナー アプリがあり、リビジョン サフィックス first-revision を決定した場合、完全なリビジョン名はalbum-api-first-revision になります。

リビジョン サフィックス名は次の条件を満たす必要があります。

• 小文字の英数字またはダッシュ (-) のみで構成される
• 英字で始まる
• 英数字で終わる

名前は次の条件を満たしてはなりません。

• 2 つの連続するダッシュ (--)
• 64 文字を超える

リビジョン サフィックスは、ARM テンプレートで、Azure CLI の az containerapp create および az containerapp update コマンドを使用して、または Azure portal からリビジョンを作成するときに設定できます。

ユース ケース

コンテナー アプリでリビジョンを使用する一般的なユース ケースを次に示します。 この一覧は、Container Apps リビジョンを使用する目的や機能を網羅した一覧ではありません。

リリース管理

リビジョンにより、新しいバージョンのアプリを導入するプロセスが効率化されます。 更新プログラムまたは新機能をロールアウトする準備ができたら、現在のライブ バージョンに影響を与えずに新しいリビジョンを作成できます。 このアプローチにより、スムーズな移行が保証され、エンド ユーザーの中断が最小限に抑えられます。

以前のバージョンに戻す

以前の安定したバージョンのアプリにすばやく戻す必要がある場合があります。 必要に応じて、コンテナー アプリの以前のリビジョンにロールバックできます。

A/B テスト

異なるバージョンのアプリをテストする場合、リビジョンは A/B テストをサポートできます。 ユーザーのサブセットを新しいリビジョンにルーティングし、フィードバックを収集し、実際のデータと情報に基づいて意思決定を行うことができます。

ブルーグリーン デプロイ

リビジョンでは、ブルーグリーン デプロイ戦略 がサポートされています。 2 つの並列リビジョン (ライブ バージョンの場合は青、新しいバージョンの場合は緑) を使用することで、新しいリビジョンを段階的にフェーズ化できます。 新しいバージョンの安定性とパフォーマンスに自信を持てたら、トラフィックをグリーン環境に完全に切り替えることができます。

次のステップ