Aspire 9.3 の新機能

📢 Aspire 9.3 は、 Aspireの次のマイナー バージョン リリースです。 以下がサポートされています。

• .NET 8.0 長期サポート (LTS)
• .NET 9.0 Standard Term Support (STS)

フィードバックや質問がある場合、または Aspireに投稿したい場合は、 GitHub で共同作業を行うか、 Discord に参加してチーム メンバーとチャットしてください。

留意すべき点として、Aspire リリースは .NET リリースとは別に発行されることがあります。 メジャー バージョンの Aspire はメジャー .NET バージョンと一致しますが、マイナー バージョンはより頻繁にリリースされます。 詳細は、.NETおよびAspireバージョンサポートについて参照してください。

• .NET サポート ポリシー: LTS と STS の定義。
• Aspire サポート ポリシー: 重要な固有の製品ライフサイクルの詳細。

🖥️ アプリ モデルの機能強化

✨ ゼロ摩擦コンテナーの構成

多くのコンテナー統合では、内部プロパティを掘り下げずに、ポート、ユーザー名、パスワードを設定するための ファースト クラス ヘルパー が公開されるようになりました。 3 つの設定はすべて パラメーターを使用して安全に指定でき、シークレットはソースから除外されます。

var pgPwd = builder.AddParameter("pg-pwd", secret: true);

builder.AddPostgres("pg")
       .WithHostPort(6045)          // choose the host-side port
       .WithPassword(pgPwd)         // reference a secret parameter

新しい WithHostPort、 WithPassword、および WithUserName (または同等のサービスごとの) 拡張メソッドは、 PostgreSQL、 SQL Server、 Redis、およびその他のいくつかのコンテナー リソースで使用でき、スタック全体で一貫した宣言型制御を実現します。

🔗 簡潔なカスタム URL

9.3 では、リソース リンクがもっとスマートになり、配置がもっと簡単になります。

• リンクが表示される場所を選択 します。各リンクには UrlDisplayLocation (SummaryAndDetails または DetailsOnly) が含まれるようになったため、メイン グリッドから診断リンクを保持したまま、詳細ウィンドウに表示されます。
• 相対パスは自動解決されます 。ヘルパー "/health" を渡 Aspire 、エンドポイントが割り当てられると、完全なホスト修飾 URL に書き換えられます。
• エンドポイントごとに複数のリンク – WithUrlForEndpoint のオーバーロードにより、再定義することなく、追加の URL (ドキュメント、管理者 UI、プローブ) を同じエンドポイントにアタッチできます。
• コールバック内のエンドポイント ヘルパー – context.GetEndpoint("https") は、プログラムでカスタム リンクを構築できるように、完全に解決されたエンドポイントをフェッチします。
• 任意のリソースのカスタム URL – WithUrl* カスタム リソースでも機能します。

var frontend = builder.AddProject<Projects.Frontend>("frontend")

    // Hide the plain-HTTP link from the Resources grid
    .WithUrlForEndpoint("http",
        url => url.DisplayLocation = UrlDisplayLocation.DetailsOnly)

    // Add an extra link under the HTTPS endpoint that points to /health
    .WithUrlForEndpoint("https", ep => new()
    {
        Url            = "/health",                  // relative path supported
        DisplayText    = "Health",
        DisplayLocation = UrlDisplayLocation.DetailsOnly
    });

これらの調整により、適切な場所に適切なリンクを表示することで、ローカル開発スタックをさらにカスタマイズできます。

🙈 状態を "偽装" せずにリソースを非表示にする

これまで、ダッシュボードからリソースを保持する唯一の方法は、リソースを Hiddenstate に配置することでした。これは、リソースが WaitForResourceAsync などの API に対して "ターミナル" に見えるハックでもあります。 9.3 では、すべてのスナップショットにブールIsHidden フラグが設定され、ライフサイクルの状態から可視性が完全に切り離されるようになりました。

• クリーナーの既定値 – AddParameter や AddConnectionString のような低レベルのヘルパーは、UI を乱雑にしないように非表示に設定します。

  var apiKey = builder.AddParameter("api-key", secret: true);   // IsHidden = true ✔
  

• 正確な待機と正常性フロー – WaitForResourceAsync は、プログラムでIsHiddenを別の述語として扱うように更新されました。これにより、非表示のリソースを特別な状態にすることなく待機したり表示したりできます。

この小さな変更により、モデルのあいまいさが解消され、ダッシュボードに表示される内容を正確に制御できます。

🔔 新しいライフサイクル イベント

Aspire 9.3 では、 Task.Run やポーリングなどのハッキングに頼ることなく、予測可能な動作でカスタム リソースを簡単に構築できる 2 つの新しいライフサイクル イベントが導入されています。

InitializeResourceEvent

このイベント は、リソースが追加された後、 エンドポイントが割り当てられる前に発生します。 これは、組み込みのライフサイクル (コンテナーや実行可能ファイルなど) がないカスタム リソースに特に便利です。バックグラウンド ロジックを開始したり、既定の状態を設定したり、動作を結び付けたりするためのクリーンな場所を提供します。

たとえば、この最小限のカスタム リソースでは、初期化時に実行中の状態が発行されます。

var myCustom = new MyCustomResource("my-resource");

builder.AddResource(myCustom);
builder.Eventing.Subscribe<InitializeResourceEvent>(myCustom, async (e, ct) =>
{
    await e.Notifications.PublishUpdateAsync(e.Resource,
        s => s with { State = KnownResourceStates.Running });
});

これにより、コンストラクターやTask.Runメソッド内のConfigure()などの厄介なパターンが置き換えられます。 公式のサンプル リポジトリの Aspireでは、より複雑なバージョンを確認できます。

ResourceEndpointsAllocatedEvent

このイベントは、リソースのエンドポイントが割り当てられた後 (ポート解決やコンテナーの割り当て後など) に発生します。 リソースごとにスコープが設定されているため、 EndpointReference を安全に取得し、派生 URL または診断を構築できます。

builder.Eventing.Subscribe<ResourceEndpointsAllocatedEvent>((e, ct) =>
{
    if (e.Resource is IResourceWithEndpoints resource)
    {
        var http = resource.GetEndpoint("http");

        Console.WriteLine($"Endpoint http - Allocated {http.IsAllocated}, Port: {http.Port}");
    }

    return Task.CompletedTask;
});

これらのイベントにより、リソースの作成がスムーズで安全になり、より決定的になります。ライフサイクルの推測作業は必要ありません。

🌐 YARP 統合 (プレビュー)

Aspire9.3 では、YARP (Yet Another Reverse Proxy) のプレビュー サポートが導入されています。これは、Aspire アプリケーション モデルにリバース プロキシを導入する、長い間要求された追加です。

この統合により、公式 の YARP コンテナー イメージを利用して、分散型アプリに軽量のプロキシ コンテナーを簡単に追加できます。 現在、指定した ファイルを使用したJSONサポートされています。

Aspire アプリにリバース プロキシを追加します。

builder.AddYarp("apigateway")
       .WithConfigFile("yarp.json")
       .WithReference(basketService)
       .WithReference(catalogService);

構成ファイルはコンテナーにマウントされ、ランタイム YARP 構成として使用されます。

yarp.jsonの例:

{
  "ReverseProxy": {
    "Routes": {
      "catalog": {
        "ClusterId": "catalog",
        "Match": {
          "Path": "/catalog/{**catch-all}"
        }
      },
      "basket": {
        "ClusterId": "basket",
        "Match": {
          "Path": "/basket/{**catch-all}"
        }
      }
    },
    "Clusters": {
      "catalog": {
        "Destinations": {
          "catalog/d1": {
            "Address": "http://catalog/"
          }
        }
      },
      "basket": {
        "Destinations": {
          "basket/d1": {
            "Address": "http://basket/"
          }
        }
      }
    }
  }
}

.WithReference(...)呼び出しでは、プロキシ コンテナーが、catalogの内部ネットワーク グラフを使用して、参照されるサービスを名前 (basket、Aspire) で自動的に解決できることを確認します。

⚠️ このプレビューでの既知の制限事項

• 構成ベースのルーティングのみがサポートされています。 コード ベースまたはプログラムによるルート生成はまだ使用できません。
• 構成ファイルは 発行操作の一部として展開されません。ファイルは手動で管理する必要があります。
• Podman制限により、では機能しません。

🐬 MySQL AddDatabase データベースを作成する

Aspire 9.3 では、MySQL統合で、 API を使用したAddDatabaseがサポートされるようになりました。これは、SQL ServerとPostgreSQLで既に使用可能な動作と一致します。

以前は、.AddDatabase("dbname") リソースでMySQLを呼び出すと、Aspireのアプリ モデルに論理参照のみが作成されました。サーバー上にデータベースが作成されませんでした。 この不一致により混乱が生じたのは、特にユーザーが他の統合技術と同様にAspireがデータベースを設定することを期待していた場合です。

✅ 9.3 の新しい動作:

var mysql = builder.AddMySql("db");

mysql.AddDatabase("appdb");

実行時に、現在実行中のAspireコンテナまたはサーバーに対してCREATE DATABASEコマンドを"appdb"するために、MySQLが実行されるようになりました。 データベースが既に存在する場合、コマンドは安全にスキップされます。

これにより、MySQLがより広範なAspireデータベース エコシステムに沿ったものになります。

追加の構成は必要ありません。既に使用しているのと同じ AddDatabase 呼び出しによって、バックグラウンドでデータベースがプロビジョニングされるようになりました。

📊 ダッシュボードの楽しみ

✨ ダッシュボードに Copilot が GitHub にある

GitHub Copilot を Aspire ダッシュボードに導入します。 GitHub Copilot は、新しい AI デバッグ アシスタントです。

GitHub Copilot は、ダッシュボードの OpenTelemetry デバッグと診断のエクスペリエンスを高めます。 AI を使用すると、次のことができます。

• 1 回のクリックで何百ものログ メッセージを確認する
• 複数のアプリにわたるエラーの根本原因を調査する
• トレースのパフォーマンスの問題を強調表示する
• AI の巨大なナレッジ リポジトリを使用してあいまいなエラー コードを説明する

VS Code または Visual Studio からアプリを起動すると、ダッシュボードで Copilot にアクセスできます。

要件と開始方法の詳細については、GitHub ダッシュボードの「Copilot のAspire」を参照してください。

🧠 フィルター設定を記憶する

Aspire ダッシュボードには、セッション間のリソース フィルター設定が記憶されるようになりました。 以前は、[リソース] ビューをフィルター処理した場合 (たとえば、サポート サービスを非表示にしたり、フロントエンド アプリのみを強調表示したりするには)、ページの再読み込み時にこれらのフィルターがリセットされていました。

9.3 の時点では、フィルターの状態は ローカル ストレージに保持されるため、選択内容は更新と再起動の間も保持されます。 この小さな改善により、アプリの最も重要な部分 (特に、 Redis、SQL、キューなど、多くのサポート サービスを含む大規模なグラフ) に集中しやすくなります。

非計装のリソースがトレースに表示されるようになりました。

9.3 では、ダッシュボードで、データベース、キャッシュ、組み込みのトレースがないその他のインフラストラクチャ コンポーネントなど、 独自のテレメトリを出力しないリソースへの発信呼び出しを視覚化できるようになりました。

以前は、OTLP トレースを出力しない限り、これらの依存関係は [ トレース ] ビューでは表示されませんでした。 これで、アプリが、スパン自体を出力しないRedisに対して HTTP、SQL、またはAspire呼び出しを行った場合でも、トレース タイムラインにとして表示Aspire。

これは、次の場合に役立ちます。

• 一部のコンポーネントがパッシブであっても、依存関係の完全なチェーンを理解する
• 計測されていないサービスへの呼び出しにおける待機時間や障害をデバッグする
• インフラストラクチャの種類間でトレース UI の一貫性を維持する

🧪 インストルメンテーションの変更は必要ありません。Aspire は、リソース参照に基づいてマッピングを推論します。

🖱️ リソースのコンテキスト メニューとクイック起動アクション

Aspire 9.3 では、新しい コンテキスト メニュー を導入し、ビュー全体で リソース URL を 表示する方法を強化することで、ダッシュボードの対話型性と移動が容易になります。

🧭 グラフ内のコンテキスト メニューを右クリックする

これで、Resource Graph ビュー内の任意のリソース ノードを右クリックして、クイック アクションを含むコンテキスト メニューを表示できるようになりました。

• そのリソースの構造化されたログ、コンソール ログ、トレース、またはメトリックを開く
• リソースに関連付けられている外部 URL (PGAdmin、Swagger、Grafana など) を起動する
• リソースの詳細ウィンドウに直接移動する

これにより、クリック数が減り、特定のサービスを調査しながらグラフに残ります。

🔗 コンソール ログ アクションのリソース URL

WithUrlForEndpoint(...)を使用して定義されたリソース URL が、ダッシュボード UI により目立つように統合されるようになりました。 次のように表示されます。

• コンソールログビューのアクションバーで
• 新しい 右クリック メニュー
• 前と同様に、 リソースの詳細ウィンドウで

これにより、管理者 UI、正常性チェック、ドキュメントなどの一般的な宛先に、作業している場所であればどこでもすぐにアクセスできます。

これらの機能強化により、 Aspire ダッシュボードは、分散アプリ内を移動するための真のコントロール プレーンに変わり、摩擦が少なくなり、フォーカスが増えます。

⏸️ メトリクス一時停止警告

メトリックの収集が一時停止されると、ダッシュボードに 警告バナー が表示されるようになりました。 これにより、テレメトリを一時的に停止した場合、データが古くなる可能性が明らかになります。

📝 コンソール ログの親しみやすい名前

リソースにレプリカが 1 つしかない場合、Aspire ダッシュボードでは、コンソール ログ ビューのレプリカ ID (frontend など) ではなく、apigateway (redis、frontend-0、など) が使用されるようになりました。

この小さな変更により、ログの読み取りが容易になり、特に開発中の一般的な単一インスタンスのセットアップで視覚的なノイズが軽減されます。

🚀 デプロイおよび発行

🏗️ プレビュー段階のパブリッシャー モデルとコンピューティング環境のサポートの機能強化

9.2 では、AppHost 内の任意のクラウドへのデプロイを柔軟に構成する方法である"パブリッシャー" の最初のイテレーションを出荷しました。 柔軟性を高めるために、 Aspire 9.3 には、単一のトップレベルパブリッシャーに依存するのではなく、アプリケーション グラフ全体に発行動作を分散する 新しい改良された パブリッシャー モデルが含まれています。

Dockerなどを呼び出してターゲット環境 (AzureやAddDockerComposePublisher()など) を選択するのではなく、Aspireには、各リソースでを検索するPublishingCallbackAnnotationが含まれるようになりました。 この注釈は、リソースを発行する方法 (たとえば、 Docker Compose サービス、 Kubernetes マニフェスト、Bicep モジュール Azure ) について説明します。

ほとんどのアプリに必要な環境は 1 つだけです

一般的なアプリでは、次のような 単一のコンピューティング環境を追加するだけで済みます。

builder.AddAzureContainerAppEnvironment("env");

この場合、 Aspire はアプリ モデル内のすべてのコンピューティング リソースに適切な発行動作を適用します。追加の構成は必要ありません。

複数の環境であいまいさを解消する必要があります

複数のコンピューティング環境を追加する場合Aspireは、どのリソースがどこに行くかを把握する必要があります。 コンピューティング環境は、 該当するすべてのコンピューティング リソース (プロジェクト、コンテナー、実行可能ファイル) に変換を適用します。 複数の環境が特定のリソースと一致する場合、 Aspire は発行時に あいまいな環境例外 をスローします。

これを解決するには、次の WithComputeEnvironment(...)を使用します。

var k8s = builder.AddKubernetesEnvironment("k8s-env");
var compose = builder.AddDockerComposeEnvironment("docker-env");

builder.AddProject<Projects.Api>("api")
       .WithComputeEnvironment(compose);

builder.AddProject<Projects.Frontend>("frontend")
       .WithComputeEnvironment(k8s);

この例では、サービスをさまざまなコンピューティング ターゲット (たとえば、 Kubernetes のフロントエンドや Docker Compose のバックエンド) に明示的にマップする方法を示します。

⚠️ 以前のパブリッシャー登録 API ( AddDockerComposePublisher() など) はすべて、この新しいモデルを優先して削除されました。

サポートされているコンピューティング環境

Aspire 9.3 には、次の環境リソースのプレビュー サポートがあります。

• AddDockerComposeEnvironment(...)
• AddKubernetesEnvironment(...)
• AddAzureContainerAppEnvironment(...)
• AddAzureAppServiceEnvironment(...) — 新しい App Service サポート →を参照してください

これらは、アプリ モデルからインフラストラクチャ固有の成果物を変換および出力できるデプロイ ターゲットを表します。

🐳 Docker 作成機能の改善

Aspire 9.3 では、厳密に型指定された C# ベースの構成を使用して、 Docker Compose 出力をカスタマイズするための強力な新機能が導入されています。 グローバル Compose ファイルと個々のサービスの両方を、Aspire アプリ モデルから直接宣言によって構成できるようになりました。これにより、デプロイ出力の推論、カスタマイズ、自動化が簡単になります。

🛠Compose ファイルとサービス定義をカスタマイズする

次の 2 つの新しい API を使用して、最上位の Compose ファイルと個々のサービスの動作をプログラムで構成できるようになりました。

• ConfigureComposeFile(...) — docker-compose.yml メタデータをカスタマイズする
• PublishAsDockerComposeService(...) — 任意のコンピューティング リソース (コンテナーやプロジェクトなど) の生成されたサービスを変更します。

builder.AddDockerComposeEnvironment("env")
       .WithProperties(env =>
       {
           env.BuildContainerImages = false; // skip image build step
       })
       .ConfigureComposeFile(file =>
       {
           file.Name = "aspire-ai-chat"; // sets the file name
       });

// Add a container to the app
builder.AddContainer("service", "nginx")
       .WithEnvironment("ORIGINAL_ENV", "value")
       .PublishAsDockerComposeService((resource, service) =>
       {
           service.Labels["custom-label"] = "test-value";
           service.AddEnvironmentalVariable("CUSTOM_ENV", "custom-value");
           service.Restart = "always";
       });

これらの API を使用すると、生成された出力を厳密に型指定した構造化された方法で変更できます。これにより、YAML を手動で編集することなく、より豊富な CI オートメーション、カスタム ツール、環境固有の調整が可能になります。

🔗 パラメーターと式を Docker Compose にマップする

Aspire では、環境変数プレースホルダーを使用して 、アプリ モデルの値 (パラメーターや参照など) を Docker Compose 定義にバインドできるようになりました。

これにより、動的構成 (CI パイプラインやシークレット ストアなど) を最終的な出力に直接フローすることが容易になります。

builder.AddDockerComposeEnvironment("docker-compose");

var containerNameParam = builder.AddParameter("param-1", "default-name", publishValueAsDefault: true);

builder.AddContainer("service", "nginx")
       .WithEnvironment("ORIGINAL_ENV", "value")
       .PublishAsDockerComposeService((resource, service) =>
       {
           service.ContainerName = containerNameParam.AsEnvironmentPlaceholder(resource);
       });

ここでの重要な API は.AsEnvironmentPlaceholder(...)であり、Aspireなどの Compose 変数を出力し、それに応じて${PARAM_1} ファイルが更新されるようにマッピングを登録するように.envに指示します。

これらの機能強化により、 Docker Compose は 完全にプログラミング可能な発行ターゲットになり、ローカル開発、コンテナーベースの CI ワークフロー、および脆弱な YAML オーバーレイを使用せずに構造化された制御を必要とするチームに最適です。

☸️ マニフェストのカスタマイズKubernetes

Aspire 9.3 では、発行プロセスの一環として 、生成された Kubernetes マニフェストをプログラムでカスタマイズ するためのサポートが追加されました。 これにより、生のマニフェスト オーバーレイやパッチを記述することなく、出力 Aspire YAML アーティファクトをきめ細かく制御できます。

Docker Compose と同様に、Aspireではグローバル環境レベルの設定とリソースごとのカスタマイズの両方がサポートされるようになりました。

🛠️ グローバルおよびリソースごとの設定を構成する

次の API を使用して、C# で Kubernetes 出力を構成できます。

• WithProperties(...) グローバル動作を設定するコンピューティング環境
• PublishAsKubernetesService(...) コンピューティング リソースで特定の Kubernetes リソースを変更する

builder.AddKubernetesEnvironment("env")
       .WithProperties(env =>
       {
           env.DefaultImagePullPolicy = "Always"; // e.g., Always, IfNotPresent
       });

builder.AddContainer("service", "nginx")
       .WithEnvironment("ORIGINAL_ENV", "value")
       .PublishAsKubernetesService(resource =>
       {
           // Add custom deployment-level settings
           resource.Deployment!.Spec.RevisionHistoryLimit = 5;
       });

これにより、 Kubernetes オブジェクト モデルへの完全に型指定されたアクセスが可能になり、次のような強力な変更が可能になります。

• コンテナ イメージのプルポリシーをオーバーライドする
• レプリカ数またはデプロイ戦略のカスタマイズ
• サービス、デプロイ、または ConfigMap へのラベルまたは注釈の挿入

🖥️ Aspire CLI の機能強化

🧪 Aspire CLI はまだ プレビュー段階であり 、開発中です。 今後のリリースでは、より多くの機能と洗練された機能を期待してください。

📦 インストールするには:

dotnet tool install --global aspire.cli --prerelease

🔍 よりスマートな AppHost 検出

CLI は現在のディレクトリから 上に向かって進み 、AppHost プロジェクトの 各レベルを再帰的に検索 します。 見つけたら、結果を .aspire フォルダーにキャッシュして、将来のコマンドを高速化します。

aspire runからaspire add、aspire publish、などのコマンドを実行できるようになりました。CLI によって AppHost が自動的に解決されます。

例えば次が挙げられます。

cd src/frontend
aspire run

⏳ 健康に配慮したダッシュボードの立ち上げ

CLI は、 ダッシュボードが応答するまで待機してから 、その URL をターミナルに出力するようになりました。 これにより、リンクが開いたときにすぐに機能します。空白のページや再試行ループはなくなります。

これらの更新により、 Aspire CLI はより信頼性が高く、スクリプトに優しく、開発者が毎日の開発中にフォルダーやプロジェクト間を移動する方法に合わせて調整されます。

☁️ Azure のお楽しみ

🌐 Azure App Service (プレビュー サポート)

Aspire9.3 では、既存の.NET環境でAzureを使用する開発者から最も要求された機能の 1 つである、Aspire プロジェクトを Azure App Service にデプロイするためのプレビュー サポートが導入されています。

この統合により、新しいLinux API を使用して、 AppHost で直接モデルAspireされた AddAzureAppServiceEnvironment(...) Web アプリとしてプロジェクトをデプロイできます。

🚧 現在の制限事項 (プレビュー)

この最初のリリースは、最も一般的なユース ケースを対象としています。

• .NET プロジェクトのみをサポート (AddProject(...)経由)
• 各プロジェクトは、1 つのパブリック HTTP エンドポイントを公開する必要があります
• プロジェクトはコンテナーとしてコンテナーとして発行され、コンテナー レジストリAzure
• AppHost 内のコンテナー はサポートされていません
• 既存の App Service プランはサポートされていません
• Aspire dashboard はまだ App Service でホストされていません

例: Azure App Service にデプロイする

builder.AddAzureAppServiceEnvironment("env");

builder.AddProject<Projects.Api>("api")
       .WithExternalHttpEndpoints()
       .PublishAsAzureAppServiceWebsite((infra, site) =>
       {
           site.SiteConfig.IsWebSocketsEnabled = true;
       });

この例では：

• Aspire App Service プランと Web アプリをプロビジョニングする
• プロジェクトはコンテナーとしてビルドされ、Azure Container Registry に発行されます
• コンテナーは、指定した構成で App Service にデプロイされます

🧠 PublishAsAzureAppServiceWebsite(...) を使用して、サイト構成、認証、SKU などの設定をカスタマイズします。

💬 この機能は プレビュー段階です。サポートが拡大するにつれて、フィードバックをお待ちしております。

📤 既存の Azure Container Registry (ACR) を使用する

Aspire9.3 では、新しい Azure API を使用して既存AddAzureContainerRegistry(...) をモデル化するためのサポートが追加されました。 これにより、新しい ACR をプロビジョニングすることなく、Aspireできます。

これは、次のチームに最適です。

• 環境間で一元化されたレジストリを共有する
• 既存の CI/CD パイプラインとプロモーション ワークフローとの統合
• イメージの公開をきめ細かく制御する必要があります

例: ACR を Azure Container Apps 環境に関連付ける

var acr = builder.AddAzureContainerRegistry("my-acr");

builder.AddAzureContainerAppEnvironment("env")
       .WithAzureContainerRegistry(acr);

builder.AddProject<Projects.Api>("api")
       .WithExternalHttpEndpoints();

この例では：

• ACR は Aspire でモデル化され、コンテナー アプリ環境で使用されます
• Aspire ビルドされたイメージを my-acr に発行し、そこからプルするように Azure Container Apps を構成します

ACR は複数のコンピューティング環境で動作します

AzureContainerRegistryResource を関連付けることができます。

• AddAzureContainerAppEnvironment(...)
• AddAzureAppServiceEnvironment(...)

これにより、異なるコンピューティング ターゲット間でも、イメージを公開する場所を一貫して制御できます。

💡 ACR リソースの .RunAsExisting() または .PublishAsExisting() を使用して、既存のレジストリをプロビジョニングせずに参照します。

🖇️ BLOB コンテナーのリソース ディープリンク

Aspire9.3 では、、Event Hubs、Service Bus、Cosmos DB に既に使用されているモデル上に構築された、Azure コンテナーを含むようにOpenAIが拡張されます。

AppHost で個々の BLOB コンテナーを直接モデル化し、スコープ付き BlobContainerClient インスタンスをサービスに挿入できるようになりました。これにより、接続文字列やアクセスを手動で構成しなくても、BLOB の読み取りまたは書き込みが簡単になります。

AppHost:

var builder = DistributedApplication.CreateBuilder(args);

// Add Azure Storage Emulator
var storage = builder.AddAzureStorage("storage").RunAsEmulator();

// Add a blob group and a container
var blobs = storage.AddBlobs("blobs");
var container = blobs.AddBlobContainer("images", blobContainerName: "image-uploads");

// Add the API project and reference the container
builder.AddProject<Projects.my94app_ApiService>("api")
       .WithExternalHttpEndpoints()
       .WithReference(container);

builder.Build().Run();

APIプロジェクトで:

using Azure.Storage.Blobs;

var builder = WebApplication.CreateBuilder(args);

// Register the blob container client
builder.AddAzureBlobContainerClient("images");

var app = builder.Build();

// Minimal POST endpoint for image upload
app.MapPost("/upload", async (
    IFormFile file,
    BlobContainerClient container) =>
{
    await container.CreateIfNotExistsAsync();

    var blob = container.GetBlobClient(file.FileName);
    using var stream = file.OpenReadStream();
    await blob.UploadAsync(stream, overwrite: true);

    return Results.Ok(new { Url = blob.Uri });
});

app.Run();

このパターンは、懸念事項、セキュリティで保護されたコンテナー スコープ、および最小限の儀式をクリーンに分離します。これは、特定の BLOB コンテナーと対話するマイクロサービスに最適です。

🔐 拡張された Azure Key Vault クライアント統合

Aspire9.3 では、Azure Key Vaultと証明書に対する新しいクライアント統合 API によるサポートが拡張され、型指定された Azure SDK クライアントをサービスに直接挿入できます。

• AddAzureKeyVaultKeyClient(...)
• AddAzureKeyVaultCertificateClient(...)
• AddKeyedAzureKeyVaultKeyClient(...)
• AddKeyedAzureKeyVaultCertificateClient(...)

これらの API は、既存のAddAzureKeyVaultClient(...)を補完し、KeyClient SDK for CertificateClientからAzureと.NETに簡単にアクセスできます。

var builder = WebApplication.CreateBuilder(args);

// Register default clients
builder.AddAzureKeyVaultKeyClient("kv");
builder.AddAzureKeyVaultCertificateClient("kv");

// Register named (keyed) clients
builder.AddKeyedAzureKeyVaultCertificateClient("kv", "signing-cert");

キー付きオーバーロードを使用すると、同じ Key Vault リソースをスコープとする複数のクライアントを登録できます。目的によって複数の証明書またはキーにアクセスする場合に便利です。

🙌 この機能は 、@james-gould によって提供されました。 ありがとうございます！

🔑 環境変数で Key Vault シークレットを使用する

Aspire9.3 では、を受け入れるWithEnvironment(...)の新しいオーバーロードを使用して、IAzureKeyVaultSecretReference接続するためのサポートが追加されました。

これにより、シークレット値をハードコーディングすることなく、モデル化された Key Vault からシークレットを安全に参照することが容易になり、それらの参照が Azure Bicep などのデプロイ出力に正しく送られます。

var kv = builder.AddAzureKeyVault("myKeyVault");

var secretRef = kv.Resource.GetSecret("mySecret");

builder.AddContainer("myContainer", "nginx")
       .WithEnvironment("MY_SECRET", secretRef);

🧩 既存の Key Vault からシークレットを参照する

リソースをAzure Key Vault、またはでマークすることで、既存のAsExisting(...)でこれを使用することもできます。 これにより、既にプロビジョニングされているボールトのシークレットを使用できます。これは、共有環境やチームが管理するインフラストラクチャに最適です。

var keyVaultNameParam = builder.AddParameter("key-vault-name");
var keyVaultResourceGroupParam = builder.AddParameter("key-vault-rg");

var existingVault = builder.AddAzureKeyVault("sharedVault")
                           .AsExisting(keyVaultNameParam, keyVaultResourceGroupParam);

var apiKey = existingVault.Resource.GetSecret("stripe-api-key");

builder.AddContainer("billing", "mycompany/billing")
       .WithEnvironment("STRIPE_API_KEY", apiKey);

このパターンにより、次の Aspireが保証されます。

• Key Vault の再プロビジョニングを行わない
• 発行モードで正しい既存のリソースへの参照を出力します
• 引き続き、環境変数を使用してシークレットの挿入とセキュリティで保護されたスコープを有効にします

📖「既存のAzure リソースを使用する」も参照してください。

🧠 Azure AI 推論クライアント統合 (プレビュー)

Aspire9.3 では、Azure ライブラリと抽象化を使用して、Azure.AI.InferenceMicrosoft.Extensions.AIが追加されます。

この統合により、SDK を直接使用する場合でも、抽象化に優しいインターフェイスを使用する場合でも、アプリケーションからの AzureOpenAI または Azure AI 推論サービスの呼び出しが簡略化されます。

ChatCompletionsClient SDK でAzureを使用する

builder.AddAzureChatCompletionsClient("connectionName");

app.MapPost("/chat-raw", (
    ChatCompletionsClient client,
    ChatRequest message) =>
{
    // Use the client
});

IChatClientを使用するMicrosoft.Extensions.AI

builder.AddAzureChatCompletionsClient("inference")
       .AddChatClient();

登録したら、標準の依存関係の挿入を使用して IChatClient を挿入できます。

app.MapPost("/chat", async (
    IChatClient chatClient,
    ChatRequest message) =>
{
    var result = await chatClient.GetResponseAsync(message.Input);
    return result;
});

このセットアップはセ マンティック カーネルなどのフレームワークとシームレスに統合され、モジュール型またはプラグ可能な AI システムで適切に機能します。

🔗 Microsoft.Extensions.AI と ChatCompletionsClient の詳細を確認します。

⚙️ Azure アプリ構成クライアントの統合

Aspire9.3 では、新しいクライアント統合 (Azure) を介して、📦Aspire のサポートが追加されます。Microsoft.Extensions.Configuration.AzureAppConfiguration NuGet パッケージ。

これにより、公式の Azure SDK と Microsoft.Extensions.Configuration.AzureAppConfiguration プロバイダーを使用して一元化された構成に簡単に接続できます。手動でセットアップする必要はありません。

builder.AddAzureAppConfiguration("appconfig");

登録が完了すると、AspireAzure App Configuration をアプリケーションの構成パイプラインに自動的に接続します。

例: Azure App Configuration をアプリ設定にバインドする

var builder = WebApplication.CreateBuilder(args);

builder.AddAzureAppConfiguration("appconfig");

var app = builder.Build();

app.MapGet("/feature", (IConfiguration config) =>
{
    var isEnabled = config.GetValue<bool>("FeatureFlag:Enabled");
    return Results.Ok(new { Enabled = isEnabled });
});

app.Run();

これにより、次のことが可能になります。

• 動的機能フラグの評価
• 環境全体の一元的な構成管理
• Aspire ホスティング モデルへの安全な統合

🔐 AzureのすべてのAspire統合と同様に、App Configuration クライアントは既定でマネージド ID を使用してセキュリティで保護されたアクセスを行います。接続文字列は必要ありません。

📦NuGet パッケージ: Aspire.Microsoft.Extensions.Configuration.AzureAppConfiguration🔗Azure App Configuration の詳細を確認する

🛡️ Azure SQL へのマルチアプリ アクセスをセキュリティで保護する (破壊的変更)

Aspire 9.2 では、AzureSQL Serverで同じAzure Container Appsを持つ複数のプロジェクトを使用すると、アプリの ID モデルが自動的に中断される可能性があります。

各アプリには独自の マネージド ID が割り当てられましたが、 Aspire 最後にデプロイされたアプリへの 管理者アクセス 権が付与され、以前にデプロイされたすべてのアプリのアクセスが上書きされます。 これにより、一度に 1 つのアプリしかデータベースと通信できないという混乱を招くエラーが発生しました。

✅ 9.3 の新しい動作

Aspire 9.3 は次の方法でこれを修正します。

1. として SQL Server割り当てる

2. 次の SQL スクリプトを出力します。

   • 追加のマネージド ID ごとに ユーザー を作成します
   • 各ユーザーにターゲット データベースの db_owner ロールを割り当てます

これにより、データベースを参照するすべてのアプリが、他のアプリと競合することなく フル アクセス できるようになります。

これが重要な理由

• 同じSQL Serverに安全にアクセスする複数のアプリをサポート
• アプリ ID 間 の最小特権の分離 を保持します
• 以前のリリースにあった不安定な「最後の 1 つが勝つ」方式の管理動作を避けます
• 次のようなクラウドネイティブ環境で、より充実したデプロイ シナリオを実現します。 Azure Container Apps

⚠️ 互換性を壊す変更

デプロイでマネージド ID を AspireSQL Server として設定に依存している場合は、アクセス モデルを確認する必要があります。 アプリは、広範な管理者権限ではなく 、明示的なロールベースのアクセス (db_owner) を受け取るようになりました。

📖 関連: dotnet/aspire#8381 と dotnet/aspire#8389

💸 既定 Azure SQL SKU で無料プランが使用されるようになりました (破壊的変更)

Aspire9.3 では、AzureSQL データベースを Free プランを使用して GP_S_Gen5_2 (General Purpose Serverless) レベルにプロビジョニングするときに使用される既定の SKU が変更されます。 これにより、開発と実験中の予期しないコストを削減できます。

以前は、Aspire Free プランを使用しないGeneral Purpose (GP) レベルに既定で設定されており、小規模アプリやテスト アプリでも料金が発生する可能性があります。

新着情報

次のように SQL データベースをプロビジョニングする場合:

var sql = builder.AddAzureSqlServer("sqlserver");

sql.AddDatabase("appdb");

Aspireオーバーライドしない限り、GP_S_Gen5_2 (General Purpose Serverless) を展開するのappdbが自動的に使用されるようになりました。

前の動作を復元する方法

アプリで General Purpose 有料レベルのパフォーマンスまたは機能が必要な場合は、次を使用して新しい既定値をオプトアウトできます。

sql.AddDatabase("appdb")
   .WithDefaultAzureSku(); // Uses the previous (General Purpose) default

使用する SKU を指定する場合は、「特定の SKU の設定」で説明されているように、 ConfigureInfrastructure 方法 を使用します。

⚠️ 互換性を壊す変更

この変更は、新しいデプロイのコスト、パフォーマンス、および使用可能な機能に影響します。 アプリが上位レベルの機能に依存している場合は、それに応じて SKU を構成してください。

🔧 .WithDefaultAzureSku()のを使用して古い動作に戻す

🚀 AZD: Aspire アプリの CI/CD の大幅な機能強化

CI/CD パイプラインのazd構成方法がAspire ベースのアプリケーション用に大幅に改善されました。 これらの更新プログラムは、コミュニティによって報告された最も不満な問題点の 1 つに直接対処します。環境間で安全かつ予測可能に環境パラメーターとシークレットを管理します。

Aspire アプリは、接続文字列、ランタイム バージョン、API キー、機能フラグなどのインフラストラクチャ定義の設定を使用して、ますますパラメーター駆動型になっています。 GitHub Actions などの CI パイプラインにこれらの値を安全かつ一貫して取得することは、これまで困難でした。 このリリースでは、これを修正します。

🧠 よりスマートなパラメーター処理 - もう AZD_INITIAL_ENVIRONMENT_CONFIG は必要ありません

以前は、インフラストラクチャ パラメーターを必要とするアプリ Aspire 、 AZD_INITIAL_ENVIRONMENT_CONFIGと呼ばれる非表示の環境変数に依存していました。 この変数は、すべてのローカル環境構成を含む大きな JSON BLOB でした。 CI パイプラインに手動で渡す必要があり、検査が困難であり、環境を共有または更新するときに摩擦が発生しました。

Now:azd は Aspire パラメーターをインフラストラクチャ定義から直接抽出し、それらをパイプライン内の名前付き環境変数またはシークレットとして 安全かつ明示的に公開します。

例えば次が挙げられます。

param openaiKey string
param dbPassword string

成る：

AZURE_OPENAI_KEY: ${{ secrets.AZURE_OPENAI_KEY }}
AZURE_DB_PASSWORD: ${{ secrets.AZURE_DB_PASSWORD }}

つまり、バンドルが不要になり、脆弱な構成ハックがなくなり、CI で環境がどのように構成されているかを推測する必要がなくなります。

🔤 一貫性のある予測可能なパラメーターの名前付け

Aspire パラメーターは、明確な規則を使用して環境変数の名前にマップされます。

1. camelCase を SNAKE_CASE に変換する
2. ダッシュ (-) をアンダースコア (_) に置き換える
3. すべて大文字
4. AZURE_で始めてください

この名前付けの一貫性は、Aspireなどのデプロイ ターゲットAzure Container Apps、ローカルまたはクラウドで、カスタム マッピングなしで構成を解決できることを意味します。

📦 Aspire CI に自動的にエクスポートされるパラメーター

Aspire アプリは、多くの場合、API キー、資格情報、ランタイム構成など、Bicep またはインフラストラクチャ モジュールで必要なパラメーターを定義します。 これらは、上記の名前付け規則を使用してパイプライン構成に自動的にエクスポートされるようになりました。

次の手順を実行する必要がなくなりました。

• これらを .azure/env-name/config.json で手動で構成する
• 複雑なJSONブロブを介してCIに挿入する
• ローカルとクラウドの間の構成の欠落または不一致について心配する

セキュリティで保護されたパラメーター ( openaiKey や dbPasswordなど) は自動的に CI シークレットとして扱われ、他のパラメーターは変数として挿入され、すべて azdによって処理されます。

🧼 GitHub アクションでの対話型シークレット管理

azd pipeline configを実行すると、azdによって、GitHub リポジトリにシークレットが既に存在するかどうか、またはシークレットが使用されなくなったかどうかが検出され、プロンプトが表示されるようになりました。

既存のシークレット プロンプト:

The secret AZURE_OPENAI_KEY already exists. What would you like to do?
  [1] Keep it
  [2] Keep ALL existing secrets
  [3] Overwrite it
  [4] Overwrite ALL secrets

未使用のシークレット プロンプト:

The secret AZURE_OLD_SECRET is no longer used. What would you like to do?
  [1] Keep it
  [2] Keep ALL unused secrets
  [3] Delete it
  [4] Delete ALL unused secrets

これにより、次の内容が保証されます。

• シークレットの上書きに驚くことはありません
• リポジトリを古い構成のクリーンな状態に保つことができます
• CI は実際のインフラストラクチャのセットアップを反映します

🔄 エンド ツー エンドの反復可能な Aspire 展開

これらの変更により、 Aspire アプリのローカルからクラウドへのワークフローが一貫して自動化されるようになりました。

1. インフラストラクチャ パラメーターは、 Aspire アプリの一部として定義します。
2. azd は、プロビジョニング中にそれらをキャプチャします。
3. azd pipeline config は、それらを GitHub Actions または devOps パイプライン Azure にマップします。
4. パイプラインは、ローカル環境と同じ入力をすべて使用して安全に実行されます。手動の手順は必要ありません。

もうAZD_INITIAL_ENVIRONMENT_CONFIGない。 脆弱なオーバーライドはもう心配ありません。 明確で安全な、パラメーター化されたデプロイ。

これらの変更により、 Aspire プロジェクトのよりスムーズで安全な CI/CD エクスペリエンスのロックが解除されます。手動構成の削減、セキュリティの向上、ローカル開発のセットアップと運用パイプラインの調整が可能になります。

💔 互換性を壊す変更

すべてのリリースで、 Aspire の向上に努めています。 ただし、いくつかの変更によって既存の機能が損なわれる可能性があります。 Aspire 9.3 では、次の破壊的変更が導入されています。

• バージョン Aspire 9.3 の破壊的変更