Implantar Orleans no Serviço de Aplicativo do Azure

2025-05-29

Neste tutorial, saiba como implantar um Orleans aplicativo de carrinho de compras no Serviço de Aplicativo do Azure. Este guia percorre um aplicativo de exemplo que suporta os seguintes recursos:

Carrinho de compras: Um aplicativo de carrinho de compras simples usando Orleans para seu suporte de estrutura multiplataforma e recursos escaláveis de aplicativos distribuídos.
- Gestão de inventário: Editar e/ou criar inventário de produtos.
- Inventário da loja: Explore os produtos que podem ser comprados e adicione-os ao carrinho.
- Carrinho: Visualize um resumo de todos os itens no carrinho e gerencie esses itens removendo ou alterando a quantidade de cada item.

Com uma compreensão do aplicativo e seus recursos, saiba como implantar o aplicativo no Serviço de Aplicativo do Azure usando as Ações do GitHub, as CLIs do .NET e do Azure e o Azure Bicep. Além disso, saiba como configurar a rede virtual para o aplicativo no Azure.

Neste tutorial, aprenderás como:

Implantar um Orleans aplicativo no Serviço de Aplicativo do Azure
Automatize a implantação usando o GitHub Actions e o Azure Bicep
Configurar a rede virtual para o aplicativo no Azure

Pré-requisitos

Uma conta do GitHub
Leia uma introdução ao Orleans
O SDK do .NET 8
Azure CLI
Um ambiente de desenvolvimento integrado (IDE) .NET
- Sinta-se à vontade para usar o Visual Studio ou o Visual Studio Code

Executar a aplicação localmente

Para executar o aplicativo localmente, bifurque o repositório Azure Samples: Orleans Cluster on Azure App Service e clone-o para sua máquina local. Uma vez clonado, abra a solução em um IDE de sua escolha. Se estiver a usar o Visual Studio, clique com o botão direito do rato no projeto OrleansShoppingCart.Silo, selecione Definir como projeto de inicialização e, em seguida, execute a aplicação. Caso contrário, execute o aplicativo usando o seguinte comando da CLI do .NET:

dotnet run --project Silo\Orleans.ShoppingCart.Silo.csproj

Para obter mais informações, consulte dotnet run. Com o aplicativo em execução, navegue e teste seus recursos. Toda a funcionalidade do aplicativo quando executado localmente depende da persistência na memória e do clustering local. Além disso, utiliza o pacote Bogus NuGet para gerar produtos falsos. Pare o aplicativo selecionando a opção Parar depuração no Visual Studio ou pressionando Ctrl+C na CLI do .NET.

Dentro do aplicativo de carrinho de compras

Orleans é uma estrutura confiável e escalável para a criação de aplicativos distribuídos. Para este tutorial, implante um aplicativo de carrinho de compras simples criado usando Orleans o Serviço de Aplicativo do Azure. O aplicativo expõe a capacidade de gerenciar inventário, adicionar e remover itens em um carrinho e comprar produtos disponíveis. O cliente é construído usando Blazor com um modelo de hospedagem de servidor. O aplicativo é arquitetado da seguinte maneira:

O diagrama anterior mostra que o cliente é o aplicativo Blazor do lado do servidor. É composto por vários serviços que consomem um grão correspondente Orleans . Cada serviço emparelha com um grão Orleans da seguinte forma:

InventoryService: Consome IInventoryGrain onde o estoque é particionado por categoria de produto.
ProductService: Consome o IProductGrain, onde um único produto está ligado a uma única instância de grão por Id.
ShoppingCartService: Consome-se o IShoppingCartGrain em que um único utilizador tem apenas uma única instância de carrinho de compras, independentemente dos clientes que o utilizam.

A solução contém três projetos:

Orleans.ShoppingCart.Abstractions: Uma biblioteca de classes que define os modelos e interfaces para o aplicativo.
Orleans.ShoppingCart.Grains: Uma biblioteca de classes que define os componentes que implementam a lógica de negócios da aplicação.
Orleans.ShoppingCart.Silos: Uma aplicação Blazor no lado do servidor que hospeda o Orleans silo.

A experiência do cliente

O aplicativo cliente do carrinho de compras tem várias páginas, cada uma representando uma experiência de usuário diferente. A interface do usuário do aplicativo é criada usando o pacote NuGet MudBlazor .

Página inicial

Algumas frases simples ajudam a entender a finalidade do aplicativo e adicionam contexto a cada item do menu de navegação.

Página de inventário da loja

Uma página com todos os produtos disponíveis para compra. Os itens podem ser adicionados ao carrinho a partir desta página.

Página do carrinho vazia

Se nada tiver sido adicionado ao carrinho, a página renderizará uma mensagem indicando que nenhum item está no carrinho.

Itens adicionados ao carrinho enquanto estão na página de inventário da loja

Quando os itens são adicionados ao carrinho enquanto estão na página de inventário da loja, o aplicativo exibe uma mensagem indicando que o item foi adicionado.

Página de gestão de produtos

Gerencie o inventário a partir desta página. Os produtos podem ser adicionados, editados e removidos do inventário.

Página de gerenciamento de produtos criar nova caixa de diálogo

Clicar no botão Criar novo produto exibe uma caixa de diálogo que permite a criação de um novo produto.

Itens na página do carrinho

Quando os itens estiverem no carrinho, visualize-os, altere sua quantidade e até mesmo remova-os. Um resumo dos itens no carrinho e o custo total antes de impostos é mostrado.

Importante

Quando este aplicativo é executado localmente em um ambiente de desenvolvimento, ele usa clustering localhost, armazenamento na memória e um silo local. Ele também preenche o inventário com dados falsos gerados automaticamente usando o pacote Bogus NuGet. Isso é intencional para demonstrar a funcionalidade.

Visão geral da implantação

Orleans Os aplicativos são projetados para aumentar e expandir de forma eficiente. Para fazer isso, as instâncias do aplicativo se comunicam diretamente por meio de soquetes TCP. Portanto, Orleans requer conectividade de rede entre silos. O Serviço de Aplicativo do Azure dá suporte a esse requisito por meio da integração de rede virtual e da configuração adicional, instruindo o Serviço de Aplicativo a alocar portas de rede privada para instâncias de aplicativo.

Ao implantar Orleans no Serviço de Aplicativo do Azure, execute as seguintes ações para garantir que os hosts possam se comunicar:

Habilite a integração de rede virtual seguindo o guia Habilitar integração com uma rede virtual do Azure .
Configure o aplicativo com portas privadas usando a CLI do Azure, conforme descrito na seção Configurar contagem de portas privadas usando a CLI do Azure . O modelo Bicep na seção Explore the Bicep templates abaixo mostra como configurar essa configuração via Bicep.
Se estiver implantando no Linux, certifique-se de que os hosts escutem todos os endereços IP, conforme descrito na seção Configurar rede de host .

Configurar a contagem de portas privadas usando a CLI do Azure

az webapp config set -g '<resource-group-name>' --subscription '<subscription-id>' -n '<app-service-app-name>' --generic-configurations '{\"vnetPrivatePortsCount\": "2"}'

Configurar rede de host

Depois de configurar o Serviço de Aplicativo do Azure com integração de rede virtual (VNet) e defini-lo para fornecer instâncias de aplicativo com pelo menos duas portas privadas cada, duas variáveis de ambiente adicionais são fornecidas aos processos do seu aplicativo: WEBSITE_PRIVATE_IP e WEBSITE_PRIVATE_PORTS. Estas variáveis fornecem duas informações importantes:

Qual endereço IP outros hosts em sua rede virtual podem usar para entrar em contato com uma determinada instância do aplicativo; e ainda
Quais portas nesse endereço IP serão roteadas para essa instância do aplicativo

A WEBSITE_PRIVATE_IP variável especifica um IP roteável da rede virtual, mas não necessariamente um endereço IP ao qual a instância do aplicativo pode se vincular diretamente. Por esse motivo, instrua o host a ligar-se a todos os endereços internos passando listenOnAnyHostAddress: true para a chamada do método ConfigureEndpoints. O exemplo a seguir configura uma ISiloBuilder instância para consumir as variáveis de ambiente injetadas e escutar nas interfaces corretas:

var endpointAddress = IPAddress.Parse(builder.Configuration["WEBSITE_PRIVATE_IP"]!);
var strPorts = builder.Configuration["WEBSITE_PRIVATE_PORTS"]!.Split(',');
if (strPorts.Length < 2)
{
    throw new Exception("Insufficient private ports configured.");
}

var (siloPort, gatewayPort) = (int.Parse(strPorts[0]), int.Parse(strPorts[1]));

siloBuilder
    .ConfigureEndpoints(endpointAddress, siloPort, gatewayPort, listenOnAnyHostAddress: true)

O código acima também está presente no Azure Samples: Orleans Cluster no repositório do Serviço de Aplicativo do Azure , permitindo exibi-lo no contexto do restante da configuração do host.

Implantar no Serviço de Aplicações do Azure

Um aplicativo típico Orleans consiste em um cluster de processos de servidor (silos) onde os grãos vivem, e um conjunto de processos de cliente (geralmente servidores web) recebendo solicitações externas, transformando-as em chamadas de método de grão e retornando resultados. Assim, a primeira etapa para executar um Orleans aplicativo é iniciar um cluster de silos. Para fins de teste, um cluster pode consistir em um único silo.

Observação

Para uma implantação de produção confiável, você desejaria mais de um silo em um cluster para tolerância a falhas e escala.

Antes de implantar o aplicativo, crie um Grupo de Recursos do Azure (ou você pode usar um existente). Para criar um novo Grupo de Recursos do Azure, use um dos seguintes artigos:

Anote o nome do grupo de recursos escolhido; você precisa dele mais tarde para implantar o aplicativo.

Criar um "service principal"

Para automatizar a implantação da aplicação, precisa criar um principal de serviço. Esta é uma conta da Microsoft que tem permissão para gerenciar recursos do Azure em seu nome.

az ad sp create-for-rbac --sdk-auth --role Contributor \
  --name "<display-name>"  --scopes /subscriptions/<your-subscription-id>

As credenciais JSON criadas são semelhantes às seguintes, mas com valores reais para seu cliente, assinatura e locatário:

{
  "clientId": "<your client id>",
  "clientSecret": "<your client secret>",
  "subscriptionId": "<your subscription id>",
  "tenantId": "<your tenant id>",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com/",
  "resourceManagerEndpointUrl": "https://brazilus.management.azure.com",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com",
  "managementEndpointUrl": "https://management.core.windows.net"
}

Copie a saída do comando para a área de transferência e continue para o passo seguinte.

Criar um segredo do GitHub

O GitHub fornece um mecanismo para criar segredos criptografados. Os segredos que você cria estão disponíveis para uso nos fluxos de trabalho do GitHub Actions. Você verá como usar as Ações do GitHub para automatizar a implantação do aplicativo em conjunto com o Azure Bicep. O Bicep é uma linguagem específica do domínio que utiliza sintaxe declarativa para implementar recursos do Azure. Para obter mais informações, consulte O que é Bicep?. Usando a saída da etapa Criar um principal do serviço, é necessário criar um segredo do GitHub nomeado AZURE_CREDENTIALS com as credenciais formatadas em JSON.

No repositório do GitHub, selecione Configurações>Segredos>Criar um novo segredo. Insira o nome AZURE_CREDENTIALS e cole as credenciais JSON da etapa anterior no campo Valor .

Para obter mais informações, consulte GitHub: segredos criptografados.

Preparar para a implantação do Azure

Empacote o aplicativo para implantação. Orleans.ShoppingCart.Silos No projeto, é definido um Target elemento que é executado após a Publish etapa. Este destino compacta o diretório de publicação em um arquivo silo.zip :

<Target Name="ZipPublishOutput" AfterTargets="Publish">
    <Delete Files="$(ProjectDir)\..\silo.zip" />
    <ZipDirectory SourceDirectory="$(PublishDir)" DestinationFile="$(ProjectDir)\..\silo.zip" />
</Target>

Há muitas maneiras de implantar um aplicativo .NET no Serviço de Aplicativo do Azure. Neste tutorial, use as Ações do GitHub, o Bíceps do Azure e as CLIs do .NET e do Azure. Considere o arquivo ./github/workflows/deploy.yml na raiz do repositório GitHub:

name: Deploy to Azure App Service

on:
  push:
    branches:
    - main

env:
  UNIQUE_APP_NAME: cartify
  AZURE_RESOURCE_GROUP_NAME: orleans-resourcegroup
  AZURE_RESOURCE_GROUP_LOCATION: centralus

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - name: Setup .NET 8.0
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: 8.0.x

    - name: .NET publish shopping cart app
      run: dotnet publish ./Silo/Orleans.ShoppingCart.Silo.csproj --configuration Release

    - name: Login to Azure
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

    - name: Flex bicep
      run: |
        az deployment group create \
          --resource-group ${{ env.AZURE_RESOURCE_GROUP_NAME }} \
          --template-file '.github/workflows/flex/main.bicep' \
          --parameters location=${{ env.AZURE_RESOURCE_GROUP_LOCATION }} \
            appName=${{ env.UNIQUE_APP_NAME }} \
          --debug

    - name: Webapp deploy
      run: |
        az webapp deploy --name ${{ env.UNIQUE_APP_NAME }} \
          --resource-group ${{ env.AZURE_RESOURCE_GROUP_NAME  }} \
          --clean true --restart true \
          --type zip --src-path silo.zip --debug

    - name: Staging deploy
      run: |
        az webapp deploy --name ${{ env.UNIQUE_APP_NAME }} \
          --slot ${{ env.UNIQUE_APP_NAME }}stg \
          --resource-group ${{ env.AZURE_RESOURCE_GROUP_NAME  }} \
          --clean true --restart true \
          --type zip --src-path silo.zip --debug

O fluxo de trabalho anterior do GitHub faz o seguinte:

Publica o aplicativo de carrinho de compras como um arquivo zip usando o comando dotnet publishing .
Inicia sessão no Azure usando credenciais do passo Criar um principal de serviço.
Avalia o arquivo main.bicep e inicia um grupo de implantação usando az deployment group create.
Implanta o arquivo silo.zip no Serviço de Aplicativo do Azure usando az webapp deploy.
- Uma implantação adicional para teste também está configurada.

O fluxo de trabalho é acionado em um push para a main branch. Para obter mais informações, consulte Ações do GitHub e .NET.

Sugestão

Se você encontrar problemas ao executar o fluxo de trabalho, talvez seja necessário verificar se a entidade de serviço tem todos os namespaces de provedor necessários registrados. Os seguintes namespaces de provedor são necessários:

Microsoft.Web
Microsoft.Network
Microsoft.OperationalInsights
Microsoft.Insights
Microsoft.Storage

Para obter mais informações, consulte Resolver erros para registro do provedor de recursos.

O Azure impõe restrições de nomenclatura e convenções para recursos. Atualize os valores no arquivo deploy.yml para as seguintes variáveis de ambiente:

UNIQUE_APP_NAME
AZURE_RESOURCE_GROUP_NAME
AZURE_RESOURCE_GROUP_LOCATION

Defina esses valores como seu nome de aplicativo exclusivo e seu nome e local do grupo de recursos do Azure.

Para obter mais informações, consulte Regras e restrições de nomenclatura para recursos do Azure.

Explore os modelos do Bicep

Quando o az deployment group create comando é executado, ele avalia o arquivo main.bicep . Esse arquivo contém os recursos do Azure a serem implantados. Pense nesta etapa como provisionamento de todos os recursos para implantação.

Importante

Se você estiver usando o Visual Studio Code, a experiência de criação de bíceps será aprimorada ao usar a extensão Bicep.

Existem muitos arquivos Bicep, cada um contendo recursos ou módulos (coleções de recursos). O arquivo main.bicep é o ponto de entrada e consiste principalmente em module definições:

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

module storageModule 'storage.bicep' = {
  name: 'orleansStorageModule'
  params: {
    name: '${appName}storage'
    location: location
  }
}

module logsModule 'logs-and-insights.bicep' = {
  name: 'orleansLogModule'
  params: {
    operationalInsightsName: '${appName}-logs'
    appInsightsName: '${appName}-insights'
    location: location
  }
}

resource vnet 'Microsoft.Network/virtualNetworks@2021-05-01' = {
  name: '${appName}-vnet'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '172.17.0.0/16',
        '192.168.0.0/16'
      ]
    }
    subnets: [
      {
        name: 'default'
        properties: {
          addressPrefix: '172.17.0.0/24'
          delegations: [
            {
              name: 'delegation'
              properties: {
                serviceName: 'Microsoft.Web/serverFarms'
              }
            }
          ]
        }
      }
      {
        name: 'staging'
        properties: {
          addressPrefix: '192.168.0.0/24'
          delegations: [
            {
              name: 'delegation'
              properties: {
                serviceName: 'Microsoft.Web/serverFarms'
              }
            }
          ]
        }
      }
    ]
  }
}

module siloModule 'app-service.bicep' = {
  name: 'orleansSiloModule'
  params: {
    appName: appName
    location: location
    vnetSubnetId: vnet.properties.subnets[0].id
    stagingSubnetId: vnet.properties.subnets[1].id
    appInsightsConnectionString: logsModule.outputs.appInsightsConnectionString
    appInsightsInstrumentationKey: logsModule.outputs.appInsightsInstrumentationKey
    storageConnectionString: storageModule.outputs.connectionString
  }
}

O arquivo Bicep anterior define o seguinte:

Dois parâmetros para o nome do grupo de recursos e o nome do aplicativo.
A storageModule definição, que especifica a conta de armazenamento.
A logsModule definição que estabelece os recursos do Azure Log Analytics e do Application Insights.
O recurso vnet, que define a rede virtual.
A siloModule definição, definindo o Serviço de Aplicativo do Azure.

Um resource muito importante é a Rede Virtual. O vnet recurso permite que o Serviço de Aplicativo do Azure se comunique com o Orleans cluster.

Sempre que um module é encontrado no arquivo Bicep, ele é avaliado através de outro arquivo Bicep contendo as definições de recurso. O primeiro módulo encontrado é storageModule, definido no arquivo storage.bicep :

param name string
param location string

resource storage 'Microsoft.Storage/storageAccounts@2021-08-01' = {
  name: name
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
}

var key = listKeys(storage.name, storage.apiVersion).keys[0].value
var protocol = 'DefaultEndpointsProtocol=https'
var accountBits = 'AccountName=${storage.name};AccountKey=${key}'
var endpointSuffix = 'EndpointSuffix=${environment().suffixes.storage}'

output connectionString string = '${protocol};${accountBits};${endpointSuffix}'

Os arquivos Bicep aceitam parâmetros, declarados usando a param palavra-chave. Da mesma forma, eles podem declarar saídas usando a output palavra-chave. O armazenamento resource depende do tipo e da Microsoft.Storage/storageAccounts@2021-08-01 versão. Ele é provisionado no local do grupo de recursos como um StorageV2 e Standard_LRS SKU. O ficheiro Bicep de armazenamento define a sua cadeia de conexão como um output. Isso connectionString é usado posteriormente pelo arquivo silo Bicep para se conectar à conta de armazenamento.

Em seguida, o arquivo logs-and-insights.bicep define os recursos do Azure Log Analytics e do Application Insights:

param operationalInsightsName string
param appInsightsName string
param location string

resource appInsights 'Microsoft.Insights/components@2020-02-02' = {
  name: appInsightsName
  location: location
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId: logs.id
  }
}

resource logs 'Microsoft.OperationalInsights/workspaces@2021-06-01' = {
  name: operationalInsightsName
  location: location
  properties: {
    retentionInDays: 30
    features: {
      searchVersion: 1
    }
    sku: {
      name: 'PerGB2018'
    }
  }
}

output appInsightsInstrumentationKey string = appInsights.properties.InstrumentationKey
output appInsightsConnectionString string = appInsights.properties.ConnectionString

Esse arquivo Bicep define os recursos do Azure Log Analytics e do Application Insights. O appInsights recurso é um web tipo e o logs recurso é um PerGB2018 tipo. Ambos os recursos appInsights e logs são provisionados no local do grupo de recursos. O recurso appInsights está ligado ao recurso logs pela propriedade WorkspaceResourceId. Esse arquivo Bicep define duas saídas usadas posteriormente pelo Serviço de Aplicativo module.

Finalmente, o arquivo app-service.bicep define o recurso do Serviço de Aplicativo do Azure:

param appName string
param location string
param vnetSubnetId string
param stagingSubnetId string
param appInsightsInstrumentationKey string
param appInsightsConnectionString string
param storageConnectionString string

resource appServicePlan 'Microsoft.Web/serverfarms@2021-03-01' = {
  name: '${appName}-plan'
  location: location
  kind: 'app'
  sku: {
    name: 'S1'
    capacity: 1
  }
}

resource appService 'Microsoft.Web/sites@2021-03-01' = {
  name: appName
  location: location
  kind: 'app'
  properties: {
    serverFarmId: appServicePlan.id
    virtualNetworkSubnetId: vnetSubnetId
    httpsOnly: true
    siteConfig: {
      vnetPrivatePortsCount: 2
      webSocketsEnabled: true
      netFrameworkVersion: 'v8.0'
      appSettings: [
        {
          name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
          value: appInsightsInstrumentationKey
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: appInsightsConnectionString
        }
        {
          name: 'ORLEANS_AZURE_STORAGE_CONNECTION_STRING'
          value: storageConnectionString
        }
        {
          name: 'ORLEANS_CLUSTER_ID'
          value: 'Default'
        }
      ]
      alwaysOn: true
    }
  }
}

resource stagingSlot 'Microsoft.Web/sites/slots@2022-03-01' = {
  name: '${appName}stg'
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    virtualNetworkSubnetId: stagingSubnetId
    siteConfig: {
      http20Enabled: true
      vnetPrivatePortsCount: 2
      webSocketsEnabled: true
      netFrameworkVersion: 'v8.0'
      appSettings: [
        {
          name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
          value: appInsightsInstrumentationKey
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: appInsightsConnectionString
        }
        {
          name: 'ORLEANS_AZURE_STORAGE_CONNECTION_STRING'
          value: storageConnectionString
        }
        {
          name: 'ORLEANS_CLUSTER_ID'
          value: 'Staging'
        }
      ]
      alwaysOn: true
    }
  }
}

resource slotConfig 'Microsoft.Web/sites/config@2021-03-01' = {
  name: 'slotConfigNames'
  parent: appService
  properties: {
    appSettingNames: [
      'ORLEANS_CLUSTER_ID'
    ]
  }
}

resource appServiceConfig 'Microsoft.Web/sites/config@2021-03-01' = {
  parent: appService
  name: 'metadata'
  properties: {
    CURRENT_STACK: 'dotnet'
  }
}

Esse arquivo Bicep configura o Serviço de Aplicativo do Azure como um aplicativo .NET 8. Ambos os recursos appServicePlan e appService são provisionados no local do grupo de recursos. O recurso appService está configurado para usar o SKU S1 com uma capacidade de 1. Além disso, o recurso está configurado para usar a vnetSubnetId sub-rede e HTTPS. Ele também configura a appInsightsInstrumentationKey chave de instrumentação, a appInsightsConnectionString cadeia de conexão e a storageConnectionString cadeia de conexão. O aplicativo de carrinho de compras usa esses valores.

A extensão de código do Visual Studio acima mencionada para Bicep inclui um visualizador. Todos esses arquivos Bicep são visualizados da seguinte forma:

Ambientes de teste

A infraestrutura de implantação pode ser implantada em ambientes de preparação. Estes são ambientes descartáveis, de curta duração, imutáveis e centrados em testes, muito úteis para realizar testes de implementações antes de promovê-las para produção.

Observação

Se o Serviço de Aplicativo for executado no Windows, cada Serviço de Aplicativo deverá estar em seu próprio Plano de Serviço de Aplicativo separado. Como alternativa, para evitar essa configuração, use o Serviço de Aplicativo no Linux e esse problema será resolvido.

Resumo

À medida que o código-fonte é atualizado e as alterações são pushfeitas na main ramificação do repositório, o fluxo de trabalho deploy.yml é executado. Ele provisiona os recursos definidos nos arquivos Bicep e implanta o aplicativo. O aplicativo pode ser expandido para incluir novos recursos, como autenticação, ou para oferecer suporte a várias instâncias. O objetivo principal desse fluxo de trabalho é demonstrar a capacidade de provisionar e implantar recursos em uma única etapa.

Além do visualizador da extensão Bicep, a página do grupo de recursos do portal do Azure é semelhante ao exemplo a seguir após o provisionamento e a implantação do aplicativo: