仮想ネットワークに Azure Spring Apps をデプロイする
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 に移行する」を参照してください。
この記事の適用対象:✅ Java ✅ C#
この記事の適用対象: ❎ Basic ✅ Standard ✅ Enterprise
このチュートリアルでは、Azure Spring Apps インスタンスを仮想ネットワークにデプロイする方法について説明します。 このデプロイは、VNet インジェクションとも呼ばれます。
デプロイでは次のことが可能です。
- 企業ネットワークでの Azure Spring Apps アプリとサービス ランタイムのインターネットからの分離。
- オンプレミスのデータ センター内のシステムや、他の仮想ネットワーク内の Azure サービスとの Azure Spring Apps の対話。
- Azure Spring Apps の送受信ネットワーク通信を制御するための顧客への権限付与。
次のビデオでは、管理対象仮想ネットワークを使用して Spring Boot アプリケーションをセキュリティで保護する方法について説明します。
Note
Azure 仮想ネットワークは、新しい Azure Spring Apps のサービス インスタンスを作成する時点に限り選択できます。 Azure Spring Apps を作成した後で、別の仮想ネットワークを使用するように変更することはできません。
前提条件
Azure portal でのリソース プロバイダーの登録に関するセクションの手順に従うか、以下の Azure CLI コマンドを実行して、Azure Spring Apps リソースプロバイダー Microsoft.AppPlatform
および Microsoft.ContainerService
を登録します。
az provider register --namespace Microsoft.AppPlatform
az provider register --namespace Microsoft.ContainerService
仮想ネットワークの要件
Azure Spring Apps インスタンスのデプロイ先となる仮想ネットワークは、以下の要件を満たす必要があります。
- [場所]: 仮想ネットワークは、Azure Spring Apps インスタンスと同じ場所に存在する必要があります。
- [サブスクリプション]: 仮想ネットワークは、Azure Spring Apps インスタンスと同じサブスクリプションに存在する必要があります。
- サブネット: 仮想ネットワークには、Azure Spring Apps インスタンス専用の 2 つのサブネットが含まれている必要があります:
- サービス ランタイム用に 1 つ。
- Spring アプリケーション用に 1 つ。
- これらのサブネットと Azure Spring Apps インスタンスの間には、一対一のリレーションシップがあります。 デプロイするサービス インスタンスごとに新しいサブネットを使用します。 各サブネットには、1 つのサービス インスタンスのみを含めることができます。
- アドレス空間: サービス ランタイム サブネットと Spring アプリケーション サブネットの両方に対して最大 /28 までの CIDR ブロック。
- ルート テーブル: 既定では、サブネットに既存のルート テーブルが関連付けられている必要はありません。 独自のルート テーブルを使用することができます。
次の手順を使用して、Azure Spring Apps インスタンスが含まれるように仮想ネットワークを設定します。
仮想ネットワークの作成
Azure Spring Apps インスタンスをホストする仮想ネットワークが既にある場合は、手順 1、2、3 をスキップします。 手順 4 から開始して、仮想ネットワークのサブネットを準備することができます。
Azure portal のメニューで、[リソースの作成] を選択します。 Azure Marketplace で、[ネットワーク]>[仮想ネットワーク] の順に選択します。
[仮想ネットワークの作成] ダイアログ ボックスで、次の情報を入力または選択します。
設定 値 サブスクリプション サブスクリプションを選択します。 Resource group リソース グループを選択するか、新しく作成します。 名前 「azure-spring-apps-vnet」と入力します。 場所 [米国東部] を選択します。 次へ:[次へ: IP アドレス] を選択します。
[IPv4 アドレス空間] に、「10.1.0.0/16」と入力します。
[サブネットの追加] を選択します。 [サブネット名] に「service-runtime-subnet」と入力し、[サブネットのアドレス範囲] に「10.1.0.0/24」と入力します。 その後、追加を選択します。
[サブネットの追加] を再び選択し、サブネット名とサブネット アドレス範囲を入力します。 たとえば、「apps-subnet」と「10.1.1.0/24」と入力します。 その後、追加を選択します。
[Review + create](レビュー + 作成) を選択します。 残りは既定値のままにして、[作成] を選択します。
仮想ネットワークにサービス アクセス許可を付与する
このセクションでは、Azure Spring Apps に仮想ネットワーク上のユーザー アクセス管理者とネットワーク共同作成者のアクセス許可を付与する方法について説明します。 このアクセス許可により、仮想ネットワーク上の専用かつ動的なサービス プリンシパルにさらに高度なデプロイとメンテナンスの権限を付与することができます。
Note
独自のルート テーブルまたはユーザー定義ルート機能を使用している場合は、Azure Spring Apps にルート テーブルと同じロールの割り当てを付与する必要もあります。 詳細については、「独自のルート テーブルを持ち込む」セクションおよび「Azure Spring Apps インスタンスのエグレス トラフィックを制御する」を参照してください。
アクセス許可を付与するには、次の手順を使用します。
前に作成した仮想ネットワーク
azure-spring-apps-vnet
を選択します。[アクセス制御 (IAM)] を選択してから、[追加]>[ロール割り当ての追加] の順に選択します。
Azure Spring Cloud リソース プロバイダーに
Network Contributor
およびUser Access Administrator
ロールを割り当てます。 詳細については、Azure ポータルを使用した Azure ロールの割り当て を参照してください。Note
ロール
User Access Administrator
は特権管理者ロールに属し、Network Contributor
は職務権限ロールに属します。
Azure Spring Apps インスタンスをデプロイする
仮想ネットワークに Azure Spring Apps インスタンスをデプロイするには、次の手順を使用します。
Azure Portalを開きます。
上部の検索ボックスで Azure Spring Apps を検索します。 その結果から [Azure Spring Apps] を選択します。
[Azure Spring Apps] ページで [追加] を選択します。
Azure Spring Apps の [作成] ページで、フォームに入力します。
仮想ネットワークと同じリソース グループおよびリージョンを選択します。
[サービスの詳細] の下にある [名前] で、[azure-spring-cloud-vnet] を選択します。
[ネットワーク] タブを選択し、以下の値を選択します。
設定 Value Deploy in your own virtual network (自分の仮想ネットワーク内にデプロイする) [はい] を選択します。 仮想ネットワーク [azure-spring-apps-vnet] を選択します。 Service runtime subnet (サービス ランタイム サブネット) [service-runtime-subnet] を選択します。 Spring Boot microservice apps subnet (Spring Boot マイクロサービス アプリ サブネット) [apps-subnet] を選択します。 [確認と作成] を選択します。
指定を確認し、[作成] を選択します。
デプロイ後、Azure Spring Apps インスタンスのネットワーク リソースをホストするために、サブスクリプションにさらに 2 つのリソース グループが作成されます。 [ホーム] に移動し、上部のメニュー項目から [リソース グループ] を選択して、次の新しいリソース グループを検索します。
ap-svc-rt_{service instance name}_{service instance region}
という名前のリソース グループには、サービス インスタンスのサービス ランタイム用のネットワーク リソースが含まれています。
ap-app_{service instance name}_{service instance region}
という名前のリソース グループには、サービス インスタンスの Spring アプリケーション用のネットワーク リソースが含まれています。
これらのネットワーク リソースは、上の図で作成した仮想ネットワークに接続されています。
重要
リソース グループは、Azure Spring Apps サービスによって完全に管理されています。 内部のリソースを手動で削除または変更 "しない" でください。
使用するサブネット範囲を小さくする
この表は、使用するサブネット範囲を小さくしていった場合に Azure Spring Apps がサポートするアプリ インスタンスの最大数を示したものです。
アプリ サブネットの CIDR | IP 総数 | 使用可能な IP 数 | 最大アプリ インスタンス |
---|---|---|---|
/28 | 16 | 8 | 0.5のコアを持つアプリ: 192 |
/27 | 32 | 24 | 0.5のコアを持つアプリ: 456 |
/26 | 64 | 56 | 0.5のコアを持つアプリ: 500 |
/25 | 128 | 120 | 0.5のコアを持つアプリ: 500 |
/24 | 256 | 248 | 0.5のコアを持つアプリ: 500 |
サブネットの場合、5 つの IP アドレスが Azure によって予約されており、Azure Spring Apps には少なくとも 3 つの IP アドレスが必要です。 少なくとも 8 個の IP アドレスが必要になるため、/29 と /30 は非運用です。
サービス ランタイムのサブネットの場合、最小サイズは /28 です。
Note
サブネット範囲が小さいと、イングレス コントローラーなどのシステム コンポーネントに使用できる基になるリソースに影響します。 Azure Spring Apps は、基になるイングレス コントローラーを使用してアプリケーション トラフィック管理を処理します。 イングレス コントローラー インスタンスの数は、アプリケーション トラフィックが増加すると自動的に増えます。 アプリケーション トラフィックが将来的に増加する可能性がある場合は、より広い IP 範囲の仮想ネットワーク サブネットを予約してください。 通常は、1 秒あたり 10000 個の要求のトラフィックに対して 1 つの IP アドレスを予約します。
独自のルート テーブルを使用する
Azure Spring Apps では、既存のサブネットとルート テーブルの使用がサポートされています。
カスタム サブネットにルート テーブルが含まれていない場合、Azure Spring Apps はサブネットごとにルート テーブルを作成し、インスタンスのライフサイクル全体を通してこれらにルールを追加します。 カスタム サブネットにルート テーブルが含まれている場合は、Azure Spring Apps はインスタンスの操作中に既存のルート テーブルを確認し、操作に応じてルールを追加または更新します。
警告
カスタム ルールをカスタム ルート テーブルに追加し、更新することができます。 ただし、ルールは Azure Spring Apps によって追加され、これらを更新したり削除したりすることはできません。 0.0.0.0/0 などのルールは、特定のルート テーブルに常に存在し、NVA や他のエグレス ゲートウェイなどのインターネット ゲートウェイのターゲットにマップされている必要があります。 ルールの更新でカスタム ルールのみが変更されている場合は注意が必要です。
ルート テーブルの要件
カスタム仮想ネットワークが関連付けられているルート テーブルは、次の要件を満たしている必要があります。
- Azure Spring Apps サービス インスタンスの作成時のみ、Azure ルート テーブルを仮想ネットワークに関連付けることができます。 Azure Spring Apps インスタンスを作成した後に、別のルート テーブルを使用するように変更することはできません。
- Spring アプリケーション サブネットとサービス ランタイム サブネットは、異なるルート テーブルに関連付けるか、どちらもルート テーブルに関連付けないでおく必要があります。
- インスタンスの作成前にアクセス許可を割り当てる必要があります。 ルート テーブルには、必ず Azure Spring Cloud リソース プロバイダーに
User Access Administrator
およびNetwork Contributor
アクセス許可を付与してください。 - クラスターを作成した後で、関連付けられているルート テーブル リソースを更新することはできません。 ルート テーブル リソースは更新できませんが、ルート テーブルのカスタム ルールは変更できます。
- ルーティング規則が競合する可能性があるため、複数のインスタンスでルート テーブルを再利用することはできません。
カスタム DNS サーバーの使用
Azure Spring Apps では、仮想ネットワークでのカスタム DNS サーバーの使用をサポートしています。
DNS サーバー仮想ネットワーク設定でカスタム DNS サーバーを指定しない場合、Azure Spring Apps は、既定では、Azure DNS を使用して IP アドレスを解決します。 仮想ネットワークがカスタム DNS 設定で構成されている場合は、カスタム DNS サーバー内のアップストリーム DNS サーバーとして Azure DNS IP 168.63.129.16
を追加してください。 Azure DNS は、「仮想ネットワークでの Azure Spring Apps の実行に関するお客様の責任」に記載されているすべてのパブリック FQDN の IP アドレスを解決できます。 また、仮想ネットワーク内の *.svc.private.azuremicroservices.io
の IP アドレスを解決することもできます。
カスタム DNS サーバーがアップストリーム DNS サーバーとして Azure DNS IP 168.63.129.16
を追加できない場合は、次の手順を使用します。
- カスタム DNS サーバーがすべてのパブリック FQDN の IP アドレスを解決できることを確認します。 詳細については、「仮想ネットワークでの Azure Spring Apps の実行に関するお客様の責任」を参照してください。
- アプリケーションの IP に DNS レコード
*.svc.private.azuremicroservices.io
を追加します。 詳細については、「仮想ネットワーク内の Azure Spring Apps のアプリへのアクセス」の「アプリケーションの IP アドレスの確認」セクションを参照してください。