Condividi tramite

.NET .NET Aspire panoramica dell'orchestrazione

  • Articolo

.NET .NET Aspire fornisce API per esprimere risorse e dipendenze all'interno dell'applicazione distribuita. Oltre a queste API, sono disponibili strumenti che consentono diversi scenari accattivanti. L'orchestratore è destinato a scopi di sviluppo locale e non è supportato negli ambienti di produzione.

Prima di continuare, prendere in considerazione una terminologia comune usata in .NET.NET Aspire:

  • Modello di app: raccolta di risorse che costituiscono l'applicazione distribuita (DistributedApplication), definita all'interno dello spazio dei nomi Aspire.Hosting.ApplicationModel. Per una definizione più formale, vedere Definire il modello di app.
  • progetto Host app/Orchestrator: progetto di .NET che orchestra il modello di app , denominato con il *. Suffisso appHost (per convenzione).
  • risorsa: una risorsa è una parte dipendente di un'applicazione, ad esempio un progetto .NET, un contenitore, un eseguibile, un database, una cache o un servizio cloud. Rappresenta qualsiasi parte dell'applicazione che può essere gestita o a cui si fa riferimento.
  • Integrazione: un'integrazione è un pacchetto NuGet per l'host dell'app che modella una risorsa oppure un pacchetto che configura un client per l'uso in un'applicazione di consumo. Per altre informazioni, vedere panoramica delle integrazioni .NET.NET Aspire.
  • riferimento: un riferimento definisce una connessione tra le risorse, espressa come dipendenza usando l'API WithReference. Per altre informazioni, vedere Risorse di riferimento o Fare riferimento alle risorse esistenti.

Nota

.NETL'orchestrazione di.NET Aspireè progettata per migliorare l'esperienza di sviluppo locale semplificando la gestione della configurazione e delle interconnessioni della tua applicazione nativa del cloud. Anche se è uno strumento prezioso per lo sviluppo, non è progettato per sostituire sistemi di ambiente di produzione come Kubernetes, progettati specificamente per eccellere in tale contesto.

Definire il modello di app

.NET .NET Aspire consente di compilare, effettuare facilmente il provisioning, distribuire, configurare, testare, eseguire e osservare le applicazioni distribuite. Tutte queste funzionalità vengono ottenute tramite l'utilizzo di un modello di app che delinea le risorse nella soluzione .NET.NET Aspire e le relative relazioni. Queste risorse includono progetti, eseguibili, contenitori e servizi esterni e risorse cloud da cui dipende l'app. All'interno di ogni soluzione .NET.NET Aspire è presente un progetto host dell'app designato, in cui il modello di app è definito con precisione usando i metodi disponibili nel IDistributedApplicationBuilder. Questo generatore viene ottenuto richiamando DistributedApplication.CreateBuilder.

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

Progetto host dell'app

Il progetto host dell'app gestisce l'esecuzione di tutti i progetti che fanno parte del progetto .NET.NET Aspire. In altre parole, è responsabile dell'orchestrazione di tutte le app all'interno del modello di app. Il progetto stesso è un progetto eseguibile .NET che fa riferimento al pacchetto NuGet 📦Aspire.Hosting.AppHost, imposta la proprietà IsAspireHost su truee si riferisce all'SDK .NET.NET Aspire.

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

Il codice seguente descrive un host dell'app Program con due riferimenti al progetto e una cache Redis:

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

Il codice precedente:

  • Crea un nuovo generatore di modelli di app usando il metodo CreateBuilder.
  • Aggiunge una risorsa Rediscache denominata "cache" usando il metodo AddRedis.
  • Aggiunge una risorsa di progetto denominata "apiservice" usando il metodo AddProject.
  • Aggiunge una risorsa di progetto denominata "webfrontend" usando il metodo AddProject.
    • Specifica che il progetto dispone di endpoint HTTP esterni usando il metodo WithExternalHttpEndpoints.
    • Aggiunge un riferimento alla risorsa cache e attende che sia pronto usando i metodi WithReference e WaitFor.
    • Aggiunge un riferimento alla risorsa apiservice e attende che sia pronto usando i metodi WithReference e WaitFor.
  • Compila ed esegue il modello di app usando i metodi Build e Run.

Il codice di esempio usa l'integrazione dell'hosting .NET AspireRedis.

Per visualizzare la relazione tra il progetto host dell'app e le risorse descritte, considerare il diagramma seguente:

La relazione tra i progetti nel modello di applicazione iniziale di .NET.NET Aspire.

Ogni risorsa deve essere denominata in modo univoco. Questo diagramma mostra ogni risorsa e le relazioni tra di esse. La risorsa contenitore è denominata "cache" e le risorse del progetto sono denominate "apiservice" e "webfrontend". Il progetto front-end Web fa riferimento ai progetti della cache e del servizio API. Quando si esprimono riferimenti in questo modo, il progetto frontend web dichiara che dipende rispettivamente da queste due risorse: la "cache" e "apiservice".

Tipi di risorse predefiniti

I progetti .NETe.NET Aspire sono costituiti da un insieme di risorse. Tipi primari di risorse di base nel pacchetto NuGet 📦Aspire.Hosting.AppHost sono descritti nella tabella seguente.

Metodo Tipo di risorsa Descrizione
AddProject ProjectResource Un progetto .NET, ad esempio un'app Web ASP.NET Core.
AddContainer ContainerResource Immagine del contenitore, ad esempio un'immagine Docker.
AddExecutable ExecutableResource Un file eseguibile, ad esempio un'app Node.js.
AddParameter ParameterResource Risorsa di parametro che può essere usata per esprimere i parametri esterni.

Le risorse del progetto rappresentano .NET progetti che fanno parte del modello di app. Quando si aggiunge un riferimento al progetto host dell'app, .NET.NET Aspire SDK genera un tipo nello spazio dei nomi Projects per ogni progetto a cui si fa riferimento. Per altre informazioni, vedere .NET.NET Aspire SDK: Riferimenti ai progetti.

Per aggiungere un progetto al modello di app, usare il metodo AddProject:

var builder = DistributedApplication.CreateBuilder(args);

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

I progetti possono essere replicati e ridimensionati aggiungendo più istanze dello stesso progetto al modello di app. Per configurare le repliche, usare il metodo WithReplicas:

var builder = DistributedApplication.CreateBuilder(args);

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

Il codice precedente aggiunge tre repliche della risorsa di progetto "apiservice" al modello di app. Per altre informazioni, vedere dashboard .NET.NET Aspire: Repliche di risorse.

Risorse di riferimento

Un riferimento rappresenta una dipendenza tra le risorse. Ad esempio, è possibile immaginare uno scenario in cui un front-end Web dipende da una cache Redis. Si consideri il seguente host di esempio dell'app, codice C# Program:

var builder = DistributedApplication.CreateBuilder(args);

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

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

La risorsa di progetto "webfrontend" usa WithReference per aggiungere una dipendenza dalla risorsa contenitore "cache". Queste dipendenze possono rappresentare stringhe di connessione o informazioni sull'individuazione dei servizi. Nell'esempio precedente una variabile di ambiente viene inserita nella risorsa "webfronend" con il nome ConnectionStrings__cache. Questa variabile di ambiente contiene una stringa di connessione usata dal webfrontend per connettersi a Redis tramite l'integrazione .NET AspireRedis, ad esempio ConnectionStrings__cache="localhost:62354".

In attesa di risorse

In alcuni casi, potrebbe essere necessario attendere che una risorsa sia pronta prima di avviare un'altra risorsa. Ad esempio, potrebbe essere necessario attendere che un database sia pronto prima di avviare un'API che ne dipende. Per esprimere questa dipendenza, usare il metodo 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);

Nel codice precedente, la risorsa di progetto "apiservice" attende che la risorsa di database "postgresdb" entri nello stato KnownResourceStates.Running. Il codice di esempio mostra l'integrazione .NET AspirePostgreSQL, ma lo stesso modello può essere applicato ad altre risorse.

In alcuni casi potrebbe essere giustificato attendere che una risorsa, KnownResourceStates.Exited o KnownResourceStates.Finished, sia completata prima di avviare la risorsa dipendente. Per attendere il completamento di una risorsa, usare il metodo 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);

Nel codice precedente la risorsa di progetto "apiservice" attende che la risorsa di progetto "migrazione" venga eseguita fino al completamento prima dell'avvio. La risorsa di progetto "migrazione" attende che la risorsa di database "postgresdb" entri nel KnownResourceStates.Running. Ciò può essere utile negli scenari in cui si vuole eseguire una migrazione del database prima di avviare il servizio API, ad esempio.

API per l'aggiunta e l'espressione di risorse

.NET .NET Aspire le integrazioni di hosting e le integrazioni di client vengono entrambe distribuite come pacchetti NuGet, ma servono scopi diversi. Mentre le integrazioni client forniscono la configurazione della libreria client per l'utilizzo di app al di fuori dell'ambito dell'host dell'app, le integrazioni di hosting forniscono API per esprimere risorse e dipendenze all'interno dell'host dell'app. Per altre informazioni, vedere panoramica delle integrazioni di .NET.NET Aspire: Responsabilità di integrazione.

Risorse del contenitore Express

Per esprimere un ContainerResource, aggiungilo a un'istanza di IDistributedApplicationBuilder tramite il metodo AddContainer.

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

Per ulteriori informazioni, vedere il supporto GPU in Docker Desktop.

Il codice precedente aggiunge una risorsa container chiamata "ollama" con l'immagine ollama/ollama. La risorsa contenitore è configurata con diversi bind mounts, un endpoint HTTP nominato, un entry point che punta allo script di shell Unix e argomenti di esecuzione del contenitore utilizzando il metodo WithContainerRuntimeArgs.

Personalizzare le risorse del contenitore

Tutte le sottoclassi ContainerResource possono essere personalizzate per soddisfare i requisiti specifici. Può risultare utile quando si utilizza un'integrazione dell'hosting che modella una risorsa di contenitore, ma richiede modifiche. Quando si dispone di un IResourceBuilder<ContainerResource> è possibile concatenare le chiamate a una qualsiasi delle API disponibili per modificare la risorsa contenitore. .NET .NET Aspire risorse del contenitore in genere puntano a tag bloccati, ma potrebbe essere consigliabile usare invece il tag latest.

Per aiutare a esemplificare questo, si immagini uno scenario in cui si utilizza l'integrazione .NET AspireRedis. Se l'integrazione Redis si basa sul tag 7.4 e si vuole usare invece il tag latest, è possibile concatenare una chiamata all'API WithImageTag:

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.

Per altre informazioni e altre API disponibili, vedere ContainerResourceBuilderExtensions.

Ciclo di vita delle risorse del contenitore

Quando viene eseguito l'host dell'app, il ContainerResource viene usato per determinare l'immagine del contenitore da creare e avviare. In background, .NET Aspire esegue il contenitore usando l'immagine del contenitore definita delegando le chiamate al runtime del contenitore conforme a OCI appropriato, Docker o Podman. Vengono usati i comandi seguenti:

Prima di tutto, il contenitore viene creato usando il comando docker container create. Il contenitore viene quindi avviato usando il comando docker container start.

Questi comandi vengono usati invece di docker run per gestire le reti, i volumi e le porte dei contenitori collegati. La chiamata a questi comandi in questo ordine consente a qualsiasi IP (configurazione di rete) di essere già presente all'avvio iniziale.

Oltre ai tipi di risorse di base, ProjectResource, ContainerResourcee ExecutableResource, .NET.NET Aspire fornisce metodi di estensione per aggiungere risorse comuni al modello di app. Per altre informazioni, vedere Integrazioni di hosting.

Durata delle risorse del contenitore

Per impostazione predefinita, le risorse del contenitore usano la durata della sessione del contenitore. Ciò significa che ogni volta che viene avviato il processo host dell'app, il contenitore viene creato e avviato. Quando l'host dell'app si ferma, il contenitore viene fermato e rimosso. Le risorse del contenitore possono acconsentire esplicitamente a un durata permanente per evitare riavvii non necessari e usare lo stato del contenitore persistente. A tale scopo, concatenare la chiamata all'API ContainerResourceBuilderExtensions.WithLifetime e passare il parametro ContainerLifetime.Persistent:

var builder = DistributedApplication.CreateBuilder(args);

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

Il codice precedente aggiunge un contenitore di risorse denominato "ollama" con l'immagine "ollama/ollama" e una durata persistente.

Riferimenti a stringhe di connessione ed endpoint

È comune esprimere le dipendenze tra le risorse del progetto. Si consideri il codice di esempio seguente:

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

I riferimenti da progetto a progetto vengono gestiti in modo diverso rispetto alle risorse con stringhe di connessione ben definite. Anziché inserire la stringa di connessione nella risorsa "webfrontend", le variabili di ambiente per supportare l'individuazione del servizio vengono inserite.

Metodo Variabile di ambiente
WithReference(cache) ConnectionStrings__cache="localhost:62354"
WithReference(apiservice) services__apiservice__http__0="http://localhost:5455"
services__apiservice__https__0="https://localhost:7356"

L'aggiunta di un riferimento al progetto "apiservice" comporta l'aggiunta di variabili di ambiente di individuazione dei servizi al front-end. Ciò è dovuto al fatto che, in genere, la comunicazione da progetto a progetto avviene tramite HTTP/gRPC. Per altre informazioni, vedere .NET.NET Aspire'individuazione del servizio.

Per ottenere endpoint specifici da un ContainerResource o da un ExecutableResource, usare una delle API endpoint seguenti:

Chiamare quindi l'API GetEndpoint per ottenere l'endpoint che può essere usato per fare riferimento all'endpoint nel metodo 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);
Metodo Variabile di ambiente
WithReference(endpoint) services__myapp__endpoint__0=https://localhost:9043

Il parametro port è la porta su cui il contenitore è in ascolto. Per ulteriori informazioni sui porti per container, vedere Porti per container. Per ulteriori informazioni sull'individuazione del servizio, vedere .NET.NET Aspire individuazione del servizio.

Formato della variabile di ambiente dell'endpoint di servizio

Nella sezione precedente il metodo WithReference viene usato per esprimere le dipendenze tra le risorse. Quando gli endpoint di servizio comportano l'inserimento di variabili di ambiente nella risorsa dipendente, il formato potrebbe non essere ovvio. Questa sezione fornisce informazioni dettagliate su questo formato.

Quando una risorsa dipende da un'altra risorsa, l'host dell'app inserisce le variabili di ambiente nella risorsa dipendente. Queste variabili di ambiente configurano la risorsa dipendente per connettersi alla risorsa dalla quale dipende. Il formato delle variabili di ambiente è specifico per .NET.NET Aspire ed esprime gli endpoint di servizio in modo compatibile con Individuazione servizi.

I nomi delle variabili di ambiente dell'endpoint di servizio hanno il prefisso services__ (doppio carattere di sottolineatura), quindi il nome del servizio, il nome dell'endpoint e infine l'indice. L'indice supporta più endpoint per un singolo servizio, a partire da 0 per il primo endpoint e incrementando per ciascun endpoint successivo.

Si considerino gli esempi di variabili di ambiente seguenti:

services__apiservice__http__0

La variabile di ambiente precedente esprime il primo endpoint HTTP per il servizio apiservice. Il valore della variabile di ambiente è l'URL dell'endpoint di servizio. Un endpoint denominato può essere espresso nel modo seguente:

services__apiservice__myendpoint__0

Nell'esempio precedente il servizio apiservice ha un endpoint denominato myendpoint. Il valore della variabile di ambiente è l'URL dell'endpoint di servizio.

Fare riferimento alle risorse esistenti

Alcune situazioni garantiscono di fare riferimento a una risorsa esistente, ad esempio una risorsa distribuita in un provider di servizi cloud. Ad esempio, è possibile fare riferimento a un database Azure. In questo caso, si fa affidamento sul contesto di esecuzione per determinare in modo dinamico se l'host dell'app è in esecuzione in modalità "run" o "publish". Se si esegue localmente e si vuole basarsi su una risorsa cloud, è possibile usare la proprietà IsRunMode per aggiungere in modo condizionale il riferimento. È possibile scegliere di creare la risorsa in modalità di pubblicazione. Alcune integrazioni di hosting supportano direttamente la fornitura di una stringa di connessione, che può essere usata per fare riferimento a una risorsa esistente.

Analogamente, potrebbero esserci casi d'uso in cui si vuole integrare .NET.NET Aspire in una soluzione esistente. Un approccio comune consiste nell'aggiungere il progetto host dell'applicazione .NET.NET Aspire a una soluzione esistente. All'interno dell'host dell'app è possibile esprimere le dipendenze aggiungendo riferimenti di progetto all'host dell'app e la compilazione del modello di app. Ad esempio, un progetto potrebbe dipendere da un altro. Queste dipendenze vengono espresse usando il metodo WithReference. Per altre informazioni, vedere Aggiungere .NET Aspire a un'app .NET esistente.

Cicli di vita dell'host dell'app

L'host dell'app .NET.NET Aspire espone diversi cicli di vita a cui è possibile collegarsi implementando l'interfaccia IDistributedApplicationLifecycleHook. Sono disponibili i metodi del ciclo di vita seguenti:

Ordine Metodo Descrizione
1 BeforeStartAsync Viene eseguito prima dell'avvio dell'applicazione distribuita.
2 AfterEndpointsAllocatedAsync Viene eseguito dopo che l'agente di orchestrazione alloca gli endpoint per le risorse nel modello di applicazione.
3 AfterResourcesCreatedAsync Si esegue dopo che la risorsa è stata creata dall'orchestratore.

Mentre l'host dell'app fornisce hook del ciclo di vita, potrebbe essere necessario registrare eventi personalizzati. Per ulteriori informazioni, consulta Eventing in .NET.NET Aspire.

Registrare un hook del ciclo di vita

Per registrare un hook del ciclo di vita, implementare l'interfaccia IDistributedApplicationLifecycleHook e registrare l'hook con l'host dell'app usando l'API AddLifecycleHook:

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

Il codice precedente:

Quando viene eseguito questo host dell'applicazione, viene eseguito un hook del ciclo di vita per ogni evento. Viene generato l'output seguente:

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.

Il modo preferito per eseguire l'hook nel ciclo di vita dell'host dell'app consiste nell'usare l'API di creazione di eventi. Per ulteriori informazioni, consulta Eventing in .NET.NET Aspire.

Contesto di esecuzione

Il IDistributedApplicationBuilder espone un contesto di esecuzione (DistributedApplicationExecutionContext), che fornisce informazioni sull'esecuzione corrente dell'host dell'applicazione. Questo contesto può essere usato per valutare se l'host dell'app è in esecuzione in modalità "run" o come parte di un'operazione di pubblicazione. Si considerino le proprietà seguenti:

  • IsRunMode: restituisce true se l'operazione corrente è in esecuzione.
  • IsPublishMode: restituisce true se l'operazione corrente è pubblicazione.

Queste informazioni possono essere utili quando si vuole eseguire codice in modo condizionale in base all'operazione corrente. Si consideri l'esempio seguente che illustra l'uso della proprietà IsRunMode. In questo caso, viene usato un metodo di estensione per generare un nome di nodo stabile per RabbitMQ per le esecuzioni di sviluppo locale.

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

Il contesto di esecuzione viene spesso usato per aggiungere in modo condizionale risorse o stringhe di connessione che puntano alle risorse esistenti. Si consideri l'esempio seguente che illustra l'aggiunta condizionale di Redis o una stringa di connessione in base al contesto di esecuzione:

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

Nel codice precedente:

  • Se l'host dell'app è in esecuzione in modalità "run", viene aggiunta una risorsa contenitore Redis.
  • Se l'host dell'app è in esecuzione in modalità "pubblicazione", viene aggiunta una stringa di connessione.

Questa logica può essere facilmente invertita per connettersi a una risorsa di Redis esistente quando si esegue localmente e creare una nuova risorsa Redis durante la pubblicazione.

Importante

.NET .NET Aspire fornisce API comuni per controllare la modalità dei generatori di risorse, consentendo alle risorse di comportarsi in modo diverso in base alla modalità di esecuzione. Le API Fluent sono precedute da RunAs* e PublishAs*. Le API RunAs* influenzano il comportamento di sviluppo locale (o modalità di esecuzione), mentre le API PublishAs* influenzano la pubblicazione della risorsa.

Vedere anche