はじめに
Azureの開発環境を準備するにあたって、いかに簡単に使えるサービスがないかなと調べていた際に、Azure Deployment Environmentsというサービスがあることを知ったので、どんなことが出来るのか調査してみました。
Azure Deployment Environments とは
開発に必要な複数の環境を高速に準備することが可能なサービスとして、Microsoft Build 2023でGAされました。（2022年のBuildでプレビューとして紹介）
東日本リージョンなどでも利用可能なサービスとなっています。
また、2023年のGA時に、以下のような機能がサポートされるようになっています。
- Azure Deployment EnvironmentsへのTerraform のコードのサポート
- Azure Deployment EnvironmentsへのGitOpsワークフローのサポート
特徴
IaCのテンプレートと開発環境を紐づけることで、開発チームにサービスを横展開できます。また、開発チームとしては、環境提供者に依頼せずとも、自分たちで環境を構築することが可能なうえ、コストや有効期限、組織のセキュリティ、ベストプラクティスの管理も可能なサービスとなっています。
使用シーン
1. 事前構成済みの数種類の環境を利用
ライフサイクル環境の作成・更新、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインへの接続が簡単に実現できます。
2. サンドボックス環境・オンデマンドの環境を作成してテスト実施
作成されるすべての環境は、それぞれのRGに作成され、プロジェクト メンバーは対象リソースに対する共同作成者のアクセス権が付与されているため、適宜必要なリソースの追加・変更が容易に可能です。
似ているサービスとの比較
Azure ARCとの比較
Azure ARCは、一貫したマルチクラウドとオンプレミスの管理プラットフォームを提供することでガバナンスと管理を簡素化するサービスです。Azure ARCと比較すると、Azure Deployment Environmentでは以下のことが実現できます。
- 開発チームがIaCテンプレートを使用して、PaaS・サーバレスなリソースも含めて、迅速かつ簡単にセルフサービスで環境構築できる
- 開発者に自身の環境を作成・破棄するために必要な権限を提供し、対象外リソース操作は制限されており、包括的な権限制御が提供されている
- 提供環境を一元的に追跡・管理する機能や、リソースが削除されるように環境を自動的に期限切れにするといったコスト管理関連の機能もサポート
Azure DevTest Labsとの比較
Azure DevTest Labsは、開発チームがインフラストラクチャ（主にVMに焦点）をセルフサービスできるようにするクラウドサービスです。高度な構成やコスト管理に関する機能のほとんどは、VMに焦点が当てられており、すべてのリソースは同じサブスクリプション内に作成されるため、使用は開発・テストシナリオに限定されてしまいます。
一方、Azure Deployment Environmentでは、簡単にアップデート可能なIaCテンプレートを使用して、セルフサービスのアプリインフラストラクチャ (PaaS、サーバーレスなど) の実行が可能です。また、開発者の現在の段階に基づいて、サンドボックス・開発・テスト・ステージング・本番などのさまざまなタイプの環境を起動できます。さらに、エンタープライズ規模のランディングゾーンを補完するもので、開発インフラチームがさまざまな種類の環境を作成するサブスクリプションを事前構成して適切なポリシーを適用することも可能です。
構成
GitHubなどに格納されたARMなどのIaCテンプレートを、Azure Deployment Environmentsに紐づけることで、開発チームは付与されている権限内の環境をセルフサービスで使用できます。構成のイメージとしては以下のような感じでしょうか。プルリクを出して改善提案なども可能です。
実際に触ってみる
では、ここからは以下解説に沿って、実際に実機を触ってみます。
1.デベロッパーセンターを作成
まずは、デベロッパーセンターという複数のプロジェクトや共通設定（カタログや環境タイプ）を束ねるコレクションを作成します。「Azure 配置環境」と日本語では表示されてしまいますが、Azure Deployment Environmentサービスページよりアクセス可能です。
2.キーコンテナの作成
GitHubやAzure DevOpsのリポジトリにアクセスするための、PAT（個人アクセストークン）を設定・格納します。
3.カタログの作成
IaCテンプレートを格納したリポジトリの参照先を表すカタログを作成します。テンプレートのメタデータによりデプロイ単位が決まり、リポジトリに問題なく接続出来たら、接続済み状態になります。
4.環境タイプを作成
IaCテンプレート記載内容に基づき、Dev・Stg・Prdなどの環境タイプを定義します。（カタログに格納します）
5.マネージドIDを設定
各サブスクリプションへのデプロイは、マネージドIDで管理します。開発チームは用意された環境のリソース作成・削除が容易になります。
6.プロジェクトの作成
開発チーム向けに公開するアクセス単位であるプロジェクトを作成します。プロジェクトは1つのデベロッパーセンターに関連付けられ、紐づけたい環境タイプを指定することができます。
7.環境の作成
開発者ツールもしくはAzure CLIより、対象のプロジェクトやサブスクリプションを指定して、環境作成します。
ここで、この環境作成時にエラーは何度か発生しました。
Azure CLIコマンド実行時のパラメータ設定不備か、公式ドキュメントの「必須」コマンドと実体は異なるかもしれません。
下記のように、環境ごとに、簡単にコスト情報などを表示することが可能だったりします。
また、「“プロジェクト名”-“環境名”」の命名規則に沿ったRGが自動的に作成されます。
以上で、構成準備が完了となります。
構成準備にあたっては、「環境」のコマンド作成時に少々戸惑いましたが、特に大きく躓きそうなところはなく完了できました。
まとめ
今回は、開発に必要な複数の環境を高速に準備することが可能となる、Azure Deployment Environmentを実際に作成してみました。開発者側からも簡単に環境作成できる上、自動的に期限切れなどの仕組みも取り込める点は、とても良いなと思います。
一方で、「環境」毎にコストがすぐに確認できます（RGの「コスト分析」ページに遷移するだけ）が、「プロジェクト」単位では料金がすぐに確認できないのは少々残念な点な気がします。
ただ、簡単に作成自体はできるため、デプロイ時にエラーが発生したとしても、被疑箇所は以下3点ぐらいかなと思います。
- PATの設定ミスによる、カタログの同期失敗
- マネージドIDの設定ミス（デベロッパーセンターに割り当たってないなど）
- IaCテンプレートの不備（今回はIaCテンプレートを公式のリポジトリをforkしているので、そのあたりの躓きはなし）
また、今回は試していませんが、デベロッパーセンターでは、Dev BoxやAzure Compute Galleryなども設定できそうなので、時間あるときにトライしてみます。