TL;DR: O ACR geo-replicado agora conta com health-aware failover automático: em minutos, o global endpoint desvia tráfego de uma região degradada e retorna automaticamente quando ela se recupera, sem ação manual. Para workloads que exigem afinidade regional ou consistência push/pull, use regional endpoints (myregistry.
Introdução
Três perguntas recorrentes de times de infraestrutura que operam Azure Container Registry (ACR) geo-replicado:
- Como controlar qual região atende meu tráfego? — Meus clusters AKS estão espalhados por regiões; consigo fixar cada um na sua réplica local ou estou preso ao roteamento do global endpoint?
- O failover durante um incidente regional é automático ou preciso agir? — Se o registry de uma região degradar, o global endpoint redireciona sozinho ou tenho que desabilitar a réplica manualmente?
- Após a recuperação, o tráfego volta automaticamente? — Existe um cooldown, quarentena ou passo manual antes do failback?
A resposta hoje é: failover e failback são automáticos para o global endpoint, mas você tem ferramentas adicionais para controle fino: regional endpoints e desabilitação manual de réplicas. Este artigo detalha cada mecanismo, os modos de falha de consistência eventual e as práticas operacionais para empresas brasileiras que precisam de alta disponibilidade em suas imagens de container.
Principais Conclusões
- Health-aware failover é automático. Quando o registry de uma região degrada, o global endpoint redireciona o tráfego em minutos, por registry. Nenhuma ação do cliente.
- Failback também é automático. Assim que a região é considerada saudável, o roteamento volta. Sem cooldown.
- Aplica-se apenas ao global endpoint. Regional endpoints e dedicated data endpoints não sofrem failover automático.
- Não é acionado por throttling. Responde apenas à saúde da infraestrutura Azure, não a HTTP 429.
- Regional endpoints (myregistry.
.geo.azurecr.io) dão URLs explícitas por réplica para workloads que precisam de afinidade, consistência ou troubleshooting. - Reautentique ao trocar de endpoint. Cada endpoint é uma superfície autenticada independente.
- Não use cache DNS longo para o global endpoint. ACR purga DNS no lado servidor durante failover e desabilitação.
- Em produção, habilite dedicated data endpoints para segurança e previsibilidade DNS.
- Consistência bounded staleness está em desenvolvimento para eliminar os modos de falha de consistência eventual.
Background
O que é geo-replicação do ACR?
Geo-replicação é um recurso do Premium SKU que transforma um único registry em um serviço multi-região, multi-write. Cada réplica é gravável — você pode push, pull e delete de qualquer uma — e o conteúdo sincroniza de forma assíncrona (consistência eventual). O tempo de replicação escala com o tamanho total do registry.
Um registry geo-replicado expõe:
- Global endpoint:
myregistry.azurecr.io— usa um traffic manager interno para rotear cada requisição à réplica com melhor desempenho de rede. - Regional endpoint:
myregistry.<region>.geo.azurecr.io— permite fixar requisições de API a uma réplica específica.
Zone redundancy é sempre ativada em regiões com múltiplas availability zones.
Endpoints e data endpoints
Durante um pull, dois tipos de tráfego ocorrem:
- Tráfego de API do registry: autenticação, manifestos, tags, metadados. Vai para o global endpoint ou regional endpoint.
- Download de layers (blobs): o registry retorna um HTTP 307 redirecionando para um data endpoint regional. Onde esse redirect aponta depende da configuração:
| Configuração | Download de layers redireciona para |
|---|---|
| Default (sem dedicated data endpoints) | *.blob.core.windows.net |
| Dedicated data endpoints habilitados | myregistry.<region>.data.azurecr.io |
| Private endpoints habilitados | myregistry.<region>.data.azurecr.io |
Por que habilitar dedicated data endpoints? Eles substituem o wildcard *.blob.core.windows.net por um FQDN previsível no domínio do seu registry, permitindo regras de firewall restritas ao seu registry e região. Além disso, tornam o download de camadas mais previsível durante mudanças de roteamento.
As três ferramentas de controle de tráfego
| Ferramenta | Quem controla | O que faz | Casos de uso |
|---|---|---|---|
| Health-aware failover | Plataforma (automático) | Redireciona o global endpoint para longe de uma região degradada | Incidentes regionais, recuperação automática |
| Replica enable/disable para roteamento global | Cliente (manual) | Exclui uma réplica do roteamento do global endpoint sem deletá-la (dados continuam sincronizando) | DR rehearsals, manutenção, quarentena |
| Regional endpoints | Cliente (por requisição) | URLs dedicadas por região que bypassam o traffic manager interno | Fixar clusters AKS, consistência push/pull, capacity planning, troubleshooting |
O comportamento em questão
Antes do health-aware failover, a resposta para "o que acontece quando uma região degrada?" era próxima de (A) Nada automático — o cliente precisava desabilitar manualmente. Agora a resposta é (C): o sistema detecta a degradação e redireciona em minutos, sem ação do cliente. O failback também é automático.
Walkthrough (Passo a Passo Operacional)
Os comandos a seguir assumem um registry Premium e Azure CLI logado. Use myregistry, myrg, eastus como exemplos.
Pré-requisitos
- Premium SKU
- Azure CLI 2.86.0+ (para regional endpoints)
Passo 1: Adicionar uma réplica em West US
az acr replication create --registry myregistry --location westus
Pushes e pulls continuam funcionando na réplica existente enquanto a nova é populada em background. O tempo de seed escala com o tamanho total do registry.
Passo 2a: Fixar workloads com regional endpoints
Habilite:
az acr update -n myregistry -g myrg --regional-endpoints enabled
Push para West US:
az acr login --name myregistry --endpoint westus
docker push myregistry.westus.geo.azurecr.io/myapp:v1
Fixar AKS no deployment:
image: myregistry.eastus.geo.azurecr.io/myapp:v1
Passo 2b: Manter o global endpoint para o restante
Não faça nada. O global endpoint com health-aware failover roteia automaticamente.
Passo 3: Remover uma réplica do roteamento global
az acr replication update --registry myregistry --name westus --global-endpoint-routing false
A réplica continua sincronizando dados e custos continuam acumulando. Se regional endpoints estiverem habilitados, a URL regional ainda funciona.
Passo 4: Reabilitar a réplica no roteamento global
az acr replication update --registry myregistry --name westus --global-endpoint-routing true
Sem cooldown. Como os dados continuaram sincronizando, a réplica está imediatamente pronta.
Passo 5: O que esperar quando o health-aware failover dispara
- Timing: minutos — rápido o suficiente para capturar degradação real, lento o suficiente para ignorar erros transitórios.
- Escopo: apenas operações contra o global endpoint. Regional endpoints e dedicated data endpoints não são afetados.
- Sinais para confirmar:
az acr replication list, Resource Health no portal, aumento de latência de pull. - Não acionado por throttling: use regional endpoints para distribuir carga entre réplicas.
Nota sobre pushes longos durante failover: um push multi-layer que cruza uma fronteira de failover pode espalhar layers e manifesto em réplicas diferentes. Para evitar, fixe pushes a uma única réplica via regional endpoint.
Perguntas Frequentes
-
O failover automático do ACR é acionado por throttling (HTTP 429)?
- Não. O health-aware failover responde apenas à degradação da infraestrutura do Azure e do serviço ACR. Throttling não redireciona o tráfego. Para gerenciar limites por réplica, use regional endpoints para distribuir a carga entre múltiplas réplicas.
-
Preciso reautenticar ao trocar de endpoint (global para regional)?
- Sim. Cada endpoint (global ou regional) é uma superfície autenticada independente. Ao mudar, execute
az acr login, renove a autenticação do SDK ou deixe o Kubernetes ACR credential provider tratar automaticamente.
- Sim. Cada endpoint (global ou regional) é uma superfície autenticada independente. Ao mudar, execute
-
O que acontece com webhooks durante um failover?
- Webhooks disparam da réplica que recebeu o push. Como o conteúdo é replicado para outras réplicas, um único push gera eventos de cada réplica à medida que a replicação é concluída. Projete seus consumidores de webhook para tratar múltiplos eventos e deduplicar.
-
Como evitar o problema de DNS bouncing durante um push?
- A maneira mais limpa é fixar o push a uma única réplica usando um regional endpoint. Alternativamente, use um cache DNS de curta duração (
dnsmasq) apenas durante o push. Nunca use cache DNS longo para o global endpoint, pois ele interfere no failover e na desabilitação manual de réplicas.
- A maneira mais limpa é fixar o push a uma única réplica usando um regional endpoint. Alternativamente, use um cache DNS de curta duração (
-
Durante uma interrupção na home region, o que fica indisponível?
- O plano de controle (criar/excluir réplicas, modificar regras de rede) fica indisponível. O plano de dados (pulls, pushes, autenticação, webhooks) continua funcionando através do global endpoint ou regional endpoints. A home region é fixa na criação do registry e não pode ser alterada.
Artigo originalmente publicado por Johnson Shi, Zoey (Zhuyu) Li, Huangli Wu em Azure Updates - Latest from Azure Charts.
