Relocate Azure Container Apps para outra região

Este artigo descreve como realocar uma carga de trabalho Azure Container Apps para outra região Azure, recriando o ambiente gerido e as aplicações de contentores na região-alvo. O processo abrange a exportação da configuração da aplicação, a redistribuição de recursos, a validação da implementação e a limpeza de recursos na região de origem.

Importante

O Azure Container Apps não suporta migração regional no local. Recrias recursos na região-alvo – os recursos existentes não são movimentados. Este artigo aborda a realocação da configuração e infraestrutura das Aplicações Container. Não cobre a replicação de dados de aplicação, bases de dados ou outras dependências com estado.

Pré-requisitos

Antes de começar, verifique se cumpre os seguintes requisitos:

  • O Azure Container Apps está disponível na região de destino.
  • A região-alvo suporta as mesmas funcionalidades Container Apps, perfis de carga de trabalho e opções de rede que utiliza na região de origem.
  • Tem quotas suficientes na região-alvo para os recursos que planeia implementar.
  • Tem as seguintes permissões tanto na subscrição de origem como na de destino:
    • Proprietário ou Contribuinte no grupo de recursos.
    • Colaborador do Container Apps (recomendado). Esta função inclui permissões wildcard que concedem acesso a valores secretos das Aplicações Container. Para acesso mais restrito, veja Permissões para gerir segredos.
  • As imagens dos seus contentores estão num registo acessível a partir da região de destino (por exemplo, Azure Container Registry ou um registo externo suportado).
  • Recursos dependentes do Azure, como Key Vault, contas de armazenamento, bases de dados, redes virtuais e serviços de mensagens, já estão disponíveis na região-alvo ou têm um plano de reimplantação.

Tip

Se usar o Azure Container Registry (ACR), considere ativar a geo-replicação para disponibilizar imagens na região de destino sem ter de redistribuir o registo.

az acr replication create --registry <REGISTRY_NAME> --location <TARGET_REGION>

Compreender os requisitos de tempo de inatividade

O Azure Container Apps não suporta migração de regiões ao vivo. O tempo de inatividade é principalmente impulsionado pela propagação do DNS e pelas alterações no encaminhamento do tráfego durante o cutover. Para minimizar o impacto:

  1. Implemente e valide primeiro a aplicação do contentor na região-alvo.
  2. Reduzir os valores TTL do DNS antecipadamente (por exemplo, até 60 segundos) para que as alterações de roteamento se propaguem rapidamente.
  3. Redirecione o tráfego de produção para o novo endpoint apenas após a validação estar concluída.
  4. Manter a aplicação de contenedor de origem a funcionar até confirmar que a implementação do alvo está saudável.

Prepare

Para preparar a relocalização, exporte a configuração de origem e reveja todas as definições específicas da região.

Identificar dependências

Os seguintes recursos dependentes devem existir na região-alvo antes do corte:

  • Azure Key Vault
  • Contas de armazenamento
  • Bases de dados e serviços de mensagens (como Azure Service Bus, Azure Cosmos DB)
  • Redes virtuais, sub-redes e endpoints privados
  • Grupos de segurança de rede (NSGs) e rotas definidas pelo utilizador (UDRs)
  • Zonas DNS Privadas
  • Espaços de trabalho do Log Analytics
  • Componentes do Dapr (se forem utilizados)

Importante

Segredos, certificados, domínios personalizados e valores de configuração seguros não são preservados nos templates exportados. Deve recriar estes recursos manualmente na região-alvo a partir das suas fontes originais.

Plano para alterações de identidade geridas

O tratamento gerido da identidade depende do tipo de identidade:

  • Identidade atribuída ao sistema: Quando recria a aplicação container, o Azure gera um novo principal ID. Deve reatribuir todos os papéis RBAC, políticas de acesso ao Key Vault e permissões de serviço a jusante para a nova identidade.

  • Identidade atribuída pelo utilizador: As identidades geridas atribuídas pelo utilizador são recursos regionais e não podem ser movidas entre regiões. Crie uma nova identidade atribuída pelo utilizador na região de destino e atribua as permissões necessárias antes da implementação.

Exportar a configuração de origem

Use o portal Azure para exportar templates ARM tanto para o ambiente gerido por Aplicações de Container como para aplicações individuais de container.

  1. Inicie sessão no portal Azure.
  2. Navegue até ao ambiente gerido Container Apps ou ao recurso de Container App.
  3. No menu à esquerda, selecione Automação>Exportar modelo.
  4. Selecione Download e extraia o .zip ficheiro para uma pasta local.

Os ficheiros extraídos incluem:

Ficheiro Descrição
template.json Definição de configuração de recursos
Ficheiros de parâmetros Valores dos parâmetros de implantação
Scripts de implantação Scripts para execução de templates

Observação

Os modelos exportados servem como ponto de partida para compreender a sua configuração. Podem incluir propriedades de apenas leitura que precisa de remover, e não incluem segredos ou valores de certificados. Revise cuidadosamente a saída exportada antes de a usar para reimplantação.

Modificar o modelo do ambiente gerido

Antes de reimplantar o ambiente gerido, atualize a configuração exportada:

  • Atualize a localização: Defina a location propriedade para a região Azure alvo.
  • Validar nomes de recursos: Garantir que o nome do ambiente gerido é único dentro do grupo de recursos e da região alvo.
  • Rever a configuração do Log Analytics: Atualize a referência do espaço de trabalho do Log Analytics se o espaço for específico de uma região. Pode ser necessário criar um novo espaço de trabalho na região de destino.
  • Remover propriedades de apenas leitura: Se exportou do portal, remova propriedades como id, type, systemData, e outros campos de apenas leitura que causam falhas de implementação.

Modificar o modelo da aplicação container

Após exportar a configuração da aplicação do contentor, faça as seguintes alterações:

  • Atualize a referência do ambiente gerido: Substitua managedEnvironmentId pelo ID de recurso do novo ambiente gerido na região de destino. Os ambientes geridos são regionais e não podem ser reutilizados entre regiões.

  • Verificar referências de imagens de contentores: Confirme que as referências de imagem apontam para um registo de contentores acessível a partir da região de destino. Se ativares a geo-replicação ACR, as referências existentes podem funcionar sem alterações.

  • Rever a configuração de entrada: Após a reimplantação, o nome de domínio totalmente qualificado (FQDN) da aplicação muda. Planear a atualização de registos DNS personalizados e o encaminhamento de tráfego durante a transição.

  • Reconfigure segredos e definições da aplicação: Recrie segredos usando referências do Azure Key Vault ou a configuração da aplicação. Não dependas dos valores exportados para definições sensíveis.

  • Atualize componentes Dapr: Se usar Dapr, verifique se as configurações de componentes Dapr referenciam recursos disponíveis na região de destino (por exemplo, state stores, pub/subbrokers, secret stores).

  • Atualizar diagnósticos e monitorização: Verificar referências ao espaço de trabalho do Log Analytics e reconfigurar as definições de diagnóstico conforme necessário.

Reimplantar

Os ambientes geridos do Azure Container Apps são regionais. Crie o ambiente gerido na região de destino antes de reimplantar quaisquer aplicações de contentores.

Implementar o ambiente gerido

  1. No portal Azure, vai ao grupo de recursos alvo.
  2. Selecione Implementar um modelo personalizado.
  3. Escolha Criar o seu próprio modelo no editor e carregue o modelo ARM modificado.
  4. Revise as definições de implementação e depois selecione Rever + criar para iniciar a implementação.

Validar o acesso ao registo de contentores

Antes de implementar a aplicação contentor, confirme que a identidade utilizada pela aplicação contentor (identidade gerida atribuída pelo sistema ou pelo utilizador) tem a função AcrPull atribuída ao Azure Container Registry de destino.

az role assignment create \
  --assignee <IDENTITY_PRINCIPAL_ID> \
  --role AcrPull \
  --scope <ACR_RESOURCE_ID>

Observação

Se a aplicação container referenciar um ACR numa subscrição ou região diferente, verifique previamente que as permissões necessárias estejam configuradas para evitar falhas na captação de imagens durante a implementação.

Implementar a aplicação de contentor

  1. No portal Azure, vai ao grupo de recursos alvo.
  2. Selecione Implementar um modelo personalizado.
  3. Carregue o modelo ARM modificado para a aplicação do contenedor.
  4. Rever as definições e concluir a implementação.

Configurar rede

Após a implementação, reconfigure a rede para corresponder à configuração de origem:

  1. Configurar entradas: Configure entradas públicas ou privadas com base no modelo de exposição da sua aplicação.

  2. Reaplique a integração com a VNet: Se a aplicação de contentores usar rede privada, configure a VNet, sub-redes, endpoints privados e zonas DNS privadas na região de destino.

  3. Atualizar NSGs e UDRs: Recriar grupos de segurança de rede e rotas definidas pelo utilizador conforme necessário.

  4. Atualizar listas de permissão IP: Se os serviços a jusante utilizarem listas de permissão baseadas em IP, atualize-as com os novos endereços IP de saída do ambiente da região-alvo.

  5. Configurar domínios e certificados personalizados: Domínios personalizados e certificados TLS não são transferidos durante a realocação. Reconfigure-os na nova aplicação de contentores e atualize os registos DNS.

Redirecionamento de tráfego

Após a validação, redirecione o tráfego para a implementação da região-alvo:

  1. Se baixaste o DNS TTL anteriormente, atualiza os registos DNS para apontarem para a nova aplicação de contentores FQDN.

  2. Se usar Azure Front Door ou Gestor de Tráfego do Azure, atualize o backend pool ou endpoint para incluir a aplicação contentor da região de destino e remova o endpoint da região de origem.

  3. Monitorize o tráfego para confirmar que os pedidos estão a chegar à nova instalação.

Tip

Mantém a aplicação do contentor de origem a correr durante a janela de rollback. Se surgirem problemas, reverta o DNS ou o encaminhamento de tráfego para o endpoint de origem até resolveres o problema.

Verificar

Após o corte de tráfego, valide os seguintes itens:

  • Disponibilidade de candidaturas e tempos de resposta.
  • Comportamento de escalonamento sob carga esperada e máxima.
  • Conectividade a serviços dependentes como bases de dados, Cofre de Chaves, armazenamento e mensagens.
  • Acesso de identidade gerida a recursos a jusante.
  • Funcionalidade do componente Dapr, se usada.
  • Registos e métricas a fluir para o Azure Monitor e Log Analytics.

Verifique usando a interface de linha de comandos:

# Confirm the container app is running
az containerapp show \
  --name <APP_NAME> \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --query "{status:properties.runningStatus, fqdn:properties.configuration.ingress.fqdn}" \
  --output table

# Test the application endpoint
curl -s -o /dev/null -w "%{http_code}" https://<APP_FQDN>/health

Importante

Mantenha a aplicação de contentor de origem a funcionar até que a validação esteja completa e a implementação do alvo seja confirmada como estável. Defina uma janela de rollback, como entre 24 a 48 horas, antes de limpar os recursos fonte.

Limpar recursos de origem

Após validação bem-sucedida e corte de tráfego:

  1. Eliminar a aplicação de contentores fonte.
  2. Elimina o ambiente gerido pelo código-fonte se já não precisares dele.
  3. Remova imagens de contentores não utilizadas, recursos de rede e atribuições de identidade para evitar encargos desnecessários.
  4. Atualize quaisquer painéis de monitorização ou regras de alerta que referenciassem os recursos de origem.

Limitações

  • O Azure Container Apps não suporta relocação de regiões no local ou ao vivo.
  • Deve recriar segredos, certificados e domínios personalizados.
  • O histórico de revisões não é mantido na implementação de destino.
  • É necessário tempo de inatividade durante a transição (cutover).
  • Os IDs principais de identidade gerida atribuídos pelo sistema mudam, por isso deve recriar todas as atribuições RBAC.
  • As identidades geridas atribuídas pelo utilizador são regionais e devem ser recriadas na região-alvo.
  • Os endereços IP de saída mudam, o que pode afetar as listas de autorização de serviços subsequentes.

Conteúdo relacionado

  • Última atualização a