Dostosowywanie parametry połączenia przy użyciu manifestów platformy .NET Aspire

7 min

Narzędzia wdrażania, takie jak Program Visual Studio lub interfejs wiersza polecenia dla deweloperów platformy Azure, tworzą pliki manifestu opisujące zawartość rozwiązania .NET Aspire. Jeśli chcesz dostosować wdrożenie, możesz wprowadzić zmiany bezpośrednio w pliku manifestu.

W sklepie detalicznym sprzętu zewnętrznego zdecydowano się użyć istniejącego wystąpienia usługi Azure Cache for Redis do hostowania wyjściowej pamięci podręcznej dla mikrousługi aplikacji internetowej. Chcesz upewnić się, że usługa aplikacji internetowej łączy się z poprawnym wystąpieniem usługi Azure Cache for Redis.

W tej lekcji dowiesz się, jak zmienić parametry połączenia na usługi zapasowe w pliku manifestu programu .NET Aspire.

Generowanie pliku manifestu przy użyciu interfejsu wiersza polecenia platformy .NET

Podczas lokalnego programowania i debugowania platforma .NET Aspire nie tworzy pliku manifestu. Jeśli chodzi o wdrożenie, platforma .NET musi opisać zawartość rozwiązania .NET Aspire, w tym jej mikrousługi, usługi zapasowe i konfigurację. Plik manifestu służy do tego celu. Opisuje rozwiązanie w formacie JSON.

Aby utworzyć plik manifestu, zarówno program Visual Studio, jak i interfejs wiersza polecenia dla deweloperów platformy Azure, uruchom polecenie interfejsu wiersza polecenia run platformy .NET z określonym elementem docelowym. Możesz ręcznie uruchomić to samo polecenie, aby utworzyć własny plik manifestu w następujący sposób:

dotnet run --project eShop.AppHost\eShop.AppHost.csproj `
    --publisher manifest `
    --output-path ../aspire-manifest.json

Uwaga

Upewnij się, że określono projekt hosta aplikacji z opcją --project .

Polecenie generuje dane wyjściowe podobne do następującego tekstu:

Building...
info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 8.0.1+a6e341ebbf956bbcec0dda304109815fcbae70c9
info: Aspire.Hosting.Publishing.ManifestPublisher[0]
      Published manifest to: C:\repos\eShop\aspire-manifest.json

Możesz również użyć profilu uruchamiania, aby uruchomić dotnet polecenie. Profil uruchamiania to grupa ustawień, które konfigurują projekt platformy .NET podczas jego uruchamiania. Na przykład szablon .NET Aspire Starter tworzy następujące profile uruchamiania:

"profiles": {
  "https": {
    "commandName": "Project",
    "dotnetRunMessages": true,
    "launchBrowser": true,
    "applicationUrl": "https://localhost:17170;http://localhost:15281",
    "environmentVariables": {
      "ASPNETCORE_ENVIRONMENT": "Development",
      "DOTNET_ENVIRONMENT": "Development",
      "DOTNET_DASHBOARD_OTLP_ENDPOINT_URL": "https://localhost:21147",
      "DOTNET_RESOURCE_SERVICE_ENDPOINT_URL": "https://localhost:22239"
    }
  },
  "http": {
    "commandName": "Project",
    "dotnetRunMessages": true,
    "launchBrowser": true,
    "applicationUrl": "http://localhost:15281",
    "environmentVariables": {
      "ASPNETCORE_ENVIRONMENT": "Development",
      "DOTNET_ENVIRONMENT": "Development",
      "DOTNET_DASHBOARD_OTLP_ENDPOINT_URL": "http://localhost:19197",
      "DOTNET_RESOURCE_SERVICE_ENDPOINT_URL": "http://localhost:20233"
    }
  }
}

Dodaj profil uruchamiania, aby utworzyć plik manifestu z kodem JSON podobnym do następującego tekstu:

"profiles": {
  "generate-manifest": {
    "commandName": "Project",
    "launchBrowser": false,
    "dotnetRunMessages": true,
    "commandLineArgs": "--publisher manifest --output-path aspire-manifest.json"
  }
}

W programie Visual Studio możesz wybrać profil generowania manifestu podczas rozpoczynania debugowania. W wierszu polecenia użyj --launch-profile opcji:

dotnet run --launch-profile generate-manifest

Format pliku manifestu

Manifest jest plikiem JSON z pojedynczym elementem najwyższego poziomu o nazwie resources. W tym obiekcie znajduje się jeden obiekt dla każdej mikrousługi i usługi zapasowej. Dla każdego z tych obiektów ustawienia obejmują parametry połączenia, zmienne środowiskowe i nazwy obrazów kontenera.

Oto przykładowy manifest szablonu .NET Aspire Starter bez żadnych modyfikacji. Rozwiązanie korzysta z pamięci podręcznej Redis:

{
  "resources": {
    "cache": {
      "type": "container.v0",
      "connectionString": "{cache.bindings.tcp.host}:{cache.bindings.tcp.port}",
      "image": "docker.io/library/redis:7.2",
      "bindings": {
        "tcp": {
          "scheme": "tcp",
          "protocol": "tcp",
          "transport": "tcp",
          "targetPort": 6379
        }
      }
    },
    "apiservice": {
      "type": "project.v0",
      "path": "AspireStarter.ApiService/AspireStarter.ApiService.csproj",
      "env": {
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY": "in_memory",
        "ASPNETCORE_FORWARDEDHEADERS_ENABLED": "true"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http"
        },
        "https": {
          "scheme": "https",
          "protocol": "tcp",
          "transport": "http"
        }
      }
    },
    "webfrontend": {
      "type": "project.v0",
      "path": "AspireStarter.Web/AspireStarter.Web.csproj",
      "env": {
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY": "in_memory",
        "ASPNETCORE_FORWARDEDHEADERS_ENABLED": "true",
        "ConnectionStrings__cache": "{cache.connectionString}",
        "services__apiservice__http__0": "{apiservice.bindings.http.url}",
        "services__apiservice__https__0": "{apiservice.bindings.https.url}"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http",
          "external": true
        },
        "https": {
          "scheme": "https",
          "protocol": "tcp",
          "transport": "http",
          "external": true
        }
      }
    }
  }
}

Parametry połączenia i odwołania do powiązań

W przykładzie manifestu istnieją trzy zasoby:

webfrontend: ten zasób jest mikrousługą, która przedstawia klientom interfejs internetowy.
apiservice: ten zasób jest interfejsem API REST, który webfrontend wywołuje. W szablonie to wywołanie polega na uzyskaniu danych pogodowych.
cache: ten zasób to pamięć podręczna Redis, używana do optymalizacji wydajności webfrontend mikrousługi.

Zwróć uwagę, że każdy z trzech zasobów zawiera sekcję określającą bindings protokoły, których można użyć do nawiązania połączenia z tym zasobem.

W pliku Program.cs hosta aplikacji projekt zależy od cache elementu i :apiservicewebfrontend

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

var apiService = builder.AddProject<Projects.AspireStarter_ApiService>("apiservice");

builder.AddProject<Projects.AspireStarter_Web>("webfrontend")
    .WithExternalHttpEndpoints()
    .WithReference(cache)
    .WithReference(apiService);

W pliku manifestu te zależności są wyrażane jako zmienne środowiskowe:

"env": {
  "ConnectionStrings__cache": "{cache.connectionString}",
  "services__apiservice__http__0": "{apiservice.bindings.http.url}",
  "services__apiservice__https__0": "{apiservice.bindings.https.url}"
}

Zależności używają ciągów zastępczych odwołujących się do struktury pliku manifestu. Na przykład trzecia zależność odwołuje się do powiązania HTTPS usługi API:

Dowiedz się więcej

Kontynuuj

Dostosowywanie parametry połączenia przy użyciu manifestów platformy .NET Aspire

Generowanie pliku manifestu przy użyciu interfejsu wiersza polecenia platformy .NET

Format pliku manifestu

Parametry połączenia i odwołania do powiązań

Dowiedz się więcej

Opinia