Implantação empresarial 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. Ele também descreve as melhores práticas para fortalecer a segurança da carga de trabalho.

Há uma implantação de referência para essa arquitetura disponível no GitHub.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Workflow

Você pode implantar o Ambiente do Serviço de Aplicativo de duas maneiras:

• Como um Ambiente do 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 interno de carga)

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

• Hospedar aplicativos com segurança aprimorada na nuvem com segurança e acessá-los por meio de uma VPN site a site ou do Azure ExpressRoute.
• Forneça uma camada de proteção para aplicativos usando um WAF (firewall de aplicativo Web).
• Hospedar aplicativos na nuvem que não estão listados em servidores DNS públicos.
• Criar aplicativos de back-end isolados da Internet, que podem ser integrados com seus aplicativos front-end de maneira segura.

Um Ambiente do Serviço de Aplicativo sempre deve ser implantado em sua sub-rede dentro da rede virtual da empresa para permitir um controle rígido do tráfego de entrada e saída. Nessa sub-rede, aplicativos do Serviço de Aplicativo são implantados em um ou mais Planos do Serviço de Aplicativo, que são 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 Web privada e uma função. Ela também implanta um aplicativo Web fictício chamado Aplicativo de Teste para demonstrar implantações de vários aplicativos. Cada aplicativo do Serviço de Aplicativo é hospedado no próprio Plano do Serviço de Aplicativo, permitindo que cada um seja dimensionado independentemente, 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 vejam entradas existentes, criem entradas e votem nas 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 Barramento de Serviço. A função capta votos enfileirados e atualiza o banco de dados SQL. O Azure Cosmos DB é usado para armazenar um anúncio de simulação que o aplicativo Web recupera para exibir no navegador. O aplicativo usa o Cache do Azure para Redis para gerenciamento de cache. Um Cache do Azure para Redis de camada Premium é usado, permitindo 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.

Os aplicativos Web são os únicos componentes acessíveis para a Internet por meio do Gateway de Aplicativo. A API e a função são inacessíveis de um cliente da Internet. O tráfego de entrada é protegido por um WAF configurado no Gateway de Aplicativo.

Componentes

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

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

• O Gateway de Aplicativo é um balanceador de carga de tráfego 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 Ambiente do Serviço de Aplicativo do ILB. Como esse é um 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 do ILB. Para obter mais informações, consulte hospedagem de vários sites com o Gateway de Aplicativo.

• 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 do ponto de extremidade privado e por uma tabela de rotas exigida pelo Ambiente do Serviço de Aplicativo é direcionado para a sub-rede do firewall. Por 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 oferece 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 qualquer serviço com suporte para autenticação do Microsoft Entra. Isso elimina a necessidade de configurar explicitamente 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 essa opção para armazenar segredos diretamente no aplicativo.

• O GitHub Actions fornece integração contínua e recursos de implantação contínua nesta arquitetura. Como o Ambiente do Serviço de Aplicativo está na rede virtual, uma máquina virtual é usada como um jumpbox 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 contínua de RDP/SSH, considere usar o Azure Bastion como jumpbox.

Configuração multissite

Baixe um Arquivo Visio dessa arquitetura.

O Ambiente do Serviço de Aplicativo Interno pode hospedar vários aplicativos Web e APIs com pontos de extremidade HTTP. Esses aplicativos são bloqueados da Internet pública, pois o IP do ILB só pode ser acessado de dentro da Rede Virtual. O Gateway de Aplicativo é 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. Uma zona de DNS privado é criada para mapear 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 usar um DNS personalizado para acessar os aplicativos na rede virtual.

O Gateway de Aplicativo é configurado de modo que um ouvinte ouça na porta HTTPS por solicitações para o endereço IP do gateway. Para simplificar, essa implementação não usa um registro de nome DNS público. Ele requer que você modifique o arquivo localhost no computador para apontar uma URL escolhida arbitrariamente para o IP do Gateway de Aplicativo. Para simplificar, o ouvinte usa um certificado autoassinado para processar essas solicitações. O Gateway de Aplicativo tem pools de back-end para cada 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 de 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 do 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 do Ambiente do Serviço de Aplicativo padrão, em que o gateway confia. A solicitação é redirecionada para a URL padrão do aplicativo correspondente. O DNS privado vinculado à rede virtual encaminha a 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 nos aplicativos do Ambiente do Serviço de Aplicativo passa pelo DNS privado. Observe que o ouvinte, o pool de back-end, a regra de roteamento e as configurações HTTP precisam ser configurados no gateway de aAplicativo para cada aplicativo do Ambiente do Serviço de Aplicativo.

Confira appgw.bicep e dns.bicep para saber como essas configurações são feitas para permitir vários sites. O aplicativo Web chamado testapp é um aplicativo vazio criado para demonstrar essa configuração. Os arquivos JSON são acessados por meio do script de implantação commands_std.azcli. Eles também são acessados por commands_ha.azcli, que é usado para uma implantação de Ambiente do Serviço de Aplicativo de vários sites de alta disponibilidade.

Detalhes do cenário

O Serviço de Aplicativo do Azure é um serviço de 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 aplicativos do Serviço de Aplicativo em uma sub-rede na própria Rede Virtual do Azure, fornecendo um ambiente isolado, altamente escalonável e dedicado para suas cargas de trabalho de nuvem.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

Ambiente do Serviço de Aplicativo

Um Ambiente do Serviço de Aplicativo interno é implantado na rede virtual corporativa, oculta da Internet pública. Ele permite que a empresa bloqueie os serviços de back-end, como APIs Web e funções, 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 Gateway de Aplicativo é 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 do back-end, ou seja, a API e a função, são efetivamente inacessíveis da Internet pública.

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 reforçar a segurança do tráfego entre o gateway e o aplicativo e poderá ser necessário em determinados cenários. Esses certificados não são visíveis por meio do navegador do cliente. Ele só pode responder aos certificados configurados no Gateway de Aplicativo.

Gateway de Aplicativo

Conforme descrito na Visão geral da terminação TLS e do TLS de ponta a ponta com o Gateway de Aplicativo, o Gateway de Aplicativo 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 nesse caso são configurados para HTTP. A criptografia é interrompida no gateway, e o tráfego entre o gateway e o serviço de aplicativo é descriptografado. Como a criptografia é intensiva na CPU, o tráfego não criptografado no back-end aprimora o desempenho e permite um gerenciamento de certificado mais simples. Isso fornece um nível razoável de segurança, uma vez que o back-end é protegido em virtude da configuração de 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 é feito usando a conexão HTTPS e configurando certificados no pool de back-end.

Essa implementação de referência usa certificados autoassinados para o Gateway de Aplicativo. Para código de produção, um certificado emitido por uma Autoridade de Certificação deve ser usado. Para ver uma lista de tipos de certificado com suporte, veja Certificados com suporte para terminação TLS. Leia Configurar um gateway de aplicativo com terminação TLS usando o portal do Azure para saber como criar a criptografia terminada no Gateway. As seguintes linhas de código no 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 Gateway de Aplicativo confia nos certificados SSL padrão porque eles são emitidos pela Microsoft. Veja Configurar o Serviço de Aplicativo com o Gateway de Aplicativo para obter informações sobre como essas configurações são feitas. O código a seguir de appgw.bicep mostra como ele é 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 do Aplicativo Web

O Firewall de Aplicativo Web (WAF) no Gateway de Aplicativo 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 snippet:

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

Rede Virtual

Os grupos de segurança de rede podem ser associados a uma ou mais sub-redes na rede virtual. Essas são regras de segurança que permitem ou negam o fluxo de tráfego 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 na sub-rede em questão. Por exemplo, confira a configuração de "type": "Microsoft.Network/networkSecurityGroups" 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 a sub-rede do Gateway de Aplicativo.

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 as conexões de rede, permitindo apenas aquelas que se conectam ao recurso de Link Privado 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 compatível. Em seguida, você pode melhorar a segurança do serviço na rede virtual desabilitando o acesso público, bloqueando efetivamente qualquer acesso da Internet pública. Essa arquitetura configura pontos de extremidade privados para os serviços usados que têm suporte para: Barramento de Serviço do Azure, SQL Server, Key Vault 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, confira Configuração de DNS do ponto de extremidade privado do Azure.

Firewall

O Azure Firewall e os pontos de extremidade privados complementam uns aos outros. Os pontos de extremidade privados ajudam a proteger os recursos, permitindo apenas o tráfego originado da rede virtual. O Firewall do Azure permite restringir o tráfego de saída dos aplicativos. Recomendamos permitir que todo o tráfego de saída passe pela sub-rede de firewall, incluindo o tráfego do ponto de extremidade privado. Isso permite um melhor monitoramento do tráfego de saída. Por questões de simplicidade, essa arquitetura de referência configura todos os pontos de extremidade privados na sub-rede de serviços em vez da sub-rede do firewall.

Para saber como o Firewall do Azure se integra ao Ambiente do Serviço de Aplicativo, consulte Configurar 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.

ID do Microsoft Entra

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

Nos aplicativos de nuvem, as credenciais necessárias para autenticar nos serviços de nuvem precisam ser protegidas. Idealmente, as credenciais nunca devem aparecer em estações de trabalho do desenvolvedor nem deve ser feito o check-in delas no controle do código-fonte. O Azure Key Vault oferece um modo de armazenar as credenciais e outros segredos com segurança, mas o código precisa ser autenticado no Key Vault para recuperá-los. As identidades gerenciadas dos recursos do Azure fornecem aos serviços do Azure uma identidade gerenciada automaticamente no Microsoft Entra ID. Essa identidade pode ser usada para autenticação em qualquer serviço com suporte para a autenticação do Microsoft Entra, incluindo o Key Vault, sem nenhuma credencial no aplicativo.

O RBAC (controle de acesso baseado em função) do Azure gerencia o acesso aos recursos do Azure. Isso inclui:

• Qual entidade tem o acesso: usuário, identidade gerenciada, entidade de segurança.
• Que tipo de acesso ela tem: proprietário, colaborador, leitor, administrador.
• Escopo do acesso: recurso, grupo de recursos, assinatura ou grupo de gerenciamento.

Você pode bloquear o acesso a aplicativos do Ambiente do Serviço de Aplicativo controlando firmemente 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 front-end pode ser tratado por uma equipe e o back-end por outra. O RBAC do Azure pode ser usado para limitar o acesso de cada equipe aos aplicativos nos quais está trabalhando. Explore funções personalizadas do Azure para criar funções adequadas à sua organização.

Key Vault

Alguns serviços dão suporte a identidades gerenciadas e usam o RBAC do Azure para configurar permissões para o aplicativo. Por exemplo, confira as funções do barramento de serviço e o RBAC do Azure no Azure Cosmos DB. O acesso de administrador de acesso do usuário à assinatura é necessário para conceder essas permissões, mesmo que a equipe 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 alternativa é usar o controle de acesso nativo fornecido pelos serviços:

• Para o barramento de serviço, são assinaturas de acesso compartilhado.
• Para o Azure Cosmos DB, são as chaves.

Se a carga de trabalho precisar de acesso baseado em serviço, esses segredos pré-compartilhados deverão ser armazenados no Key Vault. O cofre em si deve ser acessado por meio da identidade gerenciada do aplicativo Web.

Os segredos armazenados no Key Vault são acessados pelos aplicativos, que fazem referência ao par chave/valor do Key Vault. 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: 'ASecret'
        value: '@Microsoft.KeyVault(SecretUri=${applicationKeyVault::secretName.secretUriWithVersion})'
      }
    ]
  }
}

Escalabilidade

Criar aplicativos escalonáveis

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

Dimensionamento automático do Gateway de Aplicativo

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

Implantaçã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 os aplicativos forem implantados, as empresas poderão 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 promover a 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 de NSG. Copie os artefatos de código para a VM, compile e implante na sub-rede do Ambiente do Serviço de Aplicativo. Essa é uma maneira simples de configurar um ambiente inicial de desenvolvimento de build e teste. No entanto, 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 da estação de trabalho local: permite que você estenda a rede virtual do Ambiente do Serviço de Aplicativo para seu computador de desenvolvimento e implante a partir daí. Essa é outra maneira de configurar um ambiente de desenvolvimento inicial, e não recomendada para produção.

• Por meio do Azure Pipelines: implementa um pipeline completo de CI/CD, terminando em um agente localizado dentro da rede virtual. É ideal para ambientes de produção que exigem alta taxa de transferência de implantação. O pipeline de build permanece totalmente fora da rede virtual. O pipeline de implantação copia os objetos criados para o agente de build dentro da rede virtual e os implanta na sub-rede do Ambiente do Serviço de Aplicativo. Para saber mais, leia esta discussão sobre o agente de build 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 de CI/CD com a ajuda do esquema YAML do Azure Pipelines ajuda a automatizar os processos de build e implantação. O azure-pipelines.yml implementa um pipeline de CI/CD para o aplicativo Web nessa implementação de referência. Há scripts de CI/CD semelhantes para a API Web, bem como para a função. Leia Usar o Azure Pipelines para saber como eles são usados para automatizar CI/CD para cada aplicativo.

Algumas empresas podem não querer manter um agente de build permanente dentro da rede virtual. Nesse caso, você pode optar por criar um agente de build dentro do pipeline de DevOps e eliminá-lo depois que a implantação for concluída. Isso adiciona outra etapa ao DevOps, mas reduz a complexidade da manutenção da VM. Você pode até considerar o uso de contêineres como agentes de build, em vez de VMs. Agentes de build também podem ser completamente evitados implantando de um arquivo compactado fora da rede virtual, normalmente em uma conta de armazenamento. A conta de armazenamento precisará ser acessível no Ambiente do Serviço de Aplicativo. O pipeline deve ser capaz de acessar o armazenamento. No final do pipeline de lançamento, um arquivo compactado pode ser removido para o armazenamento de blobs. O Ambiente do Serviço de Aplicativo pode então selecioná-lo e implantá-lo. Lembre-se das seguintes limitações dessa abordagem:

• Há uma desconexão entre o DevOps e o processo de implantação real, levando a dificuldades de monitoramento e rastreamento de problemas de implantação.
• Em um ambiente bloqueado com tráfego protegido, 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 sobre como aplicativos podem ser implantados nos planos do Serviço de Aplicativo, leia os artigos sobre o Serviço de Aplicativo com foco nas estratégias de implantação.

Otimização de custo

Use a Calculadora de Preços do Azure para estimar os custos. Outras considerações são descritas na seção Custo em Microsoft Azure Well-Architected Framework. As reservas do Azure ajudam você a economizar dinheiro confirmando os planos de um ou de três anos para muitos recursos do Azure. Leia mais no artigo Comprar uma reserva.

Aqui estão alguns pontos a serem considerados para alguns dos principais serviços usados nesta 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 desse plano, há várias opções de tamanhos de CPU, de I1v2 a I6v2. Essa implementação de referência usa três I1v2s por instância.

Gateway de Aplicativo

Preços do Gateway de Aplicativo fornece várias opções de preços para o Gateway de Aplicativo. Essa implementação usa o SKU do Gateway de Aplicativo padrão v2 e do WAF v2, que dá suporte ao dimensionamento automático e à redundância de zona. Confira Colocação em escala do Gateway de Aplicativo v2 e WAF v2 para obter mais informações sobre o modelo de preços usado para esse SKU.

Cache do Azure para Redis

Preços do Cache do Azure para Redis fornece as várias opções de preço para esse serviço. Essa arquitetura usa o SKU Premium para o suporte à rede virtual.

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

• Preço do Firewall do Azure

• Preços do Key Vault

• Preço do Microsoft Entra

Implantar este cenário

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

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

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

Outros colaboradores:

• Deep Bhattacharya | Arquiteto de Soluções em Nuvem
• Suhas Rao | Arquiteto de Soluções em Nuvem

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

Próximas etapas

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

Recursos relacionados

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