Tutorial: Criar um aplicativo de várias regiões altamente disponível no Serviço de Aplicativo do Azure

Alta disponibilidade e tolerância a falhas são componentes fundamentais 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 em execução automaticamente.

Ao implantar um aplicativo na nuvem, você escolhe uma região nessa nuvem para a base de infraestrutura do aplicativo. Se você implantar um aplicativo apenas em uma única região e essa região ficar indisponível, o aplicativo também ficará indisponível. A falta de disponibilidade pode ser inaceitável nos termos do SLA (contrato de nível de serviço) do aplicativo. Para garantir a disponibilidade, implante o aplicativo e seus serviços em várias regiões na nuvem.

Este tutorial descreve como implantar um aplicativo Web de várias regiões altamente disponível. O procedimento implementa um cenário simples que consiste em um aplicativo Web e Azure Front Door. Você pode expandir os conceitos para dar suporte a outros padrões de infraestrutura. Por exemplo, se seu aplicativo se conectar a uma oferta de banco de dados do Azure ou a uma conta de armazenamento, consulte Replicação geográfica ativa para bancos de dados SQL e Armazenamento do Azure: redundância. Para obter uma arquitetura de referência para um cenário mais detalhado, consulte o padrão de aplicativo Web Reliable para .NET.

Neste tutorial, você:

Pré-requisitos

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

Para concluir este tutorial:

• Use o ambiente bash em Azure Cloud Shell. Para obter mais informações, consulte Get iniciado com Azure Cloud Shell.

  

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

  • Se você estiver usando uma instalação local, entre no CLI do Azure usando o comando az login. Para concluir o processo de autenticação, siga as etapas exibidas no terminal. Para obter outras opções de entrada, consulte Authenticate para Azure usando CLI do Azure.

  • Quando for solicitado, instale a extensão CLI do Azure no primeiro uso. Para obter mais informações sobre extensões, consulte Use e gerencie extensões com o CLI do Azure.

  • Execute az version para localizar a versão e as bibliotecas dependentes que estão instaladas. Para fazer a atualização para a versão mais recente, execute az upgrade.

Examinar a arquitetura do cenário

O diagrama de arquitetura a seguir mostra a infraestrutura que você criará neste tutorial. Ele consiste em dois aplicativos idênticos do Serviço de Aplicativo em regiões separadas. O primeiro aplicativo Web está na região ativa. É o aplicativo principal responsável pelo processamento do tráfego de entrada. O segundo aplicativo está na região de standby e aguarda a disponibilidade do aplicativo primário. Azure Front Door tenta rotear o tráfego para o aplicativo Web primário. Quando a região primária não está disponível, o tráfego é roteado para a Web em espera. No diagrama, a linha pontilhada representa o roteamento de tráfego com base no status da região. As restrições de acesso são configuradas para bloquear o acesso direto aos aplicativos da Internet.

Azure fornece várias opções para balanceamento de carga e roteamento de tráfego. Azure Front Door está selecionado para este tutorial porque envolve aplicativos Web voltados para a Internet hospedados em Serviço de Aplicativo do Azure implantados em várias regiões. Se sua configuração for diferente do exemplo neste tutorial, consulte Escolher uma solução de balanceamento de carga para seu cenário.

O cenário neste tutorial fornece o seguinte comportamento:

• Os aplicativos de Serviços de Aplicativo idênticos são implantados em duas regiões separadas.
• O tráfego público enviado diretamente para os aplicativos Web está bloqueado.
• Azure Front Door roteia o tráfego para o aplicativo ativo na região primária.
• O aplicativo em espera na região secundária está disponível para atender ao tráfego, conforme necessário.

Criar um grupo de recursos

Você precisa de duas instâncias de um aplicativo Web que são executadas em regiões de Azure diferentes para este tutorial.

1. Examine os pares de região disponíveis e selecione duas regiões emparelhadas para seus aplicativos Web.

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

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

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

   Substitua os seguintes <placeholder> valores de parâmetro pelas informações de 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>	O local da região para o grupo de recursos. Este tutorial usa o mesmo local de região para o grupo de recursos e o aplicativo Web primário.	eastus

   Em uma implementação real, use grupos de recursos separados para cada região/recurso. A separação permite o isolamento de recursos em uma situação de recuperação de desastre.

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

Criar dois planos do Serviço de Aplicativo

Crie dois planos do Serviço de Aplicativo, um para cada aplicativo Web. Crie cada plano no local da região em que você espera criar o aplicativo correspondente.

Para este comando, use o par de região selecionado anteriormente. Use a região ativa para o aplicativo Web primário e a região passiva para o aplicativo Web em espera.

Execute o comando a seguir para criar o plano do Serviço de Aplicativo para o aplicativo Web primário e execute o comando novamente para criar o plano para o aplicativo em espera.

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

Substitua os seguintes <placeholder> valores de parâmetro pelas informações de seus próprios recursos:

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

Criar dois aplicativos

Crie dois aplicativos Web do Serviço de Aplicativo. Coloque cada aplicativo em um plano de App Service correspondente e na região apropriada.

1. Identifique a versão do --runtime idioma para os aplicativos Web.

   Você pode executar o seguinte comando para a lista de runtimes disponíveis:

   az webapp list-runtimes
   

   Se você planeja usar o exemplo Node.js aplicativo descrito neste tutorial, defina o <language-version> valor como NODE:24-lts.

2. Crie dois aplicativos Web. Execute o comando a seguir para criar o aplicativo Web primário e execute o comando novamente para criar o aplicativo em 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âmetro pelas informações de seus próprios recursos:

   Parâmetro	Valor	Descrição	Exemplo
   --name	<web-app-name>	O nome do aplicativo Web. Cada aplicativo deve ter um nome globalmente exclusivo. Os caracteres válidos são a-z, 0-9e -.	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 do aplicativo para o aplicativo web.	zava-primary-plan zava-standby-plan
   --runtime	<language-version>	A versão de idioma do runtime para o aplicativo web.	NODE:24-lts

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

3. Identifique o defaultHostName valor de cada aplicativo Web. O formato do nome do host é <web-app-name>.azurewebsites.net.

   Examine a saída do comando para cada aplicativo Web e localize o valor ou execute o seguinte comando para cada aplicativo Web:

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

   Substitua os seguintes <placeholder> valores de parâmetro pelas informações de seus próprios recursos:

   Parâmetro	Valor	Descrição	Exemplo
   --name	<web-app-name>	O nome do aplicativo 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 host de cada aplicativo fica visível na página Overview do aplicativo Web.

   Registre os valores do nome do host para posteriormente. Use os nomes de host para definir os endereços de back-end para a implantação do Azure Front Door.

4. Confirme se você pode acessar os novos aplicativos Web.

   1. Em um navegador, insira o nome do host para o aplicativo Web primário, como zava-primary-app.azurewebsites.net.

      Quando a conexão for bem-sucedida, você verá a seguinte mensagem:

      

   2. Repita o teste com o nome do host para seu aplicativo Web em espera.

Configurar Azure Front Door

Uma implantação em várias regiões pode usar uma configuração ativa-ativa ou ativa-passiva. A região primária está ativa e a região em espera é passiva.

• A configuração ativa-ativa distribui as solicitações entre várias regiões ativas.
• Uma configuração ativa-passiva continua executando instâncias na região em espera (passiva), mas não envia tráfego para lá, a menos que a região primária (ativa) falhe.

Azure Front Door permite habilitar ambas as configurações. Para obter mais informações sobre como criar aplicativos para alta disponibilidade e tolerância a falhas, consulte a lista de verificação de revisão de design para obter confiabilidade.

Criar um perfil

Crie uma instância do Azure Front Door Premium para rotear o tráfego para seus aplicativos Web.

1. Examine a comparação de camadas Azure Front Door e selecione a camada para sua implantação.

   Este tutorial usa Azure Front Door Premium (Premium_AzureFrontDoor).

   Se você preferir implantar Azure Front Door Standard, tenha em mente que a camada Standard não dá suporte à implantação de regras gerenciadas com a Política de 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âmetro pelas informações de seus próprios recursos:

   Parâmetro	Valor	Descrição	Exemplo
   --profile-name	<front-door-profile>	Nome do perfil do Azure Front Door. O nome deve ser exclusivo no grupo de recursos selecionado.	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 SKU da camada do Azure Front Door para a implantação.	Premium_AzureFrontDoor (recomendado) Standard_AzureFrontDoor

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

Adicionar um ponto de extremidade

Crie um ponto de extremidade em seu perfil. Depois de criar o primeiro ponto de extremidade, você pode criar vários pontos de extremidade em 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âmetro pelas informações de seus próprios recursos:

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

Criar um grupo de origem

Ao implantar no Azure Front Door, você precisa de uma origem de tráfego para servir como endpoint para o back-end do aplicativo Web. Para obter mais informações, consulte Origins e grupos de origem em Azure Front Door. As origens são armazenadas em um grupo de origem.

Crie um grupo de origem em seu perfil Azure Front Door para conter origens para seus dois aplicativos 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âmetro pelas informações de seus próprios recursos:

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

Adicionar origens ao grupo de origem

Adicione uma origem para cada um dos seus aplicativos Web ao seu grupo de origem Azure Front Door.

1. Adicione uma origem para o aplicativo Web primário . Defina o parâmetro --priority como 1, que informa Azure Front Door que esse aplicativo é o receptor primário do 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âmetro pelas informações de 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 do host do seu aplicativo Web primário. O nome do host combina o nome do aplicativo Web, como zava-primary-app com o identificador azurewebsites.netdo host.	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 origens do Azure Front Door.	zava-origin-group
   --origin-name	<web-app-origin-name>	O nome de origem do aplicativo web primário. O nome deve ser exclusivo dentro do grupo de origem.	primary-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	O cabeçalho do host a ser enviado nas solicitações para o servidor de origem do aplicativo web primário. Se você não especificar um valor, o nome do host da solicitação determinará esse valor. As origens do CDN do Azure, como os Aplicativos Web, o Armazenamento de Blobs e os Serviços de Nuvem, exigem que este valor do cabeçalho do host corresponda ao nome do host de origem por padrão.	zava-primary-app.azurewebsites.net
   --priority	<origin-priority>	A prioridade dessa origem dentro do grupo de origens. Para o aplicativo Web primário , defina a prioridade como 1. Azure Front Door usa 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 balanceamento de carga. O valor deve estar entre 1 e 1000.	1000
   --enabled-state	<origin-state>	Indique se essa origem deve ser habilitada para receber tráfego.	Enabled
   --http-port	<origin-port>	A porta usada nas solicitações HTTP para a origem.	80
   --https-port	<origin-secure-port>	A porta usada para solicitações HTTPS seguras para a origem.	443

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

2. Execute o comando novamente e adicione uma origem para o aplicativo Web em espera . O comando usa os mesmos parâmetros, mas com os seguintes valores de parâmetro exclusivos:

   Parâmetro	Valor	Descrição	Exemplo
   --host-name	<web-app-name>.azurewebsites.net	O nome do host para seu aplicativo Web em espera .	zava-standby-app.azurewebsites.net
   --origin-name	<web-app-origin-name>	O nome da origem do aplicativo web standby.	standby-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	O cabeçalho do host a ser enviado para solicitações para a origem do aplicativo Web em espera .	zava-standby-app.azurewebsites.net
   --priority	<origin-priority>	A prioridade dessa origem dentro do grupo de origens. Para o aplicativo Web em espera , defina a prioridade como 2. Azure Front Door tenta direcionar todo o tráfego para a origem primária. Quando a origem primária não está disponível, o tráfego é roteado para a origem em espera.	2

Adicionar uma regra de rota

Adicione uma regra de roteamento para mapear o endpoint Azure Front Door ao grupo de origem. A rota encaminha solicitações do ponto de extremidade para o grupo de origem.

1. Crie uma regra de rota para mapear o ponto de extremidade do Azure Front Door ao 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âmetro pelas informações de 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 ponto de extremidade no perfil do Azure Front Door.	zava-endpoint
   --forwarding-protocol	<protocol-type>	O protocolo usado por essa regra de rota ao encaminhar o tráfego para os aplicativos de back-end.	MatchRequest
   --route-name	<route-rule-name>	O nome da regra de rota. Deve ser exclusivo dentro do perfil Azure Front Door.	zava-route-rule
   --https-redirect	<secure-redirect>	Indica se o tráfego HTTP é redirecionado automaticamente para o tráfego HTTPS.	Enabled
   --origin-group-name	<front-door-origin-group>	O nome do grupo de origens do Azure Front Door.	zava-origin-group
   --supported-protocols	<protocol-list>	A lista de protocolos com suporte para essa regra de rota. Use um espaço para separar os tipos de protocolo.	Http Https
   --link-to-default-domain	<domain-link>	Indique se essa rota está vinculada ao domínio de ponto de extremidade padrão.	Enabled

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

2. Permita cerca de 15 minutos para a conclusão da implantação. Pode levar algum tempo para que as alterações se propaguem globalmente.

Restringir o acesso somente por meio de Azure Front Door

Atualmente, você pode acessar seus aplicativos Web diretamente inserindo seus nomes de host em um navegador. Se você definir restrições de acesso em seus aplicativos, poderá garantir que o tráfego atinja seus aplicativos somente por meio de Azure Front Door.

Recursos do Azure Front Door funcionam melhor quando tráfego flui apenas através do serviço. É uma prática recomendada configurar as origens do aplicativo Web para bloquear o tráfego que não é enviado por Azure Front Door. Caso contrário, o tráfego poderá ignorar o Azure Front Door firewall do aplicativo Web, a proteção contra DDoS e outros recursos de segurança.

O tráfego de Azure Front Door para seus aplicativos se origina de um conjunto bem conhecido de intervalos de IP definido na marca de serviço AzureFrontDoor.Backend. Usando uma regra de restrição de marca de serviço, você pode restringir o tráfego de forma que se origine apenas do Azure Front Door.

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

   Você precisa da ID do perfil para garantir que o tráfego se origine apenas de sua instância de Azure Front Door específica. A restrição de acesso filtra ainda mais as solicitações de entrada com base no cabeçalho HTTP exclusivo enviado do seu perfil de 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âmetro pelas informações de 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 exibe a ID do perfil (valor alfanumérico de 32 dígitos):

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

   Na próxima etapa, você usará a ID do perfil para o valor <profile-identifier>.

2. Execute o comando a seguir para definir restrições de acesso em seu aplicativo Web primário e execute o comando novamente para definir restrições no aplicativo em 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âmetro pelas informações de 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 do aplicativo Web para o qual você está definindo 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 marca de serviço reconhecido por Azure Front Door. As restrições de acesso se aplicam ao intervalo de IP indicado pela marca de serviço.	AzureFrontDoor.Backend
   --http-header	x-azure-fdid=<profile-identifier>	Especifique um ou mais cabeçalhos HTTP exclusivos para filtragem extra do tráfego de entrada. As restrições de acesso filtram as solicitações de entrada com base no cabeçalho HTTP exclusivo enviado de seu perfil de Azure Front Door. O cabeçalho combina o prefixo Azure Front Door e o identificador de perfil para sua instância de Azure Front Door.	x-azure-fdid=0000aaaa-1b1b-2c2c-3d3d-444444eeeeee

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

Testar restrições de acesso

Confirme se as restrições de acesso impedem o acesso direto aos seus aplicativos.

1. Em um navegador, insira o nome do host para o aplicativo Web primário, como zava-primary-app.azurewebsites.net.

   A conexão deve falhar com a seguinte mensagem:

   

2. Repita o teste com o nome do host para seu aplicativo Web em espera, como zava-standby-app.azurewebsites.net.

Testar implantação de Azure Front Door

Quando você cria o perfil Azure Front Door Standard ou Premium, pode levar algum tempo para que a configuração seja implantada globalmente. Após a conclusão da implantação, você pode acessar o host de front-end.

1. Obtenha o nome do host do seu ponto de extremidade 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âmetro pelas informações de 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 ponto de extremidade no perfil do Azure Front Door.	zava-endpoint

   A saída do comando exibe o nome do host do endpoint.

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

   O nome do host é composto pelo nome do ponto de extremidade, um hash alfanumérico exclusivo, um identificador e pelo sufixo do Azure Front Door. No próximo passo, você usará o hostname do endpoint.

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

2. Em um navegador, insira o nome do host do endpoint, por exemplo, zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

   Sua solicitação deve rotear automaticamente para seu aplicativo primário na região ativa.

   Quando a conexão for bem-sucedida, você verá a seguinte mensagem:

   

3. Teste o failover global instantâneo entre os apps nas regiões emparelhadas.

   1. Em um navegador, insira o hostname do endpoint, como zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

   2. Interrompa o aplicativo primário executando o comando az webapp stop .

      Substitua os seguintes <placeholder> valores de parâmetro pelas informações de seus próprios recursos:

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

   3. Atualize seu navegador.

      Caso o tráfego redirecione corretamente para o aplicativo em espera na outra região, você verá a mesma página e mensagem.

      Dica

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

      Você pode confirmar que o Azure Front Door redireciona para o aplicativo de contingência verificando o status dos aplicativos web no portal do Azure. Na página Visão geral do aplicativo web primário, a opção Iniciar deve estar disponível (não desativada). Na página Visão geral do aplicativo Web em espera, a opção Iniciar deve estar indisponível (acinzentada).

   4. Execute o az webapp stop comando novamente e interrompa o aplicativo em espera .

      Substitua os seguintes <placeholder> valores de parâmetro pelas informações de seus próprios recursos:

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

   5. Atualize o navegador novamente.

      Se o aplicativo em espera também for interrompido, todo o roteamento de tráfego deverá parar. Desta vez, você deverá ver uma mensagem de erro:

      

   6. Execute o az webapp start comando e reinicie seu aplicativo em espera .

      Substitua os seguintes <placeholder> valores de parâmetro pelas informações de seus próprios recursos:

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

   7. Atualize seu navegador e você deverá ver uma conexão de aplicativo bem-sucedida.

A validação confirma que agora você pode acessar seus aplicativos por meio de funções de Azure Front Door e failover conforme o esperado.

Quando terminar o teste de failover, reinicie seu aplicativo primário.

Limpar os recursos

Nas etapas anteriores, você criou os recursos do Azure em um grupo de recursos. Se você não espera precisar desses recursos no futuro, exclua o grupo de recursos executando o comando a seguir no Cloud Shell.

Substitua o valor do <placeholder> parâmetro pelas informações do seu próprio recurso:

az group delete --name <resource-group>

Esse comando pode levar alguns minutos para ser executado.

Implantar a partir de ARM ou Bicep

Os recursos que você criou neste tutorial podem ser implantados usando um modelo do Azure Resource Manager (ARM template) ou modelo Bicep. Você pode começar com o arquivo Bicep de aplicativo web altamente disponível em várias regiões no GitHub. Esse modelo ajuda você a criar uma solução de ponta a ponta de várias regiões segura e altamente disponível com dois aplicativos Web em regiões diferentes por trás Azure Front Door.

Para saber como implantar modelos ARM e Bicep, consulte Deploy Bicep Files com o CLI do Azure.

Perguntas frequentes

Neste tutorial, você implantou uma 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 que seguem as melhores práticas e recomendações de segurança.

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

Gerenciar e implantar recursos de infraestrutura e Azure

Para este tutorial, você usou o CLI do Azure para implantar seus recursos de infraestrutura. Considere a configuração de um mecanismo de implantação contínua para gerenciar sua infraestrutura de aplicativo. Como você está implantando recursos em regiões diferentes, você precisa gerenciar esses recursos de forma independente entre as regiões. Para garantir que os recursos sejam idênticos em cada região, IaC (infraestrutura como código), como um modelo ARM ou Terraform deve ser usado com pipelines de implantação, como Azure Pipelines ou GitHub Actions. Quando você configura essa configuração adequadamente, qualquer alteração nos recursos dispara atualizações em todas as regiões de implantação. Para obter mais informações, consulte Configurar a implantação contínua no Serviço de Aplicativo do Azure.

Usar slots de preparo para implantação segura na produção

Não é recomendável implantar o código de aplicação diretamente em aplicativos e slots de produção. É importante ter um lugar seguro para testar seus aplicativos e validar as alterações antes de implementar na produção. Use uma combinação de slots de preparo e troca de slots para mover o código do ambiente de teste para a produção.

Neste tutorial, você criou a infraestrutura base que dá suporte ao uso de slots de estágio. Você pode criar slots de implantação para cada instância do seu aplicativo Web e configurar a implantação contínua para esses slots de preparo com GitHub Actions. Assim como acontece com o 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 permaneçam em sincronia. Se você não configurar a implantação contínua, será necessário atualizar manualmente cada aplicativo em cada região sempre que houver uma alteração de código.

Para usar slots de preparação, siga este procedimento:

1. Para este procedimento, você precisa de um aplicativo pronto para implantar em seu aplicativo do Serviço de Aplicativo.

   Se você concluiu o tutorial, pode usar seu aplicativo Web primário e aplicativo Web em espera. No entanto, você precisa de um plano do Serviço de Aplicativo que dê suporte a slots de implantação suficientes. Para obter mais informações, consulte Azure limites de assinatura e serviço, cotas e restrições.

   Se você não tiver um aplicativo, poderá começar com o aplicativo de exemplo Node.js Olá, Mundo. Bifurque o repositório GitHub para que você tenha sua própria cópia para fazer alterações.

2. Defina as configurações de pilha do Serviço de Aplicativo para seus aplicativos Web.

   As configurações de stack referem-se à versão de idioma ou ao runtime utilizado para o seu aplicativo.

   Você pode definir as configurações no portal do Azure ou usar o comando az webapp config set. Se você usar o exemplo de Node.js, defina as configurações de pilha como Node 24 LTS.

   1. No Azure portal, acesse seu aplicativo web principal.

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

   3. Na guia Configurações da pilha, defina as seguintes configurações:

      1. Selecione o valor Stack, como Nó.

      2. Selecione o valor de versão, como Node 24 LTS.

      3. Selecione Aplicar.

   4. Repita o processo para definir as configurações de pilha do Serviço de Aplicativo para seu aplicativo Web em espera .

3. Configure a implantação contínua no portal do Azure. Para obter diretrizes detalhadas sobre como configurar a implantação contínua com provedores como GitHub Actions, consulte Configuração contínua para Serviço de Aplicativo do Azure.

4. Execute o seguinte comando para criar um slot de preparação nomeado stage para seu aplicativo 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 az webapp deployment slot create comando novamente e crie um slot de preparo nomeado stage para o aplicativo Web em espera .

6. Configure a implantação contínua com GitHub Actions para cada slot de estágio.

   1. No Azure portal, vá para o seu aplicativo web primário.

   2. No menu à esquerda, selecione Implantação>slots de Implantação.

   3. Localize o slot stage na lista e selecione o slot para abrir o painel de detalhes.

   4. No menu à esquerda, selecione Implantação>Centro de Implantação.

   5. Na guia Settings, defina a opção Source como GitHub:

      

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

   7. Depois de autorizar sua conta de Azure com GitHub, selecione o Organization, Repository e Branch para configurar CI/CD. Se você 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 Gerenciar o acesso do usuário 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
      Branch	principal

   8. Clique em Salvar.

As novas confirmações no repositório e no branch selecionados agora são implantadas continuamente em seu aplicativo do Serviço de Aplicativo. É possível 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 GitHub. Você pode exibir esse arquivo acessando o diretório <repo-name>/.github/workflows/.

Desabilitar a autenticação básica no Serviço de Aplicativo

Você pode limitar o acesso aos pontos de extremidade FTP e SCM a usuários apoiados por Microsoft Entra ID desabilitando a autenticação básica.

Se você usar uma ferramenta de implantação contínua para implantar o código-fonte do aplicativo, desabilitar a autenticação básica exigirá etapas extras para configurar a implantação contínua. Por exemplo, você não pode usar um perfil de publicação porque ele não usa credenciais de Microsoft Entra. Em vez disso, você precisa usar um principal de serviço ou credencial do OpenID Connect.

Os comandos a seguir desabilitam a autenticação básica para o aplicativo web principal do App Service e seu slot de preparo, bem como para o aplicativo web de standby e seu slot de preparo. Substitua os valores de parâmetro a seguir <placeholder> pelas informações de seus próprios recursos.

1. Desativar o acesso FTP para os sites de produção e slots de hospedagem intermediária para seu aplicativo Web primário:

   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. Execute os comandos novamente para seu aplicativo Web em espera .

3. Desabilite o acesso de autenticação básica à porta WebDeploy e ao site do SCM para os sites de produção e os slots de preparo para seu aplicativo Web primário :

   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. Execute os comandos novamente para seu aplicativo Web em espera .

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.

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

Se você optar por permitir a 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. Por exemplo, você pode usar o perfil de publicação configurado na seção de slots de preparo .

Se você desativar a autenticação básica para seus aplicativos do App Service, a implantação contínua exigirá um principal de serviço ou o OpenID Connect para autenticação. Se você usar GitHub Actions como repositório de código, consulte o Deploy para Serviço de Aplicativo do Azure usando GitHub Actions. O tutorial fornece instruções passo a passo para criar uma entidade de serviço ou configurar OpenID Connect para implantar no Serviço de Aplicativo usando GitHub Actions. Você também pode concluir o processo seguindo o procedimento na próxima seção.

Criar principal de serviço e credenciais com GitHub Actions

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

1. Crie a entidade de serviço para sua aplicação Web primária e aplicação Web secundária:

   Substitua os valores de parâmetro a seguir <placeholder> pelas informações de 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 a 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ó está visível no momento.

   Dica

   É uma boa prática conceder acesso mínimo. Neste exemplo, o escopo é limitado apenas aos aplicativos, não a todo o grupo de recursos.

2. Copie o objeto JSON para que você tenha um registro do segredo do cliente.

3. Forneça suas credenciais de entidade de serviço para a operação de entrar no Azure como parte do fluxo de trabalho do GitHub Actions.

   Você pode fornecer os valores diretamente no fluxo de trabalho ou armazená-los como segredos do GitHub, que são referenciados no seu fluxo de trabalho. Salvar os valores como GitHub segredos é a opção mais segura.

   1. Abra o repositório GitHub para seu aplicativo.

   2. Vá para Configurações> Segredosde Segurança>e variáveis>Ações.

   3. Selecione Novo segredo do repositório e crie um segredo para cada uma das configurações a seguir. Use os valores da 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 GitHub Actions

Depois que você tiver um principal de serviço capaz de acessar seus aplicativos do App Service, edite os fluxos de trabalho padrão desses aplicativos. Esses fluxos de trabalho são gerados automaticamente quando você configura a implantação contínua.

A autenticação deve ser feita usando seu principal de serviço em vez do perfil de publicação. Para obter fluxos de trabalho de exemplo, consulte a guia Service principal em Adicionar o arquivo de fluxo de trabalho ao seu repositório do GitHub. O fluxo de trabalho de exemplo a seguir pode ser usado para o aplicativo de exemploNode.js.

1. Abra o repositório GitHub para seu aplicativo.

2. Acesse o diretório <repo-name>/.github/workflows/. Você deve visualizar os fluxos de trabalho gerados automaticamente.

3. Para cada arquivo de fluxo de trabalho, selecione Editar (lápis).

4. Substitua o conteúdo do arquivo de fluxo de trabalho pelo conteúdo a seguir. O código pressupõe que você já criou os segredos do GitHub para sua credencial.

   Na seção env, configure as seguintes configurações:

   • AZURE_WEBAPP_NAME: substitua o <web-app-name> marcador de posição pelo nome do aplicativo web.
   • NODE_VERSION: especifique a versão do node a ser usada. Para o exemplo de Node.js, o valor é '24.x'.
   • AZURE_WEBAPP_PACKAGE_PATH: especifique o caminho para o projeto do aplicativo Web. O padrão é a raiz do repositório. '.'
   • AZURE_WEBAPP_SLOT_NAME: especifique o nome do slot do aplicativo. 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. Salve e confirme as alterações do arquivo de fluxo de trabalho diretamente no branch principal do repositório.

   A confirmação dispara a ação GitHub para executar novamente e implantar seu código. Desta vez, o principal de serviço é usado para autenticar.

Testar atualizações do aplicativo usando o roteamento de tráfego de slots

O roteamento de tráfego com slots permite direcionar uma parte predefinida do tráfego do usuário para cada slot. Inicialmente, 100% do tráfego é direcionado para o site de produção. No entanto, você pode enviar 10% do tráfego para o slot de testes. Essa abordagem para roteamento de tráfego de slot envia automaticamente 10% dos usuários que tentam acessar o slot de preparação. A abordagem não requer alterações em sua instância de Azure Front Door. Para saber mais sobre trocas de slot e ambientes de preparo no App Service, consulte Configurar ambientes de preparo no Serviço de Aplicativo do Azure.

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

Depois de concluir o teste e a validação em seus ambientes de preparação, você poderá executar uma troca de slot do ambiente de preparação para o ambiente de produção. Você conclui a troca para todas as instâncias do seu aplicativo em cada região. Durante uma troca de slot, a plataforma Serviço de Aplicativo garante que o slot de destino não seja submetido a períodos de inatividade.

1. Execute a troca para seu aplicativo Web primário :

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

2. Execute a troca para seu aplicativo Web em espera :

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

3. Após alguns minutos, acesse o ponto de extremidade do Azure Front Door no portal do Azure e verifique se a troca de slots foi bem-sucedida.

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

Evitar interrupções e problemas de continuidade usando implantações de várias regiões

Você pode evitar possíveis interrupções ou problemas de continuidade entre regiões removendo temporariamente um site que está passando pela troca de slots de seu grupo de origem Azure Front Door. Essa ação ajuda a impedir que os clientes vejam versões diferentes do seu aplicativo ao mesmo tempo. Também é útil quando você está fazendo alterações significativas em seus aplicativos. A remoção temporária faz com que todo o tráfego redirecione para a outra origem.

1. No portal Azure, vá para a instância Azure Front Door.

2. No menu à esquerda, selecione Configurações>Grupos de origem.

3. Na lista de grupos de origem, selecione o grupo de origem que contém o slot que você deseja remover temporariamente.

4. No painel Atualizar grupo de origem , localize o espaço a ser removido na lista Nome do Host de Origem.

5. Selecione Mais ações (...) >Exclua e selecione Atualizar.

   Captura de tela que mostra como remover temporariamente um slot de origem do Azure Front Door.

   Pode levar vários minutos para aplicar a alteração.

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

7. Na parte superior, selecione + Adicionar uma origem para ler o slot de origem de volta ao grupo de origem.

   

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

Se você preferir não excluir e readicionar origens, poderá criar grupos de origem adicionais para a sua instância do Azure Front Door. Em seguida, você pode associar a rota ao grupo de origem que aponta para a origem pretendida.

Por exemplo, você pode criar dois grupos de origem extra, um para sua região primária (ativa) e outro para sua região em espera (passiva). Se sua região primária estiver passando por uma alteração, associe a rota à sua região em espera. Se sua região em espera estiver passando por uma alteração, associe a rota à sua região primária. Quando todas as alterações forem concluídas, você poderá associar a rota ao 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 por vez.

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

• O Main-Origin grupo contém os aplicativos Web primários e em espera, cada um em suas respectivas regiões.
• O Primary-Origin grupo contém apenas o aplicativo Web primário na região ativa.
• O Standby-Origin grupo contém apenas o aplicativo web em espera na região passiva.

Suponha que o aplicativo Web primário esteja passando por uma alteração. Antes do início das alterações, a associação de rota do Main-Origin grupo é alterada para o Secondary-Origin grupo. Essa ação garante que todo o tráfego seja direcionado para o aplicativo Web de espera em sua respectiva região, enquanto o aplicativo Web primário na mesma região está passando por uma alteração.

Siga estas etapas para alterar a associação de rota de um grupo de origem:

1. No portal Azure, vá para a instância Azure Front Door.

2. No menu à esquerda, selecione Configurações>Grupos de origem.

3. Na lista de grupos de origem, localize um grupo de origem que mostra o indicador não associado na coluna Rotas .

4. Selecione Mais ações (...) >Associar ponto de extremidade e rota.

   

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

   

Restringir o acesso ao site de ferramentas avançadas

Com o serviço Azure App, o site de ferramentas avançadas/SCM é usado para gerenciar seus aplicativos e fazer a implantação do código-fonte do aplicativo. Considere bloquear o site de ferramentas avançadas/SCM, pois esse site provavelmente não precisa ser acessado por meio do Front Door. Por exemplo, você pode configurar restrições de acesso que só permitem realizar seus testes e habilitar a implantação contínua da sua ferramenta preferida. Caso esteja usando slots de implantação, especificamente para slots de produção, você poderá negar quase todo o acesso ao site do SCM, pois o teste e a validação serão feitos com seus slots de preparo.

Conteúdo relacionado

• Implantar um aplicativo Web altamente disponível de várias regiões
• Examinar a arquitetura de linha de base para um aplicativo Web com redundância de zona altamente disponível