Compartilhar via

visão geral da orquestração .NET.NET Aspire

  • Artigo

.NET .NET Aspire fornece APIs para expressar recursos e dependências em seu aplicativo distribuído. Além dessas APIs, há ferramentas que permitem vários cenários atraentes. O orquestrador destina-se à finalidade de desenvolvimento local e não tem suporte em ambientes de produção.

Antes de continuar, considere alguma terminologia comum usada em .NET.NET Aspire:

  • modelo de aplicativo: uma coleção de recursos que compõem seu aplicativo distribuído (DistributedApplication), definido no namespace Aspire.Hosting.ApplicationModel. Para obter uma definição mais formal, consulte Definir o modelo de aplicativo.
  • do projeto Host de Aplicativo/Orquestrador: o projeto .NET que orquestra o modelo de aplicativo , nomeado com o sufixo *.AppHost (por convenção).
  • Resource: uma de recurso é uma parte dependente de um aplicativo, como um projeto , contêiner, executável, banco de dados, cache ou serviço de nuvem. Ele representa qualquer parte do aplicativo que possa ser gerenciada ou referenciada.
  • Integration: uma integração é um pacote NuGet para o host do aplicativo que modela um de recursos ou um pacote que configura um para uso em um aplicativo consumidor. Para obter mais informações, consulte .NET.NET Aspire visão geral de integrações.
  • de Referência: uma referência define uma conexão entre recursos, expressada como uma dependência usando a API WithReference. Para obter mais informações, consulte recursos de referência ou consulte recursos existentes.

Nota

A orquestração do .NET.NET Aspirefoi projetada para aprimorar sua experiência de desenvolvimento local simplificando o gerenciamento da configuração e das interconexões do aplicativo nativa da nuvem. Embora seja uma ferramenta inestimável para o desenvolvimento, não se destina a substituir sistemas de ambiente de produção como Kubernetes, que são especificamente projetados para se destacar nesse contexto.

Definir o modelo de aplicativo

.NET .NET Aspire permite que você crie, provisione, implante, configure, teste, execute e observe seus aplicativos distribuídos perfeitamente. Todos esses recursos são obtidos por meio da utilização de um modelo de aplicativo que descreve os recursos em sua solução .NET.NET Aspire e suas relações. Esses recursos abrangem projetos, executáveis, contêineres e serviços externos e recursos de nuvem dos quais seu aplicativo depende. Em cada solução .NET.NET Aspire, há um projeto anfitrião de aplicativo designado , em que o modelo de aplicativo é definido com precisão usando métodos disponíveis no IDistributedApplicationBuilder. Esse construtor é obtido 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();

Projeto de host do aplicativo

O projeto de host do aplicativo manipula a execução de todos os projetos que fazem parte do projeto .NET.NET Aspire. Em outras palavras, ele é responsável por orquestrar todos os aplicativos dentro do modelo de aplicativo. O projeto em si é um projeto executável .NET que faz referência ao 📦Aspire. Hosting.AppHost pacote NuGet, define a propriedade IsAspireHost como truee faz referência ao 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>

O código a seguir descreve um host de aplicativo Program com duas referências de projeto e um cache 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();

O código anterior:

  • Cria um novo construtor de modelos de aplicativo usando o método CreateBuilder.
  • Adiciona um recurso Rediscache chamado "cache" usando o método AddRedis.
  • Adiciona um recurso de projeto chamado "apiservice" usando o método AddProject.
  • Adiciona um recurso de projeto chamado "webfrontend" usando o método AddProject.
    • Especifica que há endpoints HTTP externos, usando o método WithExternalHttpEndpoints.
    • Adiciona uma referência ao recurso cache e aguarda que ele esteja pronto usando os métodos WithReference e WaitFor.
    • Adiciona uma referência ao recurso apiservice e aguarda que ele esteja pronto usando os métodos WithReference e WaitFor.
  • Cria e executa o modelo de aplicativo usando os métodos Build e Run.

O código de exemplo usa a integração de hospedagem .NET AspireRedis.

Para ajudar a visualizar a relação entre o projeto de host do aplicativo e os recursos descritos, considere o seguinte diagrama:

a relação entre os projetos no modelo de aplicativo inicial do .NET.NET Aspire.

Cada recurso deve ser nomeado exclusivamente. Este diagrama mostra cada recurso e as relações entre eles. O recurso de contêiner é chamado de "cache" e os recursos do projeto são chamados de "apiservice" e "webfrontend". O projeto de front-end da Web faz referência aos projetos de cache e serviço de API. Quando você está expressando referências dessa forma, o projeto de front-end da Web está dizendo que ele depende desses dois recursos, o "cache" e o "apiservice", respectivamente.

Tipos de recursos integrados

.NET .NET Aspire projetos são compostos por um conjunto de recursos. Os principais tipos de recursos base no pacote NuGet 📦Aspire.Hosting.AppHost são descritos na tabela a seguir:

Método Tipo de recurso Descrição
AddProject ProjectResource Um projeto .NET, por exemplo, um aplicativo Web ASP.NET Core.
AddContainer ContainerResource Uma imagem de contêiner, como uma imagem Docker.
AddExecutable ExecutableResource Um arquivo executável, como um aplicativo Node.js.
AddParameter ParameterResource Um recurso de parâmetro que pode ser usado para parâmetros externos expressos.

Os recursos de projetos representam .NET projetos que fazem parte do modelo de aplicativo. Quando você adiciona uma referência de projeto ao projeto de host do aplicativo, o SDK do .NET.NET Aspire gera um tipo no namespace Projects para cada projeto referenciado. Para obter mais informações, consulte .NET.NET Aspire SDK: referências de projeto.

Para adicionar um projeto ao modelo de aplicativo, use o 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");

Os projetos podem ser replicados e dimensionados adicionando várias instâncias do mesmo projeto ao modelo de aplicativo. Para configurar réplicas, use o 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);

O código anterior adiciona três réplicas do recurso de projeto "apiservice" ao modelo de aplicativo. Para obter mais informações, consulte o painel ".NET.NET Aspire": "Réplicas de Recurso".

Recursos de referência

Uma referência representa uma dependência entre recursos. Por exemplo, você provavelmente pode imaginar um cenário em que um front-end web depende de um cache de Redis. Considere o seguinte exemplo de host de aplicativo Program código C#:

var builder = DistributedApplication.CreateBuilder(args);

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

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

O recurso de projeto "webfrontend" usa WithReference para adicionar uma dependência ao recurso de contêiner "cache". Essas dependências podem representar cadeias de conexão ou informações de descoberta de serviço. No exemplo anterior, uma variável de ambiente é injetada no recurso "webfronend" com o nome ConnectionStrings__cache. Essa variável de ambiente contém uma string de conexão que o webfrontend usa para se conectar a Redis por meio da integração .NET AspireRedis, por exemplo, ConnectionStrings__cache="localhost:62354".

Aguardando recursos

Em alguns casos, talvez você queira aguardar que um recurso esteja pronto antes de iniciar outro recurso. Por exemplo, talvez você queira esperar que um banco de dados esteja pronto antes de iniciar uma API que depende dele. Para expressar essa dependência, use o 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);

No código anterior, o recurso de projeto "apiservice" aguarda o recurso de banco de dados "postgresdb" inserir o KnownResourceStates.Running. O código de exemplo mostra a integração .NET AspirePostgreSQL, mas o mesmo padrão pode ser aplicado a outros recursos.

Outros casos podem justificar a espera pela execução completa de um recurso, seja KnownResourceStates.Exited ou KnownResourceStates.Finished, antes que o recurso dependente comece. Para aguardar a conclusão de um recurso, use o 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);

No código anterior, o recurso de projeto "apiservice" aguarda o recurso de projeto de "migração" ser executado até a conclusão antes de começar. O recurso do projeto de "migração" aguarda que o recurso de banco de dados "postgresdb" entre no KnownResourceStates.Running. Isso pode ser útil em cenários em que você deseja executar uma migração de banco de dados antes de iniciar o serviço de API, por exemplo.

APIs para adicionar e expressar recursos

.NET .NET Aspire integrações de hospedagem e integrações client são entregues como pacotes NuGet, mas atendem a diferentes finalidades. Embora client integrações forneçam client configuração de biblioteca para aplicações consumidoras fora do escopo do host do aplicativo, integrações de hospedagem fornecem APIs para expressar recursos e dependências dentro do host do aplicativo. Para obter mais informações, consulte .NET.NET Aspire visão geral das integrações: responsabilidades de integração.

Recursos de contêiner expresso

Para expressar um ContainerResource adicione-o a uma instância de IDistributedApplicationBuilder chamando o 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 obter mais informações, consulte suporte à GPU no Docker Desktop.

O código anterior adiciona um recurso de contêiner chamado "ollama" com a imagem ollama/ollama. O recurso de contêiner é configurado com várias montagens de vínculo, um ponto de extremidade HTTP nomeado, um ponto de entrada que resolve para o script de shell Unix, e argumentos de execução do contêiner com o método WithContainerRuntimeArgs.

Personalizar recursos de contêiner

Todas as subclasses ContainerResource podem ser personalizadas para atender aos seus requisitos específicos. Isso pode ser útil ao usar uma integração de hospedagem que modela um recurso de contêiner, mas requer modificações. Quando você tem um IResourceBuilder<ContainerResource> pode encadear chamadas para qualquer uma das APIs disponíveis para modificar o recurso de contêiner. .NET .NET Aspire recursos de contêiner geralmente apontam para tags fixas, mas talvez você queira usar a tag latest.

Para ajudar a exemplificar isso, imagine um cenário em que você está usando a integração .NET AspireRedis. Se a integração Redis depender da marca 7.4 e você quiser usar a marca latest, você pode encadear uma chamada à 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.

Para obter mais informações e APIs adicionais disponíveis, consulte ContainerResourceBuilderExtensions.

Ciclo de vida do recurso de contêiner

Quando o host do aplicativo é executado, o ContainerResource é usado para determinar qual imagem de contêiner criar e iniciar. Internamente, o .NET Aspire executa o contêiner usando a imagem de contêiner definida, delegando chamadas para o runtime de contêiner compatível com OCI apropriado, Docker ou Podman. Os seguintes comandos são usados:

Primeiro, o contêiner é criado usando o comando docker container create. Em seguida, o contêiner é iniciado usando o comando docker container start.

Esses comandos são usados em vez de docker run para gerenciar redes, volumes e portas de contêiner anexados. Chamar esses comandos nesta ordem permite que qualquer IP (configuração de rede) já esteja presente na inicialização inicial.

Além dos tipos de recursos base, ProjectResource, ContainerResourcee ExecutableResource, .NET.NET Aspire fornece métodos de extensão para adicionar recursos comuns ao modelo de aplicativo. Para obter mais informações, consulte integrações de hospedagem.

Tempo de vida do recurso de contêiner

Por padrão, os recursos de contêiner usam o tempo de vida do contêiner da sessão . Isso significa que sempre que o processo de host do aplicativo é iniciado, o contêiner é criado e iniciado. Quando o host do aplicativo é interrompido, o contêiner é interrompido e removido. Os recursos de contêiner podem optar por um tempo de vida persistente para evitar reinicializações desnecessárias e usar o estado do contêiner persistente. Para conseguir isso, encadeie uma chamada à API de ContainerResourceBuilderExtensions.WithLifetime e passe ContainerLifetime.Persistent:

var builder = DistributedApplication.CreateBuilder(args);

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

O código anterior adiciona um recurso de contêiner chamado "ollama" com a imagem "ollama/ollama" e um tempo de vida persistente.

Referências de cadeia de conexão e ponto de extremidade

É comum expressar dependências entre os recursos do projeto. Considere o seguinte código de exemplo:

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

As referências projeto a projeto são tratadas de forma diferente dos recursos que têm cadeias de conexão bem definidas. Em vez de a cadeia de conexão ser injetada no recurso "webfrontend", variáveis de ambiente para dar suporte à descoberta do serviço são injetadas.

Método Variável de ambiente
WithReference(cache) ConnectionStrings__cache="localhost:62354"
WithReference(apiservice) services__apiservice__http__0="http://localhost:5455"
services__apiservice__https__0="https://localhost:7356"

Adicionar uma referência ao projeto "apiservice" resulta em variáveis de ambiente de descoberta de serviço sendo adicionadas ao front-end. Isso ocorre porque, normalmente, a comunicação projeto a projeto ocorre por HTTP/gRPC. Para obter mais informações, consulte .NET.NET Aspire descoberta de serviço.

Para obter pontos de extremidade específicos de um ContainerResource ou um ExecutableResource, use uma das seguintes APIs de ponto de extremidade:

Em seguida, chame a API GetEndpoint para obter o ponto de extremidade que pode ser usado para referenciar o ponto de extremidade no 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 Variável de ambiente
WithReference(endpoint) services__myapp__endpoint__0=https://localhost:9043

O parâmetro port é a porta na qual o contêiner está escutando. Para obter mais informações sobre portas de contêiner, consulte portas de contêiner. Para obter mais informações sobre descoberta de serviço, consulte .NET.NET Aspire descoberta de serviço.

Formato de variável de ambiente do ponto de extremidade de serviço

Na seção anterior, o método WithReference é usado para expressar dependências entre recursos. Quando pontos de extremidade de serviço resultam em variáveis de ambiente sendo injetadas no recurso dependente, o formato pode não ser óbvio. Esta seção fornece detalhes sobre esse formato.

Quando um recurso depende de outro recurso, o host do aplicativo injeta variáveis de ambiente no recurso dependente. Essas variáveis de ambiente configuram o recurso dependente para se conectar ao recurso do qual ele depende. O formato das variáveis de ambiente é específico para .NET.NET Aspire e expressa pontos de extremidade de serviço de maneira compatível com de Descoberta de Serviço.

Os nomes das variáveis de ambiente do ponto de extremidade de serviço são prefixados com services__ (sublinhado duplo), o nome do serviço, o nome do ponto de extremidade e, por fim, o índice. O índice dá suporte a vários pontos de extremidade para um único serviço, começando com 0 para o primeiro ponto de extremidade e incrementando para cada ponto de extremidade.

Considere os seguintes exemplos de variável de ambiente:

services__apiservice__http__0

A variável de ambiente anterior expressa o primeiro ponto de extremidade HTTP para o serviço apiservice. O valor da variável de ambiente é a URL do endpoint do serviço. Um ponto de extremidade nomeado pode ser expresso da seguinte maneira:

services__apiservice__myendpoint__0

No exemplo anterior, o serviço apiservice tem um ponto de extremidade nomeado chamado myendpoint. O valor da variável de ambiente é a URL do endpoint do serviço.

Referenciar recursos existentes

Algumas situações garantem que você faça referência a um recurso existente, talvez um que seja implantado em um provedor de nuvem. Por exemplo, talvez você queira fazer referência a um banco de dados Azure. Nesse caso, você contaria com o contexto de execução para determinar dinamicamente se o host do aplicativo está em execução no modo "executar" ou "publicar". Se você estiver executando localmente e quiser contar com um recurso de nuvem, poderá usar a propriedade IsRunMode para adicionar condicionalmente a referência. Em vez disso, você pode optar por criar o recurso no modo de publicação. Alguns integrações de hospedagem suporte para fornecer uma cadeia de conexão diretamente, que pode ser usada para fazer referência a um recurso existente.

Da mesma forma, pode haver casos de uso em que você deseja integrar .NET.NET Aspire em uma solução existente. Uma abordagem comum é adicionar o projeto host do aplicativo .NET.NET Aspire a uma solução existente. No host do aplicativo, você expressa dependências adicionando referências de projeto ao host do aplicativo e criando o modelo de aplicativo. Por exemplo, um projeto pode depender de outro. Essas dependências são expressas usando o método WithReference. Para obter mais informações, consulte Adicionar .NET Aspire a um aplicativo .NET existente.

Ciclos de vida do host do aplicativo

O host do aplicativo .NET.NET Aspire expõe vários ciclos de vida que você pode conectar implementando a interface IDistributedApplicationLifecycleHook. Os seguintes métodos de ciclo de vida estão disponíveis:

Ordem Método Descrição
1 BeforeStartAsync É executado antes do início do aplicativo distribuído.
2 AfterEndpointsAllocatedAsync Executa-se após o orquestrador alocar endpoints para os recursos no modelo de aplicativo.
3 AfterResourcesCreatedAsync É executado depois que o recurso foi criado pelo orquestrador.

Embora o host do aplicativo forneça ganchos de ciclo de vida, talvez você queira registrar eventos personalizados. Para obter mais informações, consulte Eventos em .NET.NET Aspire.

Registrar um gancho de ciclo de vida

Para registrar um gancho de ciclo de vida, implemente a interface IDistributedApplicationLifecycleHook e registre o gancho com o host do aplicativo usando a 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;
    }
}

O código anterior:

Quando esse host do aplicativo é executado, o gancho do ciclo de vida é executado para cada evento. A seguinte saída é gerada:

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.

A maneira preferida de conectar-se ao ciclo de vida do host do aplicativo é usar a API de eventos. Para obter mais informações, consulte Eventos em .NET.NET Aspire.

Contexto de execução

O IDistributedApplicationBuilder expõe um contexto de execução (DistributedApplicationExecutionContext), que fornece informações sobre a execução atual do host do aplicativo. Esse contexto pode ser usado para avaliar se o host do aplicativo está ou não executando como modo de "execução" ou como parte de uma operação de publicação. Considere as seguintes propriedades:

  • IsRunMode: retorna true se a operação atual estiver em execução.
  • IsPublishMode: retorna true se a operação atual estiver sendo publicada.

Essas informações podem ser úteis quando você deseja executar condicionalmente o código com base na operação atual. Considere o exemplo a seguir que demonstra o uso da propriedade IsRunMode. Nesse caso, utiliza-se um método de extensão para gerar um nome de nó estável para RabbitMQ em execuções locais de desenvolvimento.

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

O contexto de execução geralmente é usado para adicionar condicionalmente recursos ou cadeias de conexão que apontam para recursos existentes. Considere o exemplo a seguir que demonstra a adição condicional de Redis ou uma cadeia de conexão com base no contexto de execução:

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

No código anterior:

  • Se o host do aplicativo estiver em execução no modo "executar", um recurso de contêiner Redis será adicionado.
  • Se o host do aplicativo estiver em execução no modo "publicar", uma cadeia de conexão será adicionada.

Essa lógica pode ser facilmente invertida para se conectar a um recurso de Redis existente quando você estiver executando localmente e criar um novo recurso Redis quando estiver publicando.

Importante

.NET .NET Aspire fornece APIs comuns para controlar a modalidade dos construtores de recursos, permitindo que os recursos se comportem de forma diferente com base no modo de execução. As APIs fluentes são prefixadas com RunAs* e PublishAs*. As APIs de RunAs* influenciam o comportamento do desenvolvimento local (ou modo de execução), enquanto as APIs de PublishAs* influenciam a publicação do recurso.

Consulte também