Realocar os Serviços de Aplicativos Azure para outra região

Este artigo descreve como mover recursos do Serviço de Aplicativo para outra região do Azure.

Há vários motivos pelos quais talvez você queira mover seus recursos existentes do Azure de uma região para outra. Talvez você queira:

• Aproveitar uma nova região do Azure.
• Implantar recursos ou serviços disponíveis apenas em regiões específicas.
• Atender aos requisitos internos de política e governança.
• Alinhar-se com fusões e aquisições da empresa
• Atenda aos requisitos de planejamento de capacidade.

Os recursos do Serviço de Aplicativo são específicos de uma região e não podem ser movidos para outra. Você deve criar uma cópia dos seus recursos do Serviço de Aplicativos existentes na região de destino e, em seguida, realocar seu conteúdo para o novo aplicativo. Se o seu aplicativo de origem usar um domínio personalizado, você pode migrá-lo para o novo aplicativo na região de destino após a conclusão da realocação.

Para facilitar a cópia do aplicativo, você pode fazer backup e restaurar aplicativos individuais do Serviço de Aplicativos em um plano de Serviço de Aplicativos em outra região.

Pré-requisitos

• Verifique se o aplicativo do Serviço de Aplicativo está na região do Azure da qual você quer mover.
• Verifique se a região de destino dá suporte para o Serviço de Aplicativo e os serviços relacionados cujos recursos você quer mover.
• Valide se existe permissão suficiente para implantar recursos do Serviço de Aplicativo na assinatura e região de destino.
• Verifique se alguma política do Azure está atribuída com uma restrição de região.
• Considere os custos operacionais, pois os preços dos recursos de computação podem variar de região para região. Para fazer uma estimativa dos custos, consulte a Calculadora de preços.

Preparar-se

Identifique todos os recursos do Serviço de Aplicativo que você está usando. Por exemplo:

• Aplicativos do Serviço de Aplicativo
• Planos do Serviço de Aplicativo
• Slots de implantação
• Domínios personalizados comprados no Azure
• Certificados TLS/SSL
• Integração da Rede Virtual do Azure
• Conexões Híbridas.
• identidades gerenciadas
• Configurações de backup

Determinados recursos, como certificados importados ou conexões híbridas, contêm integração com outros serviços do Azure. Para saber como mover esses recursos entre regiões, confira a documentação dos respectivos serviços.

Plano

Esta seção é uma lista de verificação de planejamento nas seguintes áreas:

• Dependências de estado, armazenamento e downstream
• Certificados
• Configuração
• Conectividade VNet / Nomes Personalizados / DNS
• Identidades
• Pontos de Extremidade de Serviço

Dependências de estado, armazenamento e downstream

• Determine se o aplicativo do Serviço de Aplicativo está com estado ou sem estado. Embora recomendemos que os aplicativos do Serviço de Aplicativos sejam sem estado e os arquivos no %HOME%\site drive devam ser apenas aqueles necessários para executar o aplicativo implantado com quaisquer arquivos temporários, ainda é possível armazenar o estado de execução do aplicativo no %HOME%\site drive virtual. Se o aplicativo gravar o estado no caminho de armazenamento compartilhado do aplicativo, planeje como você gerenciará esse estado durante uma movimentação de recursos.

  Dica

  Você pode usar o Kudu para, juntamente com o acesso ao portal, fornecer uma API de acesso a arquivos (VFS (Virtual File System)) que pode ler/gravar arquivos no diretório %HOME%\site. Para obter mais informações, consulte Wiki do Kudu.

• Verifique o cache interno e o estado no código do aplicativo.

• Desabilite a configuração de afinidade de sessão. Sempre que possível, recomendamos que você desabilite a configuração de afinidade de sessão. Desabilitar a afinidade de sessão melhora o balanceamento de carga para uma expansão horizontal. Qualquer estado interno pode afetar o planejamento de redução de uma carga de trabalho, especialmente se o tempo de inatividade zero for um requisito. Sempre que possível, pode ser benéfico refatorar qualquer estado de aplicativo para tornar o aplicativo sem estado em preparação para a movimentação.

• Analisar cadeias de conexão de banco de dados. Cadeias de conexão de banco de dados podem ser encontradas nas Configurações do Aplicativo. No entanto, eles também podem ser codificados ou gerenciados em arquivos de configuração que são enviados com o aplicativo. Analise e planeje a migração/replicação de dados como parte do planejamento de nível superior para mover a carga de trabalho. Para aplicativos verbosos ou críticos de latência, não é eficiente para o aplicativo na região de destino acessar fontes de dados na região de origem.

• Analisar o cache externo (por exemplo, Redis). Os caches de aplicativos devem ser implantados o mais próximo possível do aplicativo. Analise como os caches são preenchidos, políticas de expiração/remoção e qualquer impacto que um cache frio possa ter sobre os primeiros usuários a acessar a carga de trabalho após o corte.

• Analisar e planejar dependências de API (ou aplicativo) comunicação entre regiões é significativamente menos performante se o aplicativo na região de destino retornar às dependências que ainda estão na região de origem. Recomendamos que você realoque todas as dependências downstream como parte da realocação da carga de trabalho. No entanto, os recursos *locais* são a exceção, em particular os recursos geograficamente mais próximos da região de destino (como pode ser o caso de cenários de repatriação).

  O Registro de Contêiner do Azure pode ser uma dependência downstream (runtime) do Serviço de Aplicativo configurada para execução em imagens de contêiner personalizadas. Faz mais sentido que o Registro de Contêiner esteja na mesma região que o próprio Aplicativo. Considere carregar as imagens necessárias em um novo ACR na região de obtenção de destino. Caso contrário, considere usar o recurso de replicação geográfica se você planeja manter as imagens na região de origem.

• Analisar e planejar serviços regionais. Os dados do Application Insights e do Log Analytics são serviços regionais. Considere a criação de novos Application Insights e armazenamento do Log Analytics na região de destino. Para o App Insights, um novo recurso também afeta a cadeia de conexão que deve ser atualizada como parte da alteração na Configuração do Aplicativo.

Certificados

Os recursos de Certificado do Serviço de Aplicativo podem ser movidos para um novo grupo de recursos ou assinatura, mas não entre regiões. Certificados que podem ser exportados também podem ser importados para o aplicativo ou para o Key Vault na nova região. Esse processo de exportação e importação é equivalente a uma movimentação entre regiões.

Há tipos diferentes de certificados que precisam ser levados em consideração ao planejar a realocação do serviço:

Tipo de certificado	Exportável	Comentários
Serviço de Aplicativo gerenciado	Não	Recrie esses certificados na nova região.
Azure Key Vault gerenciado	Sim	Esses certificados podem ser exportados do Key Vault e, em seguida, importados para o Key Vault na nova região.
Chave privada (autogerenciada)	Sim	Os certificados adquiridos fora do Azure podem ser exportados do Serviço de Aplicativo e importados para o novo aplicativo ou para o Key Vault na nova região.
Chave pública	Não	Seu aplicativo pode ter certificados apenas com chave pública e sem segredo, que são usados para acessar outros pontos de extremidade protegidos. Obtenha os arquivos de certificado de chave pública necessários e importe-os no aplicativo na nova região.

Alguns outros pontos a serem considerados:

• Endereços Atribuídos ao Aplicativo, em que uma conexão SSL do aplicativo do Serviço de Aplicativo está associada a um IP designado por um aplicativo específico, podem ser usados para permitir chamadas de listagem de redes de terceiros para o Serviço de Aplicativo. Por exemplo, um administrador de rede/TI pode querer bloquear chamadas de saída de uma rede local ou VNet para usar um endereço estático e conhecido. Dessa forma, se o recurso Endereço Atribuído do Aplicativo estiver em uso, as regras de firewall upstream - como internas, externas ou terceiros - para os chamadores no aplicativo deverão ser verificadas e informadas sobre o novo endereço. As regras de firewall podem ser internas, externas ou de terceiros, como parceiros ou clientes conhecidos.

• Considere qualquer NVA (Solução de Virtualização de Rede) upstream ou Proxy Reverso. A configuração NVA pode precisar ser alterada se você estiver reescrevendo o cabeçalho do host ou e/ou terminação de SSL.

Observação

O Ambiente do Serviço de Aplicativo é a única oferta do Serviço de Aplicativo que permite chamadas downstream para dependências de aplicativos downstream por SSL, em que o SSL se baseia em autoassinado/PKI com certificados de AC raiz não padrão. O serviço multilocatário não fornece acesso para os clientes carregarem no repositório de certificados confiável.

O Ambiente do Serviço de Aplicativo hoje não permite a compra de certificado SSL, apenas certificados Bring Your Own. O IP-SSL não é possível (e não faz sentido), mas o SNI é. O Ambiente interno do Serviço de Aplicativo não seria associado a um domínio público e, portanto, os certificados SSL usados devem ser fornecidos pelo cliente e, portanto, transportáveis, por exemplo, certificados para uso interno gerados usando PKI. O Ambiente do Serviço de Aplicativo v3 no modo externo compartilha os mesmos recursos que o Serviço de Aplicativo multilocatário regular.

Configuração

• Você pode capturar um instantâneo das configurações de aplicativo e cadeias de conexão existentes no portal do Azure. Expanda Configurações>Variáveis de ambiente, selecione Edição avançada em Configurações de aplicativo ou Cadeias de conexão e salve o arquivo JSON que contém as configurações ou conexões existentes. Você precisa recriar essas configurações na nova região, mas os próprios valores provavelmente mudarão devido às alterações subsequentes de região nos serviços conectados.

• As referências do Key Vault existentes não podem ser exportadas em um limite geográfico do Azure. Você deve recriar as referências necessárias na nova região.

• Sua configuração de aplicativo pode ser gerenciada pela Configuração de Aplicativos do Azure ou por alguma outra dependência de banco de dados central (downstream). Revise qualquer repositório das Configuração de Aplicativos ou repositórios semelhantes para identificar configurações específicas de ambiente e região que possam exigir modificações.

• Verifique se qualquer configuração de arquivo de disco, que pode ou não ser substituída pelas configurações do aplicativo.

Conectividade VNet / Nomes Personalizados / DNS

• O Ambiente do Serviço de Aplicativo é um serviço de locatário único injetado em VNet. A rede do Ambiente do Serviço de Aplicativo é diferente do Serviço de Aplicativo multilocatário, que requer um ou ambos os “pontos de extremidade privados” ou “a integração” de VNet regional. Outras opções que podem estar em jogo incluem a integração de VNet baseada em VPN P2S herdada e conexões híbridas (um serviço de Retransmissão do Azure).

  Observação

  A rede ASEv3 é simplificada – o tráfego do Gerenciamento do Azure e os Ambientes do Serviço de Aplicativo possuem dependências downstream não são visíveis para a Rede Virtual do cliente, simplificando consideravelmente a configuração necessária onde o cliente está usando um túnel de força para todo o tráfego ou enviando um subconjunto de tráfego de saída, por meio de uma Solução de Virtualização/Firewall de Rede.

  As Conexões Híbridas (Retransmissão do Azure) são regionais. Se as Conexões Híbridas forem usadas e, embora um Namespace de Retransmissão do Azure possa ser movido para outra região, seria mais simples reimplantar a Conexão Híbrida (garantir que a conexão híbrida esteja configurada na nova região na implantação dos recursos de destino) e vinculá-la novamente ao Gerenciador de Conexões Híbridas. O local do Gerenciador de Conexões Híbridas deve ser cuidadosamente considerado.

• Siga a estratégia para uma região de espera passiva. Verifique se a rede e a conectividade principais, rede hub, controladores de domínio, DNS, VPN ou Express Route, etc., estão presentes e testados antes da realocação de recursos.

• Validar quaisquer ACLs de rede upstream ou downstream e de configuração. Por exemplo, considere um serviço downstream externo que permite listas somente do tráfego do aplicativo. Uma realocação para um novo Plano de Aplicativo para um Serviço de Aplicativo multilocatário também seria uma alteração nos endereços IP de saída.

• Na maioria dos casos, é melhor garantir que as VNets da região de destino tenham espaço de endereço exclusivo. Um espaço de endereço exclusivo facilita a conectividade de VNet se for necessário, por exemplo, replicar dados. Portanto, nesses cenários há um requisito implícito para alterar:

  • DNS privado
  • Qualquer configuração codificada ou externa que faça referência a recursos por endereço IP (sem um nome de host)
  • ACLs de rede, incluindo grupos de segurança de rede e configuração de firewall (considere o impacto para quaisquer NVAs locais aqui também)
  • Todas as regras de roteamento, tabelas de rotas definidas pelo usuário

  Além disso, verifique a configuração, incluindo intervalos de IP/marcas de serviço específicos da região, se os recursos de implantação de DevOps existentes forem encaminhados.

• Menos alterações são necessárias para o DNS privado implantado pelo cliente configurado para encaminhar para o Azure para domínios do Azure e Zonas Privadas do DNS do Azure. No entanto, como os pontos de extremidade privados são baseados em um FQDN de recurso e isso geralmente também é o nome do recurso (que pode ser esperado para ser diferente na região de destino), lembre-se de verificar a configuração para garantir que os FQDNs referenciados na configuração sejam atualizados adequadamente.

• Recriar pontos de extremidade privados, se usados, na região de destino. O mesmo se aplica à integração de VNet regional.

• O DNS para Ambiente do Serviço de Aplicativo normalmente é gerenciado por meio da solução DNS personalizada privada dos clientes (há uma substituição de configurações manuais disponíveis em um básico por aplicativo). O Ambiente do Serviço de Aplicativo fornece um balanceador de carga para entrada/saída, enquanto o próprio Serviço de Aplicativo filtra os cabeçalhos do Host. Portanto, vários nomes personalizados podem ser apontados para o mesmo ponto de extremidade de entrada do Ambiente do Serviço de Aplicativo. O Ambiente do Serviço de Aplicativo não requer validação de domínio.

  Observação

  O ponto de extremidade do Kudu para o Ambiente do Serviço de Aplicativo v3 só está disponível em {resourcename}.scm.{asename}.appserviceenvironment.net. Para obter mais informações sobre o Ambiente do Serviço de Aplicativo v3 DNS e Rede, consulte sistema de rede do Ambiente do Serviço de Aplicativo.

  Para o Ambiente de Serviço de Aplicativos, o cliente é responsável pelo roteamento e, portanto, pelos recursos utilizados na mudança. Onde quer que o acesso esteja habilitado para o Ambiente do Serviço de Aplicativo externamente – normalmente por meio de uma NVA da Camada 7 ou proxy reverso – o Gerenciador de Tráfego ou o Azure Front Door/Outro Serviço de Balanceamento de Carga Global L7 pode ser usado.

• Para a versão multilocatário pública do serviço, um nome padrão {resourcename}.azurewebsites.net é provisionado para os pontos de extremidade do plano de dados, juntamente com um nome padrão para o ponto de extremidade do Kudu (SCM). Como o serviço fornece um ponto de extremidade público por padrão, a associação deve ser verificada para provar a propriedade do domínio. No entanto, depois que a associação estiver em vigor, a nova verificação não será necessária nem será necessária para que os registros DNS públicos apontem para o ponto de extremidade do Serviço de Aplicativo.

• Se você usar um domínio personalizado, associe-o preventivamente ao aplicativo de destino. Verifique e habilite o domínio no aplicativo de destino.

Identidades

• Você precisa recriar todas as identidades gerenciadas atribuídas pelo sistema junto com seu aplicativo na nova região de destino. Normalmente, um aplicativo do Microsoft Entra ID criado automaticamente, usado pelo EasyAuth, tem como padrão o nome do recurso do aplicativo.

• Identidades gerenciadas atribuídas pelo usuário também não podem ser movidas entre regiões. Para manter as identidades gerenciadas atribuídas pelo usuário no mesmo grupo de recursos com seu aplicativo, você deve recriá-las na nova região. Para obter mais informações, consulte Realocar identidades gerenciadas para recursos do Azure para outra região.

• Conceda às identidades gerenciadas as mesmas permissões nos serviços relocados que as identidades originais que estão substituindo, incluindo as associações a grupos.

• Plano para realocar o IDP (Provedor de Identidade) para a região de destino. Embora a ID do Microsoft Entra seja um serviço global, algumas soluções dependem de um IDP local (ou downstream local).

• Atualizar todos os recursos para o Serviço de Aplicativo que possam depender das credenciais de FTP do Kudu.

Pontos de extremidade de serviço

Os pontos de extremidade de serviço de rede virtual do Azure Cosmos DB restringem o acesso a uma rede virtual especificada. Os pontos de extremidade também podem restringir o acesso a uma lista de intervalos de endereços IPv4 (protocolo da Internet versão 4). Qualquer usuário que se conecte aos Hubs de Eventos de fora dessas fontes tem acesso negado. Se os pontos de extremidade de serviço foram configurados na região de origem do recurso dos Hubs de Eventos, o mesmo precisaria ser feito no destino um.

Para uma recriação bem-sucedida do Serviço de Aplicativo do Azure para a região de destino, a VNet e a Sub-rede devem ser criadas com antecedência. Caso a movimentação desses dois recursos esteja sendo realizada com a ferramenta do Azure Resource Mover, os pontos de extremidade de serviço não serão configurados automaticamente. Portanto, eles precisam ser configurados manualmente, o que pode ser feito por meio do portal do Azure, da CLI do Azure ou do Azure PowerShell.

Realocar

Para realocar recursos do Serviço de Aplicativo, você pode usar o portal do Azure ou a IaC (Infraestrutura como Código).

Realocar usando o portal do Azure

A maior vantagem de usar o portal do Azure para realocar é sua simplicidade. O aplicativo, o plano e o conteúdo, bem como muitas configurações são clonadas no novo plano e recurso do Serviço de Aplicativo.

Tenha em mente que, para camadas de Ambiente do Serviço de Aplicativo (Isolado), você precisa reimplantar todo o Ambiente do Serviço de Aplicativo em outra região primeiro e, em seguida, você pode começar a reimplantar os planos individuais no novo Ambiente do Serviço de Aplicativo na nova região.

Para realocar os recursos do Serviço de Aplicativo para uma nova região usando o portal do Azure:

1. Crie um backup do aplicativo de origem.
2. Crie um aplicativo em um novo plano do Serviço de Aplicativo na região de destino.
3. Restaure o backup no aplicativo de destino
4. Se você usa um domínio personalizado, associe-o preventivamente ao aplicativo de destino com asuid. e habilite o domínio no aplicativo de destino.
5. Ajuste as demais configurações do aplicativo de destino para que sejam iguais às do aplicativo de origem e confira a configuração.
6. Quando tudo estiver pronto para o domínio personalizado apontar para o aplicativo de destino, remapeie o nome de domínio.

Realocar usando IaC

Use IaC quando existir um pipeline de CI/CD (integração contínua e entrega/implantação contínua) existente ou pode ser criado. Com um pipeline de CI/CD em vigor, o recurso do Serviço de Aplicativo pode ser criado na região de destino por meio de uma ação de implantação ou uma implantação zip do Kudu.

Os requisitos de SLA devem determinar quanto esforço adicional é necessário. Por exemplo: essa é uma reimplantação com tempo de inatividade limitado ou é uma mudança quase em tempo real necessária com tempo de inatividade mínimo ou sem tempo de inatividade?

A inclusão de serviços de borda de roteamento de tráfego globais externos, como o Gerenciador de Tráfego ou o Azure Front Door, ajuda a facilitar a substituição para usuários e aplicativos externos.

Dica

É possível usar o ATM (Gerenciador de Tráfego) ao fazer failover dos Serviços de Aplicativo por trás de pontos de extremidade privados. Embora os pontos de extremidade privados não sejam acessíveis por investigações do Gerenciador de Tráfego – se todos os pontos de extremidade forem degradados, o ATM permitirá o roteamento. Para obter mais informações, consulte Controlando o tráfego do Serviço de Aplicativo do Azure com o Gerenciador de Tráfego do Azure.

Validar

Depois que a realocação for concluída, teste e valide o Serviço de Aplicativo do Azure com as diretrizes recomendadas:

• Depois que o Serviço de Aplicativo do Azure for realocado para a região de destino, execute um teste de fumaça e integração. Você pode testar ou executar manualmente um teste por meio de um script. Verifique se todas as configurações e os recursos dependentes estão vinculados corretamente e se todos os dados configurados estão acessíveis.

• Valide todos os componentes e integração do Serviço de Aplicativo do Azure.

• Execute testes de integração na implantação da região de destino, incluindo todos os testes formais de regressão. O teste de integração deve se alinhar com os processos habituais de implantação e teste do Rhythm of Business aplicáveis à carga de trabalho.

• Em alguns cenários, particularmente em que a realocação inclui atualizações, alterações nos aplicativos ou recursos do Azure ou uma alteração no perfil de uso, use o teste de carga para validar que a nova carga de trabalho é adequada para a finalidade. O teste de carga também é uma oportunidade para validar as operações e a cobertura de monitoramento. Por exemplo, use o teste de carga para validar se a infraestrutura necessária e os logs de aplicativos estão sendo gerados corretamente. Os testes de carga devem ser medidos em relação às linhas de base de desempenho de carga de trabalho estabelecidas.

Dica

Uma realocação do Serviço de Aplicativo também é uma oportunidade para reavaliar o planejamento de Disponibilidade e Recuperação de Desastres. O Serviço de Aplicativo e o Ambiente do Serviço de Aplicativo (Ambiente do Serviço de Aplicativo v3) dão suporte a zonas de disponibilidade e é recomendável configurar com uma configuração de zona de disponibilidade. Tenha em mente os pré-requisitos para implantação, preços e limitações e fatore-os no planejamento de movimentação de recursos. Para obter mais informações sobre as zonas de disponibilidade e o Serviço de Aplicativo, consulte Confiabilidade no Serviço de Aplicativo do Azure.

Limpar

Exclua o aplicativo e o plano do Serviço de Aplicativo de origem. Há cobrança pelos planos do Serviço de Aplicativo que não são gratuitos, mesmo que não haja aplicativo em execução neles.

Próximas etapas

Clonagem de aplicativo do Serviço de Aplicativo do Azure usando o Azure PowerShell