overzicht van .NET.NET Aspire orkestratie

Artikel
12/15/2024

.NET .NET Aspire biedt API's voor het uitdrukken van resources en afhankelijkheden binnen uw gedistribueerde toepassing. Naast deze API's is er een hulpprogramma waarmee verschillende aantrekkelijke scenario's mogelijk worden gemaakt. De orchestrator is bedoeld voor lokale ontwikkeling doeleinden en wordt niet ondersteund in productieomgevingen.

Voordat u verdergaat, moet u rekening houden met een aantal algemene terminologie die wordt gebruikt in .NET.NET Aspire:

app-model: een verzameling resources waaruit uw gedistribueerde toepassing (DistributedApplication) bestaat die is gedefinieerd in de Aspire.Hosting.ApplicationModel naamruimte. Voor een meer formele definitie, zie Het app-model definiëren.
App-host-/Orchestrator-project: het .NET project dat het app-modelorkestreert, met de naam met de *.AppHost als achtervoegsel (volgens conventie).
Resource: een resource is een afhankelijk onderdeel van een toepassing, zoals een .NET project, container, uitvoerbaar bestand, database, cache of cloudservice. Het vertegenwoordigt elk deel van de toepassing dat beheerd of waarnaar verwezen kan worden.
Integratie: Een integratie is een NuGet-pakket voor de app-host die een resource modelleert of een pakket dat een client configureert voor gebruik in een applicatie. Zie .NET.NET Aspire overzicht van integratiesvoor meer informatie.
Referentie: een verwijzing definieert een verbinding tussen resources, uitgedrukt als een afhankelijkheid met behulp van de WithReference-API. Zie voor meer informatie Referentiematerialen of Bestaande materialen.

Notitie

.NET .NET Aspireorkestratie is ontworpen om uw lokale ontwikkeling ervaring te optimaliseren door het beheer van de configuratie en verbindingen van uw cloud-native app te vereenvoudigen. Hoewel het een waardevol hulpprogramma voor ontwikkeling is, is het niet bedoeld om productieomgevingssystemen zoals Kuberneteste vervangen, die speciaal zijn ontworpen om in die context uit te blinken.

Het app-model definiëren

.NET .NET Aspire kunt u naadloos uw gedistribueerde toepassingen bouwen, inrichten, implementeren, configureren, testen, uitvoeren en observeren. Al deze mogelijkheden worden bereikt door gebruik te maken van een app-model waarin de resources in uw .NET.NET Aspire oplossing en hun relaties worden beschreven. Deze resources omvatten projecten, uitvoerbare bestanden, containers en externe services en cloudresources waarop uw app afhankelijk is. Binnen elke .NET.NET Aspire oplossing is er een aangewezen App-hostproject, waarbij het app-model nauwkeurig is gedefinieerd met behulp van methoden die beschikbaar zijn op de IDistributedApplicationBuilder. Deze bouwer wordt verkregen door DistributedApplication.CreateBuilderaan te roepen.

// 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();

App-hostproject

Het app-hostproject verwerkt het uitvoeren van alle projecten die deel uitmaken van het .NET.NET Aspire project. Met andere woorden, het is verantwoordelijk voor het organiseren van alle apps binnen het app-model. Het project zelf is een .NET uitvoerbaar project dat verwijst naar de 📦Aspire. Hosting.AppHost NuGet-pakket, stelt de eigenschap IsAspireHost in op trueen verwijst naar de .NET.NET Aspire SDK:

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

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

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

    <!-- Omitted for brevity -->

</Project>

De volgende code beschrijft een app-host Program met twee projectverwijzingen en een Redis-cache:

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();

De voorgaande code:

Hiermee maakt u een nieuwe opbouwfunctie voor app-modellen met behulp van de methode CreateBuilder.
Hiermee wordt een Rediscache resource met de naam 'cache' toegevoegd met behulp van de methode AddRedis.
Hiermee voegt u een projectresource met de naam 'apiservice' toe met behulp van de methode AddProject.
Hiermee voegt u een projectresource met de naam webfrontend toe met behulp van de methode AddProject.
- Hiermee geeft u op dat het project externe HTTP-eindpunten heeft met behulp van de methode WithExternalHttpEndpoints.
- Voegt een verwijzing toe naar de cache resource en wacht tot deze gereed is met behulp van de WithReference en WaitFor methoden.
- Voegt een verwijzing toe naar de apiservice resource en wacht tot deze gereed is met behulp van de WithReference en WaitFor methoden.
Bouwt en voert het app-model uit met behulp van de Build- en Run-methoden.

De voorbeeldcode maakt gebruik van de .NET AspireRedis hostingintegratie.

Bekijk het volgende diagram om de relatie tussen het app-hostproject en de resources die worden beschreven te visualiseren:

Elke resource moet een unieke naam hebben. In dit diagram ziet u elke resource en de relaties ertussen. De containerresource heet 'cache' en de projectresources hebben de naam 'apiservice' en 'webfrontend'. Het webfront-endproject verwijst naar de cache- en API-serviceprojecten. Wanneer u op deze manier verwijzingen uitdrukt, zegt het webfront-endproject dat het afhankelijk is van deze twee resources, respectievelijk de 'cache' en 'apiservice'.

Ingebouwde resourcetypen

.NET .NET Aspire projecten bestaan uit een set middelen. De primaire basisresourcetypen in de 📦Aspire. Hosting.AppHost NuGet-pakket wordt beschreven in de volgende tabel:

Methode	Type bron	Beschrijving
AddProject	ProjectResource	Een .NET-project, bijvoorbeeld een ASP.NET Core-web-app.
AddContainer	ContainerResource	Een containerimage, zoals een Docker-image.
AddExecutable	ExecutableResource	Een uitvoerbaar bestand, zoals een Node.js-app.
AddParameter	ParameterResource	Een parameterresource die kan worden gebruikt om externe parameters uit te drukken .

Projectbronnen vertegenwoordigen .NET projecten die deel uitmaken van het app-model. Wanneer u een projectreferentie toevoegt aan het app-hostproject, genereert de .NET.NET Aspire SDK een type in de Projects-naamruimte voor elk project waarnaar wordt verwezen. Zie .NET.NET Aspire SDK voor meer informatie: Projectverwijzingen.

Als u een project wilt toevoegen aan het app-model, gebruikt u de methode AddProject:

var builder = DistributedApplication.CreateBuilder(args);

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

Projecten kunnen worden gerepliceerd en uitgeschaald door meerdere exemplaren van hetzelfde project toe te voegen aan het app-model. Gebruik de methode WithReplicas om replica's te configureren:

var builder = DistributedApplication.CreateBuilder(args);

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

Met de voorgaande code worden drie replica's van de projectresource 'apiservice' toegevoegd aan het app-model. Zie .NET.NET Aspire dashboard: Resourcereplica'svoor meer informatie.

Referentiebronnen

Een verwijzing vertegenwoordigt een afhankelijkheid tussen bronnen. U kunt zich bijvoorbeeld een scenario voorstellen waarbij een webfront-end afhankelijk is van een Redis cache. Bekijk de volgende voorbeeld-app-host Program C#-code:

var builder = DistributedApplication.CreateBuilder(args);

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

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

De projectresource 'webfrontend' maakt gebruik van WithReference om een afhankelijkheid toe te voegen van de containerresource 'cache'. Deze afhankelijkheden kunnen verbindingsreeksen of servicedetectie informatie vertegenwoordigen. In het voorgaande voorbeeld wordt een omgevingsvariabele geïnjecteerd in de resource 'webfrontend' met de naam ConnectionStrings__cache. Deze omgevingsvariabele bevat een verbindingsreeks die de webfrontend gebruikt om verbinding te maken met Redis via de .NET AspireRedis-integratie, bijvoorbeeld ConnectionStrings__cache="localhost:62354".

Wachten op middelen

In sommige gevallen wilt u wellicht wachten totdat een resource gereed is voordat u een andere resource start. U kunt bijvoorbeeld wachten totdat een database gereed is voordat u een API start die ervan afhankelijk is. Als u deze afhankelijkheid wilt uitdrukken, gebruikt u de methode WaitFor:

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);

In de voorgaande code wacht de projectresource 'apiservice' totdat de postgresdb-databaseresource in de staat KnownResourceStates.Runningkomt. In de voorbeeldcode ziet u de .NET AspirePostgreSQL integratie, maar hetzelfde patroon kan worden toegepast op andere resources.

In andere gevallen kan het nodig zijn om te wachten tot een resource is voltooid, of dat nu KnownResourceStates.Exited of KnownResourceStates.Finished is, voordat de afhankelijke resource start. Als u wilt wachten totdat een resource is voltooid, gebruikt u de methode WaitForCompletion:

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);

In de voorgaande code wacht de projectresource 'apiservice' totdat de projectresource 'migratie' is voltooid voordat deze wordt gestart. De projectresource 'migratie' wacht tot de postgresdb-databaseresource de status KnownResourceStates.Runningbereikt. Dit kan handig zijn in scenario's waarin u bijvoorbeeld een databasemigratie wilt uitvoeren voordat u de API-service start.

API's voor het toevoegen en uitdrukken van resources

.NET .NET Aspire hostingintegraties en client integraties beide worden geleverd als NuGet-pakketten, maar ze dienen verschillende doeleinden. Hoewel client integratiesclient bibliotheekconfiguratie bieden voor het gebruik van apps buiten het bereik van de app-host, hostingintegraties API's bieden voor het uitdrukken van resources en afhankelijkheden binnen de app-host. Zie .NET.NET Aspire overzicht van integraties voor meer informatie: Integratieverantwoordelijkheden.

Express-containerresources

Als u een ContainerResource wilt uitdrukken, voegt u deze toe aan een IDistributedApplicationBuilder exemplaar door de methode AddContainer aan te roepen:

Docker
Podman

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");

Zie GPU-ondersteuning in Docker Desktopvoor meer informatie.

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");

Zie GPU-ondersteuning in Podmanvoor meer informatie.

Met de voorgaande code wordt een containerresource met de naam 'ollama' toegevoegd met de afbeelding ollama/ollama. De containerresource is geconfigureerd met meerdere bindingskoppelingen, een benoemd HTTP-eindpunt, een invoerpunt dat wordt omgezet in Unix shellscript en argumenten voor het uitvoeren van containers met de WithContainerRuntimeArgs methode.

Containerbronnen aanpassen

Alle ContainerResource subklassen kunnen worden aangepast om te voldoen aan uw specifieke vereisten. Dit kan handig zijn bij het gebruik van een hostingintegratie die een containerresource modellt, maar wijzigingen vereist. Wanneer u een IResourceBuilder<ContainerResource> heeft, kunt u oproepen met elkaar verbinden naar een van de beschikbare API's om de containerbron aan te passen. .NET .NET Aspire containerbronnen verwijzen meestal naar gepinde tags, maar je kunt in plaats daarvan de latest tag gebruiken.

Om dit te illustreren, stelt u zich een scenario voor waarin u de .NET AspireRedis-integratiegebruikt. Als de Redis-integratie afhankelijk is van de 7.4-tag en u in plaats daarvan de latest-tag wilt gebruiken, kunt u een aanroep koppelen aan de WithImageTag-API:

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.

Zie ContainerResourceBuilderExtensionsvoor meer informatie en aanvullende API's.

Levenscyclus van containerresources

Wanneer de app host wordt uitgevoerd, wordt de ContainerResource gebruikt om te bepalen welke containerimage moet worden gemaakt en gestart. Onder de motorkap voert .NET Aspire de container uit met behulp van de gedefinieerde containerimage door oproepen te delegeren naar de juiste OCI-compatibele containerruntime, hetzij Docker of Podman. De volgende opdrachten worden gebruikt:

Docker
Podman

Eerst wordt de container gemaakt met behulp van de opdracht docker container create. Vervolgens wordt de container gestart met behulp van de opdracht docker container start.

docker container maakt: Hiermee maakt u een nieuwe container aan op basis van de opgegeven image, zonder deze te starten.
docker container starten: een of meer gestopte containers starten.

Deze opdrachten worden gebruikt in plaats van docker run voor het beheren van gekoppelde containernetwerken, volumes en poorten. Als u deze opdrachten in deze volgorde aanroept, kan elk IP-adres (netwerkconfiguratie) al aanwezig zijn bij het opstarten.

Eerst wordt de container gemaakt met behulp van de opdracht podman container create. Vervolgens wordt de container gestart met behulp van de opdracht podman container start.

podman container maken: Hiermee maakt u een beschrijfbare containerlaag boven de opgegeven afbeelding en bereidt u deze voor op uitvoering.
podman container starten: een of meer gestopte containers starten.

Deze opdrachten worden gebruikt in plaats van podman run voor het beheren van gekoppelde containernetwerken, volumes en poorten. Als u deze opdrachten in deze volgorde aanroept, kan elk IP-adres (netwerkconfiguratie) al aanwezig zijn bij het opstarten.

Naast de basisresourcetypen, ProjectResource, ContainerResourceen ExecutableResourcebiedt .NET.NET Aspire uitbreidingsmethoden voor het toevoegen van algemene resources aan uw app-model. Zie Hosting-integratiesvoor meer informatie.

Levensduur van een containerresource

Containerbronnen maken standaard gebruik van de levensduur van de sessie container. Dit betekent dat telkens wanneer het app-hostproces wordt gestart, de container wordt gemaakt en gestart. Wanneer de app-host stopt, wordt de container gestopt en verwijderd. Containerbronnen kunnen zich aanmelden voor een permanente levensduur om onnodig opnieuw opstarten te voorkomen en permanente containerstatus te gebruiken. Om dit te bereiken, koppelt u een aanroep van de ContainerResourceBuilderExtensions.WithLifetime-API en geeft u ContainerLifetime.Persistentdoor:

var builder = DistributedApplication.CreateBuilder(args);

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

Met de voorgaande code wordt een containerresource met de naam 'ollama' met de afbeelding 'ollama/ollama' en een permanente levensduur toegevoegd.

Verbindingsreeks en eindpunt-referenties

Het is gebruikelijk om afhankelijkheden tussen projectresources uit te drukken. Bekijk de volgende voorbeeldcode:

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);

Project-naar-projectverwijzingen worden anders verwerkt dan resources met goed gedefinieerde verbindingsreeksen. In plaats van de verbindingsreeks die wordt geïnjecteerd in de 'webfrontend'-resource, worden omgevingsvariabelen ter ondersteuning van servicedetectie geïnjecteerd.

Methode	Omgevingsvariabele
`WithReference(cache)`	`ConnectionStrings__cache="localhost:62354"`
`WithReference(apiservice)`	`services__apiservice__http__0="http://localhost:5455"` `services__apiservice__https__0="https://localhost:7356"`

Als u een verwijzing toevoegt naar het 'apiservice'-project, worden omgevingsvariabelen voor servicedetectie toegevoegd aan de front-end. Dit komt omdat project-naar-project-communicatie doorgaans plaatsvindt via HTTP/gRPC. Zie .NET.NET Aspire servicedetectievoor meer informatie.

Als u specifieke eindpunten wilt ophalen uit een ContainerResource of een ExecutableResource, gebruikt u een van de volgende eindpunt-API's:

Roep vervolgens de GetEndpoint-API aan om het eindpunt op te halen dat kan worden gebruikt om te verwijzen naar het eindpunt in de methode WithReference:

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);

Methode	Omgevingsvariabele
`WithReference(endpoint)`	`services__myapp__endpoint__0=https://localhost:9043`

De parameter port is de poort waarop de container luistert. Zie Containerpoortenvoor meer informatie over containerpoorten. Zie .NET.NET Aspire servicedetectievoor meer informatie over servicedetectie.

Omgevingsvariabeleindeling voor service-eindpunten

In de voorgaande sectie wordt de WithReference methode gebruikt om afhankelijkheden tussen resources uit te drukken. Wanneer service-eindpunten ertoe leiden dat omgevingsvariabelen worden geïnjecteerd in de afhankelijke resource, is de indeling mogelijk niet duidelijk. In deze sectie vindt u meer informatie over deze indeling.

Wanneer de ene resource afhankelijk is van een andere resource, injecteert de app-host omgevingsvariabelen in de afhankelijke resource. Deze omgevingsvariabelen configureren de afhankelijke resource om verbinding te maken met de resource die ervan afhankelijk is. De indeling van de omgevingsvariabelen is specifiek voor het .NET.NET Aspire en expresseert service-eindpunten op een manier die compatibel is met Service Discovery-.

Namen van omgevingsvariabelen voor service-eindpunten worden voorafgegaan door services__ (dubbele onderstrepingsteken), vervolgens de servicenaam, de eindpuntnaam en ten slotte de index. De index ondersteunt meerdere eindpunten voor één service, te beginnen met 0 voor het eerste eindpunt en incrementeren voor elk eindpunt.

Bekijk de volgende voorbeelden van omgevingsvariabelen:

services__apiservice__http__0

De voorgaande omgevingsvariabele geeft het eerste HTTP-eindpunt voor de apiservice-service weer. De waarde van de omgevingsvariabele is de URL van het service-eindpunt. Een benoemd eindpunt kan als volgt worden uitgedrukt:

services__apiservice__myendpoint__0

In het voorgaande voorbeeld heeft de apiservice-service een benoemd eindpunt met de naam myendpoint. De waarde van de omgevingsvariabele is de URL van het service-eindpunt.

Verwijzen naar bestaande resources

Sommige situaties rechtvaardigen dat u naar een bestaande resource verwijst, misschien naar een resource die is geïmplementeerd in een cloudprovider. U kunt bijvoorbeeld verwijzen naar een Azure-database. In dit geval bent u afhankelijk van de uitvoeringscontext om dynamisch te bepalen of de app-host wordt uitgevoerd in de modus Uitvoeren of Publiceren. Als u lokaal werkt en wilt vertrouwen op een cloudresource, kunt u de eigenschap IsRunMode gebruiken om de verwijzing voorwaardelijk toe te voegen. U kunt ervoor kiezen om in plaats daarvan de resource te maken in de publicatiemodus. Sommige hostingintegraties ondersteunen het rechtstreeks bieden van een verbindingstekst, die kan worden gebruikt om te verwijzen naar een bestaande resource.

Op dezelfde manier kunnen er gebruiksvoorbeelden zijn waarin u .NET.NET Aspire wilt integreren in een bestaande oplossing. Een veelvoorkomende benadering is het toevoegen van het .NET.NET Aspire app-hostproject aan een bestaande oplossing. Binnen uw app-host drukt u afhankelijkheden uit door projectverwijzingen toe te voegen aan de app-host en het app-model uit te bouwen. Het ene project kan bijvoorbeeld afhankelijk zijn van een ander project. Deze afhankelijkheden worden uitgedrukt met behulp van de methode WithReference. Zie .NET Aspire toevoegen aan een bestaande .NET-appvoor meer informatie.

Levenscyclus van app-host

De .NET.NET Aspire app-host bevat verschillende levenscycli waarmee u zich kunt verbinden door de IDistributedApplicationLifecycleHook-interface te implementeren. De volgende levenscyclusmethoden zijn beschikbaar:

Bevelen	Methode	Beschrijving
1	BeforeStartAsync	Wordt uitgevoerd voordat de gedistribueerde toepassing wordt gestart.
2	AfterEndpointsAllocatedAsync	Wordt uitgevoerd nadat de orchestrator eindpunten toewijst voor resources in het toepassingsmodel.
3	AfterResourcesCreatedAsync	Wordt uitgevoerd nadat de resource is gemaakt door de orchestrator.

Hoewel de app-host levenscyclushaken biedt, wilt u wellicht aangepaste gebeurtenissen registreren. Zie Eventing in .NET.NET Aspirevoor meer informatie.

Een levenscyclushook registreren

Als u een levenscyclushook wilt registreren, implementeert u de IDistributedApplicationLifecycleHook-interface en registreert u de hook bij de app-host met behulp van de AddLifecycleHook-API:

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;
    }
}

De voorgaande code:

Implementeert de IDistributedApplicationLifecycleHook interface als een LifecycleLogger.
Registreert de levenscyclushook bij de app-host met behulp van de AddLifecycleHook-API.
Registreert een bericht voor alle gebeurtenissen.

Wanneer deze applicatiehost wordt uitgevoerd, wordt de levenscyclusfunctie voor elke gebeurtenis uitgevoerd. De volgende uitvoer wordt gegenereerd:

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.

De voorkeursmethode voor het koppelen aan de levenscyclus van de app-host is het gebruik van de eventing-API. Zie Eventing in .NET.NET Aspirevoor meer informatie.

Uitvoeringscontext

De IDistributedApplicationBuilder geeft een uitvoeringscontext (DistributedApplicationExecutionContext) weer die informatie biedt over de huidige uitvoering van de app-host. Deze context kan worden gebruikt om te evalueren of de app-host wordt uitgevoerd als 'run'-modus of als onderdeel van een publicatiebewerking. Houd rekening met de volgende eigenschappen:

IsRunMode: retourneert true als de huidige bewerking wordt uitgevoerd.
IsPublishMode: retourneert true als de huidige bewerking wordt gepubliceerd.

Deze informatie kan handig zijn als u code voorwaardelijk wilt uitvoeren op basis van de huidige bewerking. Bekijk het volgende voorbeeld dat laat zien hoe u de eigenschap IsRunMode gebruikt. In dit geval wordt een extensiemethode gebruikt om een stabiele knooppuntnaam te genereren voor RabbitMQ voor lokale ontwikkelingsuitvoeringen.

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;
}

De uitvoeringscontext wordt vaak gebruikt om resources of verbindingsreeksen voorwaardelijk toe te voegen die verwijzen naar bestaande resources. Bekijk het volgende voorbeeld met het voorwaardelijk toevoegen van Redis of een verbindingsreeks op basis van de uitvoeringscontext:

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();

In de voorgaande code:

Als de app-host wordt uitgevoerd in de uitvoeringsmode, wordt er een Redis containerresource toegevoegd.
Als de app-host wordt uitgevoerd in de modus Publiceren, wordt er een verbindingsreeks toegevoegd.

Deze logica kan eenvoudig worden omgekeerd om verbinding te maken met een bestaande Redis-resource wanneer u lokaal werkt en een nieuwe Redis resource te maken wanneer u publiceert.

Belangrijk

.NET .NET Aspire biedt algemene API's voor het beheren van de modaliteit van resourcebouwers, zodat resources zich anders kunnen gedragen op basis van de uitvoeringsmodus. De fluent-API's worden voorafgegaan door RunAs* en PublishAs*. De RunAs* API's beïnvloeden het gedrag van lokale ontwikkeling (of uitvoeringsmodus), terwijl de PublishAs* API's invloed hebben op het publiceren van de resource.

Delen via