Implantar Orleans no Serviço de Aplicativo do Azure

Artigo
01/27/2024

Neste tutorial, você aprenderá como implantar um aplicativo de carrinho de compras do Orleans para Serviço de Aplicativo do Azure. O tutorial orienta você por meio de um aplicativo de amostra que dá suporte aos seguintes recursos:

Carrinho de compras: um aplicativo de carrinho de compras simples que usa Orleans para seu suporte à estrutura multiplataforma e seus recursos de aplicativos distribuídos escalonáveis.
- Gerenciamento de inventário: editar e/ou criar inventário de produtos.
- Inventário de lojas: explore os produtos adquiríveis e adicione-os ao carrinho.
- Carrinho: exibir um resumo de todos os itens no carrinho e gerenciar esses itens; remover ou alterar a quantidade de cada item.

Com o entendimento do aplicativo e seus recursos, você aprenderá a implantar o aplicativo em Serviço de Aplicativo do Azure usando as GitHub Actions, os CLIs do .NET e do Azure e o Azure Bicep. Além disso, você aprenderá a configurar a rede virtual para o aplicativo no Azure.

Neste tutorial, você aprenderá a:

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

Pré-requisitos

Uma conta do GitHub
Ler uma introdução a Orleans
O SDK do .NET 6
A CLI do Azure
Um ambiente de desenvolvimento integrado do .NET (IDE)
- Fique à vontade para usar o Visual Studio ou o Visual Studio Code

Executar o aplicativo localmente

Para executar o aplicativo localmente, bifurque as Exemplos do Azure: Cluster de Orleans no repositório do Serviço de Aplicativo do Azure e clone-o no computador local. Depois de clonado, abra a solução em um IDE de sua escolha. Se você estiver usando o Visual Studio, clique com o botão direito do mouse no projeto Orleans.ShoppingCart.Silo e selecione Definir como Projeto de Inicialização e execute o aplicativo. Caso contrário, você poderá executar o aplicativo usando o seguinte comando da CLI do .NET:

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

Para obter mais informações, confira dotnet run. Com o aplicativo em execução, você pode navegar e está livre para testar os recursos. Toda a funcionalidade do aplicativo ao ser executado localmente depende da persistência na memória, do clustering local e usa o pacote NuGet Falso para gerar produtos falsos. Interrompa 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 escalonável para a criação de aplicativos distribuídos. Neste tutorial, você implantará um aplicativo de carrinho de compras simples criado usando o Orleans no Serviço de Aplicativo do Azure. O aplicativo expõe a capacidade de gerenciar o inventário, adicionar e remover itens em um carrinho e comprar produtos disponíveis. O cliente é criado usando o 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 uma granularidade correspondente do Orleans. Cada serviço emparelha com uma granularidade do Orleans da seguinte maneira:

InventoryService: consome o IInventoryGrain em que o inventário é particionado por categoria de produto.
ProductService: consome o IProductGrain em que um único produto é amarrado a uma única instância de granularidade por Id.
ShoppingCartService: consome o IShoppingCartGrain em que um único usuário tem apenas uma única instância de carrinho de compras, independentemente dos clientes consumidores.

A solução contém dois projetos:

Orleans.ShoppingCart.Abstractions: uma biblioteca de classes que define os modelos e as interfaces do aplicativo.
Orleans.ShoppingCart.Grains: uma biblioteca de classes que define as granularidades que implementam a lógica de negócios do aplicativo.
Orleans.ShoppingCart.Silos: um aplicativo Blazor do lado do servidor que hospeda o silo do Orleans.

A experiência do usuário cliente

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

Home page

Algumas frases simples para o usuário entender a finalidade do aplicativo e adicionar contexto a cada item de menu de navegação.

Página de inventário da loja

Uma página que exibe todos os produtos que estão disponíveis para compra. Os itens podem ser adicionados ao carrinho a partir desta página.

Página de carrinho vazia

Quando você não adiciona nada ao carrinho, a página renderiza uma mensagem que indica que você não tem itens no carrinho.

Itens adicionados ao carrinho na página de inventário da loja

Quando os itens são adicionados ao carrinho durante a página de inventário da loja, o aplicativo exibe uma mensagem que indica que o item foi adicionado ao carrinho.

Página de gerenciamento do produto

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

Caixa de diálogo criar na página de gerenciamento de produto

Quando um usuário clica no botão Criar novo produto, o aplicativo exibe uma caixa de diálogo que permite que o usuário crie um novo produto.

Itens na página do carrinho

Quando os itens estão no seu carrinho, você pode visualizá-los, alterar sua quantidade e até removê-los do carrinho. É exibido para o usuário um resumo dos itens no carrinho e o custo total antes do imposto.

Importante

Quando esse aplicativo for executado localmente, em um ambiente de desenvolvimento, o aplicativo usará clustering localhost, armazenamento na memória e um silo local. Ele também propaga o inventário com dados falsos gerados automaticamente usando o pacote NuGet Falso. Isso tudo é intencional para demonstrar a funcionalidade.

Implantar no Serviço de Aplicativo do Azure

Um aplicativo típico do Orleans consiste em um cluster de processos de servidor (silos), em que reside a granularidade, e um conjunto de processos de cliente, geralmente servidores Web que recebem solicitações externas, as transformam em chamadas de método de granularidade e retornam resultados. Portanto, a primeira coisa que é necessário fazer para executar um aplicativo do Orleans é 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ê deseja mais de um silo em um cluster para escala e tolerância a falhas.

Antes de implantar o aplicativo, você precisa criar um Grupo de Recursos do Azure (ou 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ê precisará dele mais tarde para implantar o aplicativo.

Criar uma entidade de serviço

Para automatizar a implantação do aplicativo, você precisará criar uma entidade de serviço. Essa é uma conta 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 serã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 na área de transferência e continue para a próxima etapa.

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 em fluxos de trabalho das GitHub Actions. Você verá como o GitHub Actions pode ser usado para automatizar a implantação do aplicativo, em conjunto com o Azure Bicep. Bicep é uma DSL (linguagem específica de domínio) que usa uma sintaxe declarativa para implantar recursos do Azure. Para obter mais informações, confira O que é o Bicep? Usando a saída da etapa Criar uma entidade de serviço, você precisará criar o segredo AZURE_CREDENTIALS do GitHub 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, confira GitHub: segredos criptografados.

Preparar para a implantação do Azure

O aplicativo precisará ser empacotado para implantação. No projeto Orleans.ShoppingCart.Silos, definimos um elemento Target que é executado após a etapa Publish. Isso vai compactar 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 para Serviço de Aplicativo do Azure. Neste tutorial, você usará os GitHub Actions, o Azure Bicep e os CLIs do .NET e do Azure. Considere o arquivo ./github/workflows/deploy.yml na raiz do repositório do 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 6.0
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: 6.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

O fluxo de trabalho anterior do GitHub será:

Publique o aplicativo de carrinho de compras como um arquivo zip, usando o comando dotnet publish.
Faça logon no Azure usando as credenciais da etapa Criar uma entidade de serviço.
Avalie o arquivo main.bicep e inicie um grupo de implantação usando az deployment group create.
Implante o arquivo silo.zip para Serviço de Aplicativo do Azure usando az webapp deploy.

O fluxo de trabalho é acionado por um push na ramificação principal. Para obter mais informações, confira GitHub Actions e .NET.

Dica

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 obrigatórios:

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

Para mais informações, confira Resolver erros de registro do provedor de recursos.

O Azure impõe convenções e restrições de nomenclatura para recursos. Você precisa atualizar os valores de arquivo deploy.yml para o seguinte:

UNIQUE_APP_NAME
AZURE_RESOURCE_GROUP_NAME
AZURE_RESOURCE_GROUP_LOCATION

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

Para saber mais, confira Regras de nomenclatura e restrições para recursos do Azure.

Explorar os modelos do Bicep

Quando o comando az deployment group create for executado, ele avaliará o arquivo main.bicep. Esse arquivo contém os recursos do Azure que você deseja implantar. Uma maneira de pensar nessa etapa é que ela provisiona todos os recursos para implantação.

Importante

Se você estiver usando o Visual Studio Code, a experiência de criação do bicep será melhorada ao usar a Extensão Bicep.

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

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'
      ]
    }
    subnets: [
      {
        name: 'default'
        properties: {
          addressPrefix: '172.17.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
    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 configuração storageModule, que define a conta de armazenamento.
A configuração logsModule, que define os recursos do Azure Log Analytics e do Application Insights.
O recurso vnet, que define a rede virtual.
A configuração siloModule, que define o Serviço de Aplicativo do Azure.

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

Sempre que um module é encontrado no arquivo bicep, ele é avaliado por meio de outro arquivo bicep que contém as definições do recurso. O primeiro módulo encontrado foi o storageModule, que é 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, que são declarados usando a palavra-chave param. Da mesma forma, eles também podem declarar saídas usando a palavra-chave output. O armazenamento resource depende do tipo e da versão de Microsoft.Storage/storageAccounts@2021-08-01. Ele será provisionado no local do grupo de recursos, como uma SKU de StorageV2 e Standard_LRS. O bicep de armazenamento define sua cadeia de conexão como um output. O connectionString é usado posteriormente pelo silo bicep para se conectar à conta de armazenamento.

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

O arquivo bicep define os recursos do Azure Log Analytics e do Application Insights. O recurso appInsights é um tipo web e o recurso logs é um tipo PerGB2018. O recurso appInsights e o recurso logs são provisionados no local do grupo de recursos. O recurso appInsights está vinculado ao recurso logs por meio da propriedade WorkspaceResourceId. Há duas saídas definidas neste bicep, usadas posteriormente pelo Serviço de Aplicativo module.

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

param appName string
param location string
param vnetSubnetId 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: 'v6.0'
      appSettings: [
        {
          name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
          value: appInsightsInstrumentationKey
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: appInsightsConnectionString
        }
        {
          name: 'ORLEANS_AZURE_STORAGE_CONNECTION_STRING'
          value: storageConnectionString
        }
      ]
      alwaysOn: true
    }
  }
}

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

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

A extensão do Visual Studio Code mencionada anteriormente para o Bicep inclui um visualizador. Todos esses arquivos bicep são visualizados da seguinte maneira:

Resumo

À medida que você atualiza o código-fonte e push é alterado para main na ramificação do repositório, o fluxo de trabalho deploy.yml será executado. Ele provisionará os recursos definidos nos arquivos bicep e implantará o aplicativo. O aplicativo pode ser expandido para incluir novos recursos, como autenticação ou para dar suporte a várias instâncias do aplicativo. 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 portal do Azure seria semelhante ao exemplo a seguir após o provisionamento e a implantação do aplicativo:

Compartilhar via