カスタム仮想ネットワークの移行
Note
Basic、Standard、Enterprise プランは、2025 年 3 月中旬以降非推奨になり、廃止期間は 3 年間です。 Azure Container Apps に移行することをお勧めします。 詳細については、「Azure Spring Apps の廃止のお知らせ」を参照してください。
Standard 従量課金と専用プランは、2024 年 9 月 30 日以降に非推奨になり、6 か月後に完全にシャットダウンされます。 Azure Container Apps に移行することをお勧めします。 詳細については、「Azure Spring Apps の Standard 従量課金および専用プランを Azure Container Apps に移行する」を参照してください。
この記事の適用対象:✅ Basic/Standard ✅ Enterprise
Azure Spring Apps では、マネージド仮想ネットワーク内にアプリケーションをデプロイできます。 このセットアップにより、アプリケーションと仮想ネットワーク内にある他のリソース (データベースや他のサービスなど) の間の通信をセキュリティで保護できるようになります。 Azure Container Apps には同様の機能がありますが、いくつかの違いがあります。 この記事では、これらの違いについて説明し、マネージド仮想ネットワークを使用した Azure Container Apps 環境の作成と管理に関するガイダンスを提供します。
前提条件
- 有効な Azure サブスクリプション。 お持ちでない場合は、無料の Azure アカウントを作成することができます。
- Azure CLI。
仮想ネットワークを使用して Azure Container Apps 環境を作成する
Azure Spring Apps では、仮想ネットワーク内に、システム ランタイム用とユーザー アプリ用の 2 つのサブネットを構成する必要があります。 このセットアップにより、システム コンポーネントとユーザー アプリケーションの両方に分離性とセキュリティが確保されます。 一方、Azure Container Apps では、仮想ネットワーク内のインフラストラクチャに対して求められるサブネットが 1 つだけになるため、ネットワーク構成が簡略化されます。
Azure Container Apps では、インフラストラクチャの仮想ネットワークは顧客の仮想ネットワークから分離されるため、Azure Spring Apps で必要に応じて仮想ネットワークにサービスのアクセス許可を付与する必要はありません。 サポートされる環境は 2 種類あります。 詳細については、「Azure Container Apps 環境」の「タイプ」セクションを参照してください。 ワークロード プロファイル環境を使用する場合は、サブネットを Microsoft.App/environments に委任するように仮想ネットワークを更新する必要があります。 詳細については、「Azure Container Apps 環境に仮想ネットワークを提供する」の「環境の作成」セクションを参照してください。
また、サブネット範囲を小さくするための要件は、2 つのサービス間で異なります。
仮想ネットワークを使用して Azure Container Apps 環境を作成するには、次の Azure CLI コマンドを使用します。
az containerapp env create \
--resource-group $RESOURCE_GROUP \
--name $ENVIRONMENT \
--location "$LOCATION" \
--internal-only true \
--infrastructure-subnet-resource-id "$INFRASTRUCTURE_SUBNET"
変数 $INFRASTRUCTURE_SUBNET は、インフラストラクチャ コンポーネントとユーザー アプリ コンテナー用の、顧客の仮想ネットワーク内にあるサブネットのリソース ID です。 詳細については、「Azure Container Apps 環境に仮想ネットワークを提供する」の「環境の作成」セクションを参照してください。
Azure Container Apps で顧客の仮想ネットワークを使用することを選択しても、コンテナー アプリがパブリック要求を受け入れることができないというわけではありません。 顧客の仮想ネットワークへのアクセスのみを完全に制限する場合は、--internal-only パラメーターを true に設定する必要があります。 この設定により、パブリック エンドポイントが作成されなくなります。 詳細については、「Azure Container Apps 環境でのネットワーク」の「仮想 IP」セクションと、「内部の Azure Container Apps 環境に仮想ネットワークを提供する」を参照してください。
Azure Container Apps にアプリを移行する
Azure Container Apps 環境を作成したら、次の手順としてアプリを Azure Container Apps に移行します。 詳細については、「概念マッピング」を参照してください。 各 Azure Container App を移行するには、「アプリケーションの移行の概要」を参照し、移行プロセスのコンテナー イメージまたは成果物を選択します。
イングレス設定を変更する
Azure Container Apps には、Azure Spring Apps と比べて、イングレス設定をカスタマイズするためのより多くのオプションが用意されています。 詳細については、「Azure Spring Apps でイングレス構成をカスタマイズする」を参照してください。
次の表では、2 つのサービスの構成プロパティを対応付けています。
| 機能 | Azure Spring Apps | Azure Container Apps |
|---|---|---|
| セッション アフィニティ | ingressSettings.sessionAffinity |
ingress.stickySessions.affinity |
| セッション Cookie の最大経過期間 | ingressSettings.sessionCookieMaxAge |
EasyAuthConfig.login.cookieExpiration.timeToExpiration |
| バックエンド プロトコル | ingressSettings.backendProtocol |
ingress.transport |
| クライアント認証 | ingressSettings.clientAuth |
ingress.clientCertificateMode |
| イングレス読み取りタイムアウト | ingressSettings.readTimeoutInSeconds |
240 |
| イングレス送信タイムアウト | ingressSettings.sendTimeoutInSeconds |
240 |
Azure Container Apps では、ユーザーがカスタム タイムアウト値を指定することはできません。 代わりに、HTTP 要求に対して組み込みの要求タイムアウトが適用されます。上限は 240 秒です。 そのため、要求がこの期間を超えると、リソースを効率的に管理できるようにし、実行時間の長い要求がシステムを独占するのを防ぐために、接続が自動的に終了します。
Azure Container Apps では、session-max-age 構成項目が直接的にはサポートされません。 ただし、他の関連設定を使用して、セッションの期間と動作を管理できます。 たとえば、EasyAuth 構成で cookieExpiration 設定を使用して、認証セッションの有効期間を制御できます。 この設定では、認証 Cookie が有効な期間を指定できます。
Azure Container Apps によって提供されるイングレス設定の詳細については、「Azure Container Apps でのイングレス」を参照してください。
Azure Spring Apps と Azure Container Apps の両方に、パブリックにアクセス可能なエンドポイントを生成する方法が用意されています。 Azure Spring Apps では、各デプロイには、ブルーグリーン デプロイで使用するテスト用の一意の URL が用意されます。 同様に、Azure Container Apps では、ラベルが割り当てられている特定のリビジョンにトラフィックをルーティングするために使用できる一意の URL がリビジョン ラベルによって提供されます。 詳細については、「Azure Container Apps の変更を更新してデプロイする」の「ラベル」セクションを参照してください。
Azure Spring Apps では、システムは、Basic/Standard プランのアプリケーションの場合はポート 1025 を、Enterprise プランのアプリケーションの場合はポート 8080 を自動的にプローブします。 これらのプローブは、アプリケーション コンテナーがトラフィックを受け入れる準備ができているかどうかを判断するのに役立ちます。 一方、Azure Container Apps では、ユーザーが --target-port パラメーターを使用してプローブ ポート自体を指定できるようにすることで、より高い柔軟性が得られます。 この設定により、ユーザーはアプリケーションの構成と動作をより詳細に制御できます。
コンテナー アプリのイングレスのターゲット ポートを更新するには、次の Azure CLI コマンドを使用できます。
az containerapp ingress update \
--resource-group <resource-group> \
--name <app-name> \
--target-port <target-port>
次のリストに各パラメーターを示します。
-
--name: コンテナー アプリの名前。 -
--resource-group: コンテナー アプリを含むリソース グループ。 -
--target-port: コンテナー アプリがリッスンしているポート。
詳細については、「Azure Container Apps でアプリのイングレスを構成する」の「イングレスの有効化」セクションを参照してください。
エグレス設定を変更する (UDR)
Azure Spring Apps と Azure Container Apps の両方に、Azure Firewall を使用して、独自のルート テーブルを使用する機能 (ユーザー定義ルート (UDR)) を経由する送信トラフィックを制御する方法が用意されています。 ただし、次の違いに注意してください。
- Azure Container Apps リソース プロバイダーのロールの割り当てを追加する必要はありません。
- Azure Container Apps サービス ランタイム サブネットの専用サブネットは必要ありません。
- Azure Container Apps では、UDR をサポートするためのより柔軟な方法が提供されます。 Azure Container Apps では、Azure Spring Apps のプロビジョニング時にオプション
--outbound-typeを明示的にuserDefinedRoutingに設定する必要はありません。
詳細については、「CLI を使用したサブネット構成」の「ルート」セクションと、「ユーザー定義のルートを使用して Azure Container Apps の送信トラフィックを制御する」を参照してください。
Azure Container Apps では、「環境」の種類のワークロード プロファイルのみが UDR をサポートします。 さらに、Azure Container Apps では、NAT Gateway 経由のエグレスと、コンテナー アプリ環境でのプライベート エンドポイントの作成がサポートされます。
UDR をサポートする Azure Container Apps 環境を作成するには、次のコマンドを使用します。
az containerapp env create \
--resource-group $RESOURCE_GROUP \
--name $ENVIRONMENT \
--location "$LOCATION" \
--enable-workload-profiles \
--infrastructure-subnet-resource-id "$INFRASTRUCTURE_SUBNET"
ワークロード プロファイルを有効にするには、パラメーター --enable-workload-profiles を true に設定します。
ネットワーク セキュリティ グループを使用して仮想ネットワークをセキュリティで保護する
Azure Spring Apps と Azure Container Apps の両方で堅牢なサポートが提供されるため、ネットワーク セキュリティ グループ (NSG) を使用して送信トラフィックを効果的に管理し、セキュリティで保護できます。 主な違いは、特定の構成にあります。
詳細については、「Azure Container Apps とネットワーク セキュリティ グループでのカスタム VNET のセキュリティ保護」を参照してください。
DNS 設定を変更する
Azure Spring Apps と Azure Container Apps はどちらも、顧客の仮想ネットワークでのカスタム DNS サーバーの使用をサポートしています。 カスタム DNS サーバーにアップストリーム DNS サーバーとして Azure DNS IP 168.63.129.16 を追加することをお勧めします。
詳細については、「Azure Container Apps 環境でのネットワーク」の「DNS」セクションを参照してください。
現時点では、環境の種類が従量課金のみの Azure Container Apps では、DNS 設定の変更のフラッシュは Azure Spring Apps のようにはサポートされていません。 詳細については、「Azure Spring Apps で DNS 設定の変更をフラッシュする」を参照してください。 ただし、種類が環境のワークロード プロファイルでは、DNS 設定が 5 分ごとに自動的に更新されます。
Azure Container Apps では、プライベート DNS ゾーンを使用したデプロイがサポートされています。 詳細については、「Azure Container Apps 環境に仮想ネットワークを提供する」の「プライベート DNS を使用したデプロイ」セクションを参照してください。 この方法では、Azure Spring Apps を使用するよりも、より柔軟にプライベート DNS ゾーンのリンクの設定がサポートされます。 詳細については、「仮想ネットワーク内の Azure Spring Apps のアプリにアクセスする」の「プライベート DNS ゾーンを Azure Spring Apps にリンクする」セクションを参照してください。
顧客の仮想ネットワーク内の Azure Container Apps 内のアプリにアクセスする
Azure Container Apps では、アプリケーションをインターネットに公開したり、プライベート ネットワーク内でアプリケーションをセキュリティで保護したりするために、公衆ネットワーク アクセスとプライベート エンドポイントの両方の機能が提供されます。 同様に、Azure Spring Apps では、これらの機能は次の記事で説明されているようにサポートされています。