Compartilhar via

Realocar seu aplicativo de funções para outra região do Azure

  • Artigo

Este artigo descreve como mover um aplicativo de funções hospedado pelo Azure Functions 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
  • Atender aos requisitos de planejamento de capacidade.

Os recursos do Azure que hospedam seu aplicativo de funções são específicos da região e não podem ser movidos para outras regiões. Em vez disso, você deve criar uma cópia dos recursos existentes do aplicativo de funções na região de destino e reimplantar o código das funções para o novo aplicativo.

Você pode mover esses mesmos recursos para outro grupo de recursos ou assinatura, desde que eles permaneçam na mesma região. Para obter mais informações, consulte Mover recursos de Serviço de Aplicativo para um novo grupo de recursos ou assinatura.

Pré-requisitos

  • Verifique se a região de destino dá suporte para o Azure Functions e os serviços relacionados cujos recursos você quer mover.
  • Verifique se você tem privilégios para criar os recursos necessários na nova região.

Preparar-se

Identifique todos os recursos do aplicativo de funções usados na região de origem, o que potencialmente inclui:

Ao se preparar para mover seu aplicativo para uma nova região, há algumas partes da arquitetura que exigem consideração e planejamento especiais.

Nome do aplicativo de funções

Os nomes dos aplicativos de funções devem ser exclusivos globalmente em todos os aplicativos do Azure. Isso significa que seu novo aplicativo de funções não pode ter o mesmo nome e URL que o original. Isso também se aplica ao usar um DNS personalizado, pois o <APP_NAME>.azurewebsites.net subjacente ainda deve ser exclusivo. Talvez seja necessário atualizar todos os clientes que se conectam a pontos de extremidade HTTP em seu aplicativo de funções. Esses clientes precisam usar a nova URL ao fazer solicitações.

Código-fonte

O ideal é manter o código-fonte em algum repositório de código ou em um repositório de contêiner, se estiver executando em um contêiner Linux. Se você estiver usando a implantação contínua, planeje alternar a conexão de implantação de repositório ou contêiner para o novo endereço do aplicativo de funções. Se, por algum motivo, você não tiver mais o código-fonte, é possível baixar o pacote atualmente em execução do aplicativo de funções original. Recomendamos armazenar seus arquivos de origem em um repositório de código e usar a implantação contínua para atualizações.

Conta de armazenamento padrão

O host do Functions requer uma conta de Armazenamento do Azure. Para saber mais, veja Requisitos da conta de armazenamento. Para obter o melhor desempenho, o aplicativo de funções deve usar uma conta de armazenamento na mesma região. Quando você cria um novo aplicativo com uma nova conta de armazenamento em sua nova região, seu aplicativo recebe um novo conjunto de chaves de acesso às funções, e o estado de qualquer gatilho (como gatilhos de temporizador) é redefinido.

Armazenamento local persistente

As execuções de funções são projetadas para serem sem estado. No entanto, não impedimos que você grave dados no sistema de arquivos local. É possível armazenar dados gerados e usados pelo aplicativo no disco virtual %HOME%\site, mas esses dados não devem estar relacionados ao estado. Se o seu cenário exige a manutenção de estado entre as execuções de funções, considere o uso de Durable Functions.

Se o aplicativo persistir dados no caminho de armazenamento compartilhado do aplicativo, planeje como você gerenciará esse estado durante uma movimentação de recursos. Tenha em mente que, para aplicativos do plano Dedicado (Serviço de Aplicativo), o compartilhamento faz parte do site. Para os planos Premium e Consumo, o compartilhamento é, por padrão, um compartilhamento dos Arquivos do Azure na conta de armazenamento padrão. Os aplicativos em execução podem estar usando um compartilhamento montado explicitamente para armazenamento persistente.

Serviços conectados

Suas funções podem se conectar aos Serviços do Azure e a outros recursos usando um SDK de serviço ou gatilhos e associações. Qualquer serviço conectado pode ser afetado negativamente quando o aplicativo se move para uma nova região. Se a latência ou o desempenho forem problemas, considere mover qualquer serviço conectado para a nova região também. Para saber como mover esses recursos entre regiões, confira a documentação dos respectivos serviços. Ao mover um aplicativo com serviços conectados, talvez seja interessante considerar uma estratégia de recuperação de desastre e continuidade de negócios entre regiões durante a migração.

As alterações nos serviços conectados podem exigir que você atualize os valores armazenados nas configurações do aplicativo, que são usados para se conectar a esses serviços.

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.

Domínios personalizados

Se o seu aplicativo de funções usa um domínio personalizado, vincule-o de forma antecipada ao aplicativo de destino. Verifique e habilite o domínio no aplicativo de destino. Após a migração, você deve remapear o nome de domínio.

Redes virtuais

O Azure Functions permite que você integre seus aplicativos a recursos de rede virtual e até mesmo execute-os em uma rede virtual. Para obter mais informações, consulte Opções de rede do Azure Functions. Ao migrar para uma nova região, primeiro você deve mover ou recriar todos os recursos de rede virtual e sub-rede necessários antes de implantar seu aplicativo. Isso inclui mover ou recriar pontos de extremidade privados e pontos de extremidade de serviço.

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.

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.

Chaves de acesso

O Functions usa chaves de acesso para tornar mais difícil acessar pontos de extremidade HTTP em seu aplicativo de funções. Essas chaves são mantidas criptografadas na conta de armazenamento padrão. Quando você cria um novo aplicativo na nova região, um novo conjunto de chaves é criado. Você deve atualizar todos os clientes existentes que usam chaves de acesso para utilizar as novas chaves na nova região. Embora você deva usar as novas chaves, é possível recriar as chaves antigas no novo aplicativo. Para obter mais informações, consulte Trabalhar com chaves de acesso no Azure Functions.

Tempo de inatividade

Se o tempo de inatividade mínimo for um requisito, considere executar seu aplicativo de funções em ambas as regiões conforme recomendado para implementar uma arquitetura de recuperação de desastre. A arquitetura específica que você implementa depende dos tipos de gatilho em seu aplicativo de funções. Para obter mais informações, confira Confiabilidade do Azure Functions.

Funções duráveis

A extensão do Durable Functions permite que você defina orquestrações, onde o estado é mantido nas execuções das funções usando entidades com estado. Idealmente, você deve permitir que as orquestrações em execução sejam concluídas antes de migrar seu aplicativo Durable Functions, especialmente se planeja mudar para uma nova conta de armazenamento na nova região. Ao migrar seus aplicativos Durable Functions, considere usar uma dessas estratégias de recuperação de desastre e distribuição geográfica.

Realocar

Recriar seu aplicativo de funções em uma nova região exige que você primeiro recrie a infraestrutura do Azure, como o plano do Serviço de Aplicativo, a instância do aplicativo de funções e os recursos relacionados, como redes virtuais, identidades e slots. Você também deve se reconectar ou, na nova região, recriar os recursos do Azure exigidos pelo aplicativo. Esses recursos podem incluir a conta de Armazenamento do Azure padrão e a instância do Application Insights.

Em seguida, você pode empacotar e reimplantar o código-fonte do aplicativo ou o contêiner para o aplicativo de funções em execução na nova região.

Recriar sua infraestrutura do Azure

Há várias maneiras de criar um aplicativo de funções e os recursos relacionados no Azure na região de destino:

  • Modelos de implantação: se você implantou originalmente seu aplicativo de funções usando arquivos de infraestrutura como código (IaC) (Bicep, modelos do ARM ou Terraform), você pode atualizar essas implantações anteriores para direcionar a nova região e usá-las para recriar os recursos na nova região. Se você não tiver mais esses arquivos de implantação, sempre poderá baixar um modelo do ARM para o grupo de recursos existente do portal do Azure.
  • Scripts da CLI do Azure/PowerShell: se você implantou originalmente seu aplicativo de funções usando scripts da CLI do Azure ou do Azure PowerShell, você pode atualizar esses scripts para direcioná-los à nova região e executá-los novamente. Se você não tiver mais esses scripts, também poderá baixar um modelo do ARM para o grupo de recursos existente do portal do Azure.
  • Portal do Azure: se você criou seu aplicativo de funções originalmente no portal ou não se sente confortável usando scripts ou arquivos IaC, você pode simplesmente recriar tudo diretamente no portal. Use o mesmo plano de hospedagem, runtime de linguagem e versão de linguagem do seu aplicativo original.

Revisar recursos configurados

Revise e configure os recursos identificados na etapa Preparar acima na região de destino se eles não foram configurados durante a implantação. Se você estiver usando implantação contínua com autenticação de identidade gerenciada, verifique se as identidades necessárias e os mapeamentos de funções existem no novo aplicativo de funções.

Reimplantar seu código-fonte

Agora que você tem a infraestrutura configurada, pode recriar pacote e reimplantar o código-fonte no aplicativo de funções. Este é um bom momento para mover seu código-fonte ou imagem de contêiner para um repositório e habilitar a implantação contínua desse repositório.

Você também pode usar qualquer outro método de publicação compatível com o Functions. A maioria das publicações baseadas em ferramentas exige que você habilite a autenticação básica no ponto de extremidade scm, oque não é recomendado para aplicativos de produção.

Considerações sobre a realocação

  • Lembre-se de verificar sua configuração e testar suas funções na região de destino.
  • Se você tiver um domínio personalizado configurado, remapeie o nome de domínio.
  • Para um aplicativo de funções em execução em um plano Dedicado (Serviço de Aplicativo), revise também o Plano de Migração do Serviço de Aplicativo quando o plano for compartilhado com um ou mais aplicativos Web.

Limpar

Depois que a movimentação for concluída, exclua o aplicativo de funções e o plano de hospedagem da região de origem. Você paga por aplicativos de funções Premium ou planos dedicados, mesmo quando o aplicativo em si não está em execução. Se você recriou outros serviços na nova região, também deverá excluir os serviços mais antigos depois de ter certeza de que não são mais necessários.

Consulte o Centro de Arquitetura do Azure para exemplos de aplicativos de funções em execução em várias regiões como parte de arquiteturas de soluções mais avançadas e com redundância geográfica.