Azure Container Apps に VNet 統合サポートが追加されたので試してみました

※Azure Container Apps はこの投稿時点ではパブリックプレビューでの提供のため、一般提供 (GA) のタイミングで手順や挙動が変更になる場合があります。

Microsoft Ignite 2021 で発表された Microsoft Azure の新しいサービス「Azure Container Apps (ACA)」について、仮想ネットワーク (VNet) 統合のサポートが追加された旨のアナウンスがありました。

Public preview: Custom virtual network support in Azure Container Apps | Azure updates | Microsoft Azure

Start deploying Azure Container Apps into your own Azure virtual netowrks.

Azure Container Apps Virtual Network Integration

Today, we are excited to announce that Azure Container Apps can be deployed into a custom Azure Virtual Network (VNet)! ...

Azure Container Apps に VNet 統合のサポートが追加されたことで、外部に公開することなく VNet 経由でのみアクセスさせることも可能となります。

Azure Container Apps に VNet 統合を追加するには、 Microsoft Docs に Azure ポータルもしくは Azure CLI から実施することが可能な風に記載がありますが、設定にあたり少しハマった部分もあったので、以下に纏めました。

Integrate a virtual network with an external Azure Container Apps environment

Learn how to integrate a VNET with an external Azure Container Apps environment.

Azure Container Apps の VNet 統合について
まとめ
関連リンク

Azure Container Apps の VNet 統合について

Azure Container Apps でデプロイされたアプリケーションを直接パブリックインターネットからアクセスできないように、VNet 上にデプロイ、ネットワーク分離を行うというものになります。

実際には Azure Container Apps はコンテナーアプリ環境上にデプロイ、動作しますが、ネットワーク分離を行うにはこのコンテナーアプリ環境に対して VNet 統合を行う形となります。

VNet 統合できる構成としては、以下となります。
※実際にアクセスする場合は、IP アドレスではなく、FQDN を指定します。

Internal (内部)
- プライベート IP アドレスなエンドポイントを介してアプリケーションにアクセス
External (外部)
- パブリック IP アドレスなエンドポイントを介してアプリケーションにアクセス

図として表現すると、ざっくりとではありますが以下となります。

Internal (内部)

External (外部)

App Service Environment (ASE) や Azure Kubernetes Service (AKS) の VNet 統合をイメージしてもらえれば分かりやすいかも。
※コンテナーアプリ環境を含む Azure Container Apps のベースは AKS

前提について

Azure Container Apps の VNet 統合環境の作成にあたり、前提条件は以下となります。

既存のコンテナーアプリ環境を用いて VNet 統合の追加は不可
- 新規作成のみ
VNet 統合で使用する VNet のアドレス空間は、以下のアドレス範囲と重複しないこと
- 169.254.0.0/16
- 172.30.0.0/16
- 172.31.0.0/16
- 192.0.2.0/24
VNet 統合で使用する VNet 内に２つの空のサブネット (/12 ～ /21 の範囲) を作成しておく必要がある
- コントロールプレーン用サブネット : コントロールプレーンインフラストラクチャとアプリケーションコンテナーで利用される
- アプリケーション用サブネット : デプロイされるアプリケーションコンテナーで利用される
Internal (内部) 向け VNet 統合で使用する VNet について、既定の「すべて許可」構成を用いる必要がある
※ネットワークセキュリティグループは設定しないようにする
- 「すべて拒否する」構成については、VNet 内に流れるトラフィックの依存関係が明確になっていないため

環境作成手順

Azure CLI による作成については、ドキュメントでは作成できない (エラーになる) 個所があったため (理由は後述)、ここでは Azure ポータルによる Internal (内部) 向け Azure Container Apps の VNet 統合環境作成手順をまとめています。

Azure Container Apps と VNet 統合されたコンテナーアプリ環境の作成

Azure Marketplace から「コンテナーアプリ」を検索し、[作成] をクリックします。
[コンテナーアプリの作成画面] 内にある [基本] タブにて [サブスクリプション]、[リソースグループ] を指定し、[コンテナーアプリ名] を入力した後で、[コンテナーアプリ環境] にある [新規作成] をクリックします。
※必要に応じて [リソースグループ] を新規作成する。
[コンテナーアプリ環境の作成] 画面内の [基本] タブにて [環境名] を入力、[地域] にてデプロイするリージョンを選択します。

なお、投稿時点ではデプロイ可能なリージョンは以下となります。
- East US
- North Europe
- Canada Central
- East US 2
- West Europe
[監視] タブを選択肢、Log Analytics ワークスペースを指定、もしくは新規作成します。
[ネットワーク] タブを選択肢、[自分の仮想ネットワークを使用する] で「はい」を選択します。
選択後に表示される [仮想ネットワーク]、[Control plane subnet] および [Apps subnet] を指定、ないし [新規作成] をクリックして、作成します。
その後、ここでは [仮想 IP] に対して「Internal: The endpoint is an internal load balancer」を選択した上で、[Create] をクリックして、コンテナーアプリ環境を作成します。
- ここで VNet を新規作成する場合、アドレス空間が「10.0.0.0/16」固定となってしまうため、予め VNet やサブネットを作成しておいたほうが良いかと思います。
  
  ※Azure CNI ネットワークの設定がらみで固定化されている可能性あり
  
  Azure Kubernetes サービス (AKS) で Azure CNI ネットワークを構成する - Azure Kubernetes Service
  Azure Kubernetes Service (AKS) で Azure CNI (高度な) ネットワークを構成する方法について学習します。
  learn.microsoft.com
- サブネットについても、/21 よりも大きい値でで新規作成、指定する場合、以下のエラーが表示されます。
[コンテナーアプリの作成画面] 内にある [基本] タブに戻るので、[確認と作成] をクリックします。
※[アプリ設定] タブでは Azure Container Apps にデプロイするコンテナーイメージを指定することも可能ですが、手順の確認のため、ここではデフォルトのクイックスタートイメージを指定する形を取っています。
内容を確認して問題がないようであれば [作成] をクリックしてデプロイします。

デプロイ後に作成されるリソースグループ「MC_…」について

Azure Container Apps の VNet 統合環境作成とともに、先頭に「MC_」から始まるリソースグループが作成されます。

このリソースグループ内には、ロードバランサーやパブリック IP アドレスといった Azure Container Apps の VNet 統合環境によって管理されるインフラストラクチャコンポーネントとなるため、変更や削除は行わないようにしてください。

作成したサブネットは本当に使われているのか？

前提条件にも記載したとおり、Azure Container Apps の VNet 統合環境で指定したそれぞれのサブネットともに /12 ～ /21 の範囲である必要がありますが、本当に使用されているかは気になるところです。

VNet の設定を確認してみると、きちんとノードプール (VMSS) として使用されていることが確認できます。

このノードプールは Azure 側で管理されるため、アクセスしようとしても権限がないためエラーとなります (既定の動作)。

Internal (内部) 向けコンテナーアプリ環境を作成する際の Azure CLI でのエラーについて

External (外部) 向けは問題なかったですが、Internal (内部) 向けコンテナーアプリ環境を作成する際、ドキュメントには –internal-only オプションを付与する記載がありますが、付与して実行してみると、そんなオプションは存在しないと言われてエラーとなり、作成することはできませんでした。
※az containerapp のバージョンは 0.2.0

※az containerapp v0.2.2 で修正されていました。

プライベート DNS の作成、設定手順

Internal (内部) 向け Azure Container Apps の VNet 統合環境の作成後、インターネット経由でアプリケーションにアクセスしようとしても、エラーになることが確認できます。

ただし、この状況は VNet 内からのアクセスも同様になりますが、理由としては内部向けの名前解決が行われていないためとなります。

アクセスするようにするには、プライベート DNS を作成、設定する必要があり、手順は以下となります。

作成したコンテナーアプリの管理ブレードにある [概要] にある [Json ビュー] をクリックし、「defaultDomain」と「staticIp」の値を確認しておきます。
Azure ポータルから [プライベート DNS] を選択し、[+ 作成] をクリックします。
[プライベート DNS ゾーンの作成] 内にある [基本] タブにて [サブスクリプション]、[リソースグループ] を指定、[名前]については、手順 1. で確認した「defaultDomain」の値を入力した後で、[確認および作成] をクリックします。
内容を確認して問題がないようであれば [作成] をクリックしてデプロイします。
作成したプライベート DNS ゾーンの作成後、管理ブレード内にある [設定] – [仮想ネットワークリンク] を選択、[+ 追加] をクリックします。
以下の項目について入力指定し、[OK] をクリックして仮想ネットワークリンクを作成します。
- リンク名 : 特定の名称で問題ないですが、統合 VNet で使用している VNet 名を入力するのがよいかと思います。
- サブスクリプション : 仮想ネットワークリンする VNet が作成されているサブスクリプションを指定します (プライベート DNS と同一サブスクリプションになるかと思います)。
- 仮想ネットワーク : 統合 VNet で使用している VNet 名を指定します。
- 自動登録を有効にする : オンにします。
プライベート DNS の管理ブレードの [概要] から [+ レコードセット] をクリックします。
以下の項目を入力、指定し、[OK] をクリック、レコードセットを作成します。
- 名前 : ワイルドカード (*) を入力します。
- 種類 : 「A – IPv4 アドレスへのエイリアスレコード」を指定します。
- TTL : 任意の値で問題ありません。
- IP アドレス : 手順 1. で確認した「staticIp」の値を入力します。