こんにちは。
今回は、Azure Container Apps の内部ネットワーク接続をデプロイしてみました。
Azure Container App とは
Azure Cotainer Apps の概要的なことを、New Bing に聞いてみました。
すごく適切な感じw
Azure Container Apps の概要
Azure Container Apps は、サーバーレス プラットフォームでマイクロサービスとコンテナー化されたアプリケーションを実行できるサービスです。Azure Container Apps では、コンテナーの上に証明書、リビジョン、スケール、環境などのアプリケーション固有の概念が提供されます。Azure Container Apps は、Web サイトや Web API などの Web アプリケーションに適しています。
Azure Container Apps の利点
Azure Container Apps の利点は、次のとおりです。
- サーバーの管理をせずにコンテナーを実行できます。
- 需要に応じてコンテナーをオンデマンドで利用できます。
- シングル コマンドで簡単に高速にクラウドにコンテナーをデプロイできます。
- 任意のコンテナーにパッケージ化されたアプリケーション コードを実行できます。
- クラウド インフラストラクチャや複雑なコンテナー オーケストレータの管理の懸念をなくすことができます。
- KEDA がサポートする任意のスケール トリガーに基づいてアプリケーションを自動的にスケールできます。ほとんどのアプリケーションは、0 までスケールダウンすることができます。
Azure Container Apps の料金
Azure Container Apps の料金は、1 秒あたりのリソース割り当てとリクエストに基づいて課金されます²。毎月最初の 180,000 vCPU 秒、360,000 GiB 秒、200 万件のリクエストは無料です²。それ以上の場合は、お客様のアプリケーションが割り当てられる vCPU 秒や GiB 秒に応じて秒単位で支払うことになります²。
Azure Container Apps – 価格 | Microsoft Azure
今回内部構成にした理由
Azure Container Apps ってどんなシナリオで使われるかなって想像してみたんですよね。
最初に思いついたシナリオは、新規サービスでインフラとかそう言うのは極力触らずに、コードを書いて早くリリースしたいようなシーンの時かなって想像しました。
ただ、このケースってありそうで、まだまだ少ないケースな気もするんですよね。
と言うのも、こういうのやってる方ってすでにコンテナを使ってるんじゃないかなって気がするんですよね。
ただ、コンテナの環境を使っていく中で、インフラも含めた運用って意外と大変でその辺を楽したいって思って、Azure Container Apps を試そうって人もいるとは思うんですが、あえて新しいサービスを試す人は少ないんだろうなって気はするんですよね。
どっちにしろ、このシナリオですと、Azure にただ普通にデプロイする話になっちゃうからブログとしても書きづらいのでやめときました。
次に思いついたのは、やっぱり既存社内システムのマイグレーションなんです。
DX 化とかモダン化っていう文脈で、既存の社内システムをクラウドにマイグレーションするケースはすごく増えていると実感しています。
で、このケースは社内のセキュリティガバナンスで、プライベートなネットワークに閉じ込める要件は非常に多いです。
また、大きな企業になってくるとプライベートなネットワーク内の IP の枯渇問題も大きな問題です。
Azure Continer Apps も仮想ネットワークに設定するときに、/23 のサブネットを割り当てる必要があるので、IP の消費が激しく見えちゃうサービスでもあるので、この辺も含めて整理してみようかなって思いました。
構築手順
今回目指す構成
今回は、以下のように 2 つの VNET を構築する構成にしました。
VNET#1 と #2 で分ければ、#1までのネットワーク設計が楽になるかなって思ったからです。
ちなみに、参考にしたドキュメントはこちらです。
内部の Azure Container Apps 環境を使用して仮想ネットワークを統合する | Microsoft Learn
あと、NW の構成を理解するのに、真壁さんのブログはすごくわかりやすかったです。
Azure Container Appsのネットワークオプションとアクセス可能なパターン – re-imagine (torumakabe.github.io)
Azure Container App
Container Apps を作成するときには、Container Apps 環境が必要になります。
まぁー、App Service に対する、App Service Plan みたいなもんすね。
Container Apps 環境の作成
Continer Apps の作成画面から Container Apps 環境は作成できます。
今回は、ゾーン上長は無効にしたけど、可用性を考えると有効にした方がいいと思うけど、今度この辺も試してみよっと。
監視タブでは Log Analaytics をひとまず繋いどきました。
ここの設定がカスタムネットワークかマネージドネットワークかを選択って感じっすかね。
今回は、仮想ネットワーク内に閉じ込めたいのでカスタムネットワークを使って、エンドポイントも内部を選びます。
サブネットの作成はこんな感じで、/23 が必要って思われるのってここの設定ですね。
コンテナを動かすエリアは、/23 必要なんすけどね。
Container Apps の作成
Container Apps 本体をデプロイします。この前にスクショをはった Container Apps 環境は、この画面から新規作成しました。
今回は、インフラ的な範囲にとどめようと思うので、コンテナイメージはクイックスタート(準備されてるやつ)を使います。
あとは、デフォのまま作成しちゃいました。
Private Link
Azure Container Apps 側の VNET にプライベートリンクを作成します。
ロードバランサーは、kubernetes-internal を選びます。
ローバランサーのフロントエンド IP は、Container Apps のカスタムドメインと同じ IP だったのでこれを選びました。
ひとまず、ロールベースのアクセス制御のみにしちゃった。
これで、リソースは作成しちゃいました。
Private Endpoint
続いて、プライベートエンドポイントの作成です。
基本では、名前つけるだけですね。
変更できるところがなかったので次へ
プライベートエンドポイントをぶら下げる VNET とサブスクを選ぶだけっすね。
プライベート DNS はグレーになってたから選べなかったや。
プライベートエンドポイントは、こんな感じで作りました。
Private DNS
プライベート DNS ゾーンは、以下のドキュメンを参考に、「<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io」を作りました。簡単に言うと、コンテナアプリのアプリケーションの接続URLですね。
Azure Container Apps でのネットワーク アーキテクチャ | Microsoft Learn
Azure Container Apps のリソース名と プライベートエンドポイントのアドレスの A レコードは自分で作りました。
この辺は、プライベートエンドポイントを作成するときに統合しなかった(グレーアウトされてて作れなかった)けど、なんか手順変えてあげればできるのかな？
仮想ネットワークリンクも作ります。
接続テスト
接続テストです。
VNET に接続されている VM からちゃんと接続できました。
インターネット越しに接続した場合は、ちゃんとエラーになってます。
まとめ
ひとまず、プライベートな NW に閉じ込めた構成ができました。
次は、ちゃんとアプリもデプロイしてみようかなー。
ちなみに、クイックスタートを使わないと、こんな感じの設定画面です。テキトーに撮ったスクショなので、項目被ってるけど雰囲気伝わるかな？
あと、内部ネットワークに使った仮想 NW に接続されているデバイスはこんな感じでした。
裏で VMSS が動いてるんですねー。
あと、ロードバランサーも見えてて、今回作成したプライベートリンクも見えてますね。
あと、カスタムネットワーク使った場合のセキュリティ保護ってドキュメントもありますので、実際に環境構築する場合はこちらもご確認ください。
Azure Container Apps でのカスタム VNET のセキュリティ保護 | Microsoft Learn
ってことで、ひとまず内部のネットワークに閉じ込めたアプリをどんどん量産して、Azure Container Apps を使っちゃってください♪
コメント