Georreplicação no Azure Container Registry

Ativar a geo-replicação para um Azure Container Registry (ACR) cria recursos de geo-réplica nas regiões da Azure à sua escolha. Quando faz upload de imagens para um registo geo-replicado, o conteúdo sincroniza-se automaticamente com todas as geo-replicas.

Com a geo-replicação:

Gerir um registo: Manter um único conjunto de credenciais, atribuições de funções, regras de rede e configuração do registo em todas as geo-réplicas.
Use um endpoint global: Referenciar myregistry.azurecr.io/myimage:tag em todas as suas compilações e implementações. O Azure encaminha pedidos para a geo-réplica com o melhor perfil de desempenho de rede para o cliente, que normalmente é a geo-réplica mais próxima. No entanto, se o cliente estiver equidistante de múltiplas geo-réplicas ou se a geo-réplica mais próxima não estiver disponível, os pedidos podem ser redirecionados para outros locais.
Sincronização automática: Enviar etiquetas e digestões uma vez; O ACR replica o conteúdo e os metadados para todas as geo-réplicas.

A geo-replicação requer o SKU Premium.

Nota

Para copiar imagens entre registos separados, veja Importar imagens de contentores.
Para mover a região de origem de um registo para outra região, consulte Relocate Azure Container Registry.

Considerações centrais

Modelo de replicação

A geo-replicação ACR utiliza um modelo ativo-ativo.

Todas as geo-réplicas são ativas e graváveis — pode enviar e extrair imagens de qualquer geo-réplica e não apenas da geo-réplica da região de origem.
Isto difere dos modelos de replicação primário-secundário, onde apenas uma região aceita escritas e as regiões secundárias são passivas.

Modelo de consistência

O ACR usa a consistência eventual.

Depois de enviares uma imagem, o ACR acaba por replicar o conteúdo e os metadados enviados para todas as geo-réplicas em segundo plano.
O tempo de replicação é uma função do tamanho da imagem.
Até que a replicação seja eventualmente concluída em segundo plano, uma geo-réplica pode não ter o conteúdo ou metadados mais recentes divulgados. Pode usar webhooks para receber notificações quando a replicação de uma imagem push específica é concluída em cada geo-réplica.

Considerações sobre alta disponibilidade

A geo-replicação melhora a disponibilidade ao manter imagens em múltiplas regiões. Se uma região sofrer uma falha, as imagens permanecem acessíveis a partir de outras geo-réplicas — o envio e a receção continuam a funcionar nas restantes geo-réplicas.

Para máxima resiliência:

A redundância de zonas está ativada para réplicas geográficas em regiões onde a redundância de zona está ativada.
Se a região de origem (onde criou o registo) não estiver disponível, ainda pode enviar e puxar imagens, mas não pode modificar as propriedades do registo até que a região de origem recupere.
Se o seu registo usar uma chave gerida pelo cliente, reveja a orientação de failover e redundância do cofre de chaves.

SLA e considerações sobre o nível de serviço

Os SLAs do Azure Container Registry aplicam-se a cada geo-réplica de forma independente.

Certos limites de nível de serviço têm a seguinte consideração especial:

Armazenamento: Os limites de armazenamento são partilhados entre todas as geo-réplicas. Quando se envia uma imagem de 1 GiB, ela ocupa 1 GiB em todas as geo-réplicas após a conclusão da replicação eventual.
Limites de taxa de API: Os limites de limitação das operações da API, como o número de leituras e escritas por minuto, são específicos de uma réplica geográfica.

Para mais informações sobre níveis e limites de serviço, consulte camadas de serviço ACR.

Considerações sobre preços

A geo-replicação pode reduzir custos ao permitir o envio e a puxada de imagens dentro da mesma região, o que evita as cobranças de transferência de dados entre regiões durante estas operações de envio ou puxada.

No entanto, as cobranças interregionais continuam a aplicar-se para replicar dados em geo-replicas quando puxa imagens. Cada geo-réplica também assume os seus próprios custos de armazenamento.

Para mais informações, consulte preços ACR.

Configurar georreplicação

Permissões necessárias

Para gerir geo-réplicas, a sua identidade precisa destas permissões:

Permissão	Description
`Microsoft.ContainerRegistry/registries/read`	Obtenha propriedades registadas
`Microsoft.ContainerRegistry/registries/write`	Criar ou atualizar propriedades do registo
`Microsoft.ContainerRegistry/registries/replications/read`	Lista de geo-réplicas
`Microsoft.ContainerRegistry/registries/replications/write`	Criar ou atualizar uma geo-réplica
`Microsoft.ContainerRegistry/registries/replications/delete`	Eliminar uma geo-réplica
`Microsoft.ContainerRegistry/registries/replications/operationStatuses/read`	Obter o estado da operação de geo-replicação

portal do Azure

Vai ao teu registo no portal Azure.
Em Serviços, selecione Geo-replicações.
No mapa:
- Hexágono azul: Região de origem (onde criou o registo)
- Hexágonos verdes: Regiões disponíveis
- Hexágonos cinzentos: Regiões indisponíveis
Seleciona um hexágono verde e depois seleciona Criar.

Azure CLI (Interface de Linha de Comando da Azure)

# Create a replica
az acr replication create --registry myregistry --location eastus

# List replicas
az acr replication list --registry myregistry --output table

# Delete a replica
az acr replication delete --registry myregistry --name eastus

Para mais comandos, consulte az acr replicação.

Enviar ou retirar imagens através do endpoint global

Após configurar a geo-replicação, pode enviar ou puxar conteúdo para o seu registo através do endpoint global do registo (myregistry.azurecr.io).

Quando se faz push ou pull através do endpoint global, o ACR encaminha o pedido para a geo-réplica com o melhor perfil de desempenho de rede para o cliente.
Esta é normalmente a réplica geográfica mais próxima.
No entanto, se o cliente estiver equidistante de múltiplas geo-réplicas ou se a geo-réplica mais próxima não estiver disponível, os pedidos podem ser redirecionados para outros locais.
Este roteamento é gerido pela ACR—não tem controlo sobre qual geo-réplica trata um pedido específico.

Excluir temporariamente uma geo-réplica do encaminhamento global de endpoints

Pode excluir uma geo-réplica do encaminhamento global dos endpoints desativando a --region-endpoint-enabled definição para uma geo-réplica específica. Isto é útil para manutenção ou resolução de problemas.

Quando a --region-endpoint-enabled definição para uma geo-réplica específica é definida para false, o ACR para de encaminhar pedidos para essa geo-réplica específica para pedidos que vão para o endpoint global.
Os dados continuam a sincronizar-se com uma geo-réplica mesmo que o encaminhamento global do endpoint esteja desativado para essa geo-réplica específica.
Assim, as quotas de armazenamento e os custos continuam a acumular-se para essa geo-réplica.

# Prevent the global endpoint from routing to a specific geo-replica.
# This excludes only the specific geo-replica from global endpoint routing.
az acr replication update --registry myregistry --name eastus \
  --region-endpoint-enabled false

# Re-enable the geo-replica in global endpoint routing.
# This allows the global endpoint to route certain requests to the geo-replica
# depending on the client's network performance profile with the geo-replica.
az acr replication update --registry myregistry --name eastus \
  --region-endpoint-enabled true

Enviar ou puxar imagens através de endpoints regionais geo-réplica

Os endpoints regionais fornecem-lhe URLs dedicadas para cada réplica, permitindo-lhe especificar exatamente qual a geo-réplica regional que gere o seu pedido push ou pull:

myregistry.eastus.geo.azurecr.io
myregistry.westeurope.geo.azurecr.io

Use endpoints regionais quando precisar de:

Roteamento previsível: Garantir que uma carga de trabalho utiliza sempre uma réplica específica para afinidade dentro da região.
Failover do lado do cliente: Implemente a sua própria lógica de failover entre geo-réplicas regionais em caso de interrupções.
Consistência push-pull: Desde a mesma réplica, realizar as operações de push e pull para evitar o atraso de replicação.

Nota

Os endpoints regionais encontram-se atualmente em pré-visualização privada. Para registo e documentação, consulte Endpoints regionais para registos geo-replicados.

Solução de problemas

O push falha com erros manifestos

Alguns resolvedores DNS Linux não armazenam respostas em cache de forma consistente. Se existirem várias geo-réplicas em regiões próximas, o DNS pode resolver para réplicas diferentes durante um único push (DNS bouncing), fazendo com que o manifesto empurrado faça referência a camadas que foram enviadas para uma geo-réplica diferente.

Soluções:

Use endpoints regionais para direcionar para uma réplica geográfica específica.
Usa uma cache DNS como dnsmasq no cliente.
Para VMs Linux no Azure, consulte opções de resolução de nomes DNS.

Criação de geo-réplicas parada para registos habilitados com endpoint privado

Isto normalmente ocorre quando a identidade que cria uma geo-réplica para um registo com endpoint privado ativado não tem permissões suficientes para criar recursos de rede de endpoint privado.

Solução:

Para resolver, apague manualmente a geo-réplica que ficou presa no estado de provisionamento.
Depois, certifique-se de que a identidade tem a permissão Microsoft.Network/privateEndpoints/privateLinkServiceProxies/write antes de criar uma geo-réplica.

Próximos passos

Pontos finais regionais

Feedback

Esta página foi útil?

Last updated on 2026-02-28