Azure Container Apps を別のリージョンに再配置する

この記事では、ターゲットリージョンでマネージド環境とコンテナーアプリを再作成して、Azure Container Apps ワークロードを別の Azure リージョンに再配置する方法について説明します。このプロセスでは、アプリケーション構成のエクスポート、リソースの再デプロイ、デプロイの検証、ソースリージョン内のリソースのクリーンアップについて説明します。

重要

Azure Container Apps では、インプレースリージョンの移行はサポートされていません。ターゲットリージョンにリソースを 再作成 します。既存のリソースは移動されません。この記事では、Container Apps の構成とインフラストラクチャの再配置について説明します。アプリケーションデータ、データベース、またはその他のステートフルな依存関係のレプリケートについては説明しません。

[前提条件]

開始する前に、次の要件を満たしていることを確認します。

Azure Container Apps はターゲットリージョンで使用できます。
ターゲットリージョンでは、ソースリージョンで使用するのと同じ Container Apps の機能、ワークロードプロファイル、およびネットワークオプションがサポートされます。
デプロイする予定のリソースに対して、ターゲットリージョンに十分なクォータがあります。
ソースサブスクリプションとターゲットサブスクリプションの両方に、次のアクセス許可があります。
- リソースグループの所有者または共同作成者。
- コンテナアプリの貢献者 (推奨)。この役割には、コンテナアプリの秘密値へのアクセスを許可するワイルドカード権限が含まれます。より狭いアクセスについては、「秘密管理の権限」を参照してください。
コンテナーイメージは、ターゲットリージョンからアクセスできるレジストリ (Azure Container Registry やサポートされている外部レジストリなど) にあります。
Key Vault、ストレージアカウント、データベース、仮想ネットワーク、メッセージングサービスなどの依存 Azure リソースは、ターゲットリージョンで既に使用可能であるか、再デプロイ計画を持っています。

ヒント

Azure Container Registry (ACR) を使用する場合は、 geo レプリケーションを有効にして、レジストリを再デプロイせずにターゲットリージョンでイメージを使用できるようにすることを検討してください。

az acr replication create --registry <REGISTRY_NAME> --location <TARGET_REGION>

ダウンタイムの要件を理解する

Azure Container Apps では、ライブリージョンの移行はサポートされていません。ダウンタイムは、主に、カットオーバー中の DNS 伝達とトラフィックルーティングの変更によって発生します。影響を最小限に抑えるには:

先にターゲットリージョンにコンテナーアプリをデプロイして検証します。
事前に DNS TTL 値を小さく (たとえば 60 秒に)、ルーティングの変更がすぐに反映されるようにします。
検証が完了した後にのみ、運用トラフィックを新しいエンドポイントにリダイレクトします。
ターゲットのデプロイが正常であることを確認するまで、ソースコンテナーアプリを実行したままにします。

準備

再配置の準備をするには、ソース構成をエクスポートし、すべてのリージョン固有の設定を確認します。

依存関係を識別する

カットオーバーの前に、次の依存リソースがターゲットリージョンに存在する必要があります。

Azure Key Vault
ストレージアカウント
データベースとメッセージングサービス (Azure Service Bus、Azure Cosmos DB など)
仮想ネットワーク、サブネット、およびプライベートエンドポイント
ネットワークセキュリティグループ (NSG) とユーザー定義ルート (UDR)
プライベート DNS ゾーン
Log Analytics ワークスペース
DAPRコンポーネント(使用されている場合)

重要

シークレット、証明書、カスタムドメイン、およびセキュリティで保護された構成値は、エクスポートされたテンプレートには 保持されません 。これらのリソースは、元のソースからターゲットリージョンに手動で再作成する必要があります。

マネージド ID の変更を計画する

マネージド ID の処理は、ID の種類によって異なります。

システム割り当て ID: コンテナーアプリを再作成すると、Azure によって新しいプリンシパル ID が生成されます。すべての RBAC ロール、Key Vault アクセスポリシー、ダウンストリームサービスのアクセス許可を新しい ID に再割り当てする必要があります。
ユーザー割り当て ID: ユーザー割り当てマネージド ID はリージョンリソースであり、リージョン間で移動することはできません。ターゲットリージョンに新しいユーザー割り当て ID を作成し、デプロイ前に必要なアクセス許可を割り当てます。

Azure portal を使用して、Container Apps マネージド環境と個々のコンテナーアプリの両方の ARM テンプレートをエクスポートします。

Azure portal にサインインする
Container Apps マネージド環境またはコンテナーアプリリソースに移動します。
左側のメニューから、 Automation>Export テンプレートを選択します。
[ ダウンロード ] を選択し、 .zip ファイルをローカルフォルダーに展開します。

抽出されたファイルには、次のものが含まれます。

File	説明
`template.json`	リソース構成の定義
パラメーターファイル	デプロイパラメーターの値
デプロイスクリプト	テンプレート実行用のスクリプト

Azure CLI を使用して、マネージド環境とコンテナーアプリの構成をエクスポートします。

マネージド環境をエクスポートします。

az containerapp env show \
  --name <ENVIRONMENT_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --output json > managed-environment.json

コンテナーアプリをエクスポートします。

az containerapp show \
  --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --output json > container-app.json

注

エクスポートされたテンプレートは、構成を理解するための開始点として機能します。削除する必要がある読み取り専用プロパティが含まれる場合があり、シークレットや証明書 の値は含まれません 。エクスポートされた出力は、再デプロイに使用する前に注意深く確認してください。

マネージド環境テンプレートを変更する

マネージド環境を再デプロイする前に、エクスポートされた構成を更新します。

場所を更新する: location プロパティをターゲットの Azure リージョンに設定します。
リソース名を検証する: マネージド環境名がターゲットリソースグループとリージョン内で一意であることを確認します。
Log Analytics の構成を確認する: ワークスペースがリージョン固有の場合は、Log Analytics ワークスペース参照を更新します。場合によっては、ターゲットリージョンに新しいワークスペースを作成する必要があります。
読み取り専用プロパティの削除: ポータルからエクスポートした場合は、展開エラーの原因となる id、 type、 systemData、その他の読み取り専用フィールドなどのプロパティを削除します。

コンテナーアプリテンプレートを変更する

コンテナーアプリの構成をエクスポートした後、次の変更を行います。

マネージド環境のリファレンスを更新します。 managedEnvironmentId は、ターゲットリージョン内の新しいマネージド環境のリソース ID に置き換えます。マネージド環境はリージョンにバインドされており、リージョン間で再利用することはできません。
コンテナーイメージ参照の確認: イメージ参照がターゲットリージョンからアクセス可能なコンテナーレジストリを指していることを確認します。 ACR geo レプリケーションを有効にした場合、既存の参照が変更なしで機能する可能性があります。
イングレス構成を確認する: 再デプロイ後、アプリケーションの完全修飾ドメイン名 (FQDN) が変更されます。カットオーバー中にカスタム DNS レコードとトラフィックルーティングを更新することを計画します。
シークレットとアプリの設定を再構成する: Azure Key Vault 参照またはアプリケーション構成を使用してシークレットを再作成します。機密性の高い設定にエクスポートされた値に依存しないでください。
Dapr コンポーネントを更新する: Dapr を使用する場合は、Dapr コンポーネント構成がターゲットリージョンで使用可能なリソース (状態ストア、pub/sub ブローカー、シークレットストアなど) を参照していることを確認します。
診断と監視の更新: Log Analytics ワークスペースの参照を確認し、必要に応じて診断設定を再構成します。

再デプロイ

Azure Container Apps のマネージド環境はリージョンにバインドされています。コンテナーアプリを再デプロイする前に、ターゲットリージョンにマネージド環境を作成します。

マネージド環境をデプロイする

Azure Portal
Azure CLI

Azure portal で、ターゲットリソースグループに移動します。
[ カスタムテンプレートのデプロイ] を選択します。
エディターで [独自のテンプレートを作成する] を選択し、変更した ARM テンプレートをアップロードします。
展開設定を確認し、[ 確認と作成 ] を選択してデプロイを開始します。

az containerapp env create \
  --name <ENVIRONMENT_NAME> \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --location <TARGET_REGION> \
  --logs-workspace-id <LOG_ANALYTICS_WORKSPACE_ID> \
  --logs-workspace-key <LOG_ANALYTICS_WORKSPACE_KEY>

カスタム仮想ネットワークを使用する場合:

az containerapp env create \
  --name <ENVIRONMENT_NAME> \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --location <TARGET_REGION> \
  --infrastructure-subnet-resource-id <SUBNET_ID> \
  --internal-only true \
  --logs-workspace-id <LOG_ANALYTICS_WORKSPACE_ID> \
  --logs-workspace-key <LOG_ANALYTICS_WORKSPACE_KEY>

コンテナーレジストリのアクセスを検証する

コンテナーアプリをデプロイする前に、コンテナーアプリで使用される ID (システム割り当てマネージド ID またはユーザー割り当てマネージド ID) に、ターゲットの Azure Container Registry に AcrPull ロールが割り当てられていることを確認します。

az role assignment create \
  --assignee <IDENTITY_PRINCIPAL_ID> \
  --role AcrPull \
  --scope <ACR_RESOURCE_ID>

注

コンテナーアプリが別のサブスクリプションまたはリージョンの ACR を参照している場合は、デプロイ中にイメージのプルエラーが発生しないように、必要なアクセス許可が事前に構成されていることを確認します。

コンテナーアプリをデプロイする

Azure Portal
Azure CLI

Azure portal で、ターゲットリソースグループに移動します。
[ カスタムテンプレートのデプロイ] を選択します。
コンテナーアプリの変更された ARM テンプレートをアップロードします。
設定を確認し、デプロイを完了します。

az containerapp create \
  --name <APP_NAME> \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <IMAGE_REFERENCE> \
  --target-port <PORT> \
  --ingress external \
  --registry-server <ACR_LOGIN_SERVER> \
  --registry-identity <IDENTITY_RESOURCE_ID>

エクスポートされたテンプレートからの完全な構成の再デプロイの場合:

az deployment group create \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --template-file container-app-template.json \
  --parameters container-app-parameters.json

ネットワークの構成

デプロイ後、ソース構成と一致するようにネットワークを再構成します。

イングレスの構成: アプリケーションの露出モデルに基づいて、パブリックまたはプライベートのイングレスを設定します。
VNet 統合の再適用: コンテナーアプリがプライベートネットワークを使用する場合は、ターゲットリージョンで VNet、サブネット、プライベートエンドポイント、プライベート DNS ゾーンを構成します。
NSG と UDR の更新: 必要に応じて、ネットワークセキュリティグループとユーザー定義ルートを再作成します。
IP 許可リストの更新: ダウンストリームサービスで IP ベースの許可リストが使用されている場合は、ターゲットリージョン環境の新しい送信 IP アドレスで更新します。
カスタムドメインと証明書を構成する: カスタムドメインと TLS 証明書は再配置中に転送されません。新しいコンテナーアプリでこれらを再構成し、DNS レコードを更新します。

トラフィックをカットオーバーする

検証後、ターゲットリージョンのデプロイにトラフィックをリダイレクトします。

以前に DNS TTL を下げた場合は、新しいコンテナーアプリの FQDN を指す DNS レコードを更新します。
Azure Front Door または Azure Traffic Manager を使用する場合は、バックエンドプールまたはエンドポイントを更新してターゲットリージョンコンテナーアプリを含め、ソースリージョンエンドポイントを削除します。
トラフィックを監視して、要求が新しいデプロイメントに到達していることを確認します。

ヒント

ロールバックウィンドウでソースコンテナーアプリを実行したままにします。問題が発生した場合は、問題を解決するまで、DNS またはトラフィックルーティングをソースエンドポイントに戻します。

確かめる

トラフィックのカットオーバー後、次の項目を検証します。

アプリケーションの可用性と応答時間。
予想される負荷とピーク時の負荷でのスケーリング動作。
データベース、Key Vault、ストレージ、メッセージングなどの依存サービスへの接続。
ダウンストリームリソースへのマネージド ID アクセス。
DAPRコンポーネント機能を使う場合。
Azure Monitor と Log Analytics に流れるログとメトリック。

CLI を使用して確認します。

# Confirm the container app is running
az containerapp show \
  --name <APP_NAME> \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --query "{status:properties.runningStatus, fqdn:properties.configuration.ingress.fqdn}" \
  --output table

# Test the application endpoint
curl -s -o /dev/null -w "%{http_code}" https://<APP_FQDN>/health

重要

検証が完了し、ターゲットのデプロイが正常であることが確認されるまで、ソースコンテナーアプリを実行したままにします。ソースリソースをクリーンアップする前に、ロールバックウィンドウ (24 ~ 48 時間など) を定義します。

ソースリソースを整理する

検証とトラフィックのカットオーバーが成功した後:

ソースコンテナーアプリを削除します。
ソース管理環境が不要になった場合は削除します。
不要な料金が発生しないように、未使用のコンテナーイメージ、ネットワークリソース、ID の割り当てを削除します。
ソースリソースを参照した監視ダッシュボードまたはアラートルールを更新します。

制限事項

Azure Container Apps では、インプレースまたはライブリージョンの再配置はサポートされていません。
シークレット、証明書、およびカスタムドメインを再作成する必要があります。
リビジョン履歴は、ターゲットデプロイには保持されません。
カットオーバー中にはダウンタイムが必要です。
システム割り当てマネージド ID プリンシパル ID が変更されるため、すべての RBAC 割り当てを再作成する必要があります。
ユーザー割り当てマネージド ID はリージョンであり、ターゲットリージョンで再作成する必要があります。
送信 IP アドレスが変更され、ダウンストリームサービスの許可リストに影響する可能性があります。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-09-04