.NET Aspire を使用して Azure Container Apps する Azure Developer CLI プロジェクトをデプロイする (詳細ガイド)

[アーティクル]
12/13/2024

Azure Developer CLI (azd) は、.NET.NET Aspire プロジェクトのデプロイをサポートするように拡張されました。このガイドを使って、.NET Aspireを用いて Azure Container Apps に Azure Developer CLI プロジェクトを作成および展開する手順を進めましょう。このチュートリアルでは、次の概念について説明します。

azd .NET プロジェクト .NET Aspire 統合がどのように機能するかを調べる
Azure を使用して、.NET Aspire プロジェクトの azd にリソースをプロビジョニングしてデプロイする
azd を使用して Bicep インフラストラクチャとその他のテンプレートファイルを生成する

前提条件

.NET .NET Aspireを使用するには、次のものがローカルにインストールされている必要があります。

.NET 8.0 または .NET 9.0
OCI 準拠のコンテナーランタイム。次に例を示します。
- Docker デスクトップまたは Podman。詳細については、「コンテナーランタイム」を参照してください。
次のような統合開発者環境 (IDE) またはコードエディター。
- Visual Studio 2022 バージョン 17.9以上 (オプション)
- Visual Studio Code (省略可能)
  - C# Dev Kit: 拡張機能の (省略可能)
- JetBrains Rider と .NET.NET Aspire プラグイン (オプション)

詳細については、セットアップとツールの、および SDK を参照してください。

また、Azure Developer CLIをローカルにインストール必要があります。一般的なインストールオプションは次のとおりです。

Windows の
macOS
Linux

winget install microsoft.azd

brew tap azure/azd && brew install azd

curl -fsSL https://aka.ms/install-azd.sh | bash

どのように Azure Developer CLI 統合が機能するか

azd init ワークフローは、.NET.NET Aspire プロジェクトに対してカスタマイズされたサポートを提供します。次の図は、このフローの概念的な動作と、azd と .NET.NET Aspire の統合方法を示しています。

プロジェクトを配置するときの 'azd' の内部処理 .NET.NET Aspire 図。

azd .NET .NET Aspire プロジェクトをターゲットにすると、特別なコマンド (dotnet run --project AppHost.csproj --output-path manifest.json --publisher manifest) を使用して AppHost が起動され、Aspireマニフェストファイルが生成されます。
マニフェストファイルは、メモリ内でのみ Bicep ファイルを生成する azd provision サブコマンドロジックによって尋問されます (既定)。
Bicep ファイルを生成すると、前に指定したサブスクリプションとリソースグループをターゲットとする Azureの ARM API を使用してデプロイがトリガーされます。
基になる Azure リソースが構成されると、同じ azd deploy マニフェストファイルを使用する Aspire サブコマンドロジックが実行されます。
デプロイ azd の一環として、コンテナーイメージを生成するために、dotnet publish組み込みのコンテナー発行サポートを使用して .NET を呼び出します。
azdがコンテナーイメージをビルドすると、それらはプロビジョニングフェーズ中に作成されたACRレジストリにプッシュされます。
最後に、コンテナーイメージが ACR に入ると、azd は ARM を使用してリソースを更新し、コンテナーイメージの新しいバージョンの使用を開始します。

手記

azd では、生成された Bicep をプロジェクト内の infra フォルダーに出力することもできます。詳細については、「アプリモデルから Bicep を生成する .NET.NET Aspire」セクションを参照してください。

.NET .NET Aspire スターターアプリをプロビジョニングしてデプロイする

このセクションの手順では、.NET Aspire スタートアプリを作成し、Azureを使用してアプリリソースを azd にプロビジョニングおよびデプロイする方法を示します。

.NET .NET Aspire スターターアプリを作成する

.NET コマンドを使用して、新しい .NET Aspiredotnet new プロジェクトを作成します。 Visual Studioを使用してプロジェクトを作成することもできます。

dotnet new aspire-starter --use-redis-cache -o AspireSample
cd AspireSample
dotnet run --project AspireSample.AppHost\AspireSample.AppHost.csproj

前のコマンドでは、キャッシュへの依存関係を含む .NET テンプレートに基づいて新しい .NET Aspireaspire-starter プロジェクト Redis 作成します。 .NET .NET Aspire プロジェクトが実行され、すべてが正常に動作していることを確認します。

テンプレートを初期化する

新しいターミナルウィンドウを開き、cd ソリューションの .NET プロジェクトディレクトリに .NET Aspire します。
azd init コマンドを実行して、azdを使用してプロジェクトを初期化します。このコマンドにより、ローカルディレクトリ構造が検査され、アプリの種類が決定されます。
```
azd init
```
コマンドの詳細については、azd init参照してください。

azd を選択してください。

? How do you want to initialize your app?  [Use arrows to move, type to filter]
> Use code in the current directory
  Select a template

ディレクトリをスキャンした後、azd は、正しい .NET.NET AspireAppHost プロジェクトが見つかったことを確認するよう促します。アプリの初期化を続行するには、の[確認]オプションを選択してください。

Detected services:

  .NET (Aspire)
  Detected in: D:\source\repos\AspireSample\AspireSample.AppHost\AspireSample.AppHost.csproj

azd will generate the files necessary to host your app on Azure using Azure Container Apps.

? Select an option  [Use arrows to move, type to filter]
> Confirm and continue initializing my app
  Cancel and exit

環境名を入力します。これは、Azure でプロビジョニングされたリソースに名前を付け、dev や prodなどのさまざまな環境を管理するために使用します。

Generating files to run your app on Azure:

  (✓) Done: Generating ./azure.yaml
  (✓) Done: Generating ./next-steps.md

SUCCESS: Your app is ready for the cloud!
You can provision and deploy your app to Azure by running the azd up command in this directory. For more information on configuring your app, see ./next-steps.md

azd は、多数のファイルを生成し、作業ディレクトリに配置します。これらのファイルは次のとおりです。

azure.yaml: AppHost プロジェクトなどのアプリのサービス .NET Aspire について説明し、それらを Azure リソースにマップします。
./configをazureします。json: 現在のアクティブな環境をazdに知らせる構成ファイル。
.azure/aspireazddev/.env: 環境固有のオーバーライドが含まれています。

azure.yaml ファイルの内容は次のとおりです。

# yaml-language-server: $schema=https://raw.githubusercontent.com/Azure/azure-dev/main/schemas/v1.0/azure.yaml.json

name: AspireSample
services:
  app:
    language: dotnet
    project: .\AspireSample.AppHost\AspireSample.AppHost.csproj
    host: containerapp

リソースの名前付け

新しい Azure リソースを作成するときは、名前付けの要件に従う必要があります。 Azure Container Appsの場合、名前の長さは 2 ~ 32 文字で、小文字、数字、ハイフンで構成されている必要があります。名前は文字で始まり、英数字で終わる必要があります。

詳細については、リソースの名前付け規則と制限参照してください。

初期デプロイ

.NET Aspire プロジェクトをデプロイするには、Azure リソース管理 API を呼び出すために、Azure AD に対して認証を行います。
```
azd auth login
```
前のコマンドは、ブラウザーを起動してコマンドラインセッションを認証します。
認証が完了したら、AppHost プロジェクトディレクトリから次のコマンドを実行して、アプリケーションをプロビジョニングしてデプロイします。
```
azd up
```
重要

コンテナーイメージを Azure Container Registry (ACR) にプッシュするには、Microsoft.Authorization/roleAssignments/write アクセス権が必要です。これを実現するには、レジストリで 管理者ユーザー を有効にします。 Azure ポータルを開き、ACR リソース/設定/アクセスキーに移動し、管理者ユーザー チェックボックスをオンにします。詳細については、「管理者ユーザーを有効にする」を参照してください。

メッセージが表示されたら、リソースのデプロイ先となるサブスクリプションと場所を選択します。これらのオプションを選択すると、.NET.NET Aspire プロジェクトが配置されます。

By default, a service can only be reached from inside the Azure Container Apps environment it is running in. Selecting a service here will also allow it to be reached from the Internet.
? Select which services to expose to the Internet webfrontend
? Select an Azure Subscription to use:  1. <YOUR SUBSCRIPTION>
? Select an Azure location to use: 1. <YOUR LOCATION>

Packaging services (azd package)


Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time.

Subscription: <YOUR SUBSCRIPTION>
Location: <YOUR LOCATION>

  You can view detailed progress in the Azure Portal:
  <LINK TO DEPLOYMENT>

  (✓) Done: Resource group: <YOUR RESOURCE GROUP>
  (✓) Done: Container Registry: <ID>
  (✓) Done: Log Analytics workspace: <ID>
  (✓) Done: Container Apps Environment: <ID>

SUCCESS: Your application was provisioned in Azure in 1 minute 13 seconds.
You can view the resources created under the resource group <YOUR RESOURCE GROUP> in Azure Portal:
<LINK TO RESOURCE GROUP OVERVIEW>

Deploying services (azd deploy)

  (✓) Done: Deploying service apiservice
  - Endpoint: <YOUR UNIQUE apiservice APP>.azurecontainerapps.io/

  (✓) Done: Deploying service webfrontend
  - Endpoint: <YOUR UNIQUE webfrontend APP>.azurecontainerapps.io/

Aspire Dashboard: <LINK TO DEPLOYED .NET ASPIRE DASHBOARD>

SUCCESS: Your up workflow to provision and deploy to Azure completed in 3 minutes 50 seconds.

azd コマンドからの出力の最後の行は、デプロイされたすべての Azure リソースを表示する Azure ポータルへのリンクです。

このアプリケーション内には、次の 3 つのコンテナーがデプロイされます。

webfrontend: スターターテンプレート内の Web プロジェクトのコードが含まれています。
apiservice: スターターテンプレートの API サービスプロジェクトのコードが含まれています。
cache: フロントエンドにキャッシュを提供する Redis コンテナーイメージ。

ローカル開発と同様に、接続文字列の構成は自動的に処理されます。この場合、azd はアプリケーションモデルを解釈し、適切なデプロイ手順に変換する役割を担いました。たとえば、webfrontend キャッシュと Redisに接続する方法を認識できるように、apiservice コンテナーに挿入される接続文字列とサービス検出変数について考えてみます。

.NET .NET Aspire プロジェクトが接続文字列とサービスの検出をどのように処理するかについてさらに詳しく知りたい方は、オーケストレーションの概要 .NET.NET Aspireを参照してください。

アプリケーションの更新プログラムをデプロイする

コマンドが実行されると、基になるリソースがプロビジョニングされ、コンテナーイメージがビルドされ、プロジェクトをホストするコンテナーアプリにデプロイ。通常、開発が進行中で、Azure リソースがデプロイされると、コードが更新されるたびに Azure リソースをプロビジョニングする必要はありません。これは、開発者の内部ループに特に当てはまります。

コード変更のデプロイを高速化するために、azd では、コンテナーイメージでのコード更新プログラムのデプロイがサポートされています。これは、azd deploy コマンドを使用して行います。

azd deploy

Deploying services (azd deploy)

  (✓) Done: Deploying service apiservice
  - Endpoint: <YOUR UNIQUE apiservice APP>.azurecontainerapps.io/

  (✓) Done: Deploying service webfrontend
  - Endpoint: <YOUR UNIQUE webfrontend APP>.azurecontainerapps.io/

Aspire Dashboard: <LINK TO DEPLOYED .NET ASPIRE DASHBOARD>

毎回すべてのサービスをデプロイする必要はありません。 azd .NET プロジェクトモデルを理解 .NET Aspire、次のコマンドを使用して指定したサービスのいずれかをデプロイできます。

azd deploy webfrontend

詳細については、「Azure Developer CLI リファレンス: azd deploy」を参照してください。

インフラストラクチャの更新プログラムをデプロイする

.NET .NET Aspire プロジェクト内の依存関係構造が変更されるたびに、azd は基になる Azure リソースを再プロビジョニングする必要があります。 azd provision コマンドは、これらの変更をインフラストラクチャに適用するために使用されます。

この動作を確認するには、AppHost プロジェクトの Program.cs ファイルを次のように更新します。

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");

// Add the locations database.
var locationsdb = builder.AddPostgres("db").AddDatabase("locations");

// Add the locations database reference to the API service.
var apiservice = builder.AddProject<Projects.AspireSample_ApiService>("apiservice")
    .WithReference(locationsdb);

builder.AddProject<Projects.AspireSample_Web>("webfrontend")
    .WithReference(cache)
    .WithReference(apiservice);

builder.Build().Run();

ファイルを保存し、次のコマンドを発行します。

azd provision

azd provision コマンドは、Postgres データベースをホストするコンテナーアプリを作成してインフラストラクチャを更新します。 azd provision コマンドは、apiservice コンテナーの接続文字列を更新しませんでした。新しくプロビジョニングされた Postgres データベースを指すように接続文字列を更新するには、azd deploy コマンドを再度呼び出す必要があります。不明な場合は、azd up を使用してプロビジョニングとデプロイの両方を行います。

リソースのクリーンアップ

このチュートリアルで作成した Azure リソースは必ずクリーンアップしてください。 'azd はリソースを作成したリソースグループを認識しているため、次のコマンドを使用して環境をスピンダウンするために使用できます。

azd down

前のコマンドの実行には時間がかかる場合がありますが、完了したらリソースグループとそのすべてのリソースを削除する必要があります。

Deleting all resources and deployed code on Azure (azd down)
Local application code is not deleted when running 'azd down'.

  Resource group(s) to be deleted:

    • <YOUR RESOURCE GROUP>: <LINK TO RESOURCE GROUP OVERVIEW>

? Total resources to delete: 7, are you sure you want to continue? Yes
Deleting your resources can take some time.

  (✓) Done: Deleting resource group: <YOUR RESOURCE GROUP>

SUCCESS: Your application was removed from Azure in 9 minutes 59 seconds.

プロジェクトモデルから Bicep の .NET.NET Aspire を生成する。

開発チームは、開発と運用の両方の目的で azd up (または azd provision と azd deploy) コマンドを展開に自由に使用できますが、一部のチームは、バージョン管理の一部としてレビューおよび管理できる Bicep ファイルを生成することを選択できます (これにより、これらの Bicep ファイルをより複雑な Azure 展開の一部として参照することもできます)。

azd には、プロビジョニングに使用する Bicep を次のコマンドにより出力する機能が含まれています。

azd config set alpha.infraSynth on
azd infra synth

このガイドで使用されているスターターテンプレートの例でこのコマンドを実行すると、AppHost プロジェクトディレクトリに次のファイルが作成されます。

infra/main.bicep: デプロイのメインエントリポイントを表します。
infra/main.parameters は です。json：メイン Bicep のパラメーターとして使用されます（.azure フォルダーで定義されている環境変数にマッピングされます）。
infra/resources.bicep: Azure プロジェクトモデルをサポートするために必要な .NET Aspire リソースを定義します。
AspireSample.Web/manifests/containerApp.tmpl.yaml: webfrontendのコンテナーアプリ定義。
AspireSample.ApiService/manifests/containerApp.tmpl.yaml: apiserviceのコンテナーアプリ定義。

infra\resources.bicep ファイルには、コンテナーアプリ自体の定義は含まれません (Redis や Postgresなどの依存関係であるコンテナーアプリは除きます)。

@description('The location used for all deployed resources')
param location string = resourceGroup().location

@description('Tags that will be applied to all resources')
param tags object = {}

var resourceToken = uniqueString(resourceGroup().id)

resource managedIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
  name: 'mi-${resourceToken}'
  location: location
  tags: tags
}

resource containerRegistry 'Microsoft.ContainerRegistry/registries@2023-07-01' = {
  name: replace('acr-${resourceToken}', '-', '')
  location: location
  sku: {
    name: 'Basic'
  }
  tags: tags
}

resource caeMiRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(containerRegistry.id, managedIdentity.id, subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '7f951dda-4ed3-4680-a7ca-43fe172d538d'))
  scope: containerRegistry
  properties: {
    principalId: managedIdentity.properties.principalId
    principalType: 'ServicePrincipal'
    roleDefinitionId:  subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '7f951dda-4ed3-4680-a7ca-43fe172d538d')
  }
}

resource logAnalyticsWorkspace 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
  name: 'law-${resourceToken}'
  location: location
  properties: {
    sku: {
      name: 'PerGB2018'
    }
  }
  tags: tags
}

resource containerAppEnvironment 'Microsoft.App/managedEnvironments@2023-05-01' = {
  name: 'cae-${resourceToken}'
  location: location
  properties: {
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: logAnalyticsWorkspace.properties.customerId
        sharedKey: logAnalyticsWorkspace.listKeys().primarySharedKey
      }
    }
  }
  tags: tags
}

resource cache 'Microsoft.App/containerApps@2023-05-02-preview' = {
  name: 'cache'
  location: location
  properties: {
    environmentId: containerAppEnvironment.id
    configuration: {
      service: {
        type: 'redis'
      }
    }
    template: {
      containers: [
        {
          image: 'redis'
          name: 'redis'
        }
      ]
    }
  }
  tags: union(tags, {'aspire-resource-name': 'cache'})
}

resource locations 'Microsoft.App/containerApps@2023-05-02-preview' = {
  name: 'locations'
  location: location
  properties: {
    environmentId: containerAppEnvironment.id
    configuration: {
      service: {
        type: 'postgres'
      }
    }
    template: {
      containers: [
        {
          image: 'postgres'
          name: 'postgres'
        }
      ]
    }
  }
  tags: union(tags, {'aspire-resource-name': 'locations'})
}
output MANAGED_IDENTITY_CLIENT_ID string = managedIdentity.properties.clientId
output AZURE_CONTAINER_REGISTRY_ENDPOINT string = containerRegistry.properties.loginServer
output AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID string = managedIdentity.id
output AZURE_CONTAINER_APPS_ENVIRONMENT_ID string = containerAppEnvironment.id
output AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN string = containerAppEnvironment.properties.defaultDomain

Bicep を使用してデプロイを自動化して Azure する方法の詳細については、「Bicep とはする」を参照してください。

.NET サービスプロジェクトからのコンテナーアプリの定義は、各プロジェクトのディレクトリ内の manifests ファイル内にそれぞれ含まれています。 webfrontend プロジェクトの例を次に示します。

location: {{ .Env.AZURE_LOCATION }}
identity:
  type: UserAssigned
  userAssignedIdentities:
    ? "{{ .Env.AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID }}"
    : {}
properties:
  environmentId: {{ .Env.AZURE_CONTAINER_APPS_ENVIRONMENT_ID }}
  configuration:
    activeRevisionsMode: single
    ingress:
      external: true
      targetPort: 8080
      transport: http
      allowInsecure: false
    registries:
    - server: {{ .Env.AZURE_CONTAINER_REGISTRY_ENDPOINT }}
      identity: {{ .Env.AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID }}
  template:
    containers:
    - image: {{ .Env.SERVICE_WEBFRONTEND_IMAGE_NAME }}
      name: webfrontend
      env:
      - name: AZURE_CLIENT_ID
        value: {{ .Env.MANAGED_IDENTITY_CLIENT_ID }}
      - name: ConnectionStrings__cache
        value: {{ connectionString "cache" }}
      - name: OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES
        value: "true"
      - name: OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES
        value: "true"
      - name: services__apiservice__0
        value: http://apiservice.internal.{{ .Env.AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN }}
      - name: services__apiservice__1
        value: https://apiservice.internal.{{ .Env.AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN }}
tags:
  azd-service-name: webfrontend
  aspire-resource-name: webfrontend

azd infra synth コマンドを実行した後、azd provision および azd deploy が呼び出されると、Bicep を使用し、生成されたファイルをサポートします。

重要

azd infra synth が再度呼び出されると、変更されたファイルが新しく生成されたファイルに置き換えられ、その前に確認を求められます。

デバッグ用の分離された環境

azd では新しい環境を簡単にプロビジョニングできるため、各チームメンバーは、運用環境と密接に一致する設定でコードをデバッグするための分離されたクラウドホスト環境を持つことができます。これを行う場合、各チームメンバーは次のコマンドを使用して独自の環境を作成する必要があります。

azd env new

これにより、ユーザーはサブスクリプションとリソースグループの情報を再度入力するように求められます。その後の azd up、azd provision、azd deploy の呼び出しでは、既定でこの新しい環境が使用されます。 --environment スイッチをこれらのコマンドに適用して、環境を切り替えることができます。

リソースのクリーンアップ

作成した Azure リソースが不要になったら、次の Azure CLI コマンドを実行してリソースグループを削除します。リソースグループを削除すると、その中に含まれるリソースも削除されます。

az group delete --name <your-resource-group-name>

詳細については、「リソースのクリーンアップ」についてAzureを参照してください。

次の方法で共有

.NET Aspire を使用して Azure Container Apps する Azure Developer CLI プロジェクトをデプロイする (詳細ガイド)

前提条件

どのように Azure Developer CLI 統合が機能するか

.NET .NET Aspire スターターアプリをプロビジョニングしてデプロイする

.NET .NET Aspire スターターアプリを作成する

テンプレートを初期化する

リソースの名前付け

初期デプロイ

アプリケーションの更新プログラムをデプロイする

インフラストラクチャの更新プログラムをデプロイする

リソースのクリーンアップ

プロジェクトモデルから Bicep の .NET.NET Aspire を生成する。

デバッグ用の分離された環境

リソースのクリーンアップ

その他のリソース

次の方法で共有

.NET Aspire を使用して Azure Container Apps する Azure Developer CLI プロジェクトをデプロイする (詳細ガイド)

前提 条件

どのように Azure Developer CLI 統合が機能するか

.NET .NET Aspire スターター アプリをプロビジョニングしてデプロイする

.NET .NET Aspire スターター アプリを作成する

テンプレートを初期化する

リソースの名前付け

初期デプロイ

アプリケーションの更新プログラムをデプロイする

インフラストラクチャの更新プログラムをデプロイする

リソースのクリーンアップ

プロジェクトモデルから Bicep の .NET.NET Aspire を生成する。

デバッグ用の分離された環境

リソースのクリーンアップ

その他のリソース

前提条件

.NET .NET Aspire スターターアプリをプロビジョニングしてデプロイする

.NET .NET Aspire スターターアプリを作成する