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 Ambiente do Serviço de Aplicativo versão 3. Ele também descreve as práticas recomendadas para fortalecer a segurança da carga de trabalho.

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

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de trabalho

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 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 de carga interno)

Essa arquitetura de referência implanta um aplicativo Web empresarial em uma Ambiente do Serviço de Aplicativo interna, também chamada de Ambiente do Serviço de Aplicativo ILB. Use um Ambiente do Serviço de Aplicativo ILB quando o cenário exigir que você:

• Hospede aplicativos da intranet com segurança aprimorada na nuvem e acesse-os 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 do aplicativo Web).
• Hospedar aplicativos na nuvem que não estão listados em servidores DNS públicos.
• Crie aplicativos de back-end isolados pela Internet, com os quais seus aplicativos front-end podem ser integrados de maneira altamente segura.

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, 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 nessa implementação permite que os usuários exibam 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 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. Uma camada Premium Cache do Azure para Redis é usada, o 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.

Os aplicativos Web são os únicos componentes acessíveis à Internet por meio de 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 em Gateway de Aplicativo.

Componentes

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

• O Azure Rede Virtual é uma rede de nuvem privada do Azure que pertence a uma empresa. Ele fornece segurança e isolamento aprimorados baseados em rede. Ambiente do Serviço de Aplicativo é uma implantação Serviço de Aplicativo em uma sub-rede da rede virtual de propriedade corporativa. 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.

• Gateway de Aplicativo é 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 Ambiente do Serviço de Aplicativo ILB. Como esse é o roteamento no nível do aplicativo, ele pode rotear o tráfego para vários aplicativos no mesmo Ambiente do Serviço de Aplicativo 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 de ponto de extremidade privado e uma tabela de rotas exigida por Ambiente do Serviço de Aplicativo é direcionado para a sub-rede do firewall. Para simplificar, essa arquitetura configura todos os pontos de extremidade privados na sub-rede de serviços.

• O Azure Active Directory ou Azure AD fornece gerenciamento de direitos de acesso e permissões para recursos e serviços do Azure. As Identidades Gerenciadas atribuem identidades a serviços e aplicativos, gerenciados automaticamente pelo Azure AD. Essas identidades podem ser usadas para autenticar qualquer serviço com suporte para autenticação do Azure AD. 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.

• GitHub Actions fornece recursos de integração contínua e implantação contínua nessa 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 de Serviço de Aplicativo. A ação cria os aplicativos fora da rede virtual. Para segurança aprimorada e conectividade RDP/SSH contínua, considere usar o Azure Bastion para o jumpbox.

Configuração de vários sites

Baixe um Arquivo Visio dessa arquitetura.

As Ambiente do Serviço de Aplicativo internas podem 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. Gateway de Aplicativo é usado para expor seletivamente esses aplicativos à Internet. Ambiente do Serviço de Aplicativo atribui uma URL padrão a cada aplicativo Serviço de Aplicativo como <default-appName>.<app-service-environment-domain>.appserviceenvironment.net. Uma zona DNS privada é criada que mapeia o nome de domínio Ambiente do Serviço de Aplicativo para o endereço IP ILB Ambiente do Serviço de Aplicativo. Isso evita o uso de um DNS personalizado para acessar os aplicativos na rede virtual.

Gateway de Aplicativo é configurado de modo que um ouvinte escute na porta HTTPS para 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 em seu computador para apontar uma URL escolhida arbitrariamente para o IP Gateway de Aplicativo. Para simplificar, o ouvinte usa um certificado autoassinado para processar essas solicitações. Gateway de Aplicativo tem pools de back-end para cada URL padrão de cada aplicativo 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 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 Ambiente do Serviço de Aplicativo padrão, 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 ILB. Ambiente do Serviço de Aplicativo encaminha isso para o serviço de aplicativo solicitado. Qualquer comunicação HTTP nos aplicativos 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 de HTTP precisam ser configurados no gateway de aplicativo para cada aplicativo Ambiente do Serviço de Aplicativo.

Examine 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. Esses arquivos JSON são acessados 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 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. Ambiente do Serviço de Aplicativo permite que as empresas implantem seus aplicativos Serviço de Aplicativo em uma sub-rede em seus próprios Rede Virtual do Azure, fornecendo um ambiente isolado, altamente escalonável e dedicado para suas cargas de trabalho de nuvem.

Considerações

Essas 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

Uma Ambiente do Serviço de Aplicativo interna é implantada na rede virtual corporativa, ocultada 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 Ambiente do Serviço de Aplicativo com um ponto de extremidade HTTP pode ser acessado por meio do ILB, de dentro da rede virtual. 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.

Os certificados padrão são criados para cada serviço de aplicativo para o nome de domínio padrão atribuído por Ambiente do Serviço de Aplicativo. Esse certificado pode reforçar 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 por meio do navegador do cliente. Ele só pode responder aos certificados configurados no Gateway de Aplicativo.

Gateway de Aplicativo

A implementação de referência configura Gateway de Aplicativo 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)

Criptografia

Conforme descrito em Visão geral do término do TLS e do TLS de ponta a ponta com Gateway de Aplicativo, Gateway de Aplicativo pode usar o protocolo 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 Gateway de Aplicativo. Para código de produção, um certificado emitido por uma Autoridade de Certificação deve ser usado. Para obter uma lista de tipos de certificado com suporte, consulte 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 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 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. Gateway de Aplicativo confia nos certificados SSL padrão porque eles são emitidos pela Microsoft. Consulte Configurar Serviço de Aplicativo com Gateway de Aplicativo para obter informações sobre como essas configurações são feitas. O seguinte código 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 do Aplicativo Web

Firewall de Aplicativo Web (WAF) em 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.0'
      }

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 nessa sub-rede. Por exemplo, consulte a configuração para "type": "Microsoft.Network/networkSecurityGroups" no arquivo ase.bicep para o grupo de segurança de rede da sub-rede Ambiente do Serviço de Aplicativo e no arquivo appgw.bicep para o grupo de segurança de rede da sub-rede Gateway de Aplicativo.

Os pontos de extremidade privados permitem 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 privadamente para o serviço do Azure, habilitando 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 dão 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 dê suporte a eles. 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 que dão suporte a ela: 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

Firewall do Azure e pontos de extremidade privados se complementam. Os pontos de extremidade privados ajudam a proteger os recursos, permitindo apenas o tráfego proveniente da rede virtual. Firewall do Azure permite restringir 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 de firewall, incluindo o tráfego de ponto de extremidade 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 Firewall do Azure se integra ao Ambiente do Serviço de Aplicativo, consulte Configurando Firewall do Azure com sua Ambiente do Serviço de Aplicativo. Qualquer tráfego que não percorra os pontos de extremidade privados e a tabela de rotas de rede virtual é monitorado e fechado pelo firewall.

Azure Active Directory

O Azure Active Directory fornece recursos de segurança para autenticar aplicativos e autorizar o acesso aos recursos. Essa arquitetura de referência usa dois recursos principais do Azure Active Directory: identidades gerenciadas e o 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 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 Azure AD. Essa identidade pode ser usada para autenticação em qualquer serviço com suporte para a autenticação do Azure AD, 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 acesso: usuário, identidade gerenciada, entidade de segurança.
• Que tipo de acesso ele tem: proprietário, contribuidor, leitor, administrador.
• Escopo do acesso: recurso, grupo de recursos, assinatura ou grupo de gerenciamento.

Você pode bloquear o acesso a aplicativos 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 na mesma 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, mas usam o RBAC do Azure para configurar permissões para o aplicativo. Por exemplo, confira as funções internas do Barramento de Serviço e o RBAC do Azure no Azure Cosmos DB. O acesso de 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 scripts de implantação, a próxima melhor opção é usar políticas de controle de acesso nativas do serviço:

• Para o Barramento de Serviço, 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 em Key Vault. O cofre em si é acessado por meio de identidades gerenciadas, que exigem RBAC do Azure. 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 front-end 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 de Key Vault 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 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: '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 Barramento de Serviço de maneira semelhante.

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 Gateway de Aplicativo

O dimensionamento automático pode ser habilitado no Gateway de Aplicativo do Azure V2. Isso permite que Gateway de Aplicativo escalar ou reduzir verticalmente 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 Ambiente do Serviço de Aplicativo, outros serviços e aplicativos dentro de 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 CI/CD de aplicativos Ambiente do Serviço de Aplicativo.

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

• Manualmente dentro do Rede Virtual: crie uma máquina virtual dentro da rede virtual 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 seus artefatos de código para a VM, compile e implante na sub-rede 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: Isso permite que você estenda seu Ambiente do Serviço de Aplicativo rede virtual 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: Isso 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, em seguida, implanta na sub-rede Ambiente do Serviço de Aplicativo. Para obter mais informações, leia esta discussão sobre o agente de build auto-hospedado entre pipelines e a rede virtual 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. Os agentes de build também podem ser completamente evitados implantando de um arquivo compactado colocado fora da rede virtual, normalmente em uma conta de armazenamento. A conta de armazenamento precisará estar 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. Em seguida, o Ambiente do Serviço de Aplicativo pode pegá-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 para tamanhos de CPU, de I1v2 a I6v2. Essa implementação de referência usa três I1v2s por instância.

Gateway de Aplicativo

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

Cache Redis do Azure

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 páginas de preços para outros serviços que são usados para bloquear o Ambiente do Serviço de Aplicativo:

• Preço do Firewall do Azure

• Preços do Key Vault

• Preço do Azure Active Directory

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 escrito originalmente pelos colaboradores a seguir.

Autor principal:

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

Outros colaboradores:

• Bhattacharya Profundo | Arquiteto de Soluções na Nuvem
• Suhas Rao | Arquiteto de Soluções na 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
• Cofre da Chave do Azure
• 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.