Implantação corporativa usando o Ambiente do Serviço de Aplicativo do Azure

Essa arquitetura de referência demonstra uma carga de trabalho corporativa comum que usa o Ambiente do Serviço de Aplicativo versão 3. Também descreve as melhores práticas para reforçar a segurança da carga de trabalho.

Uma implementação de referência para essa arquitetura está disponível no GitHub.

Arquitetura

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de trabalho

O Ambiente do Serviço de Aplicativo versão 3 fornece recursos diferentes das versões anteriores e vantagens em relação a essas versões. Para obter mais informações, consulte Diferenças de recursos. Você pode implantar o Ambiente do Serviço de Aplicativo de duas maneiras:

• Como um ambiente de serviço de aplicativo externo com um endereço IP público
• Como um Ambiente do Serviço de Aplicativo interno com um endereço IP interno que pertence ao ILB (balanceador de carga interno)

Essa arquitetura de referência implanta um aplicativo Web corporativo em um Ambiente de Serviço de Aplicativo interno, também chamado de Ambiente de Serviço de Aplicativo ILB. Use um ambiente do ILB App Service quando o cenário exigir:

• Hospede aplicativos de intranet com segurança aprimorada na nuvem e acesse-os por meio de uma VPN site a site ou da Rota Expressa do Azure.
• Forneça uma camada de proteção para aplicativos usando um firewall de aplicativo Web (WAF).
• Alojar aplicações na cloud que não estão listadas em servidores DNS públicos.
• Crie aplicativos back-end isolados da Internet, com os quais seus aplicativos front-end podem se integrar de forma altamente segura.

O Ambiente do Serviço de Aplicativo deve ser sempre implantado em sua própria sub-rede na rede virtual corporativa para permitir um controle rígido do tráfego de entrada e saída. Nessa sub-rede, os aplicativos do Serviço de Aplicativo são implantados em um ou mais planos do Serviço de Aplicativo, que é uma coleção de recursos físicos necessários para executar o aplicativo. Dependendo da complexidade e do requisito de recursos, um plano do Serviço de Aplicativo pode ser compartilhado entre vários aplicativos. Essa implementação de referência implanta um aplicativo Web chamado Aplicativo de votação, que interage com uma API da Web privada e uma função. Ele também implanta um aplicativo Web fictício chamado Test App para demonstrar implantações de vários aplicativos. Cada aplicativo do Serviço de Aplicativo é hospedado em seu próprio plano do Serviço de Aplicativo, permitindo que cada um seja dimensionado de forma independente, se necessário. Todos os recursos exigidos por esses aplicativos hospedados, como armazenamento e computação, bem como as necessidades de dimensionamento, são totalmente gerenciados pela infraestrutura do Ambiente do Serviço de Aplicativo.

O aplicativo de votação simples nesta implementação permite que os usuários visualizem entradas existentes, criem novas entradas e votem em entradas existentes. A API web é usada para criação e recuperação de entradas e votos. Os dados em si são armazenados em um banco de dados do SQL Server. Para demonstrar atualizações de dados assíncronas, o aplicativo Web enfileira votos recém-adicionados em uma instância do Service Bus. A função seleciona votos enfileirados e atualiza o banco de dados SQL. O Azure Cosmos DB é usado para armazenar um anúncio de maquete, que o aplicativo Web recupera para exibir no navegador. O aplicativo usa o Cache Redis do Azure para gerenciamento de cache. É usado um Cache Redis do Azure de camada Premium, que permite a configuração para a mesma rede virtual que o Ambiente do Serviço de Aplicativo, em sua própria sub-rede. Isso fornece segurança e isolamento aprimorados para o cache.

As aplicações Web são os únicos componentes acessíveis à Internet através do Application Gateway. A API e a função são inacessíveis a partir de um cliente de Internet. O tráfego de entrada é protegido por um WAF configurado no Application Gateway.

Componentes

Os seguintes serviços são fundamentais para bloquear o Ambiente do Serviço de Aplicativo nessa arquitetura:

• A Rede Virtual do Azure é uma rede de nuvem privada do Azure que pertence a uma empresa. Ele fornece segurança e isolamento aprimorados baseados em rede. O Ambiente do Serviço de Aplicativo é uma implantação do Serviço de Aplicativo em uma sub-rede da rede virtual de propriedade da empresa. Ele permite que a empresa controle rigorosamente esse espaço de rede e os recursos que acessa usando grupos de segurança de rede e pontos de extremidade privados.

• O Application Gateway é um balanceador de carga de tráfego da Web no nível do aplicativo com descarregamento de TLS/SSL e WAF. Ele escuta em um endereço IP público e roteia o tráfego para o ponto de extremidade do aplicativo no ILB App Service Environment. Como se trata de roteamento no nível do aplicativo, ele pode rotear o tráfego para vários aplicativos dentro do mesmo Ambiente do Serviço de Aplicativo ILB. Para obter mais informações, consulte Hospedagem de vários sites do Application Gateway.

• O Firewall do Azure é usado para restringir o tráfego de saída do aplicativo Web. O tráfego de saída que não passa pelos canais de ponto de extremidade privados e uma tabela de rotas exigida pelo Ambiente do Serviço de Aplicativo é direcionado para a sub-rede do firewall. Por uma questão de simplicidade, essa arquitetura configura todos os pontos de extremidade privados na sub-rede de serviços.

• O Microsoft Entra ID ou Microsoft Entra ID fornece direitos de acesso e gerenciamento de permissões para recursos e serviços do Azure. As Identidades Gerenciadas atribuem identidades a serviços e aplicativos, gerenciados automaticamente pelo Microsoft Entra ID. Essas identidades podem ser usadas para autenticar em qualquer serviço que ofereça suporte à autenticação do Microsoft Entra. Isso elimina a necessidade de configurar explicitamente as credenciais para esses aplicativos. Essa arquitetura atribui uma identidade gerenciada ao aplicativo Web.

• O Azure Key Vault armazena todos os segredos e credenciais exigidos pelos aplicativos. Use esta opção sobre o armazenamento de segredos diretamente no aplicativo.

• O GitHub Actions fornece integração contínua e recursos de implantação contínua nessa arquitetura. Como o Ambiente do Serviço de Aplicativo está na rede virtual, uma máquina virtual é usada como uma caixa de salto dentro da rede virtual para implantar aplicativos nos planos do Serviço de Aplicativo. A ação cria os aplicativos fora da rede virtual. Para maior segurança e conectividade RDP/SSH perfeita, considere usar o Azure Bastion para a jumpbox.

Configuração multi-site

Transfira um ficheiro do Visio desta arquitetura.

O Ambiente do Serviço de Aplicativo Interno pode hospedar vários aplicativos Web e APIs com pontos de extremidade HTTP. Estas aplicações são bloqueadas a partir da Internet pública, uma vez que o IP ILB só é acessível a partir da Rede Virtual. O Application Gateway é usado para expor seletivamente esses aplicativos à Internet. O Ambiente do Serviço de Aplicativo atribui uma URL padrão a cada aplicativo do Serviço de Aplicativo como <default-appName>.<app-service-environment-domain>.appserviceenvironment.net. É criada uma zona DNS privada que mapeia o nome de domínio do Ambiente do Serviço de Aplicativo para o endereço IP ILB do Ambiente do Serviço de Aplicativo. Isso evita o uso de um DNS personalizado para acessar os aplicativos dentro da rede virtual.

O Application Gateway é configurado de forma que um ouvinte ouça na porta HTTPS solicitações para o endereço IP do gateway. Por uma questão de simplicidade, esta implementação não utiliza um registo de nome DNS público. Ele requer que você modifique o arquivo localhost em seu computador para apontar uma URL escolhida arbitrariamente para o IP do Application Gateway. Para simplificar, o ouvinte usa um certificado autoassinado para processar essas solicitações. O Application Gateway tem pools de back-end para a URL padrão de cada aplicativo do Serviço de Aplicativo. Uma regra de roteamento é configurada para conectar o ouvinte ao pool de back-end. São criadas configurações HTTP que determinam se a conexão entre o gateway e o Ambiente do Serviço de Aplicativo será criptografada. Essas configurações também são usadas para substituir o cabeçalho de host HTTP de entrada por um nome de host escolhido no pool de back-end. Essa implementação usa certificados padrão criados para as URLs de aplicativo padrão do Ambiente do Serviço de Aplicativo, que são confiáveis pelo gateway. A solicitação é redirecionada para a URL padrão do aplicativo correspondente. O DNS privado vinculado à rede virtual encaminha essa solicitação para o IP do ILB. Em seguida, o Ambiente do Serviço de Aplicativo encaminha isso para o serviço de aplicativo solicitado. Qualquer comunicação HTTP dentro dos aplicativos do Ambiente do Serviço de Aplicativo passa pelo DNS privado. Observe que as configurações de ouvinte, pool de back-end, regra de roteamento e HTTP precisam ser configuradas no gateway de aplicativo para cada aplicativo do Ambiente do Serviço de Aplicativo.

Consulte appgw.bicep e dns.bicep para saber como essas configurações são feitas para permitir vários sites. O aplicativo Web nomeado testapp é um aplicativo vazio criado para demonstrar essa configuração. Esses arquivos JSON são acessados a partir do script de implantação commands_std.azcli. Eles também são acessados pelo commands_ha.azcli, que é usado para uma implantação de ambiente de serviço de aplicativo multissite de alta disponibilidade.

Detalhes do cenário

O Serviço de Aplicativo do Azure é um serviço PaaS usado para hospedar uma variedade de aplicativos no Azure: aplicativos Web, aplicativos de API, funções e aplicativos móveis. O Ambiente do Serviço de Aplicativo permite que as empresas implantem seus aplicativos do Serviço de Aplicativo em uma sub-rede em sua própria Rede Virtual do Azure, fornecendo um ambiente isolado, altamente escalável e dedicado para suas cargas de trabalho na nuvem.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

Ambiente do Serviço de Aplicações

Um Ambiente de Serviço de Aplicativo interno é implantado na rede virtual corporativa, oculto da Internet pública. Ele permite que a empresa bloqueie seus serviços de back-end, como APIs e funções da Web, no nível da rede. Qualquer aplicativo do Ambiente do Serviço de Aplicativo com um ponto de extremidade HTTP pode ser acessado por meio do ILB, de dentro da rede virtual. O Application Gateway está configurado para encaminhar solicitações para o aplicativo Web por meio do ILB. O próprio aplicativo Web passa pelo ILB para acessar a API. Os componentes críticos de back-end, ou seja, a API e a função, são efetivamente inacessíveis a partir da Internet pública.

Os certificados padrão são criados para cada serviço de aplicativo para o nome de domínio padrão atribuído pelo Ambiente do Serviço de Aplicativo. Esse certificado pode aumentar a segurança do tráfego entre o gateway e o aplicativo e pode ser necessário em determinados cenários. Esses certificados não são visíveis através do navegador do cliente. Ele só pode responder aos certificados configurados no Application Gateway.

Gateway de Aplicação

A implementação de referência configura o Application Gateway programaticamente em appgw.bicep. O arquivo commands_std.azcli usa essa configuração ao implantar o gateway:

az deployment group create --resource-group $RGNAME --template-file templates/appgw.bicep --parameters vnetName=$VNET_NAME appgwSubnetAddressPrefix=$APPGW_PREFIX appgwApplications=@appgwApps.parameters.json
APPGW_PUBLIC_IP=$(az deployment group show -g $RGNAME -n appgw --query properties.outputs.appGwPublicIpAddress.value -o tsv)

Encriptação

Conforme descrito em Visão geral da terminação TLS e TLS de ponta a ponta com o Application Gateway, o Application Gateway pode usar TLS (Transport Layer Security)/SSL (Secure Sockets Layer) para criptografar e proteger todo o tráfego de navegadores da Web. A criptografia pode ser configurada das seguintes maneiras:

• Criptografia encerrada no gateway. Os pools de back-end, neste caso, são configurados para HTTP. A criptografia para no gateway e o tráfego entre o gateway e o serviço de aplicativo não é criptografado. Como a criptografia exige muita CPU, o tráfego não criptografado no back-end melhora o desempenho e permite um gerenciamento de certificados mais simples. Isso fornece um nível razoável de segurança, uma vez que o back-end é protegido em virtude da configuração da rede.

• Criptografia de ponta a ponta. Em alguns cenários, como requisitos específicos de segurança ou conformidade, pode ser necessário que o tráfego seja criptografado entre o gateway e o aplicativo. Isso é conseguido usando a conexão HTTPS e configurando certificados no pool de back-end.

Esta implementação de referência usa certificados autoassinados para o Application Gateway. Para o código de produção, deve ser utilizado um certificado emitido por uma autoridade de certificação. Para obter uma lista dos tipos de certificado suportados, consulte Certificados suportados para terminação TLS. Leia Configurar um gateway de aplicativo com terminação TLS usando o portal do Azure para saber como criar criptografia terminada por gateway. As seguintes linhas de código em appgw.bicep configuram isso programaticamente:

          httpListeners: [for item in appgwApplications: {
          name: '${appgwListenerName}${item.name}'
          properties: {
            frontendIPConfiguration: {
              id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
            }
            frontendPort: {
              id: '${appgwId}/frontendPorts/port_443'
            }
            protocol: 'Https'
            sslCertificate: {
              id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
            }
            hostName: item.hostName
            requireServerNameIndication: true
          }
        }]

A implementação de referência demonstra a criptografia de ponta a ponta para o tráfego entre o Gateway de Aplicativo e os aplicativos Web no Ambiente do Serviço de Aplicativo. Os certificados SSL padrão são usados. Os pools de back-end nesta implementação são configurados para redirecionar o tráfego HTTPS com o nome do host substituído pelos nomes de domínio padrão associados aos aplicativos Web. O Application Gateway confia nos certificados SSL padrão porque eles são emitidos pela Microsoft. Consulte Configurar o Serviço de Aplicativo com o Application Gateway para obter informações sobre como essas configurações são feitas. O código a seguir de appgw.bicep mostra como isso é configurado na implementação de referência:

        backendHttpSettingsCollection: [for item in appgwApplications: {
        name: '${appgwHttpSettingsName}${item.name}'
        properties: {
          port: 443
          protocol: 'Https'
          cookieBasedAffinity: 'Disabled'
          pickHostNameFromBackendAddress: true
          requestTimeout: 20
          probe: {
            id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
          }
        }
      }]

Firewall de Aplicações Web

O Web Application Firewall (WAF) no Application Gateway protege os aplicativos Web contra ataques mal-intencionados, como injeção de SQL. Ele também é integrado ao Azure Monitor para monitorar ataques usando um log em tempo real. O WAF precisa ser habilitado no gateway, conforme descrito em Criar um gateway de aplicativo com um Firewall de Aplicativo Web usando o portal do Azure. A implementação de referência habilita o WAF programaticamente no arquivo appgw.bicep com o seguinte trecho:

        webApplicationFirewallConfiguration: {
        enabled: true
        firewallMode: 'Detection'
        ruleSetType: 'OWASP'
        ruleSetVersion: '3.0'
      }

Rede Virtual

Os grupos de segurança de rede podem ser associados a uma ou mais sub-redes na rede virtual. Estas são regras de segurança que permitem ou negam que o tráfego flua entre vários recursos do Azure. Essa arquitetura associa um grupo de segurança de rede separado para cada sub-rede. Isso permite o ajuste fino dessas regras por sub-rede, de acordo com os serviços contidos nessa sub-rede. Por exemplo, consulte a configuração para no arquivo ase.bicep para o grupo de segurança de rede para a sub-rede Ambiente do Serviço de Aplicativo e no arquivo appgw.bicep para o grupo de segurança de rede para "type": "Microsoft.Network/networkSecurityGroups" a sub-rede do Application Gateway.

Os pontos de extremidade privados permitem a conectividade privada de segurança aprimorada entre clientes e serviços do Azure em uma rede privada. Eles fornecem um endereço IP acessível de forma privada para o serviço do Azure, permitindo o tráfego de segurança aprimorada para um recurso de Link Privado do Azure. A plataforma valida conexões de rede, permitindo apenas aquelas que se conectam ao recurso Private Link especificado. Os pontos de extremidade privados oferecem suporte a políticas de rede, como grupos de segurança de rede, rotas definidas pelo usuário e grupos de segurança de aplicativos. Para melhorar a segurança, você deve habilitar pontos de extremidade privados para qualquer serviço do Azure que ofereça suporte a eles. Você pode então melhorar a segurança do serviço na rede virtual desativando o acesso público, bloqueando efetivamente qualquer acesso da Internet pública. Essa arquitetura configura pontos de extremidade privados para os serviços que oferecem suporte a ela: Barramento de Serviço do Azure, SQL Server, Cofre de Chaves e Azure Cosmos DB. Você pode ver a configuração em privatendpoints.bicep.

Para habilitar pontos de extremidade privados, você também precisa configurar zonas DNS privadas. Para obter mais informações, veja Configuração do DNS do Ponto Final Privado do Azure.

Firewall

O Firewall do Azure e os pontos de extremidade privados se complementam. Os pontos de extremidade privados ajudam a proteger os recursos, permitindo apenas o tráfego originado da sua rede virtual. O Firewall do Azure permite que você restrinja o tráfego de saída de seus aplicativos. Recomendamos que você permita que todo o tráfego de saída passe pela sub-rede do firewall, incluindo o tráfego de ponto final privado. Isso permite um melhor monitoramento do tráfego de saída. Para simplificar, essa arquitetura de referência configura todos os pontos de extremidade privados na sub-rede de serviços em vez de na sub-rede do firewall.

Para saber como o Firewall do Azure se integra ao Ambiente do Serviço de Aplicativo, consulte Configurando o Firewall do Azure com seu Ambiente do Serviço de Aplicativo. Qualquer tráfego que não atravesse os pontos de extremidade privados e a tabela de rotas de rede virtual é monitorado e fechado pelo firewall.

Microsoft Entra ID

O Microsoft Entra ID fornece recursos de segurança para autenticar aplicativos e autorizar o acesso a recursos. Essa arquitetura de referência usa dois recursos principais do Microsoft Entra ID: identidades gerenciadas e controle de acesso baseado em função do Azure.

Em aplicativos de nuvem, as credenciais necessárias para autenticar em serviços de nuvem devem ser protegidas. Idealmente, as credenciais nunca devem aparecer em estações de trabalho do desenvolvedor ou verificadas no controle do código-fonte. O Azure Key Vault fornece uma maneira de armazenar credenciais e segredos com segurança, mas o aplicativo ainda precisa se autenticar no Cofre da Chave para recuperá-los. Os recursos do Managed Identities for Azure fornecem aos serviços do Azure uma identidade gerenciada automaticamente no Microsoft Entra ID. Essa identidade pode ser usada para autenticar em qualquer serviço que ofereça suporte à autenticação do Microsoft Entra, incluindo o Cofre da Chave, sem credenciais no aplicativo.

O controle de acesso baseado em função do Azure (Azure RBAC) gerencia o acesso aos recursos do Azure. O que está incluído:

• Qual entidade tem o acesso: usuário, identidade gerenciada, entidade de segurança.
• Que tipo de acesso tem: proprietário, colaborador, leitor, administrador.
• Âmbito do acesso: recurso, grupo de recursos, subscrição ou grupo de gestão.

Você pode bloquear o acesso aos aplicativos do Ambiente do Serviço de Aplicativo controlando rigorosamente a função necessária e o tipo de acesso para cada aplicativo. Dessa forma, vários aplicativos podem ser implantados no mesmo ambiente do Serviço de Aplicativo de diferentes equipes de desenvolvimento. Por exemplo, o frontend pode ser tratado por uma equipe e o backend por outra. O RBAC do Azure pode ser usado para limitar o acesso de cada equipe ao(s) aplicativo(s) em que está trabalhando. Explore as funções personalizadas do Azure para criar funções adequadas à sua organização.

Key Vault

Alguns serviços dão suporte a identidades gerenciadas, mas usam o RBAC do Azure para configurar permissões para o aplicativo. Por exemplo, consulte as funções internas do Service Bus e o Azure RBAC no Azure Cosmos DB. O acesso do proprietário à assinatura é necessário para conceder essas permissões, embora o pessoal com acesso de Colaborador possa implantar esses serviços. Para permitir que uma equipe mais ampla de desenvolvedores possa executar os scripts de implantação, a próxima melhor opção é usar políticas nativas de controle de acesso do serviço:

• Para o Service Bus, são assinaturas de acesso compartilhado.
• Para o Azure Cosmos DB, são chaves.

As cadeias de conexão para essas políticas de controle de acesso são armazenadas no Cofre da Chave. O cofre em si é acessado por meio de identidades gerenciadas, que exigem o Azure RBAC. Defina a política de acesso para essas cadeias de conexão adequadamente. Por exemplo, somente leitura para o back-end, somente gravação para o frontend e assim por diante, em vez de usar a política de acesso raiz padrão.

O código a seguir em services.bicep mostra a configuração do Cofre da Chave para esses serviços:

      resource keyVaultName_CosmosKey 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'CosmosKey'
      properties: {
        value: cosmosName.listKeys().primaryMasterKey 
      }
    }

      resource keyVaultName_ServiceBusListenerConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusListenerConnectionString'
      properties: {
        value: listKeys(serviceBusName_ListenerSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

      resource keyVaultName_ServiceBusSenderConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusSenderConnectionString'
      properties: {
        value: listKeys(serviceBusName_SenderSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

Esses valores de cadeia de conexão são acessados pelos aplicativos, que fazem referência ao par chave/valor do Cofre da Chave. Isso é feito no arquivo sites.bicep , como mostra o seguinte código para o aplicativo de votação:

  properties: {
    enabled: true
    hostingEnvironmentProfile: {
      id:aseId
    }
    serverFarmId: votingWebPlanName.id
    siteConfig: {
      appSettings: [
        {
          name: 'ConnectionStrings:sbConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, serviceBusSenderConnectionStringSecretName), '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:RedisConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(keyVaultName_redisSecretName.id, '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:CosmosKey'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, cosmosKeySecretName), '2022-07-01').secretUriWithVersion})'
        }
      ]
    }
  }

A função também acessa a cadeia de conexão do ouvinte do Service Bus de maneira semelhante.

Escalabilidade

Projetar aplicativos escaláveis

O aplicativo nesta arquitetura de referência é estruturado para que os componentes individuais possam ser dimensionados com base no uso. Cada aplicativo Web, API e função é implantado em seu próprio plano do Serviço de Aplicativo. Você pode monitorar cada aplicativo em busca de gargalos de desempenho e, em seguida , ampliá-lo , se necessário.

Dimensionamento automático do Application Gateway

O dimensionamento automático pode ser habilitado no Azure Application Gateway V2. Isso permite que o Application Gateway aumente ou diminua a escala com base nos padrões de carga de tráfego. Essa arquitetura de autoscaleConfiguration referência configura no arquivo appgw.bicep para dimensionar entre zero e 10 instâncias adicionais. Consulte Scaling Application Gateway e WAF v2 para obter mais detalhes.

Implementação

Os scripts de implantação nessa arquitetura de referência são usados para implantar o Ambiente do Serviço de Aplicativo, outros serviços e os aplicativos dentro do Ambiente do Serviço de Aplicativo. Depois que esses aplicativos forem implantados, as empresas podem querer ter um plano de integração e implantação contínuas para manutenção e atualizações de aplicativos. Esta seção mostra algumas das maneiras comuns que os desenvolvedores usam para CI/CD de aplicativos do Ambiente do Serviço de Aplicativo.

Os aplicativos podem ser implantados em um Ambiente do Serviço de Aplicativo interno somente de dentro da rede virtual. Os três métodos a seguir são amplamente usados para implantar aplicativos do Ambiente do Serviço de Aplicativo:

• Manualmente dentro da Rede Virtual: crie uma máquina virtual dentro da rede virtual do Ambiente do Serviço de Aplicativo com as ferramentas necessárias para a implantação. Abra a conexão RDP com a VM usando uma configuração NSG. Copie seus artefatos de código para a VM, crie e implante na sub-rede do Ambiente do Serviço de Aplicativo. Esta é uma maneira simples de configurar um ambiente inicial de desenvolvimento de compilação e teste. No entanto, ele não é recomendado para o ambiente de produção, pois não pode dimensionar a taxa de transferência de implantação necessária.

• Conexão ponto a site a partir da estação de trabalho local: isso permite que você estenda sua rede virtual do Ambiente do Serviço de Aplicativo para sua máquina de desenvolvimento e implante a partir daí. Essa é outra maneira de configurar um ambiente de desenvolvimento inicial e não é recomendada para produção.

• Através dos Pipelines do Azure: implementa um pipeline de CI/CD completo, terminando num agente localizado dentro da rede virtual. Isso é ideal para ambientes de produção que exigem alto rendimento de implantação. O pipeline de compilação permanece totalmente fora da rede virtual. O pipeline de implantação copia os objetos criados para o agente de compilação dentro da rede virtual e, em seguida, implanta na sub-rede do Ambiente do Serviço de Aplicativo. Para obter mais informações, leia esta discussão sobre o agente de compilação auto-hospedado entre Pipelines e a rede virtual do Ambiente do Serviço de Aplicativo.

O uso do Azure Pipelines é recomendado para ambientes de produção. O script CI/CD com a ajuda do esquema YAML do Azure Pipelines ajuda a automatizar os processos de compilação e implantação. O azure-pipelines.yml implementa esse pipeline de CI/CD para o aplicativo Web nesta implementação de referência. Existem scripts CI/CD semelhantes para a API da Web, bem como para a função. Leia Usar Pipelines do Azure para saber como eles são usados para automatizar CI/CD para cada aplicativo.

Algumas empresas podem não querer manter um agente de compilação permanente dentro da rede virtual. Nesse caso, você pode optar por criar um agente de compilação dentro do pipeline de DevOps e desmontá-lo assim que a implantação for concluída. Isso adiciona outra etapa no DevOps, no entanto, reduz a complexidade da manutenção da VM. Você pode até considerar o uso de contêineres como agentes de compilação, em vez de VMs. Os agentes de compilação também podem ser completamente evitados implantando a partir de um arquivo compactado colocado fora da rede virtual, normalmente em uma conta de armazenamento. A conta de armazenamento precisará estar acessível a partir do Ambiente do Serviço de Aplicativo. O pipeline deve ser capaz de acessar o armazenamento. No final do pipeline de liberação, um arquivo compactado pode ser deixado no armazenamento de blob. O Ambiente do Serviço de Aplicativo pode então pegá-lo e implantá-lo. Esteja ciente das seguintes limitações desta abordagem:

• Há uma desconexão entre o DevOps e o processo de implantação real, levando a dificuldades em monitorar e rastrear quaisquer problemas de implantação.
• Em um ambiente bloqueado com tráfego seguro, talvez seja necessário alterar as regras para acessar o arquivo compactado no armazenamento.
• Você precisará instalar extensões e ferramentas específicas no Ambiente do Serviço de Aplicativo para poder implantar a partir do zip.

Para saber mais algumas maneiras pelas quais os aplicativos podem ser implantados nos planos do Serviço de Aplicativo, leia os artigos do Serviço de Aplicativo com foco em estratégias de implantação.

Otimização de custos

Utilize a calculadora de preços do Azure para prever os custos. Outras considerações são descritas na seção Custo em Microsoft Azure Well-Architected Framework. O Azure Reservations ajuda-o a poupar ao subscrever planos de um ou três anos de vários recursos do Azure. Leia mais no artigo Comprar uma reserva.

Aqui estão alguns pontos a considerar para alguns dos principais serviços usados nessa arquitetura.

Ambiente do Serviço de Aplicativo v3

Há várias opções de preços disponíveis para o Serviço de Aplicativo. Um Ambiente do Serviço de Aplicativo é implantado usando o Plano de Serviço Isolado v2. Dentro deste plano, existem várias opções para tamanhos de CPU, de I1v2 a I6v2. Esta implementação de referência usa três I1v2s por instância.

Gateway de Aplicação

Os preços do Application Gateway fornecem várias opções de preços . Essa implementação usa o Application Gateway Standard v2 e o WAF v2 SKU, que suportam dimensionamento automático e redundância de zona. Consulte Scaling Application Gateway v2 e WAF v2 para obter mais informações sobre o modelo de preços usado para essa SKU.

Cache do Azure para Redis

Os preços do Cache do Azure para Redis fornecem as várias opções de preços para este serviço. Esta arquitetura usa o Premium SKU, para o suporte de rede virtual.

A seguir estão as páginas de preços de outros serviços usados para bloquear o Ambiente do Serviço de Aplicativo:

• Preços do Firewall do Azure

• Preços do Key Vault

• Preços do Microsoft Entra

Implementar este cenário

Para implantar a implementação de referência para essa arquitetura, consulte o readme do GitHub e siga o script para implantação padrão.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• Dhanashri Kshirsagar - Brasil | PM de Conteúdo Sênior

Outros contribuidores:

• Deep Bhattacharya - Brasil | Arquiteto de Soluções Cloud
• Suhas Rao - Brasil | Arquiteto de Soluções Cloud

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

• Execute seu aplicativo no Serviço de Aplicativo do Azure diretamente de um pacote ZIP
• Esquema YAML do Azure Pipelines
• Obtenha seus endereços de gerenciamento da API
• Azure Key Vault
• Azure Pipelines

Recursos relacionados

Para saber como estender essa arquitetura para oferecer suporte à alta disponibilidade, leia Implantação de aplicativos de alta disponibilidade usando o Ambiente de Serviços de Aplicativo.