Partilhar via

Tutorial: Criar um aplicativo multirregião altamente disponível no Serviço de Aplicativo do Azure

  • Artigo

Alta disponibilidade e tolerância a falhas são componentes-chave de uma solução bem arquitetada. É melhor se preparar para o inesperado tendo um plano de emergência que pode reduzir o tempo de inatividade e manter seus sistemas funcionando automaticamente quando algo falha.

Ao implantar seu aplicativo na nuvem, você escolhe uma região nessa nuvem onde sua infraestrutura de aplicativo está baseada. Se seu aplicativo for implantado em uma única região e a região ficar indisponível, seu aplicativo também ficará indisponível. Essa falta de disponibilidade pode ser inaceitável sob os termos do SLA do seu aplicativo. Nesse caso, implantar seu aplicativo e seus serviços em várias regiões é uma boa solução.

Neste tutorial, você aprenderá a implantar um aplicativo Web multiregião altamente disponível. Esse cenário é mantido simples, restringindo os componentes do aplicativo a apenas um aplicativo Web e ao Azure Front Door, mas os conceitos podem ser expandidos e aplicados a outros padrões de infraestrutura. Por exemplo, se seu aplicativo se conectar a uma conta de oferta ou armazenamento de banco de dados do Azure, consulte replicação geográfica ativa para bancos de dados SQL e opções de redundância para contas de armazenamento. Para obter uma arquitetura de referência para um cenário mais detalhado, consulte Aplicativo Web multirregião altamente disponível.

O diagrama de arquitetura a seguir mostra a infraestrutura criada neste tutorial. Ele consiste em dois Serviços de Aplicativo idênticos em regiões separadas, sendo uma a região ativa ou principal e a outra é a região de espera ou secundária. O Azure Front Door é usado para rotear o tráfego para os Serviços de Aplicativo e as restrições de acesso são configuradas para que o acesso direto aos aplicativos da Internet seja bloqueado. A linha pontilhada indica que o tráfego é enviado para a região de espera somente se a região ativa cair.

O Azure fornece várias opções para balanceamento de carga e roteamento de tráfego. O Azure Front Door foi selecionado para este caso de uso porque envolve aplicativos Web voltados para a Internet hospedados no Serviço de Aplicativo do Azure implantados em várias regiões. Para ajudá-lo a decidir o que usar para seu caso de uso se ele for diferente deste tutorial, consulte a árvore de decisão para balanceamento de carga no Azure.

Diagrama de arquitetura de um Serviço de Aplicativo de várias regiões.

Com esta arquitetura:

  • Aplicativos idênticos do Serviço de Aplicativo são implantados em duas regiões separadas.
  • O tráfego público diretamente para os aplicativos do Serviço de Aplicativo está bloqueado.
  • O Azure Front Door é usado para rotear o tráfego para a região principal/ativa. A região secundária tem um Serviço de Aplicativo que está em funcionamento e pronto para atender ao tráfego, se necessário.

O que irá aprender:

  • Crie Serviços de Aplicativo idênticos em regiões separadas.
  • Crie o Azure Front Door com restrições de acesso que bloqueiam o acesso público aos Serviços de Aplicativo.

Pré-requisitos

Se não tiver uma subscrição do Azure, crie uma conta gratuita do Azure antes de começar.

Para concluir este tutorial:

  • Use o ambiente Bash no Azure Cloud Shell. Para obter mais informações, consulte Guia de início rápido para Bash no Azure Cloud Shell.

  • Se preferir executar comandos de referência da CLI localmente, instale a CLI do Azure. Se estiver a utilizar o Windows ou macOS, considere executar a CLI do Azure num contentor Docker. Para obter mais informações, consulte Como executar a CLI do Azure em um contêiner do Docker.

    • Se estiver a utilizar uma instalação local, inicie sessão no CLI do Azure ao utilizar o comando az login. Para concluir o processo de autenticação, siga os passos apresentados no seu terminal. Para outras opções de entrada, consulte Entrar com a CLI do Azure.

    • Quando solicitado, instale a extensão da CLI do Azure na primeira utilização. Para obter mais informações sobre as extensões, veja Utilizar extensões com o CLI do Azure.

    • Execute o comando az version para localizar a versão e as bibliotecas dependentes instaladas. Para atualizar para a versão mais recente, execute o comando az upgrade.

Criar duas instâncias de um aplicativo Web

Você precisa de duas instâncias de um aplicativo Web executado em diferentes regiões do Azure para este tutorial. Você usa o par de regiões Leste dos EUA/Oeste dos EUA como suas duas regiões e cria dois aplicativos Web vazios. Sinta-se à vontade para escolher suas próprias regiões, se necessário.

Para simplificar o gerenciamento e a limpeza, use um único grupo de recursos para todos os recursos neste tutorial. Considere o uso de grupos de recursos separados para cada região/recurso para isolar ainda mais seus recursos em uma situação de recuperação de desastres.

Execute o seguinte comando para criar seu grupo de recursos.

az group create --name myresourcegroup --location eastus

Criar planos do Serviço de Aplicativo

Execute os seguintes comandos para criar os planos do Serviço de Aplicativo. Substitua os espaços reservados para <app-service-plan-east-us> e <app-service-plan-west-us> por dois nomes exclusivos onde você pode identificar facilmente a região em que eles estão.

az appservice plan create --name <app-service-plan-east-us> --resource-group myresourcegroup --is-linux --location eastus

az appservice plan create --name <app-service-plan-west-us> --resource-group myresourcegroup --is-linux --location westus

Criar aplicações Web

Depois que os planos do Serviço de Aplicativo forem criados, execute os seguintes comandos para criar os aplicativos Web. Substitua os espaços reservados para <web-app-east-us> e <web-app-west-us> por dois nomes globalmente exclusivos (caracteres válidos são a-z, 0-9e -) e certifique-se de prestar atenção ao --plan parâmetro para que você coloque um aplicativo em cada plano (e, portanto, em cada região). Substitua o <runtime> parâmetro pela versão de idioma do seu aplicativo. Execute az webapp list-runtimes para a lista de tempos de execução disponíveis. Se você planeja usar o aplicativo de Node.js de exemplo fornecido neste tutorial nas seções a seguir, use NODE:18-lts como seu tempo de execução.

az webapp create --name <web-app-east-us> --resource-group myresourcegroup --plan <app-service-plan-east-us> --runtime <runtime>

az webapp create --name <web-app-west-us> --resource-group myresourcegroup --plan <app-service-plan-west-us> --runtime <runtime>

Anote o nome de host padrão de cada aplicativo Web para que você possa definir os endereços de back-end quando implantar a Front Door na próxima etapa. Deverá estar no formato <web-app-name>.azurewebsites.net. Esses nomes de host podem ser encontrados executando o comando a seguir ou navegando até a página Visão geral do aplicativo no portal do Azure.

az webapp show --name <web-app-name> --resource-group myresourcegroup --query "hostNames"

Criar uma porta de entrada do Azure

Uma implantação de várias regiões pode usar uma configuração ativa-ativa ou ativa-passiva. Uma configuração ativo-ativo distribui solicitações em várias regiões ativas. Uma configuração ativa-passiva mantém instâncias em execução na região secundária, mas não envia tráfego para lá, a menos que a região primária falhe. O Azure Front Door tem um recurso interno que permite habilitar essas configurações. Para obter mais informações sobre como projetar aplicativos para alta disponibilidade e tolerância a falhas, consulte Arquitetar aplicativos do Azure para resiliência e disponibilidade.

Criar um perfil do Azure Front Door

Agora você cria um Azure Front Door Premium para rotear o tráfego para seus aplicativos.

Execute az afd profile create para criar um perfil do Azure Front Door.

Nota

Se você quiser implantar o Azure Front Door Standard em vez de Premium, substitua o --sku valor do parâmetro por Standard_AzureFrontDoor. Não é possível implantar regras gerenciadas com a Política WAF se escolher a camada Padrão. Para obter uma comparação detalhada dos níveis de preços, consulte Comparação de camadas da Porta da Frente do Azure.

az afd profile create --profile-name myfrontdoorprofile --resource-group myresourcegroup --sku Premium_AzureFrontDoor
Parâmetro valor Description
profile-name myfrontdoorprofile Nome para o perfil da Porta da Frente do Azure, que é exclusivo dentro do grupo de recursos.
resource-group myresourcegroup O grupo de recursos que contém os recursos deste tutorial.
sku Premium_AzureFrontDoor A camada de preço do perfil do Azure Front Door.

Adicionar um ponto final

Execute az afd endpoint create para criar um ponto de extremidade no seu perfil. Você pode criar vários pontos de extremidade em seu perfil depois de terminar a experiência de criação.

az afd endpoint create --resource-group myresourcegroup --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
Parâmetro valor Description
endpoint-name myendpoint Nome do ponto de extremidade sob o perfil, que é exclusivo globalmente.
enabled-state Enabled Se esse ponto de extremidade deve ser habilitado.

Criar um grupo de origem

Execute az afd origin-group create para criar um grupo de origem que contenha seus dois aplicativos Web.

az afd origin-group create --resource-group myresourcegroup --origin-group-name myorigingroup --profile-name myfrontdoorprofile --probe-request-type GET --probe-protocol Http --probe-interval-in-seconds 60 --probe-path / --sample-size 4 --successful-samples-required 3 --additional-latency-in-milliseconds 50
Parâmetro valor Description
origin-group-name myorigingroup Nome do grupo de origem.
probe-request-type GET O tipo de solicitação de sonda de saúde que é feita.
probe-protocol Http Protocolo a utilizar para sonda de saúde.
probe-interval-in-seconds 60 O número de segundos entre as sondas de saúde.
probe-path / O caminho relativo à origem que é usado para determinar a integridade da origem.
sample-size 4 O número de amostras a serem consideradas para decisões de balanceamento de carga.
successful-samples-required 3 O número de amostras dentro do período de amostragem que devem ser bem-sucedidas.
additional-latency-in-milliseconds 50 A latência extra em milissegundos para que as sondas caiam no bucket de latência mais baixa.

Adicionar uma origem ao grupo

Execute az afd origin create para adicionar uma origem ao seu grupo de origem. Para o parâmetro, substitua o espaço reservado para <web-app-east-us> pelo nome do --host-name aplicativo nessa região. Observe que o parâmetro está definido como , o 1que indica que todo o --priority tráfego é enviado para seu aplicativo principal.

az afd origin create --resource-group myresourcegroup --host-name <web-app-east-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name primaryapp --origin-host-header <web-app-east-us>.azurewebsites.net --priority 1 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443
Parâmetro valor Description
host-name <web-app-east-us>.azurewebsites.net O nome do host do aplicativo Web principal.
origin-name primaryapp Nome da origem.
origin-host-header <web-app-east-us>.azurewebsites.net O cabeçalho do host a ser enviado para solicitações para essa origem. Se você deixar isso em branco, o nome do host da solicitação determinará esse valor. As origens da CDN do Azure, como Aplicativos Web, Armazenamento de Blob e Serviços de Nuvem, exigem que esse valor de cabeçalho de host corresponda ao nome do host de origem por padrão.
priority 1 Defina esse parâmetro como 1 para direcionar todo o tráfego para o aplicativo Web principal.
weight 1000 Peso da origem num determinado grupo de origem para o equilíbrio da carga. Deve ter entre 1 e 1000.
enabled-state Enabled Se essa origem deve ser habilitada.
http-port 80 A porta usada para solicitações HTTP para a origem.
https-port 443 A porta usada para solicitações HTTPS para a origem.

Repita este passo para adicionar a sua segunda origem. Preste atenção ao --priority parâmetro. Para esta origem, está definido como 2. Essa configuração de prioridade informa ao Azure Front Door para direcionar todo o tráfego para a origem principal, a menos que a primária fique inativa. Se você definir a prioridade para essa origem como 1, o Azure Front Door tratará ambas as origens como tráfego ativo e direto para ambas as regiões. Certifique-se de substituir ambas as instâncias do espaço reservado para <web-app-west-us> pelo nome desse aplicativo Web.

az afd origin create --resource-group myresourcegroup --host-name <web-app-west-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name secondaryapp --origin-host-header <web-app-west-us>.azurewebsites.net --priority 2 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443

Adicionar uma rota

Execute az afd route create para mapear seu ponto de extremidade para o grupo de origem. Essa rota encaminha solicitações do ponto de extremidade para seu grupo de origem.

az afd route create --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --forwarding-protocol MatchRequest --route-name route --https-redirect Enabled --origin-group myorigingroup --supported-protocols Http Https --link-to-default-domain Enabled
Parâmetro valor Description
endpoint-name myendpoint Nome do ponto de extremidade.
protocolo de encaminhamento MatchRequest Protocolo que esta regra usa ao encaminhar tráfego para back-ends.
route-name route Nome da rota.
https-redirecionamento Enabled Se o tráfego HTTP deve ser redirecionado automaticamente para o tráfego HTTPS.
supported-protocols Http Https Lista de protocolos suportados para esta rota.
link-to-default-domain Enabled Se essa rota está vinculada ao domínio de ponto de extremidade padrão.

Aguarde cerca de 15 minutos para que esta etapa seja concluída, pois leva algum tempo para que essa alteração se propague globalmente. Após esse período, sua porta frontal do Azure estará totalmente funcional.

Restringir o acesso a aplicativos Web à instância do Azure Front Door

Neste ponto, você ainda pode acessar seus aplicativos diretamente usando suas URLs neste momento. Para garantir que o tráfego só possa chegar às suas aplicações através da Porta da Frente do Azure, defina restrições de acesso em cada uma das suas aplicações. As funcionalidades do Front Door funcionam melhor quando o tráfego flui apenas através do Front Door. Você deve configurar suas origens para bloquear o tráfego que ainda não foi enviado pela Front Door. Caso contrário, o tráfego pode ignorar o firewall do aplicativo Web do Front Door, a proteção contra DDoS e outros recursos de segurança. O tráfego do Azure Front Door para seus aplicativos é originado de um conjunto bem conhecido de intervalos de IP definidos na AzureFrontDoor.Backend tag de serviço. Usando uma regra de restrição de marca de serviço, você pode restringir o tráfego para originar apenas da Porta da Frente do Azure.

Antes de configurar as restrições de acesso do Serviço de Aplicativo, anote a ID da Porta da Frente executando o seguinte comando. Esse ID é necessário para garantir que o tráfego seja originado apenas da sua instância específica do Front Door. A restrição de acesso filtra ainda mais as solicitações de entrada com base no cabeçalho HTTP exclusivo que sua Porta da Frente do Azure envia.

az afd profile show --resource-group myresourcegroup --profile-name myfrontdoorprofile --query "frontDoorId"

Execute os comandos a seguir para definir as restrições de acesso em seus aplicativos Web. Substitua o espaço reservado para <front-door-id> pelo resultado do comando anterior. Substitua os espaços reservados para os nomes dos aplicativos.

az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-east-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>

az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-west-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>

Teste a porta da frente

Quando você cria o perfil Azure Front Door Standard/Premium, leva alguns minutos para que a configuração seja implantada globalmente. Uma vez concluído, você pode acessar o host frontend que você criou.

Execute az afd endpoint show para obter o nome do host do ponto de extremidade Front Door.

az afd endpoint show --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"

Em um navegador, vá para o nome de host do ponto de extremidade que o comando anterior retornou: <myendpoint>-<hash>.z01.azurefd.net. Sua solicitação deve ser encaminhada automaticamente para o aplicativo principal no Leste dos EUA.

Para testar o failover global instantâneo:

  1. Abra um navegador e vá para o nome do host do ponto final: <myendpoint>-<hash>.z01.azurefd.net.

  2. Pare o aplicativo principal executando az webapp stop.

    az webapp stop --name <web-app-east-us> --resource-group myresourcegroup

  3. Atualize o seu browser. Você deve ver a mesma página de informações porque o tráfego agora é direcionado para o aplicativo em execução no oeste dos EUA.

    Gorjeta

    Talvez seja necessário atualizar a página algumas vezes para que o failover seja concluído.

  4. Agora pare o aplicativo secundário.

    az webapp stop --name <web-app-west-us> --resource-group myresourcegroup

  5. Atualize o seu browser. Desta vez, você verá uma mensagem de erro.

    Captura de ecrã da mensagem: Ambas as instâncias da aplicação Web foram interrompidas.

  6. Reinicie um dos Web Apps executando az webapp start. Atualize seu navegador e você verá o aplicativo novamente.

    az webapp start --name <web-app-east-us> --resource-group myresourcegroup

Agora você validou que pode acessar seus aplicativos por meio do Azure Front Door e que o failover funciona como pretendido. Reinicie seu outro aplicativo se tiver terminado o teste de failover.

Para testar suas restrições de acesso e garantir que seus aplicativos só possam ser acessados por meio do Azure Front Door, abra um navegador e navegue até cada uma das URLs do seu aplicativo. Para localizar as URLs, execute os seguintes comandos:

az webapp show --name <web-app-east-us> --resource-group myresourcegroup --query "hostNames"

az webapp show --name <web-app-west-us> --resource-group myresourcegroup --query "hostNames"

Você verá uma página de erro indicando que os aplicativos não estão acessíveis.

Clean up resources (Limpar recursos)

Nos passos anteriores, criou os recursos do Azure num grupo de recursos. Se achar que não vai precisar destes recursos no futuro, execute o seguinte comando no Cloud Shell para eliminar o grupo de recursos.

az group delete --name myresourcegroup

Esse comando pode levar alguns minutos para ser executado.

Implantar a partir de ARM/Bicep

Os recursos criados neste tutorial podem ser implantados usando um modelo ARM/Bicep. O modelo Bicep do aplicativo Web multirregião altamente disponível permite que você crie uma solução segura, altamente disponível e multirregião de ponta a ponta com dois aplicativos Web em regiões diferentes atrás da Porta da Frente do Azure.

Para saber como implantar modelos ARM/Bicep, consulte Como implantar recursos com o Bicep e a CLI do Azure.

Perguntas mais frequentes

Neste tutorial até agora, você implantou a infraestrutura de linha de base para habilitar um aplicativo Web de várias regiões. O Serviço de Aplicativo fornece recursos que podem ajudá-lo a garantir que você esteja executando aplicativos seguindo as práticas recomendadas e recomendações de segurança.

Esta seção contém perguntas frequentes que podem ajudá-lo a proteger ainda mais seus aplicativos e implantar e gerenciar seus recursos usando as práticas recomendadas.

Para este tutorial, você usou a CLI do Azure para implantar seus recursos de infraestrutura. Considere configurar um mecanismo de implantação contínua para gerenciar sua infraestrutura de aplicativos. Como você está implantando recursos em regiões diferentes, precisa gerenciar esses recursos de forma independente entre as regiões. Para garantir que os recursos sejam idênticos em cada região, a infraestrutura como código (IaC), como modelos do Azure Resource Manager ou Terraform , deve ser usada com pipelines de implantação, como Azure Pipelines ou GitHub Actions. Dessa forma, se configurada adequadamente, qualquer alteração nos recursos acionaria atualizações em todas as regiões nas quais você está implantado. Para obter mais informações, consulte Implantação contínua no Serviço de Aplicativo do Azure.

Como posso usar slots de preparo para praticar a implantação segura na produção?

Não é recomendável implantar o código do aplicativo diretamente em aplicativos/slots de produção. Isso ocorre porque você quer ter um local seguro para testar seus aplicativos e validar as alterações feitas antes de enviar para a produção. Use uma combinação de slots de preparo e troca de slots para mover o código do seu ambiente de teste para a produção.

Você já criou a infraestrutura de linha de base para esse cenário. Agora, você cria slots de implantação para cada instância do seu aplicativo e configura a implantação contínua para esses slots de preparo com as Ações do GitHub. Assim como no gerenciamento de infraestrutura, a configuração da implantação contínua para o código-fonte do aplicativo também é recomendada para garantir que as alterações entre regiões estejam sincronizadas. Se você não configurar a implantação contínua, precisará atualizar manualmente cada aplicativo em cada região sempre que houver uma alteração de código.

Para as etapas restantes neste tutorial, você deve ter um aplicativo pronto para implantar em seus Serviços de Aplicativo. Se precisar de um aplicativo de exemplo, você pode usar o aplicativo de exemplo Node.js Hello World. Fork esse repositório para que você tenha sua própria cópia.

Certifique-se de definir as configurações de pilha do Serviço de Aplicativo para seus aplicativos. As configurações de pilha referem-se ao idioma ou tempo de execução usado para seu aplicativo. Essa configuração pode ser definida usando a CLI do Azure com o az webapp config set comando ou no portal com as etapas a seguir. Se você usar o exemplo de Node.js, defina as configurações de pilha como Nó 18 LTS.

  1. Ir para a sua aplicação e selecionar Configuração no índice à esquerda.
  2. Selecione a guia Configurações gerais .
  3. Em Configurações de pilha, escolha o valor apropriado para seu aplicativo.
  4. Selecione Guardar e, em seguida, Continuar para confirmar a atualização.
  5. Repita estes passos para as suas outras aplicações.

Execute os comandos a seguir para criar slots de preparo chamados "stage" para cada um dos seus aplicativos. Substitua os espaços reservados para <web-app-east-us> e <web-app-west-us> com os nomes dos aplicativos.

az webapp deployment slot create --resource-group myresourcegroup --name <web-app-east-us> --slot stage --configuration-source <web-app-east-us>

az webapp deployment slot create --resource-group myresourcegroup --name <web-app-west-us> --slot stage --configuration-source <web-app-west-us>

Para configurar a implantação contínua, você deve usar o portal do Azure. Para obter orientações detalhadas sobre como configurar a implantação contínua com provedores como as Ações do GitHub, consulte Implantação contínua no Serviço de Aplicativo do Azure.

Para configurar a implantação contínua com as Ações do GitHub, conclua as etapas a seguir para cada um dos slots de preparação.

  1. No portal do Azure, vá para a página de gerenciamento de um dos slots de aplicativo do Serviço de Aplicativo.

  2. No painel esquerdo, selecione Centro de Implantação. Em seguida, selecione Configurações.

  3. Na caixa Origem, selecione "GitHub" nas opções de CI/CD:

    Captura de tela que mostra como escolher a fonte de implantação

  4. Se você estiver implantando a partir do GitHub pela primeira vez, selecione Autorizar e siga os prompts de autorização. Se você quiser implantar a partir do repositório de um usuário diferente, selecione Alterar conta.

  5. Depois de autorizar sua conta do Azure com o GitHub, selecione a Organização, o Repositório e a Filial para configurar o CI/CD. Se não conseguir encontrar uma organização ou repositório, talvez seja necessário habilitar mais permissões no GitHub. Para obter mais informações, consulte Gerenciando o acesso aos repositórios da sua organização.

    1. Se você estiver usando o aplicativo de exemplo Node.js, use as configurações a seguir.

      Definição Value
      Organization <your-GitHub-organization>
      Repositório nodejs-docs-hello-world
      Filial main

  6. Selecione Guardar.

    Novas confirmações no repositório e na ramificação selecionados agora são implantadas continuamente no slot do aplicativo do Serviço de Aplicativo. Você pode acompanhar as confirmações e implantações na guia Logs .

Um arquivo de fluxo de trabalho padrão que usa um perfil de publicação para autenticar no Serviço de Aplicativo é adicionado ao repositório do GitHub. Você pode visualizar este arquivo indo para o <repo-name>/.github/workflows/ diretório.

Como desativar a autenticação básica no Serviço de Aplicativo?

Considere desativar a autenticação básica, que limita o acesso aos pontos de extremidade FTP e SCM aos usuários que são apoiados pelo Microsoft Entra ID. Se estiver usando uma ferramenta de implantação contínua para implantar o código-fonte do aplicativo, desabilitar a autenticação básica exigirá etapas adicionais para configurar a implantação contínua. Por exemplo, você não pode usar um perfil de publicação, pois ele não usa credenciais do Microsoft Entra. Em vez disso, você precisa usar uma entidade de serviço ou o OpenID Connect.

Para desativar a autenticação básica para o Serviço de Aplicativo, execute os seguintes comandos para cada aplicativo e slot substituindo os espaços reservados para <web-app-east-us> e <web-app-west-us> com os nomes dos aplicativos. O primeiro conjunto de comandos desabilita o acesso FTP para os sites de produção e slots de preparo, e o segundo conjunto de comandos desabilita o acesso básico de autenticação à porta WebDeploy e ao site SCM para os locais de produção e slots de preparação.

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us>/slots/stage --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us>/slots/stage --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us>/slots/stage --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us>/slots/stage --set properties.allow=false

Para obter mais informações sobre como desabilitar a autenticação básica, incluindo como testar e monitorar entradas, consulte Desabilitar a autenticação básica em implantações do Serviço de Aplicativo.

Como faço para implantar meu código usando a implantação contínua se eu desabilitei a autenticação básica?

Se você optar por permitir autenticação básica em seus aplicativos do Serviço de Aplicativo, poderá usar qualquer um dos métodos de implantação disponíveis no Serviço de Aplicativo, inclusive usando o perfil de publicação configurado na seção de slots de preparo.

Se você desabilitar a autenticação básica para seus Serviços de Aplicativo, a implantação contínua exigirá uma entidade de serviço ou OpenID Connect para autenticação. Se você usar as Ações do GitHub como seu repositório de código, consulte o tutorial passo a passo para usar uma entidade de serviço ou o OpenID Connect para implantar no Serviço de Aplicativo usando as Ações do GitHub ou conclua as etapas na seção a seguir.

Crie a entidade de serviço e configure as credenciais com as Ações do GitHub

Para configurar a implantação contínua com as Ações do GitHub e uma entidade de serviço, use as etapas a seguir.

  1. Execute o seguinte comando para criar a entidade de serviço. Substitua os espaços reservados pelos <subscription-id> seus nomes e de aplicativos. A saída é um objeto JSON com as credenciais de atribuição de função que fornecem acesso aos seus aplicativos do Serviço de Aplicativo. Copie este objeto JSON para a próxima etapa. Inclui o segredo do seu cliente, que é visível apenas neste momento. É sempre uma boa prática conceder acesso mínimo. O escopo neste exemplo é limitado apenas aos aplicativos, não a todo o grupo de recursos.

    az ad sp create-for-rbac --name "myApp" --role contributor --scopes /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-east-us> /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-west-us> --sdk-auth

  2. Você precisa fornecer as credenciais da entidade de serviço para a ação Azure/login como parte do fluxo de trabalho da Ação do GitHub que está usando. Esses valores podem ser fornecidos diretamente no fluxo de trabalho ou podem ser armazenados em segredos do GitHub e referenciados em seu fluxo de trabalho. Salvar os valores como segredos do GitHub é a opção mais segura.

    1. Abra seu repositório GitHub e vá para Configurações>Segredos de segurança>e variáveis Ações>

    2. Selecione Novo segredo do repositório e crie um segredo para cada um dos seguintes valores. Os valores podem ser encontrados na saída json que você copiou anteriormente.

      Nome Valor
      AZURE_APP_ID <application/client-id>
      AZURE_PASSWORD <client-secret>
      AZURE_TENANT_ID <tenant-id>
      AZURE_SUBSCRIPTION_ID <subscription-id>

Criar o fluxo de trabalho de Ações do GitHub

Agora que você tem uma entidade de serviço que pode acessar seus aplicativos do Serviço de Aplicativo, edite os fluxos de trabalho padrão que foram criados para seus aplicativos quando você configurou a implantação contínua. A autenticação deve ser feita usando sua entidade de serviço em vez do perfil de publicação. Para exemplos de fluxos de trabalho, consulte a guia "Entidade de serviço" em Adicionar o arquivo de fluxo de trabalho ao repositório do GitHub. O fluxo de trabalho de exemplo a seguir pode ser usado para o aplicativo de exemplo Node.js que foi fornecido.

  1. Abra o repositório GitHub do seu aplicativo e vá para o <repo-name>/.github/workflows/ diretório. Você deve ver os fluxos de trabalho gerados automaticamente.

  2. Para cada arquivo de fluxo de trabalho, selecione o botão "lápis" no canto superior direito para editar o arquivo. Substitua o conteúdo pelo texto a seguir, que pressupõe que você criou os segredos do GitHub anteriormente para sua credencial. Atualize o espaço reservado para <web-app-name> na seção "env" e, em seguida, confirme diretamente na ramificação principal. Essa confirmação aciona a Ação do GitHub para ser executada novamente e implantar seu código, desta vez usando a entidade de serviço para autenticar.

    
name: Build and deploy Node.js app to Azure Web App

on:
  push:
    branches:
      - main
  workflow_dispatch:

env:
  AZURE_WEBAPP_NAME: <web-app-name>   # set this to your application's name
  NODE_VERSION: '18.x'                # set this to the node version to use
  AZURE_WEBAPP_PACKAGE_PATH: '.'      # set this to the path to your web app project, defaults to the repository root
  AZURE_WEBAPP_SLOT_NAME: stage       # set this to your application's slot name

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Set up Node.js version
        uses: actions/setup-node@v1
        with:
          node-version: ${{ env.NODE_VERSION }}

      - name: npm install, build
        run: |
          npm install
          npm run build --if-present

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v2
        with:
          name: node-app
          path: .

  deploy:
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: 'stage'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v2
        with:
          name: node-app

      - uses: azure/login@v1
        with:
          creds: |
            {
              "clientId": "${{ secrets.AZURE_APP_ID }}",
              "clientSecret":  "${{ secrets.AZURE_PASSWORD }}",
              "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}",
              "tenantId": "${{ secrets.AZURE_TENANT_ID }}"
            }

      - name: 'Deploy to Azure Web App'
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v2
        with:
          app-name: ${{ env.AZURE_WEBAPP_NAME }}
          slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }}
          package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

      - name: logout
        run: |
          az logout

Como é que o encaminhamento de tráfego de slots me permite testar as atualizações que faço nas minhas aplicações?

O roteamento de tráfego com slots permite direcionar uma parte predefinida do tráfego de usuários para cada slot. Inicialmente, 100% do tráfego é direcionado para o local de produção. No entanto, você tem a capacidade, por exemplo, de enviar 10% do seu tráfego para o slot de preparação. Se você configurar o roteamento de tráfego de slot dessa maneira, quando os usuários tentarem acessar seu aplicativo, 10% deles serão automaticamente roteados para o slot de preparo sem alterações na instância do Front Door. Para saber mais sobre trocas de slots e ambientes de preparo no Serviço de Aplicativo, consulte Configurar ambientes de preparo no Serviço de Aplicativo do Azure.

Como faço para mover meu código do meu slot de preparo para o meu slot de produção?

Depois de concluir o teste e a validação em seus slots de preparação, você pode realizar uma troca de slot do slot de preparo para o local de produção. Você precisa fazer essa troca para todas as instâncias do seu aplicativo em cada região. Durante uma troca de slot, a plataforma do Serviço de Aplicativo garante que o slot de destino não sofra tempo de inatividade.

Para executar a troca, execute o seguinte comando para cada aplicativo. Substitua o espaço reservado por <web-app-name>.

az webapp deployment slot swap --resource-group MyResourceGroup -name <web-app-name> --slot stage --target-slot production

Depois de alguns minutos, você pode navegar até o ponto de extremidade da sua porta da frente para validar a troca de slot bem-sucedida.

Neste ponto, seus aplicativos estão em execução e quaisquer alterações feitas no código-fonte do aplicativo acionam automaticamente uma atualização para ambos os slots de preparação. Em seguida, você pode repetir o processo de troca de slot quando estiver pronto para mover esse código para a produção.

De que outra forma posso usar o Azure Front Door em minhas implantações de várias regiões?

Se você estiver preocupado com possíveis interrupções ou problemas com a continuidade entre regiões, como em alguns clientes que veem uma versão do seu aplicativo enquanto outros veem outra versão, ou se você estiver fazendo alterações significativas em seus aplicativos, você pode remover temporariamente o site que está passando pela troca de slot do grupo de origem do seu Front Door. Todo o tráfego é então direcionado para a outra origem. Navegue até o painel Atualizar grupo de origem e Excluir a origem que está passando pela alteração. Depois de fazer todas as alterações e estar pronto para atender o tráfego novamente, você pode retornar ao mesmo painel e selecionar + Adicionar uma origem para readicionar a origem.

Captura de ecrã a mostrar como remover uma origem da Porta da Frente do Azure.

Se preferir não excluir e, em seguida, readicionar origens, você pode criar grupos de origem extras para sua instância do Front Door. Em seguida, você pode associar a rota ao grupo de origem apontando para a origem pretendida. Por exemplo, você pode criar dois novos grupos de origem, um para sua região primária e outro para sua região secundária. Quando a região primária estiver passando por uma alteração, associe a rota à região secundária e vice-versa quando a região secundária estiver passando por uma alteração. Quando todas as alterações estiverem concluídas, você poderá associar a rota ao seu grupo de origem original que contém ambas as regiões. Esse método funciona porque uma rota só pode ser associada a um grupo de origem de cada vez.

Para demonstrar o trabalho com várias origens, na captura de tela a seguir, há três grupos de origem. "MyOriginGroup" consiste em ambos os aplicativos Web, e os outros dois grupos de origem consistem cada um no aplicativo Web em sua respetiva região. No exemplo, o aplicativo na região primária está passando por uma alteração. Antes dessa alteração ser iniciada, a rota era associada a "MySecondaryRegion" para que todo o tráfego fosse enviado para o aplicativo na região secundária durante o período de alteração. Você pode atualizar a rota selecionando Não associado, que exibe o painel Rotas associadas.

Captura de ecrã a mostrar como associar rotas ao Azure Front Door.

Como posso restringir o acesso ao site de ferramentas avançadas?

Com o serviço de Aplicativo do Azure, o site SCM/ferramentas avançadas é usado para gerenciar seus aplicativos e implantar o código-fonte do aplicativo. Considere bloquear o site de SCM/ferramentas avançadas, pois este site provavelmente não precisa ser acessado pela Front Door. Por exemplo, você pode configurar restrições de acesso que só permitem que você realize seus testes e habilite a implantação contínua a partir da ferramenta de sua escolha. Se você estiver usando slots de implantação, especificamente para slots de produção, poderá negar quase todo o acesso ao site do SCM, uma vez que o teste e a validação são feitos com os slots de preparação.

Próximos passos

Como implantar um aplicativo Web multirregião altamente disponível

Aplicação Web com redundância de zona altamente disponível