visão geral das integrações .NET AspireAzure

Azure é a plataforma de nuvem mais popular para criar e implantar aplicativos .NET. O SDK do Azure para .NET permite o fácil gerenciamento e o uso de serviços de Azure. .NET Aspire oferece um conjunto de integrações aos serviços da Azure. Este artigo detalha alguns aspectos comuns de todas as integrações Azure no .NET Aspire e tem como objetivo ajudar você a entender como usá-las.

Adicionar recursos de Azure

Todas as integrações de hospedagem .NET AspireAzure expõem recursos Azure e, por convenção, são adicionadas usando APIs de AddAzure*. Quando você adiciona esses recursos ao host do aplicativo .NET Aspire, eles representam um serviço Azure. A API AddAzure* retorna um IResourceBuilder<T> em que T é o tipo de recurso Azure. Essas interfaces IResourceBuilder<T> (builder) fornecem uma API fluente que permite configurar o recurso subjacente Azure dentro do modelo de aplicativo .

Experiência típica do desenvolvedor

Quando o host do aplicativo .NET Aspire contém Azure recursos e você o executa localmente (experiência típica de desenvolvedor com F5 ou dotnet run), os recursos Azure são provisionados na sua assinatura Azure. Isso permite que você, como desenvolvedor, depure-os localmente no contexto do host do seu aplicativo.

.NET .NET Aspire tem como objetivo minimizar os custos, adotando por padrão Básica ou PadrãoUnidade de Manutenção de Estoque (SKU) para suas integrações de Azure. Embora essas configurações padrão sensatas sejam fornecidas, você pode personalizar os recursos Azure para atender às suas necessidades. Além disso, algumas integrações dão suporte a emuladores ou contêineres, que são úteis para desenvolvimento local, teste e depuração. Por padrão, quando você executa seu aplicativo localmente, os recursos de Azure usam o serviço de Azure real. No entanto, você pode configurá-los para usar emuladores ou contêineres locais, evitando custos associados ao serviço de Azure real durante o desenvolvimento local.

Emuladores locais

Alguns serviços Azure podem ser executados localmente em emuladores. Atualmente, .NET Aspire dá suporte aos seguintes emuladores de Azure:

Para que seus recursos de Azure usem os emuladores locais, encadeia uma chamada ao método RunAsEmulator no construtor de recursos Azure. Esse método configura o recurso Azure para usar o emulador local em vez do serviço de Azure real.

Contêineres locais

Alguns serviços Azure podem ser executados localmente em contêineres. Para executar um serviço de Azure localmente em um contêiner, encadeia uma chamada para o método RunAsContainer no construtor de recursos Azure. Esse método configura o recurso Azure para ser executado localmente em um contêiner em vez do serviço de Azure real.

Atualmente, .NET Aspire dá suporte aos seguintes serviços de Azure como contêineres:

Entender as APIs de integração Azure

A força do .NET.NET Aspireestá em sua capacidade de fornecer um ciclo interno de desenvolvimento incrível. As integrações Azure não são diferentes de outras. Eles fornecem um conjunto de APIs e padrões comuns que são compartilhados em todos os recursos Azure. Essas APIs e padrões são projetados para facilitar o trabalho com recursos Azure de maneira consistente.

Na seção de contêineres anterior, você viu como executar serviços Azure localmente em contêineres. Se você estiver familiarizado com .NET.NET Aspire, talvez se pergunte como chamar AddAzureRedis("redis").RunAsContainer() para obter um contêiner de docker.io/library/redis local difere de AddRedis("redis")— pois ambos resultam no mesmo contêiner local.

A resposta é que não há diferença ao executar localmente. No entanto, quando eles são publicados, você obtém recursos diferentes:

O mesmo vale para serviços sql e PostgreSQL:

Para obter mais informações sobre a diferença entre os modos de execução e publicação, consulte .NET.NET Aspire host do aplicativo: contexto de execução.

Infraestrutura como código

O SDK do Azure para .NET fornece o 📦Azure. Pacote NuGet de Provisionamento e um conjunto de pacotes de provisionamento específicos do serviço Azure. Essas bibliotecas de provisionamento Azure facilitam a especificação declarativa Azure infraestrutura nativamente no .NET. Suas APIs permitem que você escreva a infraestrutura orientada a objetos em C#, resultando em Bicep. Bicep é um de linguagem específica do domínio (DSL) para implantar Azure recursos declarativamente.

Embora seja possível provisionar Azure recursos manualmente, .NET Aspire simplifica o processo fornecendo um conjunto de APIs para expressar Azure recursos. Essas APIs estão disponíveis como métodos de extensão em bibliotecas de hospedagem .NET AspireAzure, estendendo a interface IDistributedApplicationBuilder. Quando você adiciona recursos Azure ao host do aplicativo, eles adicionam a funcionalidade de provisionamento apropriada implicitamente. Em outras palavras, você não precisa chamar nenhuma API de provisionamento diretamente.

Como .NET Aspire modela Azure recursos dentro de Azure integrações de hospedagem, o SDK Azure é usado para provisionar esses recursos. São gerados arquivos Bicep que definem os recursos Azure de que você precisa. Os arquivos Bicep gerados são emitidos junto ao arquivo de manifesto quando você publica seu aplicativo.

Há várias maneiras de influenciar os arquivos Bicep gerados:

• Azure.de personalização de provisionamento:
  • Configurar infraestrutura: personalizar a infraestrutura de recursos Azure.
  • Adicionar infraestrutura Azure: adicionar manualmente infraestrutura Azure ao host do seu aplicativo.
• Usar modelos Bicep personalizados:
  • Referenciar arquivos Bicep: Adicionar uma referência a um arquivo Bicep no disco.
  • Referência de Bicep inline : Adicionar um modelo Bicep inline.

Provisionamento local e Azure.Provisioning

Para evitar confundir termos e ajudar a desambiguar o "provisionamento", é importante entender a distinção entre provisionamento local e provisionamento Azure:

• Provisionamento local:

  Por padrão, quando você chama qualquer uma das APIs de integração de hospedagem Azure para adicionar recursos Azure, a API AddAzureProvisioning(IDistributedApplicationBuilder) é chamada implicitamente. Essa API registra serviços no contêiner de injeção de dependência (DI) que são usados para provisionar recursos Azure quando o host do aplicativo inicia. Esse conceito é conhecido como de provisionamento local. Para obter mais informações, consulte provisionamento local Azure.

• Azure.Provisioning:

  Azure.Provisioning refere-se ao pacote NuGet e é um conjunto de bibliotecas que permite usar C# para gerar o Bicep. O Azure integrações de hospedagem no .NET Aspire usar essas bibliotecas nas capas para gerar arquivos Bicep que definem os recursos de Azure necessários. Para obter mais informações, consulte a personalização de Azure.Provisioning.

personalização Azure.Provisioning

Todas as integrações de hospedagem .NET AspireAzure expõem vários recursos Azure e todas elas são subclasses do tipo AzureProvisioningResource, que herda o AzureBicepResource. Isso permite extensões que são restritas genericamente a esse tipo, permitindo que uma API fluente personalize a infraestrutura de acordo com seu gosto. Embora .NET.NET Aspire forneça padrões, você é livre para influenciar o Bicep gerado usando essas APIs.

Configurar a infraestrutura

Independentemente do recurso de Azure com o qual você está trabalhando, para configurar sua infraestrutura subjacente, você encadeia uma chamada ao método de extensão ConfigureInfrastructure. Esse método permite personalizar a infraestrutura do recurso de Azure passando um delegado configure do tipo Action<AzureResourceInfrastructure>. O tipo AzureResourceInfrastructure é uma subclasse do Azure.Provisioning.Infrastructure. Esse tipo expõe uma área de superfície de API massiva para configurar a infraestrutura subjacente do recurso Azure.

Considere o seguinte exemplo:

var sku = builder.AddParameter("storage-sku");

var storage = builder.AddAzureStorage("storage")
    .ConfigureInfrastructure(infra =>
    {
        var resources = infra.GetProvisionableResources();

        var storageAccount = resources.OfType<StorageAccount>().Single();

        storageAccount.Sku = new StorageSku
        {
            Name = sku.AsProvisioningParameter(infra)
        };
    });

O código anterior:

• Adiciona um parâmetro chamado storage-sku.
• Adiciona armazenamento Azure com a API AddAzureStorage chamada storage.
• Encadeia uma chamada para ConfigureInfrastructure para personalizar a infraestrutura de armazenamento Azure:
  • Obtém os recursos provisionáveis.
  • Filtrar para apenas um StorageAccount.
  • Atribui o parâmetro storage-sku à propriedade StorageAccount.Sku:
    • Uma nova instância do StorageSku tem sua propriedade Name atribuída do resultado da API AsProvisioningParameter.

Isso exemplifica o fluxo de um parâmetro externo para a infraestrutura de Armazenamento Azure, resultando no arquivo Bicep gerado refletindo a configuração desejada.

Adicionar infraestrutura Azure

Nem todos os serviços Azure são expostos como integrações .NET Aspire. Ainda que eles possam ser implementados em um momento posterior, você ainda pode disponibilizar serviços que estão disponíveis nas bibliotecas Azure.Provisioning.*. Imagine um cenário em que você tem um serviço de trabalho responsável pelo gerenciamento de um Registro de Contêiner Azure. Agora imagine que um projeto de host de aplicativo tenha uma dependência do pacote NuGet 📦Azure.Provisioning.ContainerRegistry.

Você pode usar a API AddAzureInfrastructure para adicionar a infraestrutura do Registro de Contêiner Azure ao host do aplicativo:

var acr = builder.AddAzureInfrastructure("acr", infra =>
{
    var registry = new ContainerRegistryService("acr")
    {
        Sku = new()
        {
            Name = ContainerRegistrySkuName.Standard
        },
    };
    infra.Add(registry);

    var output = new ProvisioningOutput("registryName", typeof(string))
    {
        Value = registry.Name
    };
    infra.Add(output);
});

builder.AddProject<Projects.WorkerService>("worker")
       .WithEnvironment(
            "ACR_REGISTRY_NAME",
            new BicepOutputReference("registryName", acr.Resource));

O código anterior:

• Chama AddAzureInfrastructure com um nome de acr.
• Fornece um delegado configureInfrastructure para personalizar a infraestrutura do Registro de Contêineres Azure.
  • Cria uma instância de um ContainerRegistryService com o nome acr e um SKU padrão.
  • Adiciona o serviço Azure Registro de Contêiner à variável infra.
  • Instancia um ProvisioningOutput com o nome registryName, um tipo de stringe um valor que corresponde ao nome do Registro de Contêiner Azure.
  • Adiciona a saída à variável infra.
• Adiciona um projeto chamado worker ao construtor.
• Encadeia uma chamada para WithEnvironment para definir a variável de ambiente ACR_REGISTRY_NAME no projeto com o valor da saída registryName.

A funcionalidade demonstra como adicionar a infraestrutura Azure ao projeto de host do aplicativo, mesmo que o serviço Azure não seja exposto diretamente como uma integração .NET Aspire. Ele mostra ainda como direcionar a saída do Registro de Contêineres Azure para o ambiente de um projeto dependente.

Considere o arquivo Bicep resultante:

@description('The location for the resource(s) to be deployed.')
param location string = resourceGroup().location

resource acr 'Microsoft.ContainerRegistry/registries@2023-07-01' = {
  name: take('acr${uniqueString(resourceGroup().id)}', 50)
  location: location
  sku: {
    name: 'Standard'
  }
}

output registryName string = acr.name

O arquivo Bicep reflete a configuração desejada do Registro de Contêiner Azure, conforme definido pela API AddAzureInfrastructure.

"Utilizar modelos Bicep personalizados"

Ao direcionar Azure como seu provedor de nuvem desejado, você pode usar o Bicep para definir sua infraestrutura como código. Ele visa simplificar drasticamente a experiência de criação com uma sintaxe mais limpa e um melhor suporte para modularidade e reutilização de código.

Embora .NET.NET Aspire forneça um conjunto de modelos Bicep predefinidos, pode haver momentos em que você deseja personalizar os modelos ou criar seus próprios. Esta seção explica os conceitos e as APIs correspondentes que você pode usar para personalizar os modelos do Bicep.

Como parte da Azure história de implantação para .NET Aspire, o Azure Developer CLI (azd) fornece uma compreensão do seu projeto de .NET Aspire e a capacidade de implantá-lo no Azure. A CLI do azd usa os modelos Bicep para implantar a aplicação em Azure.

Instalar o pacote Aspire.Hosting.Azure

Quando você deseja referenciar arquivos Bicep, é possível que você não esteja usando nenhuma das integrações de hospedagem Azure. Nesse caso, você ainda pode referenciar arquivos Bicep instalando o pacote Aspire.Hosting.Azure. Esse pacote fornece as APIs necessárias para referenciar arquivos Bicep e personalizar os recursos Azure.

Para usar qualquer uma dessas funcionalidades, o pacote NuGet 📦Aspire.Hosting.Azure deve ser instalado.

dotnet add package Aspire.Hosting.Azure

<PackageReference Include="Aspire.Hosting.Azure"
                  Version="*" />

Para obter mais informações, consulte dotnet add package ou Gerencie dependências de pacotes em aplicativos .NET.

O que esperar dos exemplos

Todos os exemplos nesta seção pressupõem que você está usando o namespace Aspire.Hosting.Azure. Além disso, os exemplos pressupõem que você tenha uma instância de IDistributedApplicationBuilder:

using Aspire.Hosting.Azure;

var builder = DistributedApplication.CreateBuilder(args);

// Examples go here...

builder.Build().Run();

Por padrão, quando você chama qualquer uma das APIs relacionadas ao Bicep, uma chamada também é feita para AddAzureProvisioning que adiciona suporte para gerar recursos Azure dinamicamente durante a inicialização do aplicativo. Para obter mais informações, consulte Provisionamento local e Azure.Provisioning.

Faça referência a arquivos Bicep

Imagine que você tenha um modelo Bicep em um arquivo chamado storage.bicep que provisiona uma conta de armazenamento Azure:

param location string = resourceGroup().location
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Para adicionar uma referência ao arquivo Bicep no disco, chame o método AddBicepTemplate. Considere o seguinte exemplo:

builder.AddBicepTemplate(
    name: "storage",
    bicepFile: "../infra/storage.bicep");

O código anterior adiciona uma referência a um arquivo Bicep localizado em ../infra/storage.bicep. Os caminhos de arquivo devem ser relativos ao projeto de host do aplicativo . Essa referência resulta em uma AzureBicepResource sendo adicionada à coleção de recursos do aplicativo com o nome "storage" e a API retorna uma instância IResourceBuilder<AzureBicepResource> que pode ser usada para personalizar ainda mais o recurso.

Referenciar o Bicep de forma embutida

Embora ter um arquivo Bicep no disco seja o cenário mais comum, você também pode adicionar modelos Bicep diretamente. Modelos embutidos podem ser úteis quando você deseja definir um modelo no código ou quando você deseja gerar o modelo dinamicamente. Para adicionar um modelo Bicep embutido, chame o método AddBicepTemplateString com o modelo Bicep como um string. Considere o seguinte exemplo:

builder.AddBicepTemplateString(
        name: "ai",
        bicepContent: """
        @description('That name is the name of our application.')
        param cognitiveServiceName string = 'CognitiveService-${uniqueString(resourceGroup().id)}'

        @description('Location for all resources.')
        param location string = resourceGroup().location

        @allowed([
          'S0'
        ])
        param sku string = 'S0'

        resource cognitiveService 'Microsoft.CognitiveServices/accounts@2021-10-01' = {
          name: cognitiveServiceName
          location: location
          sku: {
            name: sku
          }
          kind: 'CognitiveServices'
          properties: {
            apiProperties: {
              statisticsEnabled: false
            }
          }
        }
        """
    );

Neste exemplo, o modelo Bicep é definido como um string embutido e adicionado à coleção de recursos do aplicativo com o nome "ai". Este exemplo provisiona um recurso de IA Azure.

Passar parâmetros para modelos Bicep

Bicep dá suporte à aceitação de parâmetros, que podem ser usados para personalizar o comportamento do modelo. Para passar parâmetros de .NET.NET Aspirepara um modelo Bicep, encadeie as chamadas ao método WithParameter, conforme mostrado no exemplo a seguir:

var region = builder.AddParameter("region");

builder.AddBicepTemplate("storage", "../infra/storage.bicep")
       .WithParameter("region", region)
       .WithParameter("storageName", "app-storage")
       .WithParameter("tags", ["latest","dev"]);

O código anterior:

• Adiciona um parâmetro chamado "region" à instância de builder.
• Adiciona uma referência a um arquivo Bicep localizado em ../infra/storage.bicep.
• Passa o parâmetro "region" para o modelo Bicep, que é resolvido com a resolução padrão de parâmetros.
• Passa o parâmetro para o modelo Bicep com um valor de codificado em .
• Passa o parâmetro "tags" para o modelo Bicep com uma matriz de cadeias de caracteres.

Para obter mais informações, consulte Parâmetros externos.

Parâmetros conhecidos

.NET .NET Aspire fornece um conjunto de parâmetros conhecidos que podem ser passados para modelos Bicep. Esses parâmetros são usados para fornecer informações sobre o aplicativo e o ambiente para os modelos Bicep. Os seguintes parâmetros conhecidos estão disponíveis:

Para usar um parâmetro conhecido, passe o nome do parâmetro para o método WithParameter, como WithParameter(AzureBicepResource.KnownParameters.KeyVaultName). Você não passa valores para parâmetros conhecidos, pois .NET.NET Aspire os resolve em seu nome.

Considere um exemplo em que você deseja configurar um webhook da Grade de Eventos Azure. Você pode definir o modelo Bicep da seguinte maneira:

param topicName string
param webHookEndpoint string
param principalId string
param principalType string
param location string = resourceGroup().location

// The topic name must be unique because it's represented by a DNS entry. 
// must be between 3-50 characters and contain only values a-z, A-Z, 0-9, and "-".

resource topic 'Microsoft.EventGrid/topics@2023-12-15-preview' = {
  name: toLower(take('${topicName}${uniqueString(resourceGroup().id)}', 50))
  location: location

  resource eventSubscription 'eventSubscriptions' = {
    name: 'customSub'
    properties: {
      destination: {
        endpointType: 'WebHook'
        properties: {
          endpointUrl: webHookEndpoint
        }
      }
    }
  }
}

resource EventGridRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(topic.id, principalId, subscriptionResourceId('Microsoft.Authorization/roleDefinitions', 'd5a91429-5739-47e2-a06b-3470a27159e7'))
  scope: topic
  properties: {
    principalId: principalId
    principalType: principalType
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', 'd5a91429-5739-47e2-a06b-3470a27159e7')
  }
}

output endpoint string = topic.properties.endpoint

Este modelo Bicep define vários parâmetros, incluindo o topicName, webHookEndpoint, principalId, principalTypee o locationopcional. Para passar esses parâmetros para o modelo Bicep, você pode usar o seguinte snippet de código:

var webHookApi = builder.AddProject<Projects.WebHook_Api>("webhook-api");

var webHookEndpointExpression = ReferenceExpression.Create(
        $"{webHookApi.GetEndpoint("https")}/hook");

builder.AddBicepTemplate("event-grid-webhook", "../infra/event-grid-webhook.bicep")
       .WithParameter("topicName", "events")
       .WithParameter(AzureBicepResource.KnownParameters.PrincipalId)
       .WithParameter(AzureBicepResource.KnownParameters.PrincipalType)
       .WithParameter("webHookEndpoint", () => webHookEndpointExpression);

• O projeto webHookApi é adicionado como uma referência ao builder.
• O parâmetro topicName recebe um valor de nome fixo.
• O parâmetro webHookEndpoint é passado como uma expressão que se resolve na URL do endpoint "https" das referências de projeto api usando a rota /hook.
• Os parâmetros principalId e principalType são passados como parâmetros conhecidos.

Os parâmetros conhecidos são baseados em convenção e não devem ser acompanhados com um valor correspondente quando passados usando a API WithParameter. Parâmetros conhecidos simplificam algumas funcionalidades comuns, como atribuições de função , quando adicionados aos modelos Bicep, conforme mostrado no exemplo anterior. As atribuições de função são necessárias para que o webhook do Event Grid envie eventos para o endpoint especificado. Para obter mais informações, consulte atribuição de função do Remetente de Dados da Grade de Eventos.

Obtenha resultados a partir de referências do Bicep

Além de passar parâmetros para modelos Bicep, você também pode obter resultados dos modelos Bicep. Considere o seguinte modelo Bicep, que define um output chamado endpoint:

param storageName string
param location string = resourceGroup().location

resource myStorageAccount 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: storageName
  location: location
  kind: 'StorageV2'
  sku:{
    name:'Standard_LRS'
    tier: 'Standard'
  }
  properties: {
    accessTier: 'Hot'
  }
}

output endpoint string = myStorageAccount.properties.primaryEndpoints.blob

O Bicep define uma saída chamada endpoint. Para obter a saída do modelo Bicep, chame o método GetOutput em uma instância de IResourceBuilder<AzureBicepResource>, conforme demonstrado no seguinte snippet de código C#:

var storage = builder.AddBicepTemplate(
        name: "storage",
        bicepFile: "../infra/storage.bicep"
    );

var endpoint = storage.GetOutput("endpoint");

Neste exemplo, a saída do modelo Bicep é recuperada e armazenada em uma variável de endpoint. Normalmente, você passaria essa saída como uma variável de ambiente para outro recurso que depende dele. Por exemplo, se você tivesse um projeto de Minimal API ASP.NET Core que dependesse desse endpoint, você poderia passar a saída como uma variável de ambiente para o projeto usando o seguinte trecho de código:

var storage = builder.AddBicepTemplate(
                name: "storage",
                bicepFile: "../infra/storage.bicep"
            );

var endpoint = storage.GetOutput("endpoint");

var apiService = builder.AddProject<Projects.AspireSample_ApiService>(
        name: "apiservice"
    )
    .WithEnvironment("STORAGE_ENDPOINT", endpoint);

Para obter mais informações, consulte os resultados do Bicep em e.

Obter resultados secretos de referências do Bicep

É importante evitar saídas para segredos ao trabalhar com o Bicep. Se uma saída for considerada uma secreta, o que significa que ela não deve ser exposta em logs ou em outros locais, você pode tratá-la como tal. Isso pode ser feito armazenando o segredo em Azure Key Vault e referenciando-o no modelo Bicep. A integração Azure do .NET Aspirefornece um padrão para armazenar com segurança as saídas do modelo Bicep, permitindo que os recursos usem o parâmetro keyVaultName para armazenar segredos em Azure Key Vault.

Considere o seguinte modelo Bicep como um exemplo que ajuda a demonstrar esse conceito de proteger saídas secretas:

param databaseAccountName string
param keyVaultName string

param databases array = []

@description('Tags that will be applied to all resources')
param tags object = {}

param location string = resourceGroup().location

var resourceToken = uniqueString(resourceGroup().id)

resource cosmosDb 'Microsoft.DocumentDB/databaseAccounts@2023-04-15' = {
    name: replace('${databaseAccountName}-${resourceToken}', '-', '')
    location: location
    kind: 'GlobalDocumentDB'
    tags: tags
    properties: {
        consistencyPolicy: { defaultConsistencyLevel: 'Session' }
        locations: [
            {
                locationName: location
                failoverPriority: 0
            }
        ]
        databaseAccountOfferType: 'Standard'
    }

    resource db 'sqlDatabases@2023-04-15' = [for name in databases: {
        name: '${name}'
        location: location
        tags: tags
        properties: {
            resource: {
                id: '${name}'
            }
        }
    }]
}

var primaryMasterKey = cosmosDb.listKeys(cosmosDb.apiVersion).primaryMasterKey

resource vault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
    name: keyVaultName

    resource secret 'secrets@2023-07-01' = {
        name: 'connectionString'
        properties: {
            value: 'AccountEndpoint=${cosmosDb.properties.documentEndpoint};AccountKey=${primaryMasterKey}'
        }
    }
}

O modelo Bicep precedente espera um parâmetro keyVaultName, entre outros parâmetros. Em seguida, ele define um recurso Azure Cosmos DB e armazena um segredo em Azure Key Vault, chamado connectionString, que representa a string de conexão completamente qualificada para a instância Cosmos DB. Para acessar esse valor de cadeia de conexão secreta, você pode usar o seguinte snippet de código:

var cosmos = builder.AddBicepTemplate("cosmos", "../infra/cosmosdb.bicep")
    .WithParameter("databaseAccountName", "fallout-db")
    .WithParameter(AzureBicepResource.KnownParameters.KeyVaultName)
    .WithParameter("databases", ["vault-33", "vault-111"]);

var connectionString =
    cosmos.GetSecretOutput("connectionString");

builder.AddProject<Projects.WebHook_Api>("api")
    .WithEnvironment(
        "ConnectionStrings__cosmos",
        connectionString);

No trecho de código anterior, o modelo Bicep cosmos é adicionado como referência ao builder. A saída secreta connectionString é recuperada do template Bicep e armazenada em uma variável. Em seguida, a saída secreta é passada como uma variável de ambiente (ConnectionStrings__cosmos) para o projeto de api. Essa variável de ambiente é usada para se conectar à instância de Cosmos DB.

Quando esse recurso for implantado, o mecanismo de implantação subjacente automaticamente os segredos de referência de Azure Key Vault. Para garantir o isolamento secreto, .NET.NET Aspire cria um Key Vault por fonte.

Publicação

Quando você publica seu aplicativo, o Bicep gerado pelo provisionamento de Azure é usado pelo Azure Developer CLI para criar os recursos Azure em sua assinatura Azure. .NET .NET Aspire gera um manifesto de publicação , que também é uma parte vital do processo de publicação. O Azure Developer CLI é uma ferramenta de linha de comando que fornece um conjunto de comandos para gerenciar Azure recursos.

Para obter mais informações sobre publicação e implantação, consulte Implantar um projeto de .NET Aspire para Azure Container Apps usando oAzure Developer CLI (guia detalhado).