Azure Deployment Environments

解決する課題

• 開発者が検証・ステージング環境を必要とするたびに、インフラチームへ依頼して払い出しを待つボトルネックが生じる
• 各自が手作業で環境を作ると、構成がばらつき・ポリシー違反・タグ漏れが起きてガバナンスが効かない
• セルフサービスで自由に作らせると、今度は使い終わった環境が放置されてコストが膨らむ
• どのチームがどのサブスクリプションにどんな権限で環境を作れるか、払い出しの境界を中央で統制したい
• アプリの環境構築を IaC として再現性高くしたいが、開発者全員に IaC の専門知識を求めたくない

主要概念と用語

• Azure Deployment Environments（ADE）: プラットフォームチームが用意したテンプレートから、開発者がセルフサービスで Azure 環境（リソース一式）を払い出せるサービス。準拠性を保ったまま環境構築の待ち時間をなくす
• Dev Center: ADE と Microsoft Dev Box が共有する上位の管理コンテナ。カタログ・環境タイプ・プロジェクトなどの設定をここに集約する
• カタログ（catalog）: 環境を定義する IaC テンプレート（環境定義）の集合を保持する Git リポジトリ。GitHub または Azure Repos を Dev Center に接続して取り込む
• 環境定義（environment definition）: カタログ内の 1 つのテンプレート。ARM/Bicep などの IaC と、それを記述したマニフェスト（environment.yaml）の組で構成される
• プロジェクト（project）: Dev Center 配下のチーム単位の区切り。開発者はプロジェクトを通して環境を作成し、アクセス権もプロジェクト単位で付与する
• 環境タイプ（environment type）: Dev/Test/Prod のような環境の種別。どのサブスクリプションにデプロイし、どの ID とロールで作るかを環境タイプ単位で対応づける
• 開発者ポータル（developer portal）: 開発者が環境を作成・一覧・削除するセルフサービスの Web 画面。CLI や API からも同じ操作ができる

仕様・制限・クォータ

• 環境定義のテンプレートは **Git リポジトリ（GitHub または Azure Repos）**から取り込む。リポジトリを Dev Center にカタログとして接続し、同期して使う
• デプロイ先は環境タイプに紐づくサブスクリプションで、デプロイはマネージド ID の権限で実行される。開発者自身に対象サブスクリプションの直接権限は不要
• 開発者が環境を作れるかどうかは、プロジェクトと環境タイプ単位の RBACで制御する。種別ごとに作成可否や権限を分けられる
• 1 つの Dev Center に複数のプロジェクト・複数の環境タイプ・複数のカタログを束ねられ、組織構造に合わせて分割できる
• 利用できるリージョンや、Dev Center あたりのプロジェクト数などの上限は変動するため、最新の公式ドキュメントで確認する

内部の仕組み

ADE の中核は Dev Center に集約された設定と、環境タイプを通じたデプロイ先サブスクリプションへの権限の橋渡しです。プラットフォームチームは IaC テンプレートを Git リポジトリに置き、それをカタログとして Dev Center に接続します。各テンプレート（環境定義）は、マニフェストとデプロイ本体の IaC で構成されます。

開発者が開発者ポータルや CLI から環境を作成すると、ADE は選ばれた環境定義を、その環境タイプに対応づけられたサブスクリプションへ、設定されたマネージド ID の権限でデプロイします。これにより、開発者本人に対象サブスクリプションへの広い権限を渡さずに、準拠した環境だけをセルフサービスで払い出せます。

• デプロイの実体は IaC の展開なので、誰が作っても同じ構成が再現される
• 環境タイプにポリシーやタグを効かせれば、払い出し時点でガバナンスを強制できる
• 作成した環境はメタデータとして ADE に追跡され、一覧・削除をセルフサービスで行える

設計パターン / ベストプラクティス

• 環境タイプで境界を引く: Dev/Test/Prod を別々の環境タイプにし、それぞれ別サブスクリプション・別 ID・別ロールへ対応づける。本番だけ作成を絞るといった統制が自然に効く
• テンプレートは IaC としてコード管理: 環境定義を Git で管理し、レビューとバージョン管理を通す。カタログ同期で配布が一元化される
• 最小権限のマネージド ID: デプロイ用 ID には、その環境タイプで必要なロールだけを必要なサブスクリプションスコープに付与する
• プロジェクト単位で権限を配る: 開発者にはプロジェクト経由のロールだけを渡し、サブスクリプションへの直接権限を持たせない
• 使い捨て前提の運用: 検証用環境は作って壊す前提にし、放置によるコスト累積を避ける運用ルールと組み合わせる

運用・監視

• Azure Monitor / アクティビティログで、どのプロジェクトのどの環境タイプにいつ何がデプロイされたかを追跡する。払い出しの監査証跡になる
• Azure Policy をデプロイ先サブスクリプションに適用し、環境タイプ単位でコンプライアンス基準を横断強制する
• タグ付けを環境定義やデプロイ先に効かせ、コスト配賦・所有者・期限の管理をしやすくする
• 作成済み環境を開発者ポータルや CLI で定期的に棚卸しし、不要な環境を削除する。セルフサービスは放置リスクと表裏一体なので運用で締める
• カタログの同期状態とテンプレートのエラーを監視し、壊れた環境定義が配布されないようにする

コスト

ADE の管理面（Dev Center・プロジェクト・カタログ・環境タイプの定義）そのものに対する考え方は、実際に払い出した環境のリソースに費用がかかるという点が中心です。つまり開発者が作成した環境内の VM・ストレージ・データベースなどが、従来どおりそれぞれのサービスとして課金されます。セルフサービスで気軽に環境を作れる反面、作った環境を放置すると課金が累積するため、使い捨て運用と棚卸しがコスト管理の要になります。変動する具体的な単価や、サービス利用に伴う費用の扱いは公式の料金ページで都度確認してください。

セキュリティ

• 開発者は対象サブスクリプションへの直接権限を持たず、デプロイは環境タイプに紐づくマネージド ID の権限で実行される。権限の集約点を中央に置ける
• 作成可否や権限はプロジェクトと環境タイプ単位の RBACで制御し、本番系は作成を絞るなど種別ごとに分離できる
• デプロイ用 ID には最小権限のロールだけを必要なスコープに付与する。広いロールを恒久付与しない
• 環境定義は Git でコード管理しレビューを通すため、何がデプロイされるかを事前に把握・統制できる
• 払い出しの操作はアクティビティログに記録され、誰がどの環境を作成・削除したかを監査できる

関連サービス・比較

ADE と対比されやすいのが、汎用の IaC 展開サービスである **Azure Resource Manager（Bicep/ARM テンプレート）**です。素の ARM/Bicep が「テンプレートを展開する道具」そのものであるのに対し、ADE は「そのテンプレートをカタログ化し、開発者にセルフサービスとガバナンスを付けて配る」上位の枠組みです。ADE の内部では結局 IaC が展開されるため、両者は対立ではなく階層の違いと捉えるとよいです。

ハンズオン / CLI例

# devcenter 拡張機能を追加
az extension add --name devcenter

# プロジェクトで利用可能な環境定義（カタログ内テンプレート）を一覧
az devcenter dev environment-definition list \
  --dev-center-name "<dev-center-name>" \
  --project-name "<project-name>" -o table

# 利用可能な環境タイプ（Dev/Test/Prod など）を一覧
az devcenter dev environment-type list \
  --dev-center-name "<dev-center-name>" \
  --project-name "<project-name>" -o table

# 環境を作成（環境タイプと環境定義を指定してセルフサービスで払い出し）
az devcenter dev environment create \
  --dev-center-name "<dev-center-name>" \
  --project-name "<project-name>" \
  --environment-name "my-sandbox" \
  --environment-type "Dev" \
  --environment-definition-name "<definition-name>" \
  --catalog-name "<catalog-name>"

# 作成済み環境を一覧して棚卸し
az devcenter dev environment list \
  --dev-center-name "<dev-center-name>" \
  --project-name "<project-name>" -o table

# 使い終わった環境を破棄してコスト累積を防ぐ
az devcenter dev environment delete \
  --dev-center-name "<dev-center-name>" \
  --project-name "<project-name>" \
  --environment-name "my-sandbox"