Azure Developer CLI Deep Dive Toru Makabe Sr. Cloud Solution Architect Microsoft

Agenda • 概要 • コードリーディングのコツ • Deep Dive • 展望と期待、考慮点

長いので縮めます Azure Developer CLI -> azd

概要 何ができるのか どんな特徴を持つのか 何がうれしいのか

一行にまとめると “azd provides best practice, developer-friendly commands that map to key stages in your workflow” What is the Azure Developer CLI? | Microsoft Learn

azdとは • Microsoftが開発を主導する、OSSのCLIツール（MIT License) • Azureを使うアプリ/インフラ技術者、どちらにも有用 • テンプレートから、アプリとインフラのコードを生成 • 公開テンプレートの利用だけでなく、自ら作ることもできる • インフラのプロビジョニング • アプリのパッケージングとデプロイ • 複数の開発/実行環境、言語とIaCプロバイダーに対応 • Azure CLI(az)とは別もの Azure Developer CLIとは | Microsoft Learn Azure/azure-dev (github.com)

テンプレート共有サイト(awesome-azd) Awesome AZD Templates | Awesome Azure Dev CLI 62テンプレート (2023/8/22現在) 作者が”Azure Dev”のものは azdチーム謹製

テンプレートの例 Containerized React Web App with Java API and MongoDB on Azure

テンプレートの例 ChatGPT + Enterprise data with Azure OpenAI and Cognitive Search

サポートされる開発環境 • ローカル(Windows/Linux/macOS) • Dev Container/VS Code Remote – コンテナー • GitHub Codespaces • Azure Cloud Shell サポートされている言語と環境 | Microsoft Learn <メモ> azdを使った開発に限った話ではありませ んが、開発環境のCPUがarmアーキテク チャの場合、アプリの依存する要素（コ ンテナイメージなど）がarm未対応、とい うケースがぼちぼちあります。回避策の ひとつはCodespacesでx86マシンを使う、 です。

サポートされる実行環境 • Azure App Service • Azure Static Web apps • Azure Container Apps（ベータ） • Azure Functions • Azure Kubernetes Service（ベータ） • Azure Spring Apps（ベータ） サポートされている言語と環境 | Microsoft Learn <メモ> アルファ版は試験的機能であり、`azd config`で明示的に有効にする必要があり ます。いっぽうベータ版では有効化は不 要です。破壊的変更が行われる可能性は ありますが、頻度低くコントロールされ、 かつ文書化されます。

サポートされるプログラミング言語 • Node.js • Python • .NET • Java サポートされている言語と環境 | Microsoft Learn

サポートされるIaCプロバイダー • Bicep • Terraform(アルファ) Azure Developer CLIのコード ツールとして Terraform をインフラ ストラクチャとして使用する | Microsoft Learn • 本日はBicepを中心に解説します

試すだけなら • azdをインストールする • `azd auth login`でAzureにログインする • `azd init`コマンドでテンプレートを選択し、コードを生成する • `azd up`する • 以下の操作がまとめて実行される • インフラのプロビジョニング: `azd provision` • アプリのパッケージング: `azd package` • アプリのデプロイ: `azd deploy` • すこぶる楽ちん

推しポイント • 「今風で気が利いている」リポジトリ構造と生成コード • 部分にとどまらず、全体をカバー（アプリとインフラ、開発と運用） • Azureの手練れたちが作った気の利いたテンプレートから生成されるコード • モノリポのリファレンスとしても有用（アプリとインフラ、複数サービス） • ちょっとした面倒な作業の自動化、省力化 • GitHub Actionsパイプラインの認証認可設定や変数登録などもコマンド一発 • 複数の環境を管理、切り替え可能 • azdは環境別（開発、本番など）に構成ファイルを作り、コマンド実行のつど読み込む • いちいち環境変数をセットする必要がない • `azd env select`で対象環境を切り替えられる • 活用の自由度が高い • テンプレートから生成されたコードだけ使う/参考にするもよし • azdのコードを読み、パッケージングやデプロイ自動化の参考にするもよし

コードリーディングのコツ なぜコードを読むのか コードのありか 読む環境 知っておきたいポイント

なぜazdのコードを読むのか • GAから間もなく、まだ情報が少ない • 公式ドキュメント（Microsoft Learn）が、いずれ拡充すると期待しつつ • 動きを理解するならコードを読むのが確実 • 自己解決能力を高める • 便利ゆえ、強く依存してしまう可能性がある • ブラックボックスにしない • コマンドの中でやっていることが参考になる • 自動化や効率化のヒントがたくさんある • 自動化に必要な情報とその取得元/取得方法、バリデーション、リソースの操作、エラー/ 例外処理、etc • そこに読めるコードがあるから • コツをつかめば難しくありません

本日、前提とするバージョンは1.2.0

コードのありか • リポジトリ: https://github.com/Azure/azure-dev • CLIのほかに、Dev Container定義やVS Code Extensionコードも含まれる • CLIのコード: https://github.com/Azure/azure-dev/tree/azure-dev- cli_1.2.0/cli/azd

読む環境 • VS Codeなどコードナビゲーションしてくれる環境がおすすめ • 定義や参照、実装へジャンプできると読みすすめやすい • Dev Containerはさらにおすすめ • azdのリポジトリにDev Container定義が入っている （GoツールチェインやVS Code Go拡張入り） • `azd init`でテンプレートからコードを生成しておくとよい • テンプレートは何でもよい （本日はContainerized React Web App with Java API and MongoDB on Azureを使用） • azdが生成し、参照、編集する対象を見ながらコードを読むとピンときやすい • azdコマンドを打ちながら読むとさらに腹落ちする

読む前に知っておきたいポイント • azdはGoで書かれている • CLIフレームワーク“Cobra”を使っている • お作法を知っていると読みやすい • DIコンテナ”golobby/container”を使っている • DI/IoCしているとわかっていれば読みやすい • 採用の経緯 https://github.com/Azure/azure-dev/pull/1253 • 拡張/差し替えしやすい作りにしている

Cobraの基本(1/2) var cmdPrint = &cobra.Command{ Use: "print [string to print]", Short: "Print anything to the screen", Long: `print is for printing anything back to the screen. For many years people have printed back to the screen.`, Args: cobra.MinimumNArgs(1), Run: func(cmd *cobra.Command, args []string) { fmt.Println("Print: " + strings.Join(args, " ")) }, } Cobra. Dev • cobra.Command構造体にコマンドの中身を詰める • コマンド名と説明、引数、実行する関数などを定義する

Cobraの基本(2/2) var rootCmd = &cobra.Command{Use: "app"} rootCmd.AddCommand(cmdPrint, cmdEcho) cmdEcho.AddCommand(cmdTimes) rootCmd.Execute() Cobra. Dev • ルートコマンドを作る • ルートコマンドにサブコマンドを追加する • サブコマンドにサブコマンドを追加できる • ルートコマンドを実行 • Cobraが入力に応じてコマンド（サブコマンド）を判断し、実行 • この例では`app print hoge`を実行すると、cmdPrintに定義したサブコマンドが引数hoge で呼ばれる

azd main関数のポイント cmdErr := cmd.NewRootCmd(false, nil).ExecuteContext(ctx) https://github.com/Azure/azure-dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/main.go#L60 azdコマンド/サブ コマンドをまとめ て作る関数 • cmdパッケージのNewRootComd関数が本丸 • NewRootComd関数はcmd/root.goにある

サブサブ…コマンド configActions(root, opts) envActions(root) infraActions(root) pipelineActions(root) telemetryActions(root) templatesActions(root) authActions(root) https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/cmd/root.go#L104 • NewRootComd関数にサブコマンドのサブコマンドまでベタに書くと、読みにくい • サブコマンドにサブコマンドがある場合、関数化している

DIコンテナを意識(1/3) root.Add("show", &actions.ActionDescriptorOptions{ Command: newShowCmd(), FlagsResolver: newShowFlags, ActionResolver: newShowAction, OutputFormats: []output.Format{output.JsonFormat}, DefaultFormat: output.NoneFormat, }) https://github.com/Azure/azure-dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/cmd/root.go#L126 • cobra.Command構造体に直接詰めてないところがある • DIコンテナで後から解決するんだな、と意識して読む • 実行時の流れを追いたいときは、ActionResolverの定義に飛ぶ • この例ではnewShowAction • newShowActionはshowAction構造体を作る

DIコンテナを意識(2/3) func (s *showAction) Run(ctx context.Context) (*actions.ActionResult, error) { res := contracts.ShowResult{ Name: s.projectConfig.Name, Services: make(map[string]contracts.ShowService, len(s.projectConfig.Services)), } [snip] https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/cmd/show.go#L87C1-L91C3 • 各コマンドには、その構造体をレシーバとするRunメソッドがある • 各コマンドが何をやっているかを知りたいときは、主にここを読む

DIコンテナを意識(3/3) registerCommonDependencies(ioc.Global) cobraBuilder := NewCobraBuilder(ioc.Global) // Compose the hierarchy of action descriptions into cobra commands cmd, err := cobraBuilder.BuildCommand(root) https://github.com/Azure/azure-dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/cmd/root.go#L310 • DIまわりの処理は、この辺の関数を読むとわかる • コマンドの組み立てだけでなく、必要なリソースの準備もしている • 例: プロジェクト構成ファイルを読み込み、ProjectConfig構造体を作る • 「この構造体、どこで作ってるの…」なんて時は、この辺の関数を読んでみる

Deep Dive 主要コマンドの解説 コードを読みながら デモを交えて

azd auth login

Azureにログインする azd auth login [flags] --check-status --client-certificate string --client-id string --client-secret string --docs --federated-credential-provider string -h, --help --redirect-port int --tenant-id string --use-device-code[=true] • `azd login`はdeprecated Azure Developer CLI リファレンス | Microsoft Learn

認証情報の永続化場所 func GetUserConfigDir() (string, error) { configDirPath := os.Getenv("AZD_CONFIG_DIR") if configDirPath == "" { homeDir, err := os.UserHomeDir() if err != nil { return "", fmt.Errorf("could not determine current home directory: %w", err) } configDirPath = filepath.Join(homeDir, cConfigDir) [snip] https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/pkg/config/manager.go#L83 • Azure CLI(az)とは別なので注意 “.azd”

azdの認証情報を利用できるSDKもある azure-sdk-for-java/sdk/identity/azure-identity/README.md (github.com) • たとえばAzure SDK for JavaはDefaultAzureCredentialでazdの認証情報を見に行く • 開発環境からAzureのリソースにアクセスしたい場合に便利

azd init

azdプロジェクトを初期化する azd init [flags] -b, --branch string --docs -e, --environment string -h, --help -l, --location string --subscription string -t, --template string Azure Developer CLI リファレンス | Microsoft Learn

埋め込みテンプレート //go:embed templates.json var TemplatesJson []byte https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/resources/resources.go#L7 • テンプレートを指定せずに`azd init`した場合にリストされるテンプレート名のありか • go:embedでtemplates.jsonを埋め込んでいる

テンプレート指定形式 switch strings.Count(path, "/") { case 0: return fmt.Sprintf("https://github.com/Azure-Samples/%s", path), nil case 1: return fmt.Sprintf("https://github.com/%s", path), nil default: return "", fmt.Errorf( [snip] https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/pkg/templates/path.go#L18 • -tオプションで、GitHubリポジトリからテンプレートの取得を試みる • オーナー名抜きでリポジトリ名のみが指定された場合は、Azure-Samplesの下を見に行く

`azd init`で作成されるファイルとディレクトリ構造 ├── .azdo [ For Azure DevOps ] │ └── azure-dev.yaml [ Azure Pipelines workflow to deploy to Azure using azd ] ├── .azure [ For storing Azure configurations] │ └── [ For storing all environment-related configurations] │ ├── .env [ Contains environment variables ] │ └── config.json [ Contains environment configuration ] ├── .devcontainer [ For DevContainer ] │ ├── devcontainer.json [ For setting up the containerized development environment ] │ └── Dockerfile [ For building the container image ] ├── .github [ For GitHub workflow ] │ └── azure-dev.yaml [ GitHub Actions workflow to deploy to Azure using azd ] ├── infra [ For creating and configuring Azure resources ] │ ├── abbreviations.json [ Recommended abbreviations for Azure resources ] │ ├── main.bicep [ Main infrastructure file ] │ └── main.parameters.json [ Parameters file ] └── azure.yaml [ Describes the app and type of Azure resources] プロジェクトをAzure Developer CLIと互換性のあるものにする | Microsoft Learn

超重要! azure.yaml (1/2) name: todo-java-mongo-aca metadata: template: todo-java-mongo-aca@0.0.1-beta services: web: project: ./src/web language: js host: containerapp api: project: ./src/api language: java host: containerapp • アプリのソースの場所や言語、実行環境などを指定する • このファイルの指定で、ビルドやパッケージング、デプロイで使うツールと動きが変わる

超重要! azure.yaml (2/2) services: api: project: ./src/api language: js host: appservice hooks: prerestore: shell: sh run: echo 'Restoring API service...' prepackage: run: ./hooks/prepackage.sh • コマンドの実行前後にフックを入れてカスタマイズできる コマンドフックとイベントフックを使用してAzure Developer CLIワークフローをカスタマイズする | Microsoft Learn

azd env

新しい環境を作り、既定値として設定する azd env new [flags] --docs -h, --help -l, --location string --subscription string Azure Developer CLI リファレンス | Microsoft Learn

環境関連ファイルのありか ├── .azdo [ For Azure DevOps ] │ └── azure-dev.yaml [ Azure Pipelines workflow to deploy to Azure using azd ] ├── .azure [ For storing Azure configurations] │ └── [ For storing all environment-related configurations] │ ├── .env [ Contains environment variables ] │ └── config.json [ Contains environment configuration ] ├── .devcontainer [ For DevContainer ] │ ├── devcontainer.json [ For setting up the containerized development environment ] │ └── Dockerfile [ For building the container image ] ├── .github [ For GitHub workflow ] │ └── azure-dev.yaml [ GitHub Actions workflow to deploy to Azure using azd ] ├── infra [ For creating and configuring Azure resources ] │ ├── abbreviations.json [ Recommended abbreviations for Azure resources ] │ ├── main.bicep [ Main infrastructure file ] │ └── main.parameters.json [ Parameters file ] └── azure.yaml [ Describes the app and type of Azure resources]

既定の環境名 suggest := environment.CleanName(filepath.Base(wd) + "-dev") if len(suggest) > environment.EnvironmentNameMaxLength { suggest = suggest[len(suggest)- environment.EnvironmentNameMaxLength:] } • `azd init`時に新たな環境が作られるが、既定の環境名は実行ディレクトリ名 + “-dev” https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/cmd/init.go#L182

.envファイルの例 AZURE_ENV_NAME="azd-demo-todo-java-aca-dev" AZURE_SUBSCRIPTION_ID="df671090-66cd-42d6-a023-164643e521fc" SERVICE_API_IMAGE_NAME="crmz36ye4xiqojo.azurecr.io/todo-java-mongo- aca/api-azd-demo-todo-java-aca-dev:azd-deploy-1691653114" SERVICE_API_RESOURCE_EXISTS="true" SERVICE_WEB_IMAGE_NAME="crmz36ye4xiqojo.azurecr.io/todo-java-mongo- aca/web-azd-demo-todo-java-aca-dev:azd-deploy-1691653230" SERVICE_WEB_RESOURCE_EXISTS="true" • azdの各コマンドが.envレコードを作成、参照する • 重要: `azd provision`の結果（出力）が保存される（後述） • .envファイルは.gitignoreでgitの対象から除外されている • azd利用者は後述の`azd env refresh`で.envを再現できる • .envにシークレットなど秘匿情報を置かないようにしましょう • テンプレートの多くが、秘匿情報はKey Vaultを使うようにしています

環境をリストする azd env list [flags] --docs -h, --help Azure Developer CLI リファレンス | Microsoft Learn

azd env list 実行例 $ azd env list NAME DEFAULT azd-demo-todo-java-aca-dev false azd-demo-todo-java-aca-prod true

環境を切り替える azd env select [flags] --docs -h, --help Azure Developer CLI リファレンス | Microsoft Learn

環境設定を更新する azd env refresh [flags] --docs -e, --environment string -h, --help --hint string • Azureのリソース（デプロイ結果）を取得し、.envに反映する • インフラをazdで管理しないプロジェクト、インフラを管理しない開発者にとって特に重要 • たとえばアプリのテストやデバッグだけのために.envを作りたい、というケース Azure Developer CLI リファレンス | Microsoft Learn

環境設定の取得先 (1/2) stateOptions := provisioning.NewStateOptions(ef.flags.hint) getStateResult, err := ef.provisionManager.State(ctx, stateOptions) if err != nil { return nil, fmt.Errorf("getting deployment: %w", err) } if err := provisioning.UpdateEnvironment(ef.env, getStateResult.State.Outputs); err != nil { return nil, err } • IaCプロバイダーから状態を取得し、.envを更新する https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/cmd/env.go#L423

環境設定の取得先 (2/2) deployments, err := p.findCompletedDeployments(ctx, p.env.GetEnvName(), scope, options.Hint()) [snip] state := State{} state.Resources = make([]Resource, len(deployment.Properties.OutputResources)) • Bicepの場合、完了したデプロイメント情報を取得し、outputResourcesを状態として扱う • よって.envに入れたい情報は、Bicepのoutputで定義しておく https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/pkg/infra/provisioning/bicep /bicep_provider.go#L209

アプリで.envを読みたい "configurations": [ { "name": "Debug API", "type": "java", [snip] "envFile": "${input:dotEnvFilePath}" }, "inputs": [ { "id": "dotEnvFilePath", "type": "command", "command": "azure-dev.commands.getDotEnvFilePath" } ] • テスト/デバッグでアプリから.envを読みたいときがある • VS Code azd拡張のgetDotEnvFilePathコマンドで、その時点のdefault環境の.envパスを取得 • これはlaunch.jsonでの定義例

azd provision

Azure リソースをプロビジョニングする azd provision [flags] --docs -e, --environment string -h, --help --preview • --previewオプションを使うと、ドライランできる • BicepであればWhat-If Azure Developer CLI リファレンス | Microsoft Learn

プロビジョニングに使われるコード ├── .azdo [ For Azure DevOps ] │ └── azure-dev.yaml [ Azure Pipelines workflow to deploy to Azure using azd ] ├── .azure [ For storing Azure configurations] │ └── [ For storing all environment-related configurations] │ ├── .env [ Contains environment variables ] │ └── config.json [ Contains environment configuration ] ├── .devcontainer [ For DevContainer ] │ ├── devcontainer.json [ For setting up the containerized development environment ] │ └── Dockerfile [ For building the container image ] ├── .github [ For GitHub workflow ] │ └── azure-dev.yaml [ GitHub Actions workflow to deploy to Azure using azd ] ├── infra [ For creating and configuring Azure resources ] │ ├── abbreviations.json [ Recommended abbreviations for Azure resources ] │ ├── main.bicep [ Main infrastructure file ] │ └── main.parameters.json [ Parameters file ] └── azure.yaml [ Describes the app and type of Azure resources]

注: main.parameters.json { "$schema": "https://schema.management.azure.com/schemas/2019-04- 01/deploymentParameters.json#", "contentVersion": "1.0.0.0", "parameters": { "apiAppExists": { "value": "${SERVICE_API_RESOURCE_EXISTS=false}" }, "webAppExists": { "value": "${SERVICE_WEB_RESOURCE_EXISTS=false}" }, [snip] } } • `azd provision`を使わず、Bicepで直接プロビジョニングしたい場合は注意が必要 • `azd provision`は環境設定を元にmain.parameters.jsonの ${変数} を置き換えている • Bicepで直接プロビジョニングしたいときは、別途 ${変数} の部分をセットすること 環境変数を管理する | Microsoft Learn

パラメータ置き換えの実装 "github.com/drone/envsubst“ [snip] replaced, err := envsubst.Eval(string(parametersBytes), func(name string) string { if name == environment.PrincipalIdEnvVarName { return principalId } return p.env.Getenv(name) }) • drone/envsubstを使ってパラメータを環境設定で置き換えている • drone/envsubstを使うと ${var=default} のような多様な表現が可能 • 例: "${SERVICE_WEB_RESOURCE_EXISTS=false}" https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/pkg/infra/provisioning/bicep/bicep_provider.g o#L40

main.bicepのポイント var abbrs = loadJsonContent('./abbreviations.json') var resourceToken = toLower(uniqueString(subscription().id, environmentName, location)) var tags = { 'azd-env-name': environmentName } var apiContainerAppNameOrDefault = '${abbrs.appContainerApps}web-${resourceToken}' var corsAcaUrl = 'https://${apiContainerAppNameOrDefault}.${containerApps.outputs.defaultDomain}' • 複数環境でリソース名が衝突させないのは、azdではなくBibepの仕事 • ユニークになるような resourceTokenを作ってリソース名に追加している • 自らインフラのコードを書くときは意識する プロジェクトをAzure Developer CLIと互換性のあるものにする | Microsoft Learn

azd package

アプリケーションのコードをパッケージングする azd package [flags] --all --docs -e, --environment string -h, --help Azure Developer CLI リファレンス | Microsoft Learn • 例: Javaでは、ビルド(`mvn compile`)とパッケージング(`mvn package`)が実行される

複数フレームワーク対応 frameworkService, err := sm.GetFrameworkService(ctx, serviceConfig) [snip] buildResult, err := runCommand( ctx, task, ServiceEventBuild, serviceConfig, func() *async.TaskWithProgress[*ServiceBuildResult, ServiceProgress] { return frameworkService.Build(ctx, serviceConfig, restoreOutput) }, ) • Mavenや.NETなど、複数のビルド/パッケージングフレームワークに対応する • FrameworkServiceインターフェイスを満たす構造体のBuildやPackageメソッドを呼ぶ https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/pkg/project/service_manager.go#L226

インターフェイスを満たすフレームワーク

複数実行環境対応 serviceTarget, err := sm.GetServiceTarget(ctx, serviceConfig) [snip] err = serviceConfig.Invoke(ctx, ServiceEventPackage, eventArgs, func() error { [snip] serviceTargetPackageTask := serviceTarget.Package(ctx, serviceConfig, frameworkPackageResult) [snip] • App ServiceやContainer Appsなど、複数の実行環境（サービスターゲット）に対応する • ServiceTargetインターフェイスを満たす構造体のPackageメソッドを呼ぶ https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/pkg/project/service_manager.go#L280

インターフェイスを満たす実行環境

azd deploy

アプリケーションをAzureにデプロイする azd deploy [flags] --all --docs -e, --environment string --from-package string -h, --help Azure Developer CLI リファレンス | Microsoft Learn

ターゲット分岐のしくみは`azd package`と同様

azd up

プロビジョニングとデプロイをまとめて行う azd up [flags] --docs -e, --environment string -h, --help Azure Developer CLI リファレンス | Microsoft Learn

azd upでやっていること packageOptions := &middleware.Options{CommandPath: "package"} _, err = u.runner.RunChildAction(ctx, packageOptions, packageAction) [snip] provision.flags = &u.flags.provisionFlags provisionOptions := &middleware.Options{CommandPath: "provision"} provisionResult, err := u.runner.RunChildAction(ctx, provisionOptions, provision) [snip] deployOptions := &middleware.Options{CommandPath: "deploy"} _, err = u.runner.RunChildAction(ctx, deployOptions, deploy) • package、provision、deployサブコマンドを呼び出している https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/cmd/up.go#L125

azd pipeline

デプロイ パイプラインを構成する azd pipeline config [flags] --auth-type string --docs -e, --environment string -h, --help --principal-id string --principal-name string --principal-role stringArray --provider string --remote-name string Azure Developer CLI リファレンス | Microsoft Learn • GitHub Actions/Azure DevOpsを構成する • 認証認可設定や変数登録ができる

認証認可設定 clientId, credentials, err := pm.adService.CreateOrUpdateServicePrincipal( ctx, pm.env.GetSubscriptionId(), appIdOrName, pm.args.PipelineRoleNames) [snip] err = pm.ciProvider.configureConnection( ctx, gitRepoInfo, prj.Infra, credentials, PipelineAuthType(pm.args.PipelineAuthTypeName)) • サービスプリンシパルを作り • パイプラインに対する認証認可設定を行う https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/pkg/pipeline/pipeline_manager.go#L219

GitHub Actions認証認可 switch authType { case AuthTypeClientCredentials: authErr = p.configureClientCredentialsAuth(ctx, infraOptions, repoSlug, credentials) default: authErr = p.configureFederatedAuth(ctx, infraOptions, repoSlug, branches, credentials) } https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/pkg/pipeline/github_provider.go#L418 • 既定ではフェデレーション資格情報(OIDC)を使うように構成される

GitHub Actions変数登録 for name, value := range map[string]string{ environment.EnvNameEnvVarName: p.env.GetEnvName(), environment.LocationEnvVarName: p.env.GetLocation(), environment.SubscriptionIdEnvVarName: p.env.GetSubscriptionId(), } { if err := p.ghCli.SetVariable(ctx, repoSlug, name, value); err != nil { return fmt.Errorf("failed setting %s variable: %w", name, err) } p.console.MessageUxItem(ctx, &ux.CreatedRepoValue{ Name: name, Kind: ux.GitHubVariable, }) } https://github.com/Azure/azure- dev/blob/99ea7577f0df0df2ba34b677da189fafba18c0f7/cli/azd/pkg/pipeline/github_provider.go#L453 • 環境名、ロケーション、サブスクリプションIDがGitHub Actionsの変数に登録される • そのほか、認証認可構成やIaCプロバイダーなどに応じて追加の変数が登録される

ロードマップ 現状の考慮点 展望と期待、考慮点

ロードマップ/マイルストーン Milestones - Azure/azure-dev (github.com) Feature Roadmap · Azure Developer CLI Roadmap 🗺️ (github.com)

GitHub上の議論は参考になる  左の例は、環境ごとにIaCを分 割できるようにしよう、という アイデアと議論（現状は全環境 が同じコードを使う作り）  このような議論を理解すること で、azdのみならず、環境の整 備、活用に関するアイデアや方 法、懸念点などを学べる https://github.com/Azure/azure-dev/issues/2373

現状の考慮点  全環境が同じIaC（のコード）を使う  「開発環境はリソースを少なく」「開発中のIaCコードは別ディレクトリで」などができない  前述のとおり議論、開発中  ワークアラウンドはブランチの活用（アンチパターンという意見もあり）  環境間の差異が大きい場合はazdでインフラを管理せず、BYOI(Bring Your Own Infra.)も検討  `azd enf refresh`でインフラの情報を取得する  全コマンドを使うには広く強い権限が必要  チーム全員がフルスタックエンジニアであることは稀  インフラを管理する人と、そうでない人を分けて考えたほうがよい  環境によって操作したいリソースも異なる  環境ごとに適切なRBAC設定を行い、操作可能なリソースを限定する

Questions?

Thank you