.NET .NET Aspire orkiestráció áttekintése

.NET .NET Aspire API-kat biztosít az elosztott alkalmazás erőforrásainak és függőségeinek kifejezéséhez. Ezen API-k mellett olyan eszközhasználati is rendelkezésre áll, amely számos lenyűgöző forgatókönyvet tesz lehetővé. A vezénylő helyi fejlesztési célokra készült, és éles környezetben nem támogatott.

A folytatás előtt fontolja meg a .NET.NET Aspiregyakran használt terminológiát:

• alkalmazásmodell: A DistributedApplication névtérben definiált elosztott alkalmazást (Aspire.Hosting.ApplicationModel) alkotó erőforrások gyűjteménye. Formálisabb definícióért lásd: Az alkalmazásmodell definiálása.
• Alkalmazásgazda/Vezénylő projekt: A .NETvezénylő projekt, amelynek neve a *. AppHost utótaggal (konvenció szerint).
• erőforrás-: Az erőforrás- egy alkalmazás függő része, például egy .NET projekt, tároló, végrehajtható, adatbázis, gyorsítótár vagy felhőszolgáltatás. Az alkalmazás bármely olyan részét jelöli, amely felügyelhető vagy hivatkozható.
• Integráció: Az integráció egy NuGet-csomag, amely az alkalmazás gazdagépét modellezi egy erőforrással, vagy egy olyan csomag, amely az ügyfelet konfigurálja egy alkalmazásban való használatra. További információ: .NET.NET Aspire integrációk áttekintése.
• Referencia: A hivatkozás az erőforrások közötti kapcsolatot határozza meg, amely függőségként van kifejezve a WithReference API használatával. További információért lásd a Referenciaanyagot vagy tekintse meg a Meglévő erőforrásokat.

Az alkalmazásmodell definiálása

.NET .NET Aspire lehetővé teszi az elosztott alkalmazások zökkenőmentes létrehozását, kiépítését, üzembe helyezését, konfigurálását, tesztelését, futtatását és megfigyelését. Mindezek a képességek egy alkalmazásmodell segítségével érhetők el, amely felvázolja a .NET.NET Aspire megoldás erőforrásait és kapcsolatait. Ezek az erőforrások olyan projekteket, végrehajtható fájlokat, tárolókat és külső szolgáltatásokat és felhőerőforrásokat foglalnak magukban, amelyektől az alkalmazás függ. Minden .NET.NET Aspire megoldásban van egy kijelölt Alkalmazásgazda projekt, ahol az alkalmazásmodell pontosan a IDistributedApplicationBuilderelérhető módszerek használatával van definiálva. Ez az építő azzal érhető el, hogy meghívja a DistributedApplication.CreateBuilder-t.

// Create a new app model builder
var builder = DistributedApplication.CreateBuilder(args);

// TODO:
//   Add resources to the app model
//   Express dependencies between resources

builder.Build().Run();

Alkalmazásgazda projekt

Az alkalmazásgazda projekt kezeli a .NET.NET Aspire projekt részét képező összes projektet. Más szóval az alkalmazásmodell összes alkalmazásának vezényléséért felelős. Maga a projekt egy .NET végrehajtható projekt, amely a 📦Aspire-ra hivatkozik, a Hosting.AppHost NuGet-csomagra, beállítja a IsAspireHost tulajdonságot true-ra, és hivatkozik a .NET.NET Aspire SDK-ra.

<Project Sdk="Microsoft.NET.Sdk">

    <Sdk Name="Aspire.AppHost.Sdk" Version="9.1.0" />
    
    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>net9.0</TargetFramework>
        <IsAspireHost>true</IsAspireHost>
        <!-- Omitted for brevity -->
    </PropertyGroup>

    <ItemGroup>
        <PackageReference Include="Aspire.Hosting.AppHost" Version="9.1.0" />
    </ItemGroup>

    <!-- Omitted for brevity -->

</Project>

Az alábbi kód leír egy Program alkalmazásgazdát, amely két projekthivatkozással és egy Redis gyorsítótárral rendelkezik.

var builder = DistributedApplication.CreateBuilder(args);

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

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

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

builder.Build().Run();

Az előző kód:

• Új alkalmazásmodell-szerkesztőt hoz létre a CreateBuilder metódus használatával.
• Hozzáad egy "cache" nevű Rediscache erőforrást a AddRedis metódus használatával.
• Hozzáad egy "apiservice" nevű projekterőforrást a AddProject metódus használatával.
• Hozzáad egy "webfrontend" nevű projekterőforrást a AddProject metódus használatával.
  • Megadja, hogy a projekt külső HTTP-végpontokkal rendelkezik-e a WithExternalHttpEndpoints metódus használatával.
  • A cache erőforrásra mutató hivatkozást ad hozzá, és megvárja, amíg készen áll a WithReference és WaitFor metódusok használatával.
  • A apiservice erőforrásra mutató hivatkozást ad hozzá, és megvárja, amíg készen áll a WithReference és WaitFor metódusok használatával.
• Létrehozza és futtatja az alkalmazásmodellt a Build és Run metódusok használatával.

A példakód a .NET AspireRedis hosting integráció-at használja.

Az alkalmazásgazdaprojekt és az általa leírt erőforrások közötti kapcsolat megjelenítéséhez tekintse meg az alábbi ábrát:

Minden erőforrásnak egyedi névvel kell rendelkeznie. Ez az ábra az egyes erőforrásokat és a köztük lévő kapcsolatokat mutatja be. A tárolóerőforrás neve "cache", a projekterőforrások neve "apiservice" és "webfrontend". A webes előtérbeli projekt a gyorsítótár- és API-szolgáltatási projektekre hivatkozik. Ha így fejezi ki a hivatkozásokat, a webes frontend projekt azt mondja, hogy ez a két erőforrástól, a "gyorsítótár"-tól és az "apiservice"-től függ.

Beépített erőforrástípusok

.NET .NET Aspire projekteket egy erőforráskészlet alkotja. A 📦Aspireelsődleges alaperőforrás-típusait az alábbi táblázat ismerteti a Hosting.AppHost NuGet-csomagban.

A projekterőforrások az alkalmazásmodell részét képező .NET projekteket jelölik. Amikor hozzáad egy projekthivatkozást az alkalmazásgazdaprojekthez, a .NET.NET Aspire SDK létrehoz egy típust az egyes hivatkozott projektek Projects névterében. További információ: .NET.NET Aspire SDK: Projekt hivatkozások.

Ha projektet szeretne hozzáadni az alkalmazásmodellhez, használja a AddProject metódust:

var builder = DistributedApplication.CreateBuilder(args);

// Adds the project "apiservice" of type "Projects.AspireApp_ApiService".
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice");

A projektek replikálhatók és skálázhatók úgy, hogy ugyanazon projekt több példányát is hozzáadják az alkalmazásmodellhez. A replikák konfigurálásához használja a WithReplicas metódust:

var builder = DistributedApplication.CreateBuilder(args);

// Adds the project "apiservice" of type "Projects.AspireApp_ApiService".
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
                        .WithReplicas(3);

Az előző kód az "apiservice" projekterőforrás három replikáját adja hozzá az alkalmazásmodellhez. További információért tekintse meg a .NET.NET Aspire irányítópultot: Erőforrás replikák.

Explicit erőforrás-indítás konfigurálása

A projekt-, végrehajtható- és tárolóerőforrások alapértelmezés szerint automatikusan elindulnak az elosztott alkalmazással. Egy erőforrás konfigurálható úgy, hogy az WithExplicitStart metódussal explicit indítási utasítást várjon. Egy erőforrás, amely WithExplicitStart-val van konfigurálva, KnownResourceStates.NotStarted-gyel inicializálva lett.

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres");
var postgresdb = postgres.AddDatabase("postgresdb");

builder.AddProject<Projects.AspireApp_DbMigration>("dbmigration")
       .WithReference(postgresdb)
       .WithExplicitStart();

Az előzménykódban a "dbmigration" erőforrás úgy van konfigurálva, hogy ne induljon el automatikusan az elosztott alkalmazással.

Az explicit indítású erőforrások a "Start" parancsra kattintva indíthatók el az .NET.NET Aspire irányítópulton. További információ: .NET.NET Aspire irányítópult: Erőforrás leállítása vagy indítása.

Referenciaerőforrások

A hivatkozás az erőforrások közötti függőséget jelöli. Elképzelhető például, hogy egy webes előtér egy Redis gyorsítótártól függ. Tekintse meg az alábbi példaalkalmazás-gazdagépet Program C#-kóddal:

var builder = DistributedApplication.CreateBuilder(args);

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

builder.AddProject<Projects.AspireApp_Web>("webfrontend")
       .WithReference(cache);

A "webfrontend" projekt erőforrása a WithReference-t használja a "gyorsítótár" tárolóerőforrással való függőség hozzáadásához. Ezek a függőségek kapcsolati sztringeket vagy szolgáltatásfelderítési információkat jelölhetnek. Az előző példában egy környezeti változó a "webfrontend" erőforrásba ConnectionStrings__cachenéven. Ez a környezeti változó egy kapcsolati szöveget tartalmaz, amit a webfrontend a Rediskeresztüli .NET Aspire-hez való csatlakozáshoz használ, például Redis.

Erőforrásokra várva

Bizonyos esetekben érdemes megvárni, amíg egy erőforrás készen áll egy másik erőforrás indítása előtt. Előfordulhat például, hogy várnia kell, amíg egy adatbázis készen áll, mielőtt elindít egy attól függő API-t. A függőség kifejezéséhez használja a WaitFor metódust:

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres");
var postgresdb = postgres.AddDatabase("postgresdb");

builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
       .WithReference(postgresdb)
       .WaitFor(postgresdb);

Az előző kódban az "apiservice" projekterőforrás megvárja, amíg a "postgresdb" adatbázis-erőforrás beírja a KnownResourceStates.Running. A példakód az .NET AspirePostgreSQL integrációsmutatja, de ugyanez a minta más erőforrásokra is alkalmazható.

Más esetekben szükség lehet arra, hogy az erőforrás befejeződjön, akár KnownResourceStates.Exited, akár KnownResourceStates.Finished a függő erőforrás elindítása előtt. Ha meg szeretné várni, hogy egy erőforrás befejeződjön, használja a WaitForCompletion metódust:

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres");
var postgresdb = postgres.AddDatabase("postgresdb");

var migration = builder.AddProject<Projects.AspireApp_Migration>("migration")
                       .WithReference(postgresdb)
                       .WaitFor(postgresdb);

builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
       .WithReference(postgresdb)
       .WaitForCompletion(migration);

Az előző kódban az "apiservice" projekterőforrás megvárja a "migráció" projekterőforrás befejezését a kezdés előtt. A "migrálás" projekterőforrás megvárja, amíg a "postgresdb" adatbázis erőforrás eléri a KnownResourceStates.Runningállapotot. Ez olyan helyzetekben lehet hasznos, amikor például az API-szolgáltatás elindítása előtt adatbázis-migrálást szeretne futtatni.

Erőforrás indításának kényszerítése az irányítópulton

Az erőforrásra való várakozás az irányítópult "Start" parancsával megkerülhető. Ha az irányítópulton a "Start" gombra kattint egy várakozó erőforráson, az arra utasítja, hogy azonnal elinduljon anélkül, hogy megvárja az erőforrás kifogástalan állapotát vagy befejezését. Ez akkor lehet hasznos, ha azonnal tesztelni szeretne egy erőforrást, és nem szeretné megvárni, amíg az alkalmazás megfelelő állapotban van.

API-k erőforrások hozzáadásához és kifejezéséhez

.NET .NET Aspire hosztoló integrációk és kliensek integrációi egyaránt NuGet-csomagként vannak kézbesítve, de különböző célokat szolgálnak. Bár ügyfélintegrációk biztosítják az ügyfélkódtár konfigurációját az alkalmazásgazda hatókörén kívüli alkalmazások használatához, üzemeltetési integrációk API-kat biztosítanak az alkalmazásgazda erőforrásainak és függőségeinek kifejezéséhez. További információ: .NET.NET Aspire integráció áttekintése: Integrációs feladatok.

Express konténer erőforrások

Egy ContainerResource kifejezése érdekében adja hozzá egy IDistributedApplicationBuilder példányhoz a AddContainer metódus meghívásával:

var builder = DistributedApplication.CreateBuilder(args);

var ollama = builder.AddContainer("ollama", "ollama/ollama")
    .WithBindMount("ollama", "/root/.ollama")
    .WithBindMount("./ollamaconfig", "/usr/config")
    .WithHttpEndpoint(port: 11434, targetPort: 11434, name: "ollama")
    .WithEntrypoint("/usr/config/entrypoint.sh")
    .WithContainerRuntimeArgs("--gpus=all");

var builder = DistributedApplication.CreateBuilder(args);

var ollama = builder.AddContainer("ollama", "ollama/ollama")
    .WithBindMount("ollama", "/root/.ollama")
    .WithBindMount("./ollamaconfig", "/usr/config")
    .WithHttpEndpoint(port: 11434, targetPort: 11434, name: "ollama")
    .WithEntrypoint("/usr/config/entrypoint.sh")
    .WithContainerRuntimeArgs("--device", "nvidia.com/gpu=all");

Az előző kód hozzáad egy "ollama" nevű tárolóerőforrást az ollama/ollamaképpel. A tárolóerőforrás több kötési ponttal, egy elnevezett HTTP-végponttal, egy olyan belépési ponttal van konfigurálva, amely Unix rendszerhéjszkripttel oldható fel, és a WithContainerRuntimeArgs metódust használja a futtatási argumentumokhoz.

Tárolóerőforrások testreszabása

Az összes ContainerResource alosztály testre szabható az ön igényeinek megfelelően. Ez akkor lehet hasznos, ha olyan üzemeltetési integrációs használ, amely egy tárolóerőforrást modellez, de módosításokat igényel. Ha van egy IResourceBuilder<ContainerResource>-ja, láncolhat hívásokat bármelyik elérhető API-hoz a tárolóerőforrás módosításához. .NET .NET Aspire konténerek erőforrásai általában rögzített címkékre mutatnak, de érdemes lehet inkább a latest címkét választani.

Ennek szemléltetéséhez képzeljen el egy forgatókönyvet, amelyben a .NET AspireRedis integrációshasználja. Ha a Redis integráció a 7.4 címkére támaszkodik, és ehelyett a latest címkét szeretné használni, akkor a WithImageTag API-hoz láncolni tudja a hívást:

var builder = DistributedApplication.CreateBuilder(args);

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

// Instead of using the "7.4" tag, the "cache" 
// container resource now uses the "latest" tag.

További információkért és további elérhető API-kért lásd: ContainerResourceBuilderExtensions.

Tároló erőforrásának életciklusa

Amikor az alkalmazáshost fut, a ContainerResource határozza meg, hogy melyik konténerképet kell létrehozni és elindítani. Motorháztető alatt a .NET Aspire a tárolót a meghatározott tárolókép segítségével futtatja, úgy, hogy a hívásokat a megfelelő OCI-kompatibilis tárolófuttató környezetnek delegálja, vagy a Docker-nek, vagy a Podman-nek. A rendszer a következő parancsokat használja:

Az alaperőforrás-típusokon, ProjectResource, ContainerResourceés ExecutableResourcekívül .NET.NET Aspire bővítménymetelyeket is biztosít, amelyek általános erőforrásokat adnak hozzá az alkalmazásmodellhez. További információ: Hosting-integrációk.

A tároló erőforrás élettartama

A konténer erőforrások alapértelmezés szerint a munkamenet élettartamát használják. Ez azt jelenti, hogy minden alkalommal, amikor az alkalmazásgazdafolyamat elindul, a tároló létrejön és elindul. Amikor az alkalmazás gazdagépe leáll, a tároló leáll és eltávolításra kerül. A tárolóerőforrások állandó élettartamra is bejelentkezhetnek a szükségtelen újraindítások elkerülése és a tárolóállapot megőrzése érdekében. Ennek érdekében láncoljon össze egy hívást a ContainerResourceBuilderExtensions.WithLifetime API-val, és adja át a ContainerLifetime.Persistent-et.

var builder = DistributedApplication.CreateBuilder(args);

var ollama = builder.AddContainer("ollama", "ollama/ollama")
    .WithLifetime(ContainerLifetime.Persistent);

Az előző kód hozzáad egy "ollama" nevű tárolóerőforrást az "ollama/ollama" képpel és egy állandó élettartammal.

Kapcsolati sztring és végponthivatkozások

Gyakori a projekterőforrások közötti függőségek kifejezése. Vegye figyelembe a következő példakódot:

var builder = DistributedApplication.CreateBuilder(args);

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

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

builder.AddProject<Projects.AspireApp_Web>("webfrontend")
       .WithReference(cache)
       .WithReference(apiservice);

A projektek közötti referenciák kezelése eltér a jól definiált kapcsolati sztringekkel rendelkező erőforrások kezelésétől. Ahelyett, hogy a kapcsolati sztringet a "webfrontend" erőforrásba injektálják, a rendszer a szolgáltatásfelderítést támogató környezeti változókat injektálja.

Az "apiservice" projektre mutató hivatkozás hozzáadása szolgáltatásfelderítési környezeti változókat eredményez az előtérben. Ennek az az oka, hogy a projekt–projekt kommunikáció általában HTTP/gRPC protokollon keresztül történik. További információ: .NET.NET Aspire szolgáltatás felfedezése.

Ha konkrét végpontokat szeretne lekérni egy ContainerResource-ból vagy egy ExecutableResource-ből, használja az alábbi végpont API-k egyikét:

• WithEndpoint
• WithHttpEndpoint
• WithHttpsEndpoint

Ezután hívja meg a GetEndpoint API-t a végpont lekéréséhez, amely a WithReference metódus végpontjának hivatkozására használható:

var builder = DistributedApplication.CreateBuilder(args);

var customContainer = builder.AddContainer("myapp", "mycustomcontainer")
                             .WithHttpEndpoint(port: 9043, name: "endpoint");

var endpoint = customContainer.GetEndpoint("endpoint");

var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
                        .WithReference(endpoint);

A port paraméter az a port, amelyen a tároló figyel. További információ a tárolóportokról: Tárolóportok. További információ a szolgáltatásfelderítésről: .NET.NET Aspire szolgáltatásfelderítés.

Szolgáltatásvégpont környezeti változóformátuma

Az előző szakaszban a WithReference metódus az erőforrások közötti függőségek kifejezésére szolgál. Ha a szolgáltatásvégpontok környezeti változókat injektálnak a függő erőforrásba, előfordulhat, hogy a formátum nem egyértelmű. Ez a szakasz részletesen ismerteti ezt a formátumot.

Ha az egyik erőforrás egy másik erőforrástól függ, az alkalmazásgazda környezeti változókat injektál a függő erőforrásba. Ezek a környezeti változók úgy konfigurálják a függő erőforrást, hogy csatlakozzanak ahhoz az erőforráshoz, amelytől függ. A környezeti változók formátuma a .NET.NET Aspire, és úgy írja le a szolgáltatási végpontokat, hogy azok kompatibilisek legyenek a szolgáltatásfelfedező rendszerrel.

A szolgáltatásvégpont környezeti változóinak neve először services__-val (dupla aláhúzás) kezdődik, majd a szolgáltatás neve, a végpont neve és végül az index következik. Az index több végpontot támogat egyetlen szolgáltatáshoz, kezdve az első végpont 0 és az egyes végpontok számának növelésével.

Vegye figyelembe a következő környezeti változó példákat:

services__apiservice__http__0

Az előző környezeti változó az első HTTP-végpontot fejezi ki a apiservice szolgáltatáshoz. A környezeti változó értéke a szolgáltatásvégpont URL-címe. Egy elnevezett végpont a következőképpen fejezhető ki:

services__apiservice__myendpoint__0

Az előző példában a apiservice szolgáltatás egy myendpointnevű végponttal rendelkezik. A környezeti változó értéke a szolgáltatásvégpont URL-címe.

Meglévő erőforrások hivatkozása

Bizonyos helyzetekben szükség van arra, hogy hivatkozzon egy meglévő erőforrásra, például egy felhőszolgáltatón üzembe helyezett erőforrásra. Előfordulhat például, hogy egy Azure adatbázisra szeretne hivatkozni. Ebben az esetben a végrehajtási környezetre támaszkodsz, hogy dinamikusan meghatározd, az alkalmazás gazdagépe "futtatási" vagy "közzétételi" módban fut-e. Ha helyileg fut, és felhőerőforrásra szeretne támaszkodni, a IsRunMode tulajdonság használatával feltételesen hozzáadhatja a hivatkozást. Dönthet úgy is, hogy inkább közzétételi módban hozza létre az erőforrást. Egyes üzemeltetési integrációk támogatják a kapcsolati sztring közvetlen megadását, amely egy meglévő erőforrásra való hivatkozásra használható.

Hasonlóképpen előfordulhatnak olyan használati esetek is, amikor a .NET.NET Aspire integrálni szeretné egy meglévő megoldásba. Az egyik gyakori módszer az .NET.NET Aspire alkalmazásgazdaprojekt hozzáadása egy meglévő megoldáshoz. Az alkalmazás-gazdagépen belül a függőségeket úgy fejezheti ki, hogy projekthivatkozásokat ad hozzá az alkalmazás-gazdagéphez, és az alkalmazásmodellt kiépítve. Előfordulhat például, hogy az egyik projekt egy másiktól függ. Ezeket a függőségeket a WithReference metódussal fejezzük ki. További információ: .NET Aspire hozzáadása meglévő .NET alkalmazáshoz.

Alkalmazásgazda életciklusai

A .NET.NET Aspire alkalmazásgazda számos életciklust tesz elérhetővé, amelyekhez a IDistributedApplicationLifecycleHook felület implementálásával csatlakozhat. A következő életciklus-módszerek érhetők el:

Bár az alkalmazásgazda életciklus-horgokat biztosít, érdemes lehet egyéni eseményeket regisztrálni. További információ: Eseménykezelés .NET.NET Aspire.

Életciklus-horog regisztrálása

Életciklus-horog regisztrálásához implementálja a IDistributedApplicationLifecycleHook felületet, és regisztrálja a horgot az alkalmazásgazda számára a AddLifecycleHook API használatával:

using Aspire.Hosting.Lifecycle;
using Microsoft.Extensions.Logging;

var builder = DistributedApplication.CreateBuilder(args);

builder.Services.AddLifecycleHook<LifecycleLogger>();

builder.Build().Run();

internal sealed class LifecycleLogger(ILogger<LifecycleLogger> logger)
    : IDistributedApplicationLifecycleHook
{
    public Task BeforeStartAsync(
        DistributedApplicationModel appModel, CancellationToken cancellationToken = default)
    {
        logger.LogInformation("BeforeStartAsync");
        return Task.CompletedTask;
    }

    public Task AfterEndpointsAllocatedAsync(
        DistributedApplicationModel appModel, CancellationToken cancellationToken = default)
    {
        logger.LogInformation("AfterEndpointsAllocatedAsync");
        return Task.CompletedTask;
    }

    public Task AfterResourcesCreatedAsync(
        DistributedApplicationModel appModel, CancellationToken cancellationToken = default)
    {
        logger.LogInformation("AfterResourcesCreatedAsync");
        return Task.CompletedTask;
    }
}

Az előző kód:

• Implementálja a IDistributedApplicationLifecycleHook felületet LifecycleLogger-ként.
• Regisztrálja az életciklus-horgot az alkalmazásgazda számára a AddLifecycleHook API használatával.
• Az összes eseményhez naplózza az üzenetet.

Amikor ez az alkalmazás-gazda fut, végrehajtásra kerül az életciklus-horog minden eseményhez. A következő kimenet jön létre:

info: LifecycleLogger[0]
      BeforeStartAsync
info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 9.0.0
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
      Application host directory is: ..\AspireApp\AspireApp.AppHost
info: LifecycleLogger[0]
      AfterEndpointsAllocatedAsync
info: Aspire.Hosting.DistributedApplication[0]
      Now listening on: https://localhost:17043
info: Aspire.Hosting.DistributedApplication[0]
      Login to the dashboard at https://localhost:17043/login?t=d80f598bc8a64c7ee97328a1cbd55d72
info: LifecycleLogger[0]
      AfterResourcesCreatedAsync
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application started. Press Ctrl+C to shut down.

Az alkalmazásgazda életciklusához való csatlakoztatás elsődleges módja az eventing API használata. További információkért lásd: Eseménykezelés .NET.NET Aspire.

Végrehajtási környezet

A IDistributedApplicationBuilder egy végrehajtási környezetet (DistributedApplicationExecutionContext) tesz elérhetővé, amely információt nyújt az alkalmazásgazda aktuális végrehajtásáról. Ezzel a környezettel meghatározható, hogy az alkalmazás hosztja "run" üzemmódban működik-e, vagy egy közzétételi művelet részeként történik az üzemeltetése. Vegye figyelembe a következő tulajdonságokat:

• IsRunMode: Visszaadja true-et, ha az aktuális művelet fut.
• IsPublishMode: true ad vissza, ha az aktuális művelet közzététel alatt áll.

Ez az információ akkor lehet hasznos, ha feltételesen szeretné végrehajtani a kódot az aktuális művelet alapján. Tekintse meg az alábbi példát, amely a IsRunMode tulajdonság használatát mutatja be. Ebben az esetben egy kiterjesztési metódussal állít elő stabil csomópontnevet a(z) RabbitMQ-hoz helyi fejlesztési futtatásokhoz.

private static IResourceBuilder<RabbitMQServerResource> RunWithStableNodeName(
    this IResourceBuilder<RabbitMQServerResource> builder)
{
    if (builder.ApplicationBuilder.ExecutionContext.IsRunMode)
    {
        builder.WithEnvironment(context =>
        {
            // Set a stable node name so queue storage is consistent between sessions
            var nodeName = $"{builder.Resource.Name}@localhost";
            context.EnvironmentVariables["RABBITMQ_NODENAME"] = nodeName;
        });
    }

    return builder;
}

A végrehajtási környezetet gyakran használják a meglévő erőforrásokra mutató erőforrások vagy kapcsolati sztringek feltételes hozzáadására. Tekintse meg az alábbi példát, amely bemutatja, hogy a végrehajtási környezet alapján feltételesen adhat hozzá Redis vagy kapcsolati sztringet:

var builder = DistributedApplication.CreateBuilder(args);

var redis = builder.ExecutionContext.IsRunMode
    ? builder.AddRedis("redis")
    : builder.AddConnectionString("redis");

builder.AddProject<Projects.WebApplication>("api")
       .WithReference(redis);

builder.Build().Run();

Az előző kódban:

• Ha az alkalmazásgazda "futtatás" módban fut, a rendszer hozzáad egy Redis tárolóerőforrást.
• Ha az alkalmazás gazdagépe "közzétételi" módban fut, a rendszer hozzáad egy kapcsolati karakterláncot.

Ez a logika egyszerűen fordítható úgy, hogy helyi futtatáskor egy meglévő Redis-erőforráshoz csatlakozzon, és közzétételkor hozzon létre egy új Redis erőforrást.

Erőforrás-kapcsolatok

Az erőforrás-kapcsolatok összekapcsolják az erőforrásokat. A kapcsolatok tájékoztató jellegűek, és nem befolyásolják az alkalmazások futásidejének működését. Ehelyett az irányítópulton lévő erőforrások részleteinek megjelenítésekor használják őket. A kapcsolatok például láthatók az irányítópult erőforrásainak részleteiben, és Parent kapcsolatok irányítják az erőforrások beágyazását az erőforrások oldalán.

Egyes alkalmazásmodell API-k automatikusan létrehoznak kapcsolatokat. Például:

• WithReference Referencetípusú kapcsolatot ad hozzá a célerőforráshoz.
• WaitFor WaitFortípusú kapcsolatot ad hozzá a célerőforráshoz.
• Ha adatbázist ad hozzá egy ADATBÁZIS-tárolóhoz, azzal kapcsolatot hoz létre az adatbázis és a tároló között Parenttípussal.

A kapcsolatok explicit módon is hozzáadhatók az alkalmazásmodellhez WithRelationship és WithParentRelationshiphasználatával.

var builder = DistributedApplication.CreateBuilder(args);

var catalogDb = builder.AddPostgres("postgres")
                       .WithDataVolume()
                       .AddDatabase("catalogdb");

builder.AddProject<Projects.AspireApp_CatalogDbMigration>("migration")
       .WithReference(catalogDb)
       .WithParentRelationship(catalogDb);

builder.Build().Run();

Az előző példa WithParentRelationship használatával konfigurálja catalogdb adatbázist a migration projekt szülőjeként. A Parent kapcsolat azért különleges, mert az erőforrás oldalon az erőforrások beágyazását vezérli. Ebben a példában a migration a catalogdbalá van ágyazva.

Lásd még:

• .NET .NET Aspire integráció áttekintése
• .NET .NET Aspire SDK
• Eseményezés a .NET.NET Aspire
• szolgáltatás-felderítés a .NET.NET Aspire
• .NET .NET Aspire szolgáltatás alapbeállításai
• Külső paraméterek kifejezése
• .NET .NET Aspire belső hurok hálózatkezelésének áttekintése