.NET Aspire のセットアップ方法を Linux で学ぶ

Aspire CLI のインストール

[0:48 - 2:20] Tim は aspire.dev で始め、プロジェクトが最近"Aspire.NET"から"Aspire"にブランド変更されたことに注意します。この名称変更はツールの範囲拡張を反映しています。Aspire は依然として .NET 上で構築されており、主に .NET 開発者に提供されていますが、TypeScript アプリホストもサポートしており、他の言語との統合がロードマップに載っています。

インストールそのものは、Aspire ドキュメントのバージョン 9.2 からコピーされた単一のバッシュコマンドです。

dotnet tool install -g aspirate

dotnet tool install -g aspirate

インストーラを実行した後、ターミナルセッションを再起動してツールが PATH に登録されるようにします。 再起動がないと、シェルは新しいコマンドを認識しません。

その後、インストールが正しく完了したことを確認します。

aspire --version

aspire --version

バージョン番号が印刷されれば、CLI は準備完了です。 その二段階のプロセス（インストール、確認）がターミナル側のセットアップの全体です。

VS Code 拡張機能の設定

[2:23 - 3:30] CLI がインストールされたら、次は VS Code 拡張機能です。 Extensions パネルを開き、"Aspire"を検索し、Microsoft によって公開された公式拡張機能をインストールします。 この拡張機能は、プロジェクトスキャフォールディング、起動構成サポート、Aspire ダッシュボードとの統合を追加します。

インストール後、VS Code は CLI と拡張機能が整合していることを確認するための検証ステップを実行します。 Tim はこの拡張機能がコマンドパレットを通じて新しいプロジェクトを直接スキャフォールディングできることも指摘していますが、彼は CLI アプローチを選択します。 その選択は意図的です：CLI を知っていれば、GUI ツールが不安定なときでも困りません。 VS Code テンプレートピッカーがインストール後に Aspire テンプレートを表示できなかったとき、CLI は即座のバイパスを提供しました。

スタータープロジェクトのスキャフォールディング

[3:30 - 6:42] Tim は VS Code の"新しい .NET プロジェクトを作成"コマンド（Aspire テンプレートを発見するのが断続的に失敗することがある）を使用せずに、ターミナルに入り込みます。

aspire new

aspire new

インタラクティブプロンプトにはいくつかのテンプレートの選択肢が表示されます。 本番アプリケーションの場合、通常は空の C# アプリホストを選んでそこからビルドします。 学習目的で、Tim は スターターアプリ を選択し、Blazor フロントエンドが最小限の API によってバックエンドされるものを生成します。 スターターテンプレートには天気予報のエンドポイント、カウンターページ、事前配線された ヘルスチェック が含まれており、すぐに操作可能なものを提供します。

後続のプロンプトは残りの構成を通じて案内します：

プロジェクト名:         TinyTicket
出力パス:          TinyTicket
dev localhost の使用:    Yes
Redis キャッシュ:          No
テストプロジェクト:         No
AI エージェント環境: No

Tim はすべてのオプション機能をオフにして複雑さを最小限に抑えます。 目的は、将来のエピソードで徐々にビルドされるスリムな開始点を提供することです。 スキャフォールディングが完了したら、フォルダーを VS Code で開き、プロンプトが表示されたときにワークスペースを信頼します。

プロジェクト構造の理解

[6:42 - 10:00] 生成されたソリューションには4つのプロジェクトが含まれており、それらの関係は Aspire がどのように動作するかを明らかにします。 アプリホスト プロジェクトはオーケストレーションレイヤーです。 そのProgram.csは、おおよそ12行のコードです。

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.TinyTicket_ApiService>("api")
    .WithHttpHealthCheck("/health");

builder.AddProject<Projects.TinyTicket_Web>("frontend")
    .WithExternalHttpEndpoints()
    .WithHttpHealthCheck("/health")
    .WithReference(api)
    .WaitFor(api);

builder.Build().Run();

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.TinyTicket_ApiService>("api")
    .WithHttpHealthCheck("/health");

builder.AddProject<Projects.TinyTicket_Web>("frontend")
    .WithExternalHttpEndpoints()
    .WithHttpHealthCheck("/health")
    .WithReference(api)
    .WaitFor(api);

builder.Build().Run();

フロントエンドが API への参照を宣言し、開始する前にそれが健全になるのを待機する様子に注目してください。 その依存関係の順序、サービスディスカバリー、ヘルスチェックはすべてコーディングレベルで Aspire が提供するものです。 このファイルに示されている以上の隠された魔法はありません。

アプリホストの隣には、サービスデフォルト プロジェクトがあり、テレメトリー、構造化ログ、ヘルスチェック登録のための拡張メソッドが含まれています。 これらはオプトインの便宜です：すでに OpenTelemetry やあなたのサービスのヘルスエンドポイントを設定していない場合、デフォルトがそれらを配線します。

API サービス プロジェクトにはランダムに生成された天気予報を返すシングルエンドポイントがあります。 Webプロジェクトは、サービス名（"api"）だけで構成されたHttpClientを通じてAPIを呼び出すBlazorアプリケーションです。 Aspire はその名前を実行時に正しい URL に解決しますので、Blazor アプリがポート番号やホスト名をハードコードすることは決してありません。

Tim は重要なデプロイメントの詳細を強調します：Aspire 自体は本番環境にはデプロイされません。 オーケストレーションは開発時のツールです。 本番では、サービス URL は構成（環境変数、アプリ設定、もしくは デプロイパイプライン）から得られ、アプは独立してアプリホストなしで実行されます。

ダッシュボードの実行と探索

[10:59 - 14:46] VS Code で Run and Debug パネルを通じてアプホストを起動し、HTTPS ランチプロファイルを選択します。最初の復元とビルド後、Aspire ダッシュボードがブラウザで開きます。 初めて接続するときは、ターミナル出力のログイントークンを貼り付ける必要があります。

ダッシュボードは、追加の構成なしで4カテゴリの可観察性データを提示します。

コンソール出力は、すべてのサービスからの stdout を集約して単一ビューにします。 ターミナルタブを切り替える代わりに、すべての出力がインターリーブされ、サービスごとにフィルタリング可能です。

構造化ログは、それらの構造化プロパティを保持したままログエントリを表示します。 例として Tim が遭遇した証明書の信頼警告がここに表示され、どのサービスがそれを生成したのか、どのレベルの重大度であったかについての完全な文脈があります。

トレースは分散呼び出しチェーンを表示します。 Blazor フロントエンドが天気データを要求する際、そのトレースはフロントエンドからの HTTP GET、API サービスまでのホップ（ビデオで 7.35 ミリ秒）、および合計ページレンダリング時間を示します。Tim は絶対値よりも相対的な比較が重要であると指摘します：通常5秒かかる呼び出しが突然10秒かかるようになった場合、プロファイラをアタッチしなくても回帰を発見したことになります。

メトリックスは、リクエストレート、エラー率、リソース消費についてのサービスごとのカウンターを提供します。 ダッシュボードはまた、構成値が正しく流れていることを確認するために役立つ各サービスの環境変数とエンドポイント認証情報を公開します。

Tiny Ticket の紹介：シリーズプロジェクト

[14:46 - 17:17] Tim はシリーズの残りの部分を通じて続くプロジェクトの計画を概説します。 Tiny Ticket は簡素化されたヘルプデスクアプリケーションであり、ユーザはサポートチケットを提出し、システムは優先順位とステータスを追跡します。 データモデルは単一の SQL テーブルほど小さい可能性があります。 目的は機能豊富な製品を構築することではなく、Linux 上の開発ライフサイクルのすべての部分をカバーする垂直スライスを作成することです：ビルド、テスト、デプロイ、外部サービスへの接続。

スターターテンプレートの天気予報とカウンターページはチケットビューに置き換えられますが、Aspire のオーケストレーション、API からフロントエンドへのパターン、およびサービスデフォルトはそのまま残ります。 今後のエピソードでは、データベースとして Microsoft SQL Server が追加され、Tim は共通の異議に対処します：SQL Server をローカル環境で実行できない（たとえば ARM プロセッサ）開発者は異なるデータベースに手を伸ばすことがあります。 彼の対応は、開発環境がプロダクションを複製するべきだということです。 プロダクションデータベースが SQL Server であるならば、開発環境はそれに一致する必要があります。それはたとえデータベースをコンテナで実行することが必要でもそうであるべきです。

まとめ: ゼロからダッシュボードへ

[17:17 - 18:20] 20 分未満で、ビデオは Linux 上の完全な Aspire セットアップをカバーしています：CLI インストール、VS Code 拡張、スキャフォールディングされたプロジェクト、そしてゼロカスタム設定で構造化ログ、分散トレーシング、メトリックスを提供するダッシュボード。 Aspire の真の価値は個別の機能にあるのではなく、摩擦の削減にあります：開始するプロセス一つ、監視するダッシュボード一つ、サービスがどのように相互作用するかを見る場所一つ。

結論

[18:20 - 18:53] Linux 上での Aspire のセットアップには CLI ツール、VS Code 拡張機能、プロジェクトスキャフォールディングが必要です。 そこから、ダッシュボードがテレメトリーコードを書くことなく各サービス全体の可観測性を提供します。 アプホストファイルは 12 行のコードであなたのサービスグラフを定義し、サービスデフォルトは手動で構成される配管を担当します。

ここで紹介された Tiny Ticket プロジェクトが、データベース統合、Azure デプロイメント、クロスプラットフォームワークフローに関する今後のエピソードの基盤になります。 この出発点から続くことは、新しい概念がすでに確認したインフラ上に構築されることを意味します。

シリーズナビゲーション：この記事は Tiny Ticket アプリを構築する C# on Linux シリーズの一部です。前回： Linux 上の Docker で SQL Server。 次： .NET Aspire に Swagger UI を追加する Linux。

例: VS Codeのテンプレートピッカーが拡張機能のインストール後にAspireテンプレートを見つけられない場合、aspire newをターミナルから使用することで信頼性のある代替方法となり、その後VS Codeを再起動して拡張の状態を同期します。

ビデオを彼の YouTube チャンネルでフルに視聴し、Linux 開発のための .NET Aspire の設定に関するさらなる洞察を得ましょう。