Compartir a través de

Visión general de la orquestación de .NET.NET Aspire

  • Artículo

.NET .NET Aspire proporciona API para expresar recursos y dependencias dentro de la aplicación distribuida. Además de estas APIs, hay herramientas que habilitan varios escenarios interesantes. El orquestador está diseñado para de desarrollo local y no se admite en entornos de producción.

Antes de continuar, considere cierta terminología común que se usa en .NET.NET Aspire:

  • modelo de aplicación: colección de recursos que componen la aplicación distribuida (DistributedApplication), definida dentro del espacio de nombres Aspire.Hosting.ApplicationModel. Para obtener una definición más formal, consulte Definir el modelo de aplicación.
  • Proyecto de Host/Orquestador de Aplicación: el proyecto .NET que orquesta el modelo de aplicación , denominado con el sufijo *.AppHost (por convención).
  • Resource: un de recursos es una parte dependiente de una aplicación, como un proyecto de .NET, contenedor, ejecutable, base de datos, caché o servicio en la nube. Representa cualquier parte de la aplicación que se pueda administrar o hacer referencia a ella.
  • Integration: una integración es un paquete NuGet para el host de aplicación que modela un de recursos de o un paquete que configura un para su uso en una aplicación de consumo. Para obtener más información, consulte .NET.NET Aspire integrations overview.
  • Referencia: una referencia define una conexión entre recursos, expresada como una dependencia mediante la API de WithReference. Para obtener más información, vea Recursos de referencia o Referencia de recursos existentes.

Nota

.NETLa orquestación de.NET Aspireestá diseñada para mejorar la experiencia de desarrollo local simplificando la gestión de la configuración e interconexiones de tu aplicación nativa de la nube. Aunque es una herramienta inestimable para el desarrollo, no está pensada para reemplazar sistemas de entorno de producción como Kubernetes, que están diseñados específicamente para destacar en ese contexto.

Definición del modelo de aplicación

.NET .NET Aspire le permite compilar, aprovisionar, implementar, configurar, probar, ejecutar y observar las aplicaciones distribuidas sin problemas. Todas estas funcionalidades se logran mediante el uso de un modelo de aplicación de que describe los recursos de la solución de .NET.NET Aspire y sus relaciones. Estos recursos abarcan proyectos, ejecutables, contenedores y servicios externos y recursos en la nube de los que depende la aplicación. Dentro de cada solución .NET.NET Aspire, hay un proyecto host de aplicación designado , donde el modelo de aplicación se define con precisión mediante métodos disponibles en el IDistributedApplicationBuilder. Este constructor se obtiene invocando 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();

Proyecto host de aplicación

El proyecto host de la aplicación controla la ejecución de todos los proyectos que forman parte del proyecto de .NET.NET Aspire. En otras palabras, es responsable de orquestar todas las aplicaciones dentro del modelo de aplicación. El propio proyecto es un proyecto ejecutable .NET que hace referencia al paquete de NuGet 📦Aspire.Hosting.AppHost, establece la propiedad IsAspireHost en true, y hace referencia al SDK de .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>

En el código siguiente se describe un host de aplicación Program con dos referencias de proyecto y una caché de 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();

El código anterior:

  • Crea un nuevo generador de modelos de aplicaciones mediante el método CreateBuilder.
  • Agrega un recurso de Rediscache denominado "caché" mediante el método AddRedis.
  • Agrega un recurso de proyecto denominado "apiservice" mediante el método AddProject.
  • Agrega un recurso de proyecto denominado "webfrontend" mediante el método AddProject.
    • Especifica que el proyecto tiene puntos de conexión HTTP externos mediante el método WithExternalHttpEndpoints.
    • Agrega una referencia al recurso de cache y espera a que esté listo mediante los métodos WithReference y WaitFor.
    • Agrega una referencia al recurso de apiservice y espera a que esté listo mediante los métodos WithReference y WaitFor.
  • Compila y ejecuta el modelo de aplicación mediante los métodos Build y Run.

El código de ejemplo usa el .NET AspireRedis de integración de hospedaje.

Para ayudar a visualizar la relación entre el proyecto host de la aplicación y los recursos que describe, tenga en cuenta el diagrama siguiente:

La relación entre los proyectos de la plantilla de aplicación inicial de .NET.NET Aspire.

Cada recurso debe tener un nombre único. En este diagrama se muestran cada recurso y las relaciones entre ellos. El recurso de contenedor se denomina "caché" y los recursos del proyecto se denominan "apiservice" y "webfrontend". El proyecto de front-end web hace referencia a los proyectos de caché y servicio de API. Al expresar referencias de esta manera, el proyecto de front-end web dice que depende de estos dos recursos, la "caché" y "apiservice", respectivamente.

Tipos de recursos integrados

Los proyectos .NET.NET Aspire se componen de un conjunto de recursos. Los tipos de recursos base principales en el paquete NuGet 📦Aspire.Hosting.AppHost se describen en la tabla siguiente:

Método Tipo de recurso Descripción
AddProject ProjectResource Un proyecto de .NET, por ejemplo, una aplicación web de ASP.NET Core.
AddContainer ContainerResource Una imagen de contenedor, como Docker.
AddExecutable ExecutableResource Un archivo ejecutable, como una aplicación de Node.js.
AddParameter ParameterResource Un recurso de parámetro que se puede usar para expresar parámetros externos.

Los recursos del proyecto representan .NET proyectos que forman parte del modelo de aplicación. Al agregar una referencia de proyecto al proyecto host de la aplicación, el SDK de .NET.NET Aspire genera un tipo en el espacio de nombres Projects para cada proyecto al que se hace referencia. Para obtener más información, consulte .NET.NET Aspire SDK: Referencias de proyecto.

Para agregar un proyecto al modelo de aplicación, use el método AddProject:

var builder = DistributedApplication.CreateBuilder(args);

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

Los proyectos se pueden replicar y escalar horizontalmente agregando varias instancias del mismo proyecto al modelo de aplicación. Para configurar réplicas, use el método 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);

El código anterior agrega tres réplicas del recurso de proyecto "apiservice" al modelo de aplicación. Para obtener más información, consulte .NET.NET Aspire panel: Réplicas de recursos.

Recursos de referencia

Una referencia representa una dependencia entre los recursos. Por ejemplo, puede imaginar un escenario en el que un front-end web depende de una memoria caché de Redis. Tenga en cuenta el siguiente ejemplo de host de aplicación para código C# Program:

var builder = DistributedApplication.CreateBuilder(args);

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

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

El recurso de proyecto "webfrontend" usa WithReference para agregar una dependencia en el recurso de contenedor "caché". Estas dependencias pueden representar cadenas de conexión o información de detección de servicios. En el ejemplo anterior, se inserta una variable de entorno en el recurso "webfronend" con el nombre ConnectionStrings__cache. Esta variable de entorno contiene una cadena de conexión que el usa para conectarse a a través de la integraciónde , por ejemplo, .

Esperando recursos

En algunos casos, es posible que quiera esperar a que un recurso esté listo antes de iniciar otro recurso. Por ejemplo, es posible que quiera esperar a que una base de datos esté lista antes de iniciar una API que dependa de ella. Para expresar esta dependencia, use el método 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);

En el código anterior, el recurso del proyecto "apiservice" espera que el recurso de base de datos "postgresdb" entre en el KnownResourceStates.Running. El código de ejemplo muestra el .NET AspirePostgreSQL de integración, pero el mismo patrón se puede aplicar a otros recursos.

Otros casos pueden justificar la espera de que un recurso se ejecute hasta su finalización, ya sea KnownResourceStates.Exited o KnownResourceStates.Finished antes de que se inicie el recurso dependiente. Para esperar a que un recurso se ejecute hasta su finalización, use el método 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);

En el código anterior, el recurso de proyecto "apiservice" espera a que el recurso de proyecto "migration" se complete antes de comenzar. El recurso de proyecto "migración" espera a que el recurso de base de datos "postgresdb" entre en el estado KnownResourceStates.Running. Esto puede ser útil en escenarios en los que desea ejecutar una migración de base de datos antes de iniciar el servicio de API, por ejemplo.

API para agregar y expresar recursos

.NET .NET Aspire las integraciones de hospedaje y las integraciones de client se entregan como paquetes NuGet, pero tienen fines diferentes. Aunque las integraciones de client proporcionan client configuración de biblioteca para consumir aplicaciones fuera del ámbito del host de la aplicación, las integraciones de hospedaje proporcionan API para expresar recursos y dependencias dentro del host de la aplicación. Para obtener más información, consulte .NET.NET Aspire resumen de integraciones: responsabilidades de integración.

Recursos de contenedor express

Para expresar un ContainerResource, debes agregarlo a una instancia de IDistributedApplicationBuilder llamando al método 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");

Para obtener más información, consulte compatibilidad con GPU de en Docker Desktop.

El código anterior agrega un recurso de contenedor denominado "ollama" con la imagen ollama/ollama. El recurso de contenedor se configura con varios montajes de enlace, un punto de conexión HTTP con nombre, un punto de entrada que se resuelve en Unix script de shell y argumentos de ejecución de contenedor con el método WithContainerRuntimeArgs.

Personalización de recursos de contenedor

Todas las ContainerResource subclases se pueden personalizar para satisfacer sus requisitos específicos. Esto puede ser útil cuando se usa una integración de hospedaje que modela un recurso de contenedor, pero requiere modificaciones. Cuando tenga un IResourceBuilder<ContainerResource> puede encadenar llamadas a cualquiera de las API disponibles para modificar el recurso de contenedor. Los recursos de contenedor .NET.NET Aspire suelen apuntar a etiquetas ancladas, pero podría querer usar la etiqueta latest en su lugar.

Para ayudar a ejemplificar esto, imagine un escenario en el que está usando la integración de .NET AspireRedis. Si la integración de Redis se basa en la etiqueta 7.4 y quiere usar la etiqueta latest en su lugar, puede encadenar una llamada a la API de 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.

Para obtener más información y otras API disponibles, consulte ContainerResourceBuilderExtensions.

Ciclo de vida de los recursos del contenedor

Cuando se ejecuta el host de la aplicación, el ContainerResource se usa para determinar qué imagen de contenedor se va a crear e iniciar. En segundo plano, .NET Aspire ejecuta el contenedor utilizando la imagen de contenedor definida al delegar llamadas al entorno de ejecución de contenedores compatible con OCI apropiado, ya sea Docker o Podman. Se usan los siguientes comandos:

En primer lugar, el contenedor se crea con el comando docker container create. A continuación, el contenedor se inicia mediante el comando docker container start.

Estos comandos se usan en lugar de docker run para administrar redes, volúmenes y puertos de contenedor conectados. Llamar a estos comandos en este orden permite que cualquier dirección IP (configuración de red) ya esté presente en el inicio inicial.

Además de los tipos de recursos base, ProjectResource, ContainerResourcey ExecutableResource, .NET.NET Aspire proporciona métodos de extensión para agregar recursos comunes al modelo de aplicación. Para obtener más información, consulte integraciones de hospedaje.

Duración de los recursos del contenedor

De forma predeterminada, los recursos del contenedor usan la duración del contenedor de la sesión . Esto significa que cada vez que se inicia el proceso de host de la aplicación, se crea e inicia el contenedor. Cuando se detiene el host de la aplicación, el contenedor se detiene y se elimina. Los recursos de los contenedores pueden optar por un modelo de persistencia para evitar reinicios innecesarios y utilizar el estado persistente del contenedor. Para lograrlo, encadena una llamada a la API ContainerResourceBuilderExtensions.WithLifetime y pasa ContainerLifetime.Persistent

var builder = DistributedApplication.CreateBuilder(args);

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

El código anterior agrega un recurso de contenedor denominado "ollama" con la imagen "ollama/ollama" y una duración persistente.

Referencias de cadena de conexión y punto de conexión

Es habitual expresar las dependencias entre los recursos del proyecto. Tenga en cuenta el código de ejemplo siguiente:

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

Las referencias de proyecto a proyecto se controlan de forma diferente a los recursos que tienen cadenas de conexión bien definidas. En lugar de insertar la cadena de conexión en el recurso "webfrontend", se insertan variables de entorno para admitir la detección de servicios.

Método Variable de entorno
WithReference(cache) ConnectionStrings__cache="localhost:62354"
WithReference(apiservice) services__apiservice__http__0="http://localhost:5455"
services__apiservice__https__0="https://localhost:7356"

Al agregar una referencia al proyecto "apiservice", se agregan variables de entorno de detección de servicios al front-end. Esto se debe a que, normalmente, la comunicación entre proyectos se produce a través de HTTP/gRPC. Para obtener más información, consulte .NET.NET Aspire descubrimiento de servicios.

Para obtener puntos de conexión específicos de una ContainerResource o una ExecutableResource, use una de las siguientes API de punto de conexión:

A continuación, utilice la API de GetEndpoint para obtener el punto de conexión que se puede utilizar para referenciarlo en el método 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);
Método Variable de entorno
WithReference(endpoint) services__myapp__endpoint__0=https://localhost:9043

El parámetro port es el puerto en el que escucha el contenedor. Para obtener más información sobre los puertos de contenedor, consulte Puertos de contenedor. Para obtener más información sobre la detección de servicios, consulte .NET.NET Aspire service discovery.

Formato de variable de entorno del punto de conexión de servicio

En la sección anterior, el método WithReference se usa para expresar dependencias entre recursos. Cuando los puntos de conexión de servicio generan variables de entorno que se insertan en el recurso dependiente, es posible que el formato no sea obvio. En esta sección se proporcionan detalles sobre este formato.

Cuando un recurso depende de otro recurso, el host de la aplicación inserta variables de entorno en el recurso dependiente. Estas variables de entorno configuran el recurso dependiente para conectarse al recurso del que depende. El formato de las variables de entorno es específico de .NET.NET Aspire y expresa los puntos de conexión de servicio de una manera compatible con Service Discovery.

Los nombres de las variables de entorno del punto de conexión de servicio tienen el prefijo services__ (doble carácter de subrayado), el nombre del servicio, el nombre del punto de conexión y, por último, el índice. El índice admite múltiples extremos para un único servicio, comenzando con 0 para el primer extremo e incrementando para cada extremo adicional.

Tenga en cuenta los siguientes ejemplos de variables de entorno:

services__apiservice__http__0

La variable de entorno anterior expresa el primer punto de conexión HTTP para el servicio apiservice. El valor de la variable de entorno es la dirección URL del punto de conexión de servicio. Un punto de conexión con nombre puede expresarse de la siguiente manera:

services__apiservice__myendpoint__0

En el ejemplo anterior, el servicio apiservice tiene un punto de conexión con nombre denominado myendpoint. El valor de la variable de entorno es la dirección URL del punto de conexión de servicio.

Hacer referencia a los recursos existentes

Algunas situaciones garantizan que haga referencia a un recurso existente, quizás uno que se implemente en un proveedor de nube. Por ejemplo, puede que quiera referirse a una base de datos denominada Azure. En este caso, confiaría en el contexto de ejecución de para determinar dinámicamente si el host de la aplicación se ejecuta en modo "ejecutar" o "publicar". Si se ejecuta localmente y quiere confiar en un recurso en la nube, puede usar la propiedad IsRunMode para agregar condicionalmente la referencia. En su lugar, puede crear el recurso en modo de publicación. Algunas integraciones de hospedaje admiten proporcionar una cadena de conexión que se puede usar directamente para hacer referencia a un recurso existente.

Del mismo modo, puede haber casos de uso en los que quiera integrar .NET.NET Aspire en una solución existente. Un enfoque común consiste en agregar el proyecto host de aplicación .NET.NET Aspire a una solución existente. En el host de la aplicación, puede expresar las dependencias agregando referencias de proyecto al host de la aplicación y compilar el modelo de aplicación. Por ejemplo, un proyecto podría depender de otro. Estas dependencias se expresan mediante el método WithReference. Para obtener más información, consulte Agregar .NET Aspire a una aplicación de .NET existente.

Ciclos de vida del host de la aplicación

El host de la aplicación .NET.NET Aspire expone varios ciclos de vida a los que puede enlazar mediante la implementación de la interfaz IDistributedApplicationLifecycleHook. Los siguientes métodos de ciclo de vida están disponibles:

Pedido Método Descripción
1 BeforeStartAsync Se ejecuta antes de que se inicie la aplicación distribuida.
2 AfterEndpointsAllocatedAsync Se ejecuta después de que el orquestador asigne puntos de conexión para los recursos del modelo de aplicación.
3 AfterResourcesCreatedAsync Se ejecuta después de que el orquestador haya creado el recurso.

Aunque el host de la aplicación proporciona enlaces de ciclo de vida, es posible que quiera registrar eventos personalizados. Para obtener más información, vea Eventing in .NET.NET Aspire.

Registrar un enlace de ciclo de vida

Para registrar un enlace de ciclo de vida, implemente la interfaz IDistributedApplicationLifecycleHook y registre el enlace con el host de la aplicación mediante la API de 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;
    }
}

El código anterior:

Cuando se ejecuta este host de aplicación, se ejecuta el enlace de ciclo de vida para cada evento. Se genera la salida siguiente:

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.

La manera preferida de enlazar con el ciclo de vida del host de la aplicación es usar la API de eventos. Para obtener más información, vea Eventing in .NET.NET Aspire.

Contexto de ejecución

El IDistributedApplicationBuilder expone un contexto de ejecución (DistributedApplicationExecutionContext), que proporciona información sobre la ejecución actual del host de la aplicación. Este contexto se puede usar para evaluar si el host de la aplicación se está ejecutando en modo "ejecución" o como parte de una operación de publicación. Tenga en cuenta las siguientes propiedades:

  • IsRunMode: devuelve true si se está ejecutando la operación actual.
  • IsPublishMode: devuelve true si la operación actual es publicar.

Esta información puede ser útil cuando desea ejecutar código condicionalmente en función de la operación actual. Considere el ejemplo siguiente que muestra el uso de la propiedad IsRunMode. En este caso, se usa un método de extensión para generar un nombre de nodo estable para RabbitMQ para las ejecuciones de desarrollo local.

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

El contexto de ejecución se usa a menudo para agregar recursos o cadenas de conexión condicionalmente que apuntan a recursos existentes. Considere el ejemplo siguiente que muestra cómo agregar condicionalmente Redis o una cadena de conexión en función del contexto de ejecución:

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

En el código anterior:

  • Si el host de la aplicación se ejecuta en modo "run", se agrega un recurso de contenedor de Redis.
  • Si el host de la aplicación se ejecuta en modo "publicar", se agrega una cadena de conexión.

Esta lógica se puede invertir fácilmente para conectarse a un recurso de Redis existente cuando se ejecuta localmente y crear un nuevo recurso de Redis al publicar.

Importante

.NET .NET Aspire proporciona API comunes para controlar la modalidad de los generadores de recursos, lo que permite que los recursos se comporten de forma diferente en función del modo de ejecución. Las API fluidas tienen el prefijo RunAs* y PublishAs*. Las API de RunAs* influyen en el comportamiento de desarrollo local (o modo de ejecución), mientras que las API de PublishAs* influyen en la publicación del recurso.

Consulte también