APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

Azure Deployment EnvironmentsとPlatform Engineeringの親和性を考える

本記事はAP Tech Blog Week Vol.5の企画(の期間を1週間ほどオーバーランしました…)です。

はじめに

こんにちは、ACS事業部の吉川です。
「自動化」というキーワードで思い浮かべる要素は様々かと思いますが、個人的には「セルフサービス」という観点が重要だと考えています。
Azureにおけるリソースの作成をセルフサービス化するための機能として Azure Deployment Environments というサービスがあります。
プレビュー開始時に本ブログでも紹介していましたが、現在とは少し異なる部分もあるため、改めてご紹介します。

techblog.ap-com.co.jp

techblog.ap-com.co.jp

Azure Deployment Environmentsの概要

Azure Deployment Environmentsの概念を説明するのにちょうどいい図が公式ドキュメントにありますので、引用しつつ見ていきましょう。

Azure Deployment Environmentsを端的に言うと、
『プラットフォームチームが事前定義した構成を、開発者がセルフサービスでプロビジョニングできる』
というサービスです。

上図の左側にある『Dev Infra Teams』は、昨今のPlatform Engineeringの文脈で言うプラットフォームチームと読み替えて差し支えないでしょう。 このチームは、あらかじめAzureリソースの構成をテンプレート化してリポジトリに格納し、開発チーム向けにサービスカタログとして公開します。
テンプレートは標準でARMテンプレートとBicepに対応しており、プロビジョニング実行用にコンテナイメージを別途作成することでTerraformとPulumiもサポートされています。

learn.microsoft.com

上図中央の『Developers』は、開発工程において必要になったタイミングで、プラットフォームチームが公開したサービスカタログから必要な構成を選んでAzureリソースを作成します。

ここで重要なポイントとしては、DevelopersはAzureリソースを作成する権限を持つ必要なく、定められた構成のみ作成可能なように統制が取れる という点です。

セルフサービスにおける権限どうする問題

プラットフォームチームとしては、開発チームからの依頼ベースでリソースを作成すると工数が膨らむ、とはいえガバナンスの観点から開発チームが好き勝手にリソースを作れてしまうのは困る… といった悩みがあると思います。
Azure Deployment Environmentsを利用することで、開発者に不要な権限を渡すことなくセルフサービスでの環境払い出しが実現できます。

仕組みとしてはシンプルで、Azureのリソース作成はAzure Deployment EnvironmentsのマネージドID(厳密に言うとDev CenterリソースのマネージドID)が行います。 また、Azure Deployment Environmentsは開発者のユーザープリンシパルに対し、作成したリソースの管理者権限を別途割り振ることもできます。 カタログからしかリソースを作成させないことで制限をかけつつ、作成したリソースに対して強い権限を割り振ることで開発者に自由を与える という、良いとこ取りな機能を簡単に実現可能です。

Azure Deployment Environments の作成

Azure Deployment Environmentsは複数のAzureリソースの組み合わせで構成されています。 公式ドキュメント にある下図を見てもわかるように、Dev CenterやProject、Catalogなど、多様なリソースが組み合わさっています。

実際に試そうとすると複数のリソースを順番に作らねばならずかなり面倒なので、Azure CLIを用いた構成用のコマンド例を以下に示します。 Dev CenterリソースのマネージドIDにサブスクリプションの「共同作成者」「ユーザーアクセス管理者」という強めの権限を与える都合上、このコマンドを実行するユーザーはサブスクリプションの管理者権限を持っている必要があります。

# リソース名/リージョンの定義
RG_NAME="rg-devcenter"
DC_NAME="devcenter-sample"
CATALOG_NAME="catalog-sample"
PROJECT_NAME="project-sample"
LOCATION="japaneast"
SUBSCRIPTION_ID=$(az account show --query id -o tsv)

# リソースグループ作成
az group create --location $LOCATION --name $RG_NAME

# Dev Centerの作成
az devcenter admin devcenter create --name $DC_NAME \
  --resource-group $RG_NAME --location $LOCATION \
  --identity-type SystemAssigned


# Dev CenterのマネージドIDに対する権限割り当て
MANAGED_ID=$(az devcenter admin devcenter show --name $DC_NAME \
  --resource-group $RG_NAME --query identity.principalId -o tsv)

az role assignment create --assignee $MANAGED_ID --role Contributor \
  --scope /subscriptions/$SUBSCRIPTION_ID
az role assignment create --assignee $MANAGED_ID --role "User Access Administrator" \
  --scope /subscriptions/$SUBSCRIPTION_ID

# カタログの作成(GitHubにあるサンプルを利用)
az devcenter admin catalog create --catalog-name $CATALOG_NAME \
  --dev-center $DC_NAME --resource-group $RG_NAME \
  --git-hub uri="https://github.com/microsoft/devcenter-catalog.git" branch="main" path="Environment-Definitions"


# 環境定義の作成
az devcenter admin environment-type create --dev-center $DC_NAME \
  --name "Dev" --resource-group $RG_NAME --tags Env="Dev"
az devcenter admin environment-type create --dev-center $DC_NAME \
  --name "Staging" --resource-group $RG_NAME --tags Env="Staging"
az devcenter admin environment-type create --dev-center $DC_NAME \
  --name "Prod" --resource-group $RG_NAME --tags Env="Prod"

# プロジェクトの作成
DC_ID=$(az devcenter admin devcenter show --name $DC_NAME \
  --resource-group $RG_NAME --query id -o tsv)
az devcenter admin project create --dev-center-id $DC_ID \
  --name $PROJECT_NAME --resource-group $RG_NAME

# プロジェクト環境の種類の作成
az devcenter admin project-environment-type create \
  --deployment-target-id /subscriptions/$SUBSCRIPTION_ID \
  --environment-type-name Dev \
  --identity-type SystemAssigned \
  --project $PROJECT_NAME \
  --resource-group $RG_NAME \
  --roles "{\"8e3af657-a8ff-443c-a75c-2fe8c4bcb635\":{}}" \
  --status Enabled

az devcenter admin project-environment-type create \
  --deployment-target-id /subscriptions/$SUBSCRIPTION_ID \
  --environment-type-name Staging \
  --identity-type SystemAssigned \
  --project $PROJECT_NAME \
  --resource-group $RG_NAME \
  --roles "{\"8e3af657-a8ff-443c-a75c-2fe8c4bcb635\":{}}" \
  --status Enabled

az devcenter admin project-environment-type create \
  --deployment-target-id /subscriptions/$SUBSCRIPTION_ID \
  --environment-type-name Prod \
  --identity-type SystemAssigned \
  --project $PROJECT_NAME \
  --resource-group $RG_NAME \
  --roles "{\"8e3af657-a8ff-443c-a75c-2fe8c4bcb635\":{}}" \
  --status Enabled

上記のコマンド例ですと、rg-devcenter というリソースグループ内に devcenter-sample というDev Centerリソースと、project-sample というProjectリソースの2つのリソースが作成されます。
開発者がカタログからリソースを作成するためには、Projectリソースに対しIAMロールの割り当てが必要です。
Azure Deployment Environmentsを利用する開発者のアカウントを、Projectリソースの Deployment Environments User に追加します。 下図では個別のユーザーを追加していますが、実際に利用する際にはグループを活用すると便利でしょう。

これでAzure Deployment Environmentsが利用可能になりました。

Azureリソースを作ってみる

それでは、実際にAzure Deployment Environmentsを利用してリソースを作成してみましょう。
作成したDev CenterリソースやProjectリソースには、以下のようにURIが表示されています。

利用するときはこのURIにアクセスして…と思いきや、このURIにはアクセスできません。
Azure Deployment Environmentsからリソースを作成するときは、https://devportal.microsoft.com にアクセスします。

左上の「+新しい環境」をクリックすると、以下のような入力画面が表示されます。

  • 名前
  • 種類
  • 定義

の項目を入力して環境を作成します。
「定義」が構成のカタログを示す部分ですが、今回は以下リポジトリにあるMicrosoftのサンプルを取り込んでいます。 自身でカタログを作成する場合にも、以下リポジトリ内のファイルを参考にするとよいでしょう。

github.com

「スケジュールされた削除を有効にします」のチェックボックスを有効化すると、作成した環境を削除する日時を設定できます。
一時的な検証目的で環境を作成する場合には有効に使える機能です。

作成が完了すると、以下のように新規のリソースグループが作成され、リソースが配置されているのが確認できます。

リソースグループのIAMを見ると、Azure Deployment Environmentsからリソースを作成したユーザーが、リソースグループの所有者として登録されていることが確認できます。

このように、

  • カタログからのセルフサービスでのリソース作成
  • 作成されたリソースに対する権限割り当て

というサービスを開発者に提供できるのがAzure Deployment Environmentsの特徴です。

おわりに

Azure Deployment Environmentsを使うことで、セルフサービスでのAzure環境払い出しを行うことができます。 期限を決めての環境自動削除も行えることから、開発環境の払い出しに向いたサービスであるといえます。

一方、実際に本番サービスを動かす環境を作るとなると、Azureリソースだけでは環境は完結せず、

  • Gitリポジトリ
  • CI/CDパイプライン
  • モニタリング/Observabilityツール

といったものも必要となります。
その点を意識するとBackstageのSoftware Template機能のほうが有力な選択肢となりうるでしょう。

techblog.ap-com.co.jp

一口にセルフサービス化といっても、どういった目的の環境を、どのような実装で提供するかは様々です。 用途にあったツールを選択していくことが重要ですね。

本記事の投稿者: 吉川 俊甫
BicepよりTerraform派。Microsoft MVP (Microsoft Azure)
Shunsuke Yoshikawa - Credly