Tutorial: Crie uma aplicação multi-região altamente disponível no Serviço de Aplicações do Azure

Alta disponibilidade e tolerância a falhas são componentes-chave de uma solução bem arquitetada. Uma configuração robusta inclui um plano de emergência para falhas inesperadas, para reduzir o tempo de inatividade e manter os sistemas a funcionar automaticamente.

Quando implementas uma aplicação na cloud, escolhes uma região nessa cloud para a base da infraestrutura da aplicação. Se implementares uma aplicação apenas numa única região e essa região ficar indisponível, a aplicação também fica indisponível. A falta de disponibilidade pode ser inaceitável nos termos do acordo de nível de serviço (SLA) da aplicação. Para garantir a disponibilidade, implemente a aplicação e os seus serviços em várias regiões da cloud.

Este tutorial descreve como implementar uma aplicação web multi-região altamente disponível. O procedimento implementa um cenário simples que consiste numa aplicação web e Azure Front Door. Pode expandir os conceitos para suportar outros padrões de infraestrutura. Por exemplo, se a sua aplicação estiver ligada a uma oferta de base de dados do Azure ou a uma conta de armazenamento, veja Geo-replicação ativa para bases de dados SQL e Redundância do Armazenamento do Azure. Para uma arquitetura de referência para um cenário mais detalhado, veja o padrão Reliable web app para .NET.

Neste tutorial, você:

Pré-requisitos

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

Para concluir este tutorial:

• Usa o ambiente Bash em Azure Cloud Shell. Para mais informações, consulte Comece com Azure Cloud Shell.

  

• Se preferires executar comandos de referência da CLI localmente, instala CLI do Azure. Se estiveres a correr no Windows ou macOS, considera executar CLI do Azure num contentor Docker. Para mais informações, veja Como executar o CLI do Azure num contentor Docker.

  • Se estiveres a usar uma instalação local, inicia sessão na CLI do Azure usando o comando az login. Para concluir o processo de autenticação, siga os passos apresentados no seu terminal. Para outras opções de iniciação de sessão, veja Autenticar para Azure usando CLI do Azure.

  • Quando for solicitado, instale a extensão CLI do Azure na primeira utilização. Para mais informações sobre extensões, veja Usar e gerir extensões com a 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.

Revê a arquitetura do cenário

O diagrama de arquitetura a seguir mostra a infraestrutura criada neste tutorial. Consiste em duas aplicações de App Service idênticas em regiões diferentes. A primeira aplicação web está na região ativa. É a aplicação principal responsável por processar o tráfego recebido. A segunda aplicação está na região de espera e espera pela disponibilidade da aplicação principal. O Azure Front Door tenta encaminhar o tráfego para a aplicação web principal. Quando a região principal não está disponível, o tráfego é encaminhado para o sítio de espera. No diagrama, a linha pontilhada representa o encaminhamento do tráfego com base no estado da região. As restrições de acesso estão configuradas para bloquear o acesso direto às aplicações a partir da internet.

O Azure oferece várias opções para balanceamento de carga e encaminhamento de tráfego. Azure Front Door foi selecionado para este tutorial porque envolve aplicações web orientadas para a internet alojadas no Serviço de Aplicações do Azure implementadas em várias regiões. Se a sua configuração difere do exemplo neste tutorial, veja Escolher uma solução de balanceamento de carga para o seu cenário.

O cenário neste tutorial apresenta o seguinte comportamento:

• Aplicativos idênticos do Serviço de Aplicativo são implantados em duas regiões separadas.
• O tráfego público enviado diretamente para as aplicações web é bloqueado.
• O Azure Front Door encaminha o tráfego para a aplicação ativa na região principal.
• A aplicação de espera na região secundária está disponível para atender ao tráfego, quando necessário.

Criar um grupo de recursos

Precisas de duas instâncias de uma aplicação web que corram em diferentes regiões do Azure para este tutorial.

1. Revise os pares de regiões disponíveis e selecione duas regiões emparelhadas para as suas aplicações web.

   Neste tutorial, as duas regiões são referidas como (<primary-region>eastus) e <standby-region> (westus).

2. Cria um grupo de recursos para todos os recursos que configurares neste tutorial. Este tutorial cria o grupo de recursos na <primary-region> localização.

   az group create --name <resource-group> --location <primary-region>
   

   Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

   Parâmetro	valor	Descrição	Exemplo
   --name	<resource-group>	O grupo de recursos que contém os recursos criados neste tutorial.	zava-resource-group
   --location	<primary-region>	A localização da região para o grupo de recursos. Este tutorial utiliza a mesma localização de região para o grupo de recursos e para a aplicação web principal.	eastus

   Numa implementação real, use grupos de recursos separados para cada região/recurso. A separação permite o isolamento dos recursos numa situação de recuperação de desastres.

   Para mais informações, consulte a referência do comando az group create.

Criar dois planos de App Service

Crie dois planos de App Service, um para cada aplicação web. Crie cada plano na região onde espera criar a aplicação correspondente.

Para este comando, usa o par de regiões que selecionou anteriormente. Use a região ativa para a aplicação web principal e a região passiva para a aplicação web de espera.

Execute o comando seguinte para criar o plano do Serviço de Aplicações para a aplicação web principal e execute novamente o comando para criar o plano para a aplicação de espera.

az appservice plan create --name <app-service-plan> --resource-group <resource-group> --is-linux --location `<region>`

Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

Para mais informações, consulte a referência do comando az appservice plan create.

Criar duas aplicações

Criar duas aplicações web de Serviços de Aplicações. Coloque cada aplicação num plano de Serviço de Aplicações e localização regional correspondentes.

1. Identifique a --runtime versão linguística das aplicações web.

   Pode executar o seguinte comando para a lista de runtimes disponíveis:

   az webapp list-runtimes
   

   Se planeia usar a aplicação de Node.js exemplo descrita neste tutorial, defina o <language-version> valor para NODE:24-lts.

2. Cria duas aplicações web. Execute o comando seguinte para criar a aplicação web principal e execute novamente o comando para criar a aplicação de espera.

   az webapp create --name <web-app-name> --resource-group <resource-group> --plan <app-service-plan> --runtime <language-version>
   

   Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

   Parâmetro	valor	Descrição	Exemplo
   --name	<web-app-name>	o nome da aplicação Web. Cada aplicação deve ter um nome globalmente único. Os caracteres válidos são a-z, 0-9, e -.	zava-primary-app zava-standby-app
   --resource-group	<resource-group>	O grupo de recursos que contém os recursos criados neste tutorial.	zava-resource-group
   --name	<app-service-plan>	O nome do plano de serviço de aplicação para a aplicação web.	zava-primary-plan zava-standby-plan
   --runtime	<language-version>	A versão em linguagem de execução para a aplicação web.	NODE:24-lts

   Para mais informações, consulte a referência do comando az webapp create.

3. Identifique o valor defaultHostName de cada aplicação web. O formato do nome do anfitrião é <web-app-name>.azurewebsites.net.

   Analise o comando de saída de cada aplicação web e localize o valor, ou execute o seguinte comando para cada aplicação web:

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

   Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

   Parâmetro	valor	Descrição	Exemplo
   --name	<web-app-name>	o nome da aplicação Web.	zava-primary-app zava-standby-app
   --resource-group	<resource-group>	O grupo de recursos que contém os recursos criados neste tutorial.	zava-resource-group

   No portal Azure, o nome do anfitrião de cada aplicação é visível na página da aplicação web Overview.

   Regista os nomes dos hosts para mais tarde. Usas os nomes dos hosts para definir os endereços backend para a implementação do Azure Front Door.

4. Confirma que consegues aceder às novas aplicações web.

   1. Num navegador, introduza o nome de host da aplicação web principal, como zava-primary-app.azurewebsites.net.

      Quando a ligação resulta, vê a seguinte mensagem:

      

   2. Repita o teste com o nome de host da sua aplicação web secundária.

Configure Azure Front Door

Uma implementação multi-região pode usar uma configuração ativo-ativo ou ativo-passivo . A região primária é ativa e a região de reserva é passiva.

• Uma configuração ativo-ativo distribui solicitações em várias regiões ativas.
• Uma configuração ativo-passiva mantém as instâncias a correr na região de espera (passiva), mas não envia tráfego para lá a menos que a região principal (ativa) falhe.

O Azure Front Door permite ativar ambas as configurações. Para mais informações sobre o design de aplicações para alta disponibilidade e tolerância a falhas, consulte a lista de verificação de revisão de design para fiabilidade.

Criar um perfil

Crie uma instância de Azure Front Door Premium para encaminhar tráfego para as suas aplicações web.

1. Revise a comparação dos níveis de Azure Front Door e selecione o nível para o seu desdobramento.

   Este tutorial utiliza Azure Front Door Premium (Premium_AzureFrontDoor).

   Se preferir implementar o Azure Front Door Standard, tenha em mente que o nível Standard não suporta a implementação de regras geridas com a Política WAF.

2. Execute o seguinte comando para criar o perfil:

   az afd profile create --profile-name <front-door-profile> --resource-group <resource-group> --sku <front-door-tier>
   

   Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

   Parâmetro	valor	Descrição	Exemplo
   --profile-name	<front-door-profile>	O nome do perfil Azure Front Door. O nome tem de ser exclusivo dentro do grupo de recursos.	zava-profile
   --resource-group	<resource-group>	O grupo de recursos que contém os recursos criados neste tutorial.	zava-resource-group
   --sku	<front-door-tier>	O tier SKU do Azure Front Door para a implementação.	Premium_AzureFrontDoor (recomendado) Standard_AzureFrontDoor

   Para mais informações, consulte a referência do comando az afd profile create.

Adicionar um ponto final

Crie um endpoint no seu perfil. Depois de criar o primeiro endpoint, pode criar vários endpoints no seu perfil.

az afd endpoint create --resource-group <resource-group> --endpoint-name <front-door-endpoint> --profile-name <front-door-profile> --enabled-state Enabled

Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

Para mais informações, consulte a referência do comando de criação de endpoint az afd.

Criar um grupo de origem

Quando implementas para o Azure Front Door, precisas de um origin que sirva como endpoint para o backend da tua aplicação web. Para mais informações, veja Origens e grupos de origem em Azure Front Door. As origens são armazenadas num grupo de origem.

Crie um grupo de origem no seu perfil Azure Front Door para conter as origens das suas duas aplicações web.

az afd origin-group create --resource-group <resource-group> --origin-group-name <front-door-origin-group> --profile-name <front-door-profile> \
   --probe-request-type <probe-request> \
   --probe-protocol <probe-protocol> \
   --probe-interval-in-seconds <probe-interval> \
   --probe-path <probe-path> \
   --sample-size <sample-size> \
   --successful-samples-required <required-samples> \
   --additional-latency-in-milliseconds <extra-latency>

Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

Para mais informações, consulte a referência do comando az afd origin-group create.

Adicionar origens ao grupo de origem

Adicione uma origem para cada uma das suas aplicações web ao seu grupo de origem do Azure Front Door.

1. Adiciona uma origem para a aplicação web principal . Defina o parâmetro --priority para 1, o que Azure Front Door informa que esta aplicação é o principal recetor de tráfego.

   az afd origin create --resource-group <resource-group> --host-name <web-app-name>.azurewebsites.net --profile-name <front-door-profile> \
      --origin-group-name <front-door-origin-group> \
      --origin-name <web-app-origin-name> \
      --origin-host-header <web-app-name>.azurewebsites.net \
      --priority <origin-priority> --weight <origin-weight> --enabled-state <origin-state> \
      --http-port <origin-port> --https-port <origin-secure-port>
   

   Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

   Parâmetro	valor	Descrição	Exemplo
   --resource-group	<resource-group>	O grupo de recursos que contém os recursos criados neste tutorial.	zava-resource-group
   --host-name	<web-app-name>.azurewebsites.net	O nome de host da sua aplicação web principal . O nome do host combina o nome da aplicação web, como zava-primary-app com o identificador do host, azurewebsites.net.	zava-primary-app.azurewebsites.net
   --profile-name	<front-door-profile>	O nome do seu perfil do Azure Front Door.	zava-profile
   --origin-group-name	<front-door-origin-group>	O nome do grupo de origem do Azure Front Door.	zava-origin-group
   --origin-name	<web-app-origin-name>	O nome da origem para a aplicação web principal. O nome deve ser único dentro do grupo de origem.	primary-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	O cabeçalho do host para enviar pedidos para a origem principal da aplicação web. Se não especificar um valor, o nome do host do pedido determina esse valor. As origens do CDN do Azure, como Aplicações Web, Armazenamento de Blobs e Cloud Services, exigem que este valor do cabeçalho host corresponda ao nome do host de origem por padrão.	zava-primary-app.azurewebsites.net
   --priority	<origin-priority>	A prioridade para esta origem dentro do grupo de origem. Para a aplicação web principal , defina a prioridade para 1. O Azure Front Door utiliza os valores de prioridade para balanceamento de carga entre origens e regiões ativas. O valor deve estar entre 1 e 5.	1
   --weight	<origin-weight>	O peso da origem dentro do grupo de origem para o balanceamento de carga. O valor deve estar entre 1 e 1000.	1000
   --enabled-state	<origin-state>	Indique se deve ativar esta origem para receber tráfego.	Enabled
   --http-port	<origin-port>	A porta usada para solicitações HTTP para a origem.	80
   --https-port	<origin-secure-port>	A porta usada para pedidos HTTPS seguros para a origem.	443

   Para mais informações, consulte a referência do comando az afd origin create.

2. Execute o comando novamente e adicione uma origem para a aplicação web em espera. O comando usa os mesmos parâmetros, mas com os seguintes valores únicos de parâmetro:

   Parâmetro	valor	Descrição	Exemplo
   --host-name	<web-app-name>.azurewebsites.net	O nome de host para a sua aplicação web standby.	zava-standby-app.azurewebsites.net
   --origin-name	<web-app-origin-name>	O nome da origem da aplicação web em espera.	standby-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	O cabeçalho do host para enviar pedidos para a origem da aplicação web de espera .	zava-standby-app.azurewebsites.net
   --priority	<origin-priority>	A prioridade desta origem no grupo de origem. Para a aplicação web standby, defina a prioridade para 2. Azure Front Door tenta direcionar todo o tráfego para a origem principal. Quando a origem principal não está disponível, o tráfego é encaminhado para a origem de reserva.	2

Adicionar uma regra de rota

Adicione uma regra de roteamento para mapear o ponto final do Azure Front Door para o grupo de origem. A rota encaminha pedidos do endpoint para o seu grupo de origem.

1. Crie uma regra de rota para mapear o ponto final do Azure Front Door para o grupo de origem:

   az afd route create --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> `
      --forwarding-protocol <protocol-type> --route-name <route-rule-name> --https-redirect <secure-redirect> `
      --origin-group <front-door-origin-group> --supported-protocols <protocol-list> --link-to-default-domain <domain-link> 
   

   Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

   Parâmetro	valor	Descrição	Exemplo
   --resource-group	<resource-group>	O grupo de recursos que contém os recursos criados neste tutorial.	zava-resource-group
   --profile-name	<front-door-profile>	O nome do teu perfil Azure Front Door.	zava-profile
   --endpoint-name	<front-door-endpoint>	O nome do endpoint no perfil do Azure Front Door.	zava-endpoint
   --forwarding-protocol	<protocol-type>	O protocolo utilizado por esta regra de rota ao encaminhar tráfego para as aplicações de backend.	MatchRequest
   --route-name	<route-rule-name>	O nome da regra de rota. Deve ser único dentro do perfil Azure Front Door.	zava-route-rule
   --https-redirect	<secure-redirect>	Indica se deve redirecionar automaticamente o tráfego HTTP para tráfego HTTPS.	Enabled
   --origin-group-name	<front-door-origin-group>	O nome do grupo de origem do Azure Front Door.	zava-origin-group
   --supported-protocols	<protocol-list>	A lista dos protocolos suportados para esta regra de rotas. Use um espaço para separar os tipos de protocolo.	Http Https
   --link-to-default-domain	<domain-link>	Indique se esta rota está ligada ao domínio endpoint predefinido.	Enabled

   Para mais informações, consulte a referência do comando az afd route create.

2. Espere cerca de 15 minutos para a implementação ser concluída. Pode demorar algum tempo até que as mudanças se propaguem globalmente.

Restringa o acesso apenas através do Azure Front Door

Atualmente, pode aceder diretamente às suas aplicações web introduzindo os nomes dos seus anfitriões num navegador. Se definir restrições de acesso às suas aplicações, pode garantir que o tráfego só chega às suas aplicações através do Azure Front Door.

As funcionalidades do Azure Front Door funcionam melhor quando o tráfego flui apenas através do serviço. É uma boa prática configurar as origens da tua aplicação web para bloquear o tráfego que não é enviado pelo Azure Front Door. Caso contrário, o tráfego pode contornar o firewall de aplicações web do Azure Front Door, proteção DDoS e outras funcionalidades de segurança.

O tráfego de Azure Front Door para as suas aplicações origina-se de um conjunto bem conhecido de intervalos de IP definidos na etiqueta de serviço AzureFrontDoor.Backend. Ao usar uma regra de restrição de etiquetas de serviço, pode restringir tráfego para que apenas provenha de Azure Front Door.

1. Obtenha o identificador do seu perfil Azure Front Door.

   Precisas do ID do perfil para garantir que o tráfego só se origina da tua instância específica do Azure Front Door. A restrição de acesso filtra ainda mais os pedidos recebidos com base no cabeçalho HTTP único enviado pelo seu perfil Azure Front Door.

   az afd profile show --resource-group <resource-group> --profile-name <front-door-profile> --query "frontDoorId"
   

   Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

   Parâmetro	valor	Descrição	Exemplo
   --resource-group	<resource-group>	O grupo de recursos que contém os recursos criados neste tutorial.	zava-resource-group
   --profile-name	<front-door-profile>	O nome do seu perfil do Azure Front Door.	zava-profile

   A saída do comando mostra o ID do perfil (valor alfanumérico de 32 dígitos):

   "0000aaaa-1b1b-2c2c-3d3d-444444eeeeee"
   

   No passo seguinte, utilize o identificador de perfil para o valor <profile-identifier>.

2. Execute o comando seguinte para definir restrições de acesso na sua aplicação web principal e execute novamente o comando para definir restrições na aplicação de espera.

   az webapp config access-restriction add --resource-group <resource-group> --name <web-app-name> `
      --priority <access-priority> --service-tag <tag-name> --http-header x-azure-fdid=<front-door-id>
   

   Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

   Parâmetro	valor	Descrição	Exemplo
   --resource-group	<resource-group>	O grupo de recursos que contém os recursos criados neste tutorial.	zava-resource-group
   --name	<web-app-name>	O nome da aplicação web para a qual está a definir restrições de acesso.	zava-primary-app zava-standby-app
   --priority	<access-priority>	Especifique a prioridade da regra de restrição de acesso em todas as regras definidas para o perfil. Um valor mais baixo equivale a uma prioridade mais alta.	100
   --service-tag	<tag-name>	Um nome de etiqueta de serviço reconhecido pelo Azure Front Door. As restrições de acesso aplicam-se ao intervalo de IP indicado pela etiqueta de serviço.	AzureFrontDoor.Backend
   --http-header	x-azure-fdid=<profile-identifier>	Especifique um ou mais cabeçalhos HTTP únicos para filtragem extra do tráfego recebido. As restrições de acesso filtram os pedidos recebidos com base no cabeçalho HTTP único enviado pelo seu perfil Azure Front Door. O cabeçalho combina o prefixo Azure Front Door e o identificador de perfil da sua instância Azure Front Door.	x-azure-fdid=0000aaaa-1b1b-2c2c-3d3d-444444eeeeee

   Para mais informações, consulte a referência do comando az webapp config access-restriction add.

Restrições de acesso ao teste

Confirme que as restrições de acesso impedem o acesso direto às suas aplicações.

1. Num navegador, introduza o nome de host da aplicação web principal, como zava-primary-app.azurewebsites.net.

   A ligação deverá falhar com a seguinte mensagem:

   

2. Repita o teste com o nome de host da sua aplicação web de suporte, como zava-standby-app.azurewebsites.net.

Teste a implementação do Azure Front Door

Quando cria o perfil Azure Front Door Standard ou Premium, pode demorar algum tempo até a configuração ser implementada globalmente. Depois de concluída a implantação, pode aceder ao host frontend.

1. Obtenha o nome do host do seu endpoint do Azure Front Door:

   az afd endpoint show --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> --query "hostName"
   

   Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

   Parâmetro	valor	Descrição	Exemplo
   --resource-group	<resource-group>	O grupo de recursos que contém os recursos criados neste tutorial.	zava-resource-group
   --profile-name	<front-door-profile>	O nome do seu perfil do Azure Front Door.	zava-profile
   --endpoint-name	<front-door-endpoint>	O nome do endpoint no perfil do Azure Front Door.	zava-endpoint

   A saída do comando mostra o nome de host do endpoint:

   "zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net"
   

   O nome do host é composto pelo nome do endpoint, um hash alfanumérico único, um identificador, e o sufixo do Azure Front Door. No passo seguinte, usa o nome de host do endpoint.

   Para mais informações, consulte a referência de comandos do az afd endpoint show.

2. Num navegador, introduza o nome de host do endpoint, como zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

   O seu pedido deve ser automaticamente encaminhado para a sua aplicação principal na região ativa.

   Quando a ligação resulta, vê a seguinte mensagem:

   

3. Teste o failover global instantâneo entre as aplicações nas regiões emparelhadas.

   1. Num navegador, introduza o nome de host do endpoint, como zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

   2. Pare a aplicação principal executando o comando az webapp stop.

      Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

      az webapp stop --name <primary-web-app> --resource-group <resource-group>
      

   3. Atualize o seu browser.

      Se o tráfego for corretamente redirecionado para a app de espera na outra região, deverá ver a mesma página e mensagem.

      Gorjeta

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

      Pode confirmar que o Azure Front Door está a redirecionar para a app de espera verificando o estado das aplicações web no portal Azure. Na página de Visão Geral da aplicação web principal, a opção Iniciar deverá estar disponível (não cinzenta). Na página de Visão Geral da aplicação web em espera, a opção Iniciar não deveria estar disponível (indisponível).

   4. Executa o az webapp stop comando novamente e desliga a tua aplicação de espera .

      Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

      az webapp stop --name <standby-web-app> --resource-group <resource-group>
      

   5. Atualize novamente o navegador.

      Se a aplicação em modo de espera também parar, todo o encaminhamento de tráfego deve ser interrompido. Desta vez, deverá ver uma mensagem de erro:

      

   6. Executa o az webapp start comando e reinicia a tua aplicação de espera .

      Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos:

      az webapp start --name <standby-web-app> --resource-group <resource-group>
      

   7. Atualize o navegador e deverá ver uma ligação bem-sucedida à app.

A validação confirma que agora pode aceder às suas aplicações através do Azure Front Door e que as funções de recuperação estão a funcionar conforme o esperado.

Se já concluíste os testes de failover, reinicia a tua aplicação principal.

Limpar recursos

Nos passos anteriores, criou recursos do Azure num grupo de recursos. Se não esperar precisar destes recursos no futuro, elimine o grupo de recursos executando o seguinte comando na Cloud Shell.

Substitua o valor do <placeholder> parâmetro pela informação do seu próprio recurso:

az group delete --name <resource-group>

Esse comando pode levar alguns minutos para ser executado.

Desdobrar a partir do ARM ou Bicep

Os recursos que criaste neste tutorial podem ser implementados usando um modelo do Azure Resource Manager (template ARM) ou Bicep. Pode começar pelo ficheiro Bicep de aplicação web multi-região altamente disponível no GitHub. Este modelo ajuda-o a criar uma solução segura, altamente disponível e multi-região de ponta a ponta, com duas aplicações web em diferentes regiões atrás do Azure Front Door.

Para aprender a implementar modelos ARM e Bicep, consulte Implementação de ficheiros Bicep através do CLI do Azure.

Perguntas mais frequentes

Neste tutorial, implementaste uma infraestrutura básica para ativar uma aplicação web multi-região. O App Service oferece funcionalidades que podem ajudar a garantir que está a executar aplicações que seguem as melhores práticas e recomendações de segurança.

Esta secção contém respostas a perguntas frequentes que podem ajudá-lo a proteger ainda mais as suas aplicações e a implementar e gerir os seus recursos de acordo com as melhores práticas.

Gerir e implementar recursos de infraestrutura e Azure

Para este tutorial, usaste a CLI do Azure para implementar os teus recursos de infraestrutura. Considere configurar um mecanismo de implantação contínua para gerenciar sua infraestrutura de aplicativos. Como está a implementar recursos em diferentes regiões, precisa de gerir esses recursos de forma independente entre as regiões. Para garantir que os recursos são idênticos em cada região, a infraestrutura como código (IaC), como um modelo ARM ou Terraform deve ser usada com pipelines de implementação como Azure Pipelines ou GitHub Actions. Quando configuras esta configuração de forma adequada, qualquer alteração nos recursos desencadeia atualizações em todas as regiões de implementação. Para mais informações, consulte Configurar implementação contínua para Serviço de Aplicações do Azure.

Use os espaços de preparação para uma implementação segura em produção

Não é recomendado implementar código de aplicação diretamente para aplicações e slots de produção. É importante ter um local seguro para testar as suas aplicações e validar alterações antes de lançar para produção. Use uma combinação de slots de faseamento e alternação de slots para mover o código do ambiente de testes para o ambiente de produção.

Neste tutorial, criou-se a infraestrutura básica que suporta o uso de staging slots. Pode criar espaços de implementação para cada instância da sua aplicação web e configurar a implantação contínua nestes espaços de pré-produção com GitHub Actions. Tal como na gestão de infraestruturas, recomenda-se também configurar a implementação contínua do código-fonte da sua aplicação para garantir que as alterações entre regiões permaneçam sincronizadas. Se não configurares a implementação contínua, tens de atualizar manualmente cada aplicação em cada região sempre que houver uma alteração de código.

Para usar os slots de staging, siga este procedimento:

1. Para este procedimento, precisa de uma aplicação pronta para ser implementada na sua aplicação de Serviços de Aplicações.

   Se completaste o tutorial, podes usar a tua aplicação web principal e a app de espera. No entanto, precisa de um plano de Serviços de Aplicações que suporte slots de implementação suficientes. Para mais informações, consulte Azure limites de subscrição e serviços, quotas e restrições.

   Se não tiveres uma aplicação, podes começar pela aplicação de exemplo Node.js Hello World. Faz um fork no repositório do GitHub para teres a tua própria cópia para fazer alterações.

2. Configura as definições da pilha de Serviços de Aplicações para as tuas aplicações web.

   Definições de stack referem-se à versão da linguagem ou ao ambiente de execução usado na sua aplicação.

   Podes configurar as definições no portal Azure ou usar o comando az webapp config set. Se utilizar o exemplo do Node.js, defina as configurações da pilha para Node 24 LTS.

   1. No portal Azure, aceda à sua aplicação web principal.

   2. No menu à esquerda, selecione Definições>Configuração.

   3. No separador Stack Settings , configure as seguintes definições:

      1. Selecione o valor de Stack, como Node.

      2. Selecione o valor Versão, como Node 24 LTS.

      3. Selecione Aplicar.

   4. Repita o processo para configurar as definições da pilha de Serviços de Aplicações para a sua aplicação web de espera .

3. Configure a implementação contínua no portal Azure. Para orientações detalhadas sobre como configurar a implementação contínua com fornecedores como a GitHub Actions, consulte Configurar a implementação contínua para Serviço de Aplicações do Azure.

4. Execute o comando seguinte para criar um slot de staging nomeado stage para a sua aplicação web principal .

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

5. Execute o comando az webapp deployment slot create novamente e crie um slot de staging chamado stage para a aplicação web de espera.

6. Configurar a implementação contínua com GitHub Actions para cada slot de preparação:

   1. No portal Azure, aceda à sua aplicação web principal.

   2. No menu à esquerda, selecione Deployment>Deployment slots.

   3. Localiza o espaço do cenário na lista e seleciona o espaço para abrir o painel de detalhes.

   4. No menu à esquerda, selecione Centro de Implantação (Deployment>Deployment Center).

   5. No separador Settings, defina a opção Source para GitHub:

      

   6. Se estiver a implementar a partir do GitHub pela primeira vez, selecione Authorize e siga as instruções de autorização. Se você quiser implantar a partir do repositório de um usuário diferente, selecione Alterar conta.

   7. Depois de autorizar a sua conta de Azure com GitHub, selecione Organization, Repository e Branch para configurar o CI/CD. Se não conseguires encontrar uma organização ou repositório, talvez precises de ativar mais permissões no GitHub. Para mais informações, consulte Gerir o acesso dos utilizadores aos repositórios da sua organização.

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

      Configuração	valor
      Organização	<your-GitHub-organization>
      Repositório	nodejs-docs-hello-world
      Filial	principal

   8. Selecione Guardar.

Novos commits no repositório e branch selecionados agora são implementados continuamente no slot de aplicação do App Service. Você pode acompanhar os commits e as implementações na aba Logs.

Um ficheiro de workflow predefinido que utiliza um perfil de publicação para autenticar no App Service é adicionado ao teu repositório GitHub. Você pode visualizar este arquivo indo para o <repo-name>/.github/workflows/ diretório.

Desativar a autenticação básica no Serviço de Aplicação

Pode limitar o acesso aos endpoints FTP e SCM a utilizadores apoiados por Microsoft Entra ID desabilitando a autenticação básica.

Se usar uma ferramenta de implementação contínua para implementar o código-fonte da sua aplicação, desativar a autenticação básica requer passos adicionais para configurar a implementação contínua. Por exemplo, não pode usar um perfil de publicação porque não utiliza credenciais Microsoft Entra. Em vez disso, precisa de usar um principal de serviço ou credenciais de OpenID Connect.

Os comandos a seguir desativam a autenticação básica para a aplicação web principal do Serviço de Aplicações e seu slot de staging, assim como para a aplicação web de reserva e seu slot de staging. Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos.

1. Desative o acesso FTP para os locais de produção e os espaços de encenação para a sua aplicação web principal :

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

2. Executa novamente os comandos para a tua aplicação web em espera.

3. Desative o acesso básico de autenticação à porta WebDeploy e ao site SCM para os sites de produção e slots de staging para a sua aplicação web principal :

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

4. Executa novamente os comandos para a sua aplicação web em espera.

Para mais informações sobre como desativar a autenticação básica, incluindo como testar e monitorizar logins, consulte Desabilitar autenticação básica em implementações de Serviços de Aplicação.

Usar implantação contínua quando a autenticação básica estiver desativada

Se optar por permitir autenticação básica nas suas aplicações de App Service, pode usar qualquer um dos métodos de implementação disponíveis no App Service. Por exemplo, pode usar o perfil de publicação que configurou na secção de slots de staging .

Se desativar a autenticação básica para as suas aplicações do App Service, a implementação contínua requer um principal de serviço ou OpenID Connect para autenticação. Se usar GitHub Actions como repositório de código, veja o Deploy to Serviço de Aplicações do Azure usando GitHub Actions. O tutorial fornece instruções passo a passo para criar um principal de serviço ou OpenID Connect para implementar no App Service usando o GitHub Actions. Também pode completar o processo seguindo o procedimento na secção seguinte.

Crie uma identidade de serviço e credenciais utilizando o GitHub Actions

Configure a implementação contínua com GitHub Actions e um principal de serviço:

1. Crie o service principal para a sua aplicação web principal e para a aplicação web secundária:

   Substitua os seguintes <placeholder> valores de parâmetros pela informação dos seus próprios recursos.

   az ad sp create-for-rbac --name <service-principal-name> --role contributor --scopes \
      /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<primary-web-app> \
      /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<standby-web-app>
   

   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.

   {
     "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
     "clientSecret": "ffffffff-5a5a-6b6b-7c7c-888888888888",
     "subscriptionId": "cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a",
     "tenantId": "aaaabbbb-6666-cccc-7777-dddd8888eeee",
     "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
     "resourceManagerEndpointUrl": "https://management.azure.com/",
     "activeDirectoryGraphResourceId": "https://graph.windows.net/",
     "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
     "galleryEndpointUrl": "https://gallery.azure.com/",
     "managementEndpointUrl": "https://management.core.windows.net/"
   }
   

   O JSON inclui o segredo do cliente, que só é visível neste momento.

   Gorjeta

   É uma boa prática conceder acesso mínimo. Neste exemplo, o âmbito está limitado apenas às aplicações, não a todo o grupo de recursos.

2. Copia o objeto JSON para teres um registo do segredo do teu cliente.

3. Forneça as suas credenciais de principal de serviço à operação de iniciar sessão no Azure como parte do seu fluxo de trabalho do GitHub Actions.

   Podes fornecer os valores diretamente no fluxo de trabalho ou armazená-los como segredos do GitHub que são referenciados no teu fluxo de trabalho. Guardar os valores como segredos do GitHub é a opção mais segura.

   1. Abre o repositório do GitHub para a tua aplicação.

   2. Vai a Definições>Segurança>Segredos e variáveis>Ações.

   3. Selecione Novo segredo de repositório e crie um segredo para cada uma das seguintes definições. Usa os valores da tua saída JSON.

      Configuração	valor	Exemplo
      AZURE_APP_ID	<application/client-id>	00001111-aaaa-2222-bbbb-3333cccc4444
      AZURE_PASSWORD	<client-secret>	ffffffff-5a5a-6b6b-7c7c-888888888888
      AZURE_TENANT_ID	<tenant-id>	aaaabbbb-6666-cccc-7777-dddd8888eeee
      AZURE_SUBSCRIPTION_ID	<subscription-id>	cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a

Criar fluxo de trabalho do GitHub Actions

Depois de ter um principal de serviço que possa aceder às suas aplicações de Serviços de Aplicações, edite os fluxos de trabalho predefinidos para as suas aplicações. Estes fluxos de trabalho são gerados automaticamente quando configura a implementação contínua.

A autenticação deve ser feita usando o seu principal de serviço em vez do perfil de publicação. Para fluxos de trabalho de exemplo, consulte o separador principal de serviço no Adicione o ficheiro de workflow ao seu repositório GitHub. O seguinte fluxo de trabalho de exemplo pode ser usado para a aplicação de exemploNode.js.

1. Abre o repositório do GitHub para a tua aplicação.

2. Vá para o <repo-name>/.github/workflows/ diretório. Você deve ver os fluxos de trabalho gerados automaticamente.

3. Para cada ficheiro de workflow, selecione Editar (lápis).

4. Substitua o conteúdo do ficheiro de workflow pelo seguinte conteúdo. O código assume que já criaste os segredos do GitHub para a tua credencial.

   Na env secção, configure as seguintes definições:

   • AZURE_WEBAPP_NAME: Substitua o <web-app-name> marcador pelo nome da sua aplicação web.
   • NODE_VERSION: Especifique a versão do Node.js utilizar. Para a Node.js amostra, o valor é '24.x'.
   • AZURE_WEBAPP_PACKAGE_PATH: Especifique o caminho para o seu projeto de aplicação web. O padrão é a raiz do repositório, '.'.
   • AZURE_WEBAPP_SLOT_NAME: Especifique o nome da sua vaga de candidatura. O nome comum é stage.

   
    name: Build and deploy Node.js app to Azure Web App
   
    on:
      push:
        branches:
          - main
      workflow_dispatch:
   
    env:
      AZURE_WEBAPP_NAME: <web-app-name>   # Your application name
      NODE_VERSION: '24.x'                # Node version to use
      AZURE_WEBAPP_PACKAGE_PATH: '.'      # Path to your web app project
      AZURE_WEBAPP_SLOT_NAME: stage       # Application slot name
   
    jobs:
      build:
        runs-on: ubuntu-latest
   
        steps:
          - uses: actions/checkout@v4
   
          - name: Set up Node.js version
            uses: actions/setup-node@v4
            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@v4
            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@v4
            with:
              name: node-app
   
          - uses: azure/login@v2
            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@v3
            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
   

5. Guarde e faça commit das alterações do ficheiro de workflow diretamente no branch principal do seu repositório.

   O commit desencadeia a Ação do GitHub para correr novamente e implementar o seu código. Desta vez, o principal de serviço é usado para autenticar.

Testar as atualizações da aplicação usando o encaminhamento de tráfego de slot

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, pode enviar 10% do seu tráfego para o seu slot de staging. Esta abordagem ao encaminhamento de tráfego das slots envia automaticamente 10% dos utilizadores que tentam aceder às slots de staging. A abordagem não requer alterações na sua instância do Azure Front Door. Para saber mais sobre trocas de slots e ambientes de staging no App Service, veja configurar ambientes de staging em Serviço de Aplicações do Azure.

Mover código do slot de staging para o slot de produção

Depois de terminares de testar e validar os teus slots de staging, podes fazer uma troca de slot do slot de staging para o local de produção. Completas a troca para todas as instâncias da tua aplicação 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.

1. Realize a troca da sua aplicação web principal :

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

2. Faça a troca pela sua aplicação web de espera :

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

3. Depois de alguns minutos, vá até ao endpoint do Azure Front Door no portal Azure e verifique que a troca de slot foi bem-sucedida.

Neste ponto, as suas aplicações estão a funcionar, e quaisquer alterações que faça ao código-fonte da aplicação ativam automaticamente uma atualização em ambos os seus slots de staging. Em seguida, você pode repetir o processo de troca de slot quando estiver pronto para mover esse código para a produção.

Evite interrupções e problemas de continuidade utilizando implantações multi-região

Pode evitar potenciais perturbações ou problemas de continuidade entre regiões, removendo temporariamente do seu grupo de origem do Azure Front Door um site que esteja a realizar a troca de slot. Esta ação ajuda a evitar que os clientes vejam versões diferentes da sua aplicação ao mesmo tempo. Também é útil quando está a fazer mudanças significativas nas suas aplicações. A remoção temporária faz com que todo o tráfego seja redirecionado para a outra origem.

1. No portal Azure, vai à tua instância Azure Front Door.

2. No menu esquerdo, selecione Definições>Grupos de Origem.

3. Na lista de grupos de origem, selecione o grupo de origem que contém o espaço que quer remover temporariamente.

4. No painel de Atualização do grupo de origem, encontre o slot a ser removido na lista de Nome de anfitrião de origem.

5. Selecionar Mais ações (...) >Apagar, e depois selecionar Atualizar.

   

   Pode demorar vários minutos a aplicar a mudança.

6. Quando estiveres pronto para permitir tráfego para o slot removido, volta ao painel Atualizar grupo de origem.

7. No topo, selecione + Adicionar uma origem para re-adicionar o slot de origem ao grupo de origem.

   

Criar grupos de origem extra e alterar associações de rotas

Se preferir não apagar e readicionar origens, pode criar grupos de origens adicionais para a sua instância do Azure Front Door. Depois podes associar a rota ao grupo de origem que aponta para a origem pretendida.

Por exemplo, podes criar dois grupos de origem extra, um para a tua região principal (ativa) e outro para a tua região de reserva (passiva). Se a sua região principal estiver a ser alterada, associe a rota à sua região de espera. Se a sua região de reserva estiver a sofrer uma alteração, associe a rota à sua região principal. 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.

Considere uma configuração com três grupos de origem:

• O Main-Origin grupo contém tanto as aplicações web primárias como as de reserva, cada uma nas respetivas regiões.
• O Primary-Origin grupo contém apenas a principal aplicação web na região ativa.
• O grupo Standby-Origin contém apenas a aplicação web em espera na região passiva.

Suponha que a aplicação web principal está a sofrer uma alteração. Antes de começarem as alterações, a associação de rotas do Main-Origin grupo é alterada para o Secondary-Origin grupo. Esta ação assegura que todo o tráfego roteia para a aplicação web de espera na sua respetiva região enquanto a aplicação web principal na sua região está a sofrer uma alteração.

Siga estes passos para alterar a associação de rotas de um grupo de origem:

1. No portal Azure, vai à tua instância Azure Front Door.

2. No menu esquerdo, selecione Definições>Grupos de Origem.

3. Na lista de grupos de origem, localize um grupo de origem que mostre o indicador Não Associado na coluna Rotas .

4. Selecione Mais ações (...) >Associar endpoint e rota.

   

5. No painel de rotas Associadas , selecione uma ou mais rotas para associar ao grupo de origem e depois selecione Associado.

   

Restringir o acesso ao site de ferramentas avançadas

Com o serviço Aplicação Azure AD, o site SCM/ferramentas avançadas é usado para gerir as suas aplicações e implementar o código-fonte da aplicação. Considere bloquear o acesso ao site de SCM/ferramentas avançadas, pois este site provavelmente não precisa ser acessado através do 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.

Conteúdo relacionado

• Desdobrar uma aplicação web multirregional altamente disponível
• Reveja a arquitetura base de uma aplicação web altamente disponível e resistente a falhas em zonas