Docker Compose からAspire へ移行する

このガイドは、アプリケーションを Docker Compose から Aspire に移行する方法を理解するのに役立ち、主な概念上の違いを強調し、一般的な移行シナリオの実用的な例を提供します。

違いを理解する

Docker Compose と Aspire は一見似ているように見えるかもしれませんが、さまざまな目的に対応し、さまざまなレベルの抽象化で動作します。

Docker Compose と Aspire

	Docker 綴る	Aspire
主な目的	コンテナーのオーケストレーション	開発時のオーケストレーションとアプリの構成。
スコープ	コンテナーに重点を置いた	マルチリソース (コンテナー、 .NET プロジェクト、クラウドリソース)。
構成	YAML ベース	C# ベースで、厳密に型指定されます。
ターゲット環境	任意の Docker ランタイム	開発とクラウドのデプロイ。
サービス検出	DNS ベースのコンテナー検出	環境変数を使用した組み込みのサービス検出。
開発エクスペリエンス	コンテナーの手動管理	統合されたツール、ダッシュボード、テレメトリ。

詳細については、「 Docker Compose to Aspire AppHost API リファレンス」を参照してください。

主要概念シフト

Docker Compose から Aspire に移行する場合は、次の概念上の違いを考慮してください。

YAML から C# へ: 構成は宣言型 YAML から命令型の厳密に型指定された C# コードに移行します。
コンテナーからリソースへ: Aspire は、コンテナーだけでなく、プロジェクト、実行可能ファイル、パラメーターをリソースとして .NET 管理します。
手動ネットワークからサービス検出へ: Aspire は、サービス検出と接続文字列を自動的に構成します。
開発のギャップから統合されたエクスペリエンスまで: Aspire は、ダッシュボード、テレメトリ、デバッグ統合を提供します。

包括的な参照マッピングについて Compose YAML 構文Dockerから C# API 呼び出しAspireへは、「Docker Compose to Aspire AppHost API リファレンス」を参照してください。

関連リンク:

一般的な移行パターン

このセクションでは、 Docker Compose から Aspire に移行するときに発生する可能性のある実用的な移行シナリオについて説明します。各パターンでは、完全な Docker Compose の例と、それに対応する Aspire の例が示されており、移行における主な違いと利点が強調されています。

対象となるパターンは次のとおりです。

フロントエンド、API、およびデータベースコンポーネントを含むマルチサービス Web アプリケーション。
既存のイメージを使用するDocker。
環境変数と構成 管理戦略。
データの永続化とサービスの分離のためのカスタムネットワークとボリューム。

これらの例は最も一般的なユースケースを表していますが、 Aspireの柔軟性により、他の多くのシナリオに対応できます。特定のユースケースがここで取り上げられていない場合は、これらのパターンを組み合わせるか、上記の包括的な API リファレンスを参照してください。

マルチサービス Web アプリケーション

Docker 構成サンプル:

version: '3.8'
services:
  frontend:
    build: ./frontend
    ports:
      - "3000:3000"
    depends_on:
      - api
    environment:
      - API_URL=http://api:5000

  api:
    build: ./api
    ports:
      - "5000:5000"
    depends_on:
      - database
    environment:
      - ConnectionStrings__DefaultConnection=Host=database;Database=myapp;Username=postgres;Password=secret

  database:
    image: postgres:15
    environment:
      - POSTGRES_DB=myapp
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=secret
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Aspire 同等：

var builder = DistributedApplication.CreateBuilder(args);

// Add the database
var database = builder.AddPostgres("postgres")
    .WithEnvironment("POSTGRES_DB", "myapp")
    .AddDatabase("myapp");

// Add the API project
var api = builder.AddProject<Projects.MyApp_Api>("api")
    .WithReference(database);

// Add the frontend project  
var frontend = builder.AddProject<Projects.MyApp_Frontend>("frontend")
    .WithReference(api);

builder.Build().Run();

主な相違点:

サービスの依存関係: depends_on が WithReference() になり、サービス検出も構成されます。
環境変数: 接続文字列が自動的に生成され、挿入されます。
ビルドコンテキスト: ビルドコンテキストでは、単に .NET ビルドだけでなく、Dockerfile、Node.js プロジェクト、Dockerfile アプリなども使用できます。
データの永続化: ボリュームは Aspireによって自動的に管理されます。

コンテナーベースのサービス

Docker 構成サンプル:

version: '3.8'
services:
  web:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - redis
      - postgres

  redis:
    image: redis:7
    ports:
      - "6379:6379"

  postgres:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Aspire 同等：

var builder = DistributedApplication.CreateBuilder(args);

// Add backing services
var cache = builder.AddRedis("redis");
var database = builder.AddPostgres("postgres", password: "secret")
    .AddDatabase("main");

// Add the containerized web application
var web = builder.AddContainer("web", "myapp:latest")
    .WithHttpEndpoint(port: 8080, targetPort: 8080)
    .WithReference(cache)
    .WithReference(database);

builder.Build().Run();

環境変数と構成

Docker Compose のアプローチ:

services:
  app:
    image: myapp:latest
    environment:
      - DATABASE_URL=postgresql://user:pass@db:5432/myapp
      - REDIS_URL=redis://cache:6379
      - API_KEY=${API_KEY}
      - LOG_LEVEL=info

Aspire アプローチ：

var builder = DistributedApplication.CreateBuilder(args);

// Add external parameter
var apiKey = builder.AddParameter("apiKey", secret: true);

var database = builder.AddPostgres("db")
    .AddDatabase("myapp");
    
var cache = builder.AddRedis("cache");

var app = builder.AddContainer("app", "myapp:latest")
    .WithReference(database)      // Automatically sets DATABASE_URL
    .WithReference(cache)         // Automatically sets REDIS_URL  
    .WithEnvironment("API_KEY", apiKey)
    .WithEnvironment("LOG_LEVEL", "info");

builder.Build().Run();

主な相違点:

自動接続文字列: データベースとキャッシュの URL が自動的に生成されます。
型指定されたパラメーター: 外部構成では、環境変数の置換の代わりに厳密に型指定されたパラメーターが使用されます。
サービス検出: 参照によって、正しいサービスエンドポイントが自動的に構成されます。

カスタムネットワークとボリューム

Docker 構成サンプル:

version: '3.8'
services:
  app:
    image: myapp:latest
    volumes:
      - app_data:/data
      - ./config:/app/config:ro
    networks:
      - backend

  worker:
    image: myworker:latest
    volumes:
      - app_data:/shared
    networks:
      - backend

networks:
  backend:

volumes:
  app_data:

Aspire 同等：

var builder = DistributedApplication.CreateBuilder(args);

// Create a named volume
var appData = builder.AddVolume("app-data");

var app = builder.AddContainer("app", "myapp:latest")
    .WithVolume(appData, "/data")
    .WithBindMount("./config", "/app/config", isReadOnly: true);

var worker = builder.AddContainer("worker", "myworker:latest")
    .WithVolume(appData, "/shared");

builder.Build().Run();

主な相違点:

簡略化されたネットワーク: Aspire はコンテナーネットワークを自動的に処理します。
ボリューム管理: 名前付きボリュームは、リソースモデルを使用して作成および管理されます。
バインドマウント: ホストディレクトリは、 WithBindMount()を使用してマウントできます。

関連リンク:

移行戦略

Docker Compose から Aspire に正常に移行するには、体系的なアプローチが必要です。次の手順では、中断を最小限に抑え、すべてのコンポーネントが新しい環境で正しく動作することを保証しながら、アプリケーションを移動するための実証済みの手法を提供します。

1. 現在のセットアップを評価する

移行する前に、 Docker Compose セットアップのインベントリを作成します。

サービス: データベース、キャッシュ、API、Web アプリケーションを含むすべてのサービスを識別します。
依存関係: depends_on 宣言からサービスの依存関係をマップします。
データ永続化: データストレージに使用されるすべてのボリュームとバインドマウントをカタログ化します。
環境変数: すべての構成変数とシークレットを一覧表示します。
カスタムネットワーク: カスタムネットワークの要件と構成を特定します。

2. Aspire AppHost を作成する

まず、新しい Aspire プロジェクトを作成します。

dotnet new aspire-apphost -o MyApp.AppHost

3. サービスを段階的に移行する

バッキングサービス (データベース、キャッシュ) とアプリケーションから始めて、サービスを 1 つずつ移行します。

、PostgreSQL、その他のインフラストラクチャコンポーネントなどのRedisします。
統合を向上させるために、.NET アプリケーションをプロジェクト参照に変換します。
既存のイメージに AddContainer() を使用して、Dockerします。
を使用してWithReference()し、サービスの関係を確立します。
構成管理用の環境変数とパラメーターを設定します。

4. データ移行の処理

永続データの場合:

データを保持する必要がある名前付きボリュームには、 WithVolume() を使用します。
ホストファイルに直接アクセスする必要がある場合は、ホストディレクトリマウントに WithBindMount() を使用します。
自動ボリューム管理でデータベースの永続化に WithDataVolume() を使用することを検討してください。

5. テストと検証

Aspire AppHost を起動し、すべてのサービスが正しく開始されていることを確認します。
ダッシュボードを確認して、サービスの正常性と接続状態を確認します。
サービス間通信が期待どおりに動作することを検証します。
互換性を確保するために、既存のクライアントアプリケーションでテストします。

関連リンク:

移行のトラブルシューティング

Docker Compose から Aspire に移行すると、いくつかの一般的な課題が発生する可能性があります。このセクションでは、頻繁に発生する問題の解決策と、移行プロセス中に発生する問題のトラブルシューティング方法に関するガイダンスを提供します。

一般的な問題と解決策

サービス検出が機能しない

WithReference()を使用してサービス間の依存関係を確立していることを確認します。
サービスが接続に正しい環境変数名を使用していることを確認します。
ダッシュボードを確認して、環境変数が正しく挿入されていることを確認します。

データベース接続が失敗する

依存サービスが接続を試みる前に、データベースが完全に開始されていることを確認します。

WaitFor()を使用して、適切なスタートアップ順序を確認します。

var api = builder.AddProject<Projects.Api>("api")
    .WithReference(database)
    .WaitFor(database);

ボリュームのマウントに関する問題

パス解決の問題を回避するには、バインドマウントに絶対パスを使用します。
マウントする前に、ホストディレクトリが存在し、適切なアクセス許可があることを確認します。
移植性を向上するために、可能な限りバインドマウントの代わりに名前付きボリュームを使用することを検討してください。

ポートの競合

Aspire は、サービス間の競合を回避するためにポートを自動的に割り当てます。
外部アクセスに必要な場合は、 WithHttpEndpoint() を使用してカスタムポートを指定します。
開発中に実際に割り当てられたポートがダッシュボードで確認されます。

関連リンク:

次のステップ

Aspireに移行した後:

カスタムコンテナー構成の置き換えのために、統合を調べましょう。
監視を強化するために正常性チェックを設定します。
可観測性のためにテレメトリを構成します。
運用環境のデプロイオプションについて説明します。
分散アプリケーションのテストを検討してください。

こちらも参照ください

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-10-02

次の方法で共有

Docker Compose からAspire へ移行する

違いを理解する

Docker Compose と Aspire

主要概念シフト

一般的な移行パターン

マルチサービス Web アプリケーション

コンテナー ベースのサービス

環境変数と構成

カスタム ネットワークとボリューム

移行戦略

1. 現在のセットアップを評価する

2. Aspire AppHost を作成する

3. サービスを段階的に移行する

4. データ移行の処理

5. テストと検証

移行のトラブルシューティング

一般的な問題と解決策

次のステップ

こちらも参照ください

フィードバック

その他のリソース

コンテナーベースのサービス

カスタムネットワークとボリューム