Aspire 9.5入門 - この重要なツールですぐに始められる

Tim Corey

43 分 49 秒

Webアプリケーションに携わる最新 for .NET開発者は、Aspire 9.5の使い方を知っている必要があります。彼の詳細なビデオ"Intro to Aspire 9.5 - Get Started Quickly with This Essential Tool"では、Tim Coreyがこの新しい.NET Aspireシステムを紹介し、それが何であるか、なぜ価値があるのか、どのように素早く始められるかを説明しています。

ビデオを通して、ティムはVisual Studioと最新のプロジェクト・テンプレートを使用して、ステップ・バイ・ステップでソリューションの例を構築します。 この記事では、プロジェクトファイル、セットアッププロセス、およびAspireが本番環境の分散アプリケーションの構築にもたらす開発者の経験についての完全なガイドを提供し、彼のウォークスルーに忠実に従います。

Aspire9.5の使い始めとインストール

ティムはまず、Aspire の目的を説明します。APIやWebアプリケーションを構築するすべて for .NET開発者は、この必要不可欠なMicrosoftツールを理解する必要があります。 Aspireで何ができるのか混乱しているため、Timはその目的、セットアップ、使い方を一から説明します。

彼はVisual Studioを開き、Aspireスターターアプリテンプレートを使用して新しいプロジェクトを開始します。 Aspireがインストールされていない場合は、マイクロソフトのWebサイトでAspireのセットアップとツールを紹介し、.NET CLI、Visual Studio、またはVS Codeからインストールできることを指摘している。 簡単のために、TimはCLIコマンドを使用することを推奨します：

dotnet新規インストール aspire.テンプレート

dotnet新規インストール aspire.テンプレート

Aspire 9.5 を含む最新のプロジェクトテンプレートがインストールされます。インストール後、テンプレートを表示するために Visual Studio の再起動が必要になる場合があります。

Tim は Aspire Demo App を選択し、.NET 9 を選択し、HTTPS を有効にし、キャッシュに Redis 統合を使用しています。 これは、Aspireがアプリ全体をローカルで管理する実際のシナリオを示しています。 ユニットテストは省略し、ソリューションファイルの作成に進む。

プロジェクト構造とアプリモデルを探る

プロジェクトが生成されると、ティムはAspireのアプリモデルによって作成されたプロジェクトファイルを分解します。 このソリューションには、典型的な .NET プロジェクトと Aspire 固有のプロジェクトの両方を反映した 4 つの主要プロジェクトが含まれています：

1.Webプロジェクト - BlazorベースのWebアプリケーション。

2.APIサービス - データまたはビジネスロジックのバックエンドサービス。

3.AppHost - アプリ全体を起動する単一のファイルAppHost。

4.ServiceDefaults - ヘルスチェック、サービスディスカバリ、テレメトリセットアップを含むライブラリ。

最初の2つは通常の分散システム（フロントエンドとバックエンド）を表し、他の2つは環境変数、依存関係、リソースライフサイクルイベントAPIを管理するためのAspireの統合ツールチェーンを表しています。

Timは、この新しいアプリモデルが、マルチプロジェクトオーケストレーションのファーストクラスのサポートを提供し、開発者が1つのコマンドでアプリ全体を実行できるようにすることを強調します。 AppHostは起動順序と依存関係を制御し、ServiceDefaultsは設定デフォルト、ヘルスチェック、遠隔測定統合を自動的に注入します。

Aspireがローカル開発を簡素化する理由

Tim 氏は、Aspire を使用せずに分散システムをローカルで管理する際の問題点を説明します。従来、開発者はコンテナランタイムのセットアップ、ポート転送、各サービスの接続文字列を手動で設定しなければなりません。 各開発者は、環境変数、ユーザーシークレット、redisまたはAPI接続を個別に複製する必要があります。

Aspire では、Aspire CLI がこれを自動的に処理します。 開発コンテナやDockerインスタンスを通じてRedisコンテナなどの依存関係を起動し、エンドポイントディスカバリを管理し、サービスディスカバリを使用してサービス間のプライベートアクセスを提供します。

Aspireはリバースプロキシとエンドポイント解決システムを使用しているため、Webフロントエンドはハードコードされたポート番号を知る必要がありません。 単純にAPIを名前（"apiservice "のような）で参照し、Aspireが残りを解決します。

これにより、面倒なセットアップ手順がなくなり、開発者はインフラストラクチャではなくコードに集中できるようになるため、開発者のエクスペリエンスが劇的に向上します。

AppHostでサービスと依存関係を定義する

Timは、Aspireの構成の中心であるAppHostのProgram.csファイルを示しています。var builderパターンを使用して、Aspireは次のような簡単なコマンドで各サービスを定義します：

var cache = builder.AddRedis("cache");
var api = builder.AddProject<Projects.ApiService>("apiservice");
var web = builder.AddProject<Projects.Web>("webfrontend")
    .WithReference(cache)
    .WithReference(api);

var cache = builder.AddRedis("cache");
var api = builder.AddProject<Projects.ApiService>("apiservice");
var web = builder.AddProject<Projects.Web>("webfrontend")
    .WithReference(cache)
    .WithReference(api);

Dim cache = builder.AddRedis("cache")
Dim api = builder.AddProject(Of Projects.ApiService)("apiservice")
Dim web = builder.AddProject(Of Projects.Web)("webfrontend") _
    .WithReference(cache) _
    .WithReference(api)

Dim cache = builder.AddRedis("cache")
Dim api = builder.AddProject(Of Projects.ApiService)("apiservice")
Dim web = builder.AddProject(Of Projects.Web)("webfrontend") _
    .WithReference(cache) _
    .WithReference(api)

この構文では、各リソースを定義し、依存関係の順序を設定し、明確なリソースのライフサイクルを作成します。 Aspireは、依存関係の待ち時間を自動的に処理し、キャッシュが最初に起動し、次にAPI、そしてWebフロントエンドが起動するようにします。

この小さな命令セットにより、開発者はスタートアップの動作を細かく制御できるようになり、実稼働可能な分散アプリケーションでどのように実行されるかが反映されます。

Aspireの実行とダッシュボードの理解

Tim がプロジェクトを実行すると、Aspire は独自のコンテナランタイムを起動し、Aspire Dashboard を開きます。 最初はエラーが表示されます："Container runtime unhealthy"-Dockerが実行されていません。 Dockerが起動すると、Aspireは自動的にRedisの実行可能リソースを初期化し、アプリの残りの部分に接続します。

ダッシュボードには、各リソースの健全性を示す色分けされたステータスアイコンが表示されます。 Redis、API、Webフロントエンドがすべて稼働すると、ダッシュボードが緑色に変わり、アプリ全体が健全であることを示します。

この通知システムは、リアルタイムの状態を即座に反映し、標準的なコンソールログよりも明確なエラーメッセージを提供します。 開発者は、サービスの関係を視覚化し、メトリクスを監視し、UIから直接リソースエンドポイントにアクセスすることもできます。

Aspireダッシュボードを通しての視覚的な洞察

ダッシュボードのグラフビューは、サービスがどのように接続されているかを視覚化します。 例えば、WebフロントエンドはRedisとAPIサービスの両方に接続しますが、APIは独立しています。 このトレースビューは、呼び出しと依存関係の内部フローを理解するのに役立ちます。

Tim は、ダッシュボードにトレースフィルタリングオプションやタイミングブレイクダウンの表示など、トレース詳細の改善が含まれていることを強調しています。 開発者は、Aspire のトレースビューを使用して、サービス全体の HTTP リクエストをトレースし、パフォーマンスへの影響を確認できます。

集中型ロギングと構造化ログ

Aspireは、すべてのプロジェクトファイルのコンソールログを1つのビューに統合します。 開発者は、複数のログウィンドウを操作する代わりに、ダッシュボードを使用して、ウェブアプリ、API、Redis統合など、すべてのサービスのログを1つのタイムラインで表示できます。

Timは、Aspireが構造化されたロギングを使用し、ID、パラメータ、タグなどのコンテキストが豊富なエントリを可能にすることを示しています。 開発者は、レベル（情報、警告、エラー）またはプロパティ値によってログをフィルタリングできます。

例えば、開発者は、"evenOddResult" == "odd "であるエントリのみを表示することができます。 この高度なログフィルタリングとAspireの色分けされた接頭辞を組み合わせることで、デバッグを直感的かつ視覚的に行うことができます。

トレースとテレメトリを扱う

Traces タブで、Tim は、Aspire がアプリのサービス全体のリクエストを追跡する方法を示します。 各トレースには、タイミング、ステータス、どのサービスが何を処理したかを示すスパンが含まれています。

例えば、"GetWeather "リクエストは、いつキャッシュがヒットしたか、逃したか、いつAPIコールが発生したか、それぞれのアクションにかかった時間を表示します。 このトレースフィルタリングにより、ボトルネックや依存関係を正確に特定することができます。

Aspire はトレースデータを他のツールやシステムにエクスポートするための OpenTelemetry もサポートしており、開発者は分散サービス全体にわたって完全な観測性を得ることができます。

リアルタイム メトリクスとパフォーマンス モニタリング

Timは、リクエスト時間、SignalRのアクティブな接続、アクティブなリクエスト数などのメトリクスについて説明します。 これらのメトリクスは、アプリのライブ状態を視覚化し、接続や遅延の問題を早期に検出します。

Aspire 9.5 のメトリクスデータは、トレース詳細の改善とより良いトレースフィルタリングにより、開発者がリアルタイムでパフォーマンスの低下が発生する場所をピンポイントで特定できるようになりました。

Aspireはローカル開発用であり、生産用ではありません

Timは、Aspireのダッシュボードは本番サーバーへのデプロイを想定していないことを明確に指摘しています。 また、この翻訳を展開すると、内部システムの詳細や環境変数が公開されることになり、リスクを伴う可能性があります。

ただし、開発者は、Aspire の aspire deploy コマンドを使用して、Azure Container Apps、Azure Container App Jobs、またはその他の Aspire 統合にサービスを公開できます。 これらのデプロイメントオプションは増え続けていますが、ダッシュボードとは切り離されたままです。

Aspire の目的は、安全なアップグレードとプレビューサポートにより、本番環境と同様の環境をローカルでミラーリングすることであり、本番監視システムを置き換えることではありません。

ロギングと例外処理を試す

Tim は、Counter ページに構造化ロギングを追加し、Weather ページに NotImplementedException を意図的に導入しています。 再実行の際、ダッシュボードは構造化されたログと未処理の例外の両方を即座にキャプチャします。

彼は、Aspireのログがパラメータ名、値、コールスタックを含む完全な詳細を表示する方法を示しています。 GitHub ModelsとCopilot AIとの統合により、例外の自動説明や修正のためのコード提案が可能になり、初期のAIサービスとジェネレーティブAIビジュアライザーの開発者体験への統合の一例となりました。

トレースフィルタリングでエラーを分析する

Tracesタブで、Timは、失敗したAPIコールがどのように赤い感嘆符のアイコンで表示されるかを示しています。 1つをクリックすると、スパンIDでフィルタリングされたすべての関連ログが表示され、複数 for .NETプロジェクトにわたる各リクエストがリンクされます。

この統一されたビュー（ログ、トレース、ヘルスチェックを組み合わせたもの）は、デバッグのためのインタラクティブなプロンプトを提供し、外部設定なしで観測可能なシステムを構築します。

既存 for .NETプロジェクトにAspireを統合する

次にティムは、Aspireを既存のアプリに統合する方法を説明します。開発者が追加するものは2つだけです：

• AppHostプロジェクトは、どのサービスが開始し、それらの依存関係を制御します。

• ServiceDefaultsプロジェクトは、機能フラグ、ヘルスチェック、遠隔測定、サービスディスカバリーを提供します。

各プロジェクトファイルでServiceDefaultsを参照することで、開発者はデフォルトの環境変数、ロギング設定、遠隔測定を自動的に取得できます。 Aspireのエンドポイント解決システムは、手動によるポート転送や接続文字列管理の必要性を排除します。

地域限定での利用を超えてAspireを拡大

Timは、Aspireの機能がローカルでの使用を超えてどのように拡大しているかを説明します。 Azure Container Apps と Azure AI Foundry の統合により、開発者は Aspire CLI を使用して最小限の構成で分散システムをデプロイできます。

システムはすでに、カスタムリソースアイコン、名前プロパティ、OpenAIエンドポイントやAzure PostgreSQL接続のようなAIサービスのプレビューサポートをサポートしています。

Aspireの統一ツールチェーンは、バージョン管理とメジャーバージョンとマイナーバージョン間の安全なアップグレードもサポートしており、チームが自信を持ってAspire 9.5のようなアップデートを採用できるよう支援します。

最終的な感想と今後の展望

video の最後に、Tim は Aspire を "開発者にとっての金鉱" と呼んでいます。ダッシュボードは、トレースビュー、ヘルスチェック、ログ、メトリクスを1つの統一されたパネルに統合しています。

ティムと彼のチームのために、すべての新しい.NET Aspireプロジェクトは現在、デフォルトでこのシステムを使用しています。 これにより、カスタムビルドが高速化され、開発者のエクスペリエンスが向上し、本番環境の分散アプリがマシン間で一貫して動作するようになります。

彼は、Aspire の主要なリリースは、安全なアップグレードと一般的な可用性に重点を置きながら、トレースフィルタリング、エンドポイントソリューション、および ai の統合を改良し続ける予定であると述べています。

Timは、Aspire 9.5を探求し、次 for .NETプロジェクトで使用し、1つのコマンドでログを表示し、開発トンネルを管理し、アプリ全体をローカルで安心してテストできるシンプルさを活用することを勧めます。