Partilhar via

Realoque seu aplicativo de função para outra região do Azure

  • Artigo

Este artigo descreve como mover um aplicativo de função hospedado no Azure Functions para outra região do Azure.

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

  • Aproveite uma nova região do Azure.
  • Implante 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 de empresas
  • Atenda aos requisitos de planejamento de capacidade.

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

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

Pré-requisitos

  • Certifique-se de que a região de destino dá suporte ao Azure Functions e a qualquer serviço relacionado cujos recursos você deseja mover.
  • Certifique-se de que tem privilégios para criar os recursos necessários na nova região.

Preparação

Identifique todos os recursos do aplicativo de função 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 da aplicação de funções

Os nomes de aplicativos de função devem ser globalmente exclusivos em todos os aplicativos do Azure. Isso significa que seu novo aplicativo de função não pode ter o mesmo nome e URL que o original. Isso é até mesmo verdadeiro ao usar um DNS personalizado, porque o subjacente <APP_NAME>.azurewebsites.net 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ção. Esses clientes precisam usar a nova URL ao fazer solicitações.

Código fonte

Idealmente, você mantém seu código-fonte em um repositório de código de algum tipo, ou em um repositório de contêiner se estiver sendo executado 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ção. Se, por algum motivo, você não tiver mais o código-fonte, poderá baixar o pacote atualmente em execução do aplicativo de função 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 Functions requer uma conta de Armazenamento do Azure. Para obter mais informações, consulte Requisitos da conta de armazenamento. Para obter o melhor desempenho, seu aplicativo de função 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 teclas de acesso de função e o estado de quaisquer gatilhos (como gatilhos de temporizador) é redefinido.

Armazenamento local persistente

As execuções de funções destinam-se a ser sem monitoração de estado. No entanto, não impedimos que você grave dados no sistema de arquivos local. É possível armazenar dados gerados e usados pelo seu aplicativo na %HOME%\site unidade virtual, mas esses dados não devem estar relacionados ao estado. Se o seu cenário exigir que você mantenha o estado entre as execuções de função, considere usar Durable Functions.

Se o seu aplicativo persistir dados no caminho de armazenamento compartilhado do aplicativo, certifique-se de planejar como você gerenciará esse estado durante uma movimentação de recursos. Lembre-se de que, para aplicativos de plano Dedicado (Serviço de Aplicativo), o compartilhamento faz parte do site. Para os planos Consumo e Premium, o compartilhamento é, por padrão, um compartilhamento do Azure Files na conta de armazenamento padrão. Os aplicativos executados no Linux 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 outros recursos usando um SDK de serviço ou gatilhos e associações. Qualquer serviço conectado pode ser afetado negativamente quando o aplicativo é movido para uma nova região. Se a latência ou o longo forem problemas, considere mover qualquer serviço conectado para a nova região também. Para saber como mover esses recursos entre regiões, consulte a documentação dos respetivos serviços. Ao mover um aplicativo com serviços conectados, convém considerar uma estratégia de recuperação de desastres entre regiões e continuidade de negócios durante a mudança.

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 existentes e cadeias de conexão do portal do Azure. Expanda Configurações>Variáveis de ambiente, selecione Edição avançada em Configurações do aplicativo ou Cadeias de caracteres de conexões e salve a saída JSON que contém as configurações ou conexões existentes. Você precisa recriar essas configurações na nova região, mas é provável que os próprios valores sejam alterados como resultado de alterações de região subsequentes nos serviços conectados.

  • As referências existentes do Cofre da Chave não podem ser exportadas através de um limite geográfico do Azure. Você deve recriar todas as referências necessárias na nova região.

  • A configuração do seu aplicativo pode ser gerenciada pela Configuração de Aplicativo do Azure ou por alguma outra dependência de banco de dados central (downstream). Analise qualquer App Configuration Store ou lojas semelhantes para ver as configurações específicas do ambiente e da região que podem exigir modificações.

Domínios personalizados

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

Redes virtuais

O Azure Functions permite-lhe integrar as suas aplicações com recursos de rede virtual e até executá-las numa rede virtual. Para obter mais informações, consulte Opções de rede do Azure Functions. Ao mudar para uma nova região, você deve primeiro mover ou recriar todos os recursos de rede virtual e sub-rede necessários antes de implantar seu aplicativo. Isso inclui mover ou recriar quaisquer pontos de extremidade privados e pontos de extremidade de serviço.

Identidades

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

  • As 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 em seus serviços realocados que as identidades originais que elas estão substituindo, incluindo associações de grupo.

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. Os certificados que podem ser exportados também podem ser importados para o aplicativo ou para o Cofre da Chave na nova região. Este processo de exportação e importação equivale a uma deslocação entre regiões.

Há diferentes tipos de certificados que precisam ser levados em consideração ao planejar sua realocação de 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 Cofre da Chave e, em seguida, importados para o Cofre da Chave na nova região.
Chave privada (autogerida) Sim Os certificados adquiridos fora do Azure podem ser exportados do Serviço de Aplicativo e, em seguida, importados para o novo aplicativo ou para o Cofre da Chave na nova região.
Chave pública Não Seu aplicativo pode ter certificados com apenas uma 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 para o aplicativo na nova região.

Access keys

O Functions usa teclas de acesso para dificultar o acesso a pontos de extremidade HTTP em seu aplicativo de função. 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 usar 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.

Inatividade

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

Funções Duráveis

A extensão Durable Functions permite definir orquestrações, onde o estado é mantido em suas execuções de função usando entidades com monitoração de estado. Idealmente, você deve permitir que as orquestrações em execução sejam concluídas antes de migrar seu aplicativo Durable Functions, especialmente quando 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 desastres e distribuição geográfica.

Recolocar

Recriar seu aplicativo de função em uma nova região exige que você primeiro recrie a infraestrutura do Azure de um plano do Serviço de Aplicativo, instância do aplicativo de função e 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 padrão do Armazenamento do Azure e a instância do Application Insights.

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

Recrie sua infraestrutura do Azure

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

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

Rever os recursos configurados

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

Reimplantar seu código-fonte

Agora que você tem a infraestrutura instalada, pode reempacotar e reimplantar o código-fonte no aplicativo de função. 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 a partir desse repositório.

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

Considerações sobre recolocaçã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 funcional 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.

Limpeza

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

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