Replicação geográfica no Registro de Contêiner do Azure

Habilitar a replicação geográfica para um Registro de Contêiner do Azure (ACR) cria recursos de réplica geográfica em regiões do Azure de sua escolha. Quando você envia imagens por push para um registro replicado geograficamente, o conteúdo é sincronizado automaticamente com todas as réplicas geográficas.

Com replicação geográfica:

• Gerenciar um registro: manter um único conjunto de credenciais, atribuições de função, regras de rede e configuração de registro em todas as réplicas geográficas.
• Use um ponto de extremidade: referência myregistry.azurecr.io/myimage:tag em todas as suas compilações e implantações. O Azure encaminha solicitações para a réplica geográfica com o melhor perfil de desempenho de rede para o cliente, que geralmente é a réplica geográfica mais próxima. No entanto, se o cliente estiver equidistante de várias réplicas geográficas ou se a réplica geográfica mais próxima não estiver disponível, as solicitações poderão ser roteadas para outro local.
• Sincronização automática: realize o push de tags e resumos uma única vez; ACR replica o conteúdo e os metadados para todas as réplicas geográficas.

A replicação geográfica requer o SKU Premium.

Considerações sobre alta disponibilidade

Modelo de replicação

A replicação geográfica do ACR usa um modelo ativo-ativo .

• Todas as réplicas geográficas estão ativas e podem ser gravadas: você pode enviar, receber e excluir imagens de qualquer réplica geográfica, não só da réplica geográfica da região de origem.
• Isso difere dos modelos de replicação primária-secundária em que apenas uma região aceita gravações e regiões secundárias são passivas.

Modelo de consistência

O ACR usa consistência eventual.

• Depois de fazer push de uma imagem ou excluí-la em qualquer réplica geográfica, o ACR acabará replicando a alteração em todas as réplicas geográficas em segundo plano.
• O tempo de replicação depende do tamanho da imagem. Uma imagem ou tag enviada pode não ficar disponível imediatamente para download em outras georréplicas se forem enviadas grandes quantidades de imagens ou imagens muito grandes. Da mesma forma, uma imagem ou tag excluída ainda pode estar disponível para consulta em outras réplicas geográficas até que a exclusão seja propagada.
• O tempo necessário para criar uma nova réplica geográfica é dimensionado com o tamanho total do registro. Ao criar uma nova réplica geográfica, as réplicas geográficas existentes continuam atendendo normalmente ao tráfego de push, pull e exclusão. Não há período de estado restrito nem janela de degradação enquanto a nova réplica geográfica se atualiza em segundo plano.
• Até que a replicação seja concluída em segundo plano, uma réplica geográfica pode não ter o conteúdo ou os metadados mais recentes. Você pode usar webhooks para receber notificações quando a replicação de uma imagem enviada por push específica for concluída em cada réplica geográfica.

Alta disponibilidade do plano de dados

A replicação geográfica melhora a disponibilidade do plano de dados mantendo imagens em várias regiões. Se uma região tiver uma indisponibilidade, as imagens permanecerão acessíveis por meio de outras georréplicas — as operações de push, pull e exclusão continuarão funcionando por meio das georréplicas restantes.

Redundância de zona está sempre habilitada para georéplicas — o ACR distribui automaticamente os dados da réplica entre várias zonas de disponibilidade para proteger contra falhas de zona.

Failover com reconhecimento de integridade

O ACR monitora automaticamente a integridade de cada réplica geográfica e redireciona o tráfego de ponto de extremidade global para longe de réplicas geográficas que não podem atender solicitações de forma confiável. Isso é chamado de failover baseado na integridade. O ACR roteia o tráfego do ponto de extremidade global com base na integridade do serviço ACR e na integridade da infraestrutura regional do Azure.

• Automático e por registro: a integridade é avaliada por registro, não por região. Se uma degradação afetar apenas um subconjunto de registros em uma região, somente esses registros serão redirecionados – outros registros na mesma região continuarão a ser atendidos localmente sem nenhuma penalidade de latência desnecessária.
• Tempo: o redirecionamento de ponta a ponta está na ordem dos minutos, rápido o suficiente para capturar degradação regional real e lento o suficiente para eliminar erros transitórios que se resolvem por conta própria. O TTL do DNS pode adicionar atraso de propagação antes que todos os clientes passem para a nova região.
• Nenhuma ação do cliente é necessária: não há nenhum gatilho invocado pelo cliente. O failover baseado na integridade é totalmente gerenciado pela plataforma.
• O failback é automático: depois que a avaliação de integridade regional de uma réplica geográfica voltar a ser aprovada, como quando o ACR regional ou a infraestrutura do Azure se recuperar, o ponto de extremidade global poderá voltar a rotear o tráfego para a réplica geográfica na região recuperada do Azure.
• Não é acionado por limitação de taxa: o failover com reconhecimento do estado de integridade é baseado em DNS e responde ao estado de integridade do serviço regional do ACR e da infraestrutura do Azure. Ele não redireciona o tráfego com base em respostas HTTP 429 (limitação). Se uma réplica geográfica estiver restringindo suas solicitações, mas a infraestrutura da região estiver íntegra, o endpoint global continuará direcionando suas solicitações para essa réplica geográfica. Para gerenciar a limitação, use pontos de extremidade regionais para espalhar cargas de trabalho em várias réplicas geográficas para melhor distribuição de capacidade.

Escopo do failover com reconhecimento de integridade:

O failover sensível à integridade se aplica apenas às operações no ponto de extremidade global (myregistry.azurecr.io). Ele não se aplica a:

• Pontos de extremidade regionais – quando você usa um ponto de extremidade regional (myregistry.<region>.geo.azurecr.io), você está falando diretamente com uma réplica geográfica específica. Se essa região for degradada, o ACR não redirecionará automaticamente. Implemente o failover no lado do cliente alternando para um ponto de extremidade regional diferente.
• Endpoints de dados dedicados — depois que um endpoint de registro redireciona você para um endpoint de dados dedicado para o download de uma camada, você permanece no endpoint de dados dessa região durante todo o download. A região é definida antecipadamente pelo ponto de extremidade do registro que atendeu à chamada blob-location.

Limitação durante o failover:

Os limites de limitação nas operações de API são por réplica. Durante um failover com detecção de integridade, o tráfego que estava distribuído entre várias réplicas geográficas pode ser redirecionado em grande volume para as réplicas geográficas que permanecerem no pool de roteamento do ponto de extremidade global. Planeje a capacidade para ter pelo menos duas ou três réplicas geográficas, para que o tráfego possa ser distribuído entre várias réplicas geográficas íntegras durante um failover. Registros com apenas duas regiões podem atingir limites de limitação por réplica com mais facilidade quando uma região não está disponível. Para mitigar, use pontos de extremidade regionais para espalhar cargas de trabalho em várias réplicas geográficas e planejar a capacidade por réplica.

Como confirmar um failover:

• Azure portal: navegue até o registro e selecione Resource health na seção Help para ver sinais de degradação do lado da plataforma.
• CLI do Azure: verifique o status da replicação com az acr replication list --registry myregistry --output table. Réplicas geográficas com problemas apresentam um status diferente de online.
• Azure Monitor: as métricas da plataforma são coletadas automaticamente. Habilite Configurações de Diagnóstico para os logs de recursos a fim de obter telemetria detalhada.

Comportamento de interrupção na região de residência

A região inicial é a região em que você originalmente criou o registro. Ele hospeda o plano de controle do registro, que gerencia a configuração do Registro. A região principal é fixada no momento da criação e não pode ser alterada posteriormente. Para mover um registro para outra região de origem, consulte Relocate Registro de Contêiner do Azure, que descreve um procedimento de reimplantação (criando um novo registro), e não uma alteração no local.

Se a região principal ficar indisponível, o impacto se limitará às operações de gerenciamento do plano de controle. Todas as operações do plano de dados continuam a funcionar por meio das réplicas geográficas restantes.

O que continua funcionando durante uma interrupção na região doméstica:

• Push, pull e exclusão de imagens — os clientes podem fazer push, pull e excluir imagens de qualquer réplica geográfica disponível usando o ponto de extremidade global (myregistry.azurecr.io) ou qualquer ponto de extremidade regional disponível (myregistry.<region>.geo.azurecr.io). O ACR roteia automaticamente solicitações de ponto de extremidade globais para uma réplica geográfica íntegra.
• Autenticação — todos os métodos de autenticação continuam funcionando, incluindo Microsoft Entra ID, entidades de serviço, identidades gerenciadas e tokens no escopo do repositório. Os clientes podem se autenticar em qualquer réplica geográfica disponível sem a necessidade de alterar credenciais, tokens ou URLs do Registro.
• Entrega de webhook – Os webhooks configurados para réplicas geográficas disponíveis continuam a ser acionados. Um único push resulta em eventos de webhook da réplica geográfica de destino, além de eventos de cada réplica geográfica à medida que a replicação é concluída. Os consumidores de webhook devem ser projetados para lidar com vários eventos para cada imagem enviada e eliminar duplicatas conforme necessário.
• Pontos de extremidade regionais – se os pontos de extremidade regionais estiverem habilitados, eles continuarão funcionando de forma independente. Os clientes podem falar diretamente com réplicas geográficas específicas usando URLs de ponto de extremidade regionais.

O que não está disponível durante uma interrupção na região doméstica:

• Roteamento do endpoint global para a réplica geográfica da região de origem — a detecção de integridade do ACR interrompe automaticamente o roteamento do tráfego do ponto de extremidade global para a réplica geográfica da região de origem e o redireciona para réplicas geográficas íntegras.
• Ponto de extremidade regional para a região inicial – o ponto de extremidade regional da região inicial (myregistry.<home-region>.geo.azurecr.io) não está disponível enquanto a região inicial está inoperante. Os pontos de extremidade regionais para outras réplicas geográficas continuam funcionando de forma independente.
• Alterações na configuração do Registro – você não pode modificar propriedades do Registro, como regras de rede, configurações de replicação ou configurações de zona de disponibilidade até que a região inicial se recupere.
• Tarefas do ACR – as tarefas são associadas à região inicial e não são executadas enquanto ela não está disponível.

Considerações de camada de serviço e limites

As camadas de serviço e os limites do Registro de Contêiner do Azure aplicam-se a cada réplica geográfica de forma independente.

Determinados limites de camada de serviço têm a seguinte consideração especial:

• Limites de armazenamento: os limites de armazenamento da camada de serviço são compartilhados em todas as réplicas geográficas. Por exemplo, se você enviar por push uma imagem de 1 GiB e ela for replicada para 5 réplicas geográficas, apenas 1 GiB conta para os limites máximos de armazenamento da sua camada.
• Limites de taxa de API: os limites de operações de API, como o número de leituras e gravações por minuto, são específicos para cada réplica geográfica. Use pontos de extremidade regionais para espalhar cargas de trabalho em várias réplicas geográficas para melhor distribuição de capacidade e para evitar concentrar todo o tráfego em uma única réplica geográfica.

Para obter mais informações sobre as camadas de serviço e os limites, consulte as camadas de serviço do ACR.

Considerações de preço

• Cobrança de armazenamento: o armazenamento é cobrado por réplica geográfica. Por exemplo, uma imagem de 1 GiB replicada em 5 réplicas geográficas é cobrada como 5 GiB de armazenamento (1 GiB × 5 réplicas geográficas).
• Transferência de dados: a replicação geográfica pode reduzir os custos habilitando pushes e pulls de imagem na região, o que evita encargos de transferência de dados entre regiões durante essas operações de push ou pull. No entanto, as cobranças de transferência de dados entre regiões ainda se aplicam quando o ACR replica o conteúdo enviado para outras réplicas geográficas como parte da consistência eventual.

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

Adicionar ou excluir réplicas geográficas

Permissões necessárias

Para gerenciar réplicas geográficas, sua identidade precisa dessas permissões:

portal do Azure

1. Vá para o registro no portal do Azure.
2. Em Serviços, selecione Replicações geográficas.
3. No mapa:
   • Hexágono azul: região inicial (onde você criou o registro)
   • Hexágonos verdes: regiões disponíveis
   • Hexágonos cinzas: regiões indisponíveis
4. Selecione um hexágono verde e, em seguida, selecione Criar.

CLI do 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 obter mais comandos, consulte az acr replication.

Ponto de extremidade global de um registro replicado geograficamente

Após configurar a replicação geográfica, você pode enviar, receber ou excluir conteúdo em seu registro por meio do ponto de extremidade global do registro (myregistry.azurecr.io).

Como funcionam os pontos de extremidade globais

Ao enviar, receber ou excluir dados por meio do endpoint global, o ACR encaminha a solicitação para a réplica geográfica com o melhor perfil de desempenho de rede para o cliente.

• A réplica geográfica com o melhor perfil de desempenho de rede do cliente geralmente é a réplica geográfica mais próxima.
• No entanto, se o cliente estiver equidistante de várias réplicas geográficas ou se a réplica geográfica mais próxima não estiver disponível, as solicitações poderão ser roteadas para outro local.
• O ACR gerencia esse roteamento. Você não controla qual réplica geográfica manipula uma solicitação específica.

Usando o ponto de extremidade global

Autenticar:

az acr login --name myregistry

Marque e envie uma imagem por push:

docker tag myapp:v1 myregistry.azurecr.io/myapp:v1
docker push myregistry.azurecr.io/myapp:v1

Baixar uma imagem:

docker pull myregistry.azurecr.io/myapp:v1

Importar uma imagem:

az acr import \
  --name myregistry \
  --source mcr.microsoft.com/hello-world:latest \
  --image hello-world:latest

Manifesto de implantação do Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myregistry.azurecr.io/myapp:v1

Remover temporariamente uma réplica geográfica do roteamento do endpoint global

Você pode excluir uma réplica geográfica do roteamento de endpoint global desativando a configuração --global-endpoint-routing de uma réplica geográfica específica. Isso é útil para manutenção ou solução de problemas ou quando você sabe que uma réplica geográfica específica ou Azure região está enfrentando degradação. Você pode até mesmo desabilitar o roteamento de ponto de extremidade global para a réplica geográfica da região inicial: a região inicial é usada apenas para operações de plano de controle e seu tráfego de plano de dados pode ser excluído com segurança do roteamento global. Para obter mais informações sobre o que a região principal controla, consulte o comportamento em caso de indisponibilidade da região principal.

• Quando a configuração --global-endpoint-routing de uma réplica geográfica específica é definida como false, o ACR interrompe o roteamento de solicitações para essa réplica geográfica específica para solicitações que vão para o ponto de extremidade global.
• Os dados continuam sincronizando bidirecionalmente com uma réplica geográfica, mesmo que o roteamento de ponto de extremidade global esteja desabilitado para essa réplica geográfica específica. Cada imagem enviada ao registro de qualquer região, enquanto a réplica geográfica estiver excluída do roteamento global, ainda será replicada para essa réplica geográfica. Quando você habilita novamente a réplica geográfica, ela está pronta imediatamente para atender ao tráfego sem janela de recuperação.
• Assim, a cota de armazenamento e os custos continuam a acumular-se para essa réplica geográfica.
• Se os pontos de extremidade regionais estiverem habilitados, a URL do ponto de extremidade regional da réplica geográfica (myregistry.<region-name>.geo.azurecr.io) continuará funcionando mesmo enquanto o roteamento de ponto de extremidade global estiver desabilitado. --global-endpoint-routing controla apenas a participação da réplica geográfica no roteamento de ponto de extremidade global .

# Exclude a geo-replica from global endpoint routing
az acr replication update --registry myregistry --name eastus \
  --global-endpoint-routing false

# Re-enable a geo-replica in global endpoint routing
az acr replication update --registry myregistry --name eastus \
  --global-endpoint-routing true

Pontos de extremidade regionais de um registro replicado geograficamente (versão prévia)

Os endpoints regionais fornecem URLs dedicadas para cada réplica, permitindo que você especifique exatamente qual geo-réplica regional processará sua solicitação de push, pull ou exclusão:

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

Use pontos de extremidade regionais quando precisar:

Pontos de extremidade regionais coexistem com pontos de extremidade globais

Habilitar pontos de extremidade regionais não desabilitar ou substituir o ponto de extremidade global. Você pode usar ambos simultaneamente:

• Use o ponto de extremidade global (myregistry.azurecr.io) se preferir o roteamento automático gerenciado pelo Azure em réplicas geográficas.
• Use pontos de extremidade regionais (myregistry.<region-name>.geo.azurecr.io) se desejar um controle de roteamento do lado do cliente mais refinado, ignorando totalmente o roteamento gerenciado por Azure do ponto de extremidade global.

Como funcionam os pontos de extremidade regionais

Os pontos de extremidade regionais funcionam como servidores de logon para réplicas geográficas específicas. Quando você autentica e interage com um ponto de extremidade regional em vez do ponto de extremidade global do Registro, todas as operações do Registro (autenticação, uploads/downloads de artefatos, operações de repositório e ações de metadados) vão diretamente para essa réplica regional específica, ignorando totalmente o roteamento gerenciado por Azure.

Os downloads dos blobs de camada (as camadas reais da imagem de contêiner) ainda seguem a configuração existente do seu registro:

• Registros sem pontos de extremidade privados ou pontos de extremidade de dados dedicados: quando você baixa camadas de imagem de uma georréplica específica, os downloads dos blobs de camada são redirecionados para contas de armazenamento do Azure (*.blob.core.windows.net).
• Registros com pontos de extremidade privados ou pontos de extremidade de dados dedicados habilitados: quando você baixa camadas de imagem de uma georréplica específica, os downloads de blobs de camada são redirecionados para o ponto de extremidade de dados dedicado da região correspondente (myregistry.<region-name>.data.azurecr.io).

O diagrama a seguir ilustra o fluxo de solicitações do endpoint regional:

Pré-requisitos de endpoints regionais

• SKU Premium — Os endpoints regionais estão disponíveis exclusivamente em registros na camada Premium.
• CLI do Azure — versão 2.86.0 ou posterior. Todos os comandos de pontos de extremidade regionais (--regional-endpoints, az acr show-endpoints, az acr login --endpoint) estão disponíveis nativamente no CLI do Azure 2.86.0+.

az extension remove --name acrregionalendpoint

az extension list --query "[?name=='acrregionalendpoint']" -o table

Habilitar endpoints regionais

Você pode habilitar pontos de extremidade regionais ao criar um novo registro ou atualizar um registro existente.

Crie um novo registro com pontos de extremidade regionais habilitados:

az acr create \
  -n myregistry \
  -g myrg \
  -l regionname \
  --sku Premium \
  --regional-endpoints enabled

Habilite pontos de extremidade regionais em um registro existente:

az acr update \
  -n myregistry \
  -g myrg \
  --regional-endpoints enabled

Os pontos de extremidade regionais são habilitados no nível do Registro e se aplicam a cada réplica geográfica. Você não pode habilitar pontos de extremidade regionais para réplicas individuais. Ao habilitar os pontos de extremidade regionais, o Registro de Contêiner do Azure cria automaticamente URLs de servidor de logon para cada uma de suas réplicas geográficas.

Trabalhar com pontos de extremidade regionais

Autenticar e usar pontos de extremidade regionais

Os pontos de extremidade regionais dão suporte aos mesmos métodos de autenticação que o ponto de extremidade global: Microsoft Entra ID, entidades de serviço, identidades gerenciadas e credenciais de administrador.

Faça login em um endpoint regional específico:

az acr login --name myregistry --endpoint eastus

Marque e envie uma imagem por push para um ponto de extremidade regional. Imagens e marcas enviadas por push para uma réplica geográfica por meio do ponto de extremidade regional ainda serão propagadas para todas as outras réplicas geográficas com consistência eventual.

docker tag myapp:v1 myregistry.eastus.geo.azurecr.io/myapp:v1
docker push myregistry.eastus.geo.azurecr.io/myapp:v1

Baixar uma imagem de um endpoint regional:

docker pull myregistry.eastus.geo.azurecr.io/myapp:v1

Usar pontos de extremidade regionais com autenticação de identidade gerenciada do AKS

Os pulls de imagem do AKS que autenticam no ACR usando uma identidade gerenciada são compatíveis com pontos de extremidade regionais na imagem de nó do AKS 202607.29 ou posterior. Verifique a imagem atual para cada pool de nós:

az aks nodepool show \
  --resource-group <resource-group> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --query nodeImageVersion \
  --output tsv

Para receber automaticamente um VHD de imagem de nó compatível assim que ele estiver disponível em sua região e nuvem, use o canal de atualização automática do SO do nó NodeImage. AKS Automatic usa NodeImage; para AKS Standard, selecione NodeImage.

az aks update \
  --resource-group <resource-group> \
  --name <cluster-name> \
  --node-os-upgrade-channel NodeImage

Para nós do AKS executando uma imagem anterior, use um segredo de pull de imagem do Kubernetes ao extrair imagens de pontos de extremidade regionais ou faça referência ao ponto de extremidade global (<registry-name>.azurecr.io).

Usar pontos de extremidade regionais inseridos em manifestos de implantação

Você pode especificar pontos de extremidade regionais diretamente nos manifestos de implantação do Kubernetes se precisar fixar cargas de trabalho em regiões específicas. Isso garante que os clusters em regiões específicas sempre sejam retirados de sua réplica colocada, fornecendo roteamento previsível e latência reduzida.

Implantação do cluster Leste dos EUA:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-eastus
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myregistry.eastus.geo.azurecr.io/myapp:v1

Implantação de cluster na Europa Ocidental:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-westeurope
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myregistry.westeurope.geo.azurecr.io/myapp:v1

Usando pontos de extremidade regionais diferentes nos manifestos de cada cluster, você pode optar por garantir que cada cluster use sua réplica local em vez de depender do roteamento gerenciado pelo Azure.

Para obter informações sobre a autenticação do AKS (Serviço de Kubernetes do Azure) com o ACR, consulte Autenticar-se no Registro de Contêiner do Azure por meio do Serviço de Kubernetes do Azure.

Usar pontos de extremidade regionais com roteamento baseado em DNS sem alterar manifestos de implantação

Se você não quiser manter manifestos de implantação diferentes por região, poderá manter todos os manifestos apontando para o ponto de extremidade global (myregistry.azurecr.io) e usar a rede definida pelo software ou um gerenciador de tráfego regional para resolver o ponto de extremidade global para o ponto de extremidade regional apropriado com base no tráfego da região de origem. Isso alcança os mesmos objetivos de colocação que os pontos de extremidade regionais (roteamento previsível e latência reduzida), sem incorporar URLs específicas da região aos seus manifestos de implantação.

Para obter informações sobre a autenticação do AKS (Serviço de Kubernetes do Azure) com o ACR, consulte Autenticar-se no Registro de Contêiner do Azure por meio do Serviço de Kubernetes do Azure.

Importar de réplicas geográficas específicas usando pontos de extremidade regionais

Registro de Contêiner do Azure dá suporte à importação de imagens de uma variedade de registros de origem entre provedores de nuvem. Se a origem de importação for um ACR, você poderá importar somente da região inicial do ACR de origem. Os pontos de extremidade regionais do ACR de origem não têm suporte como fontes de importação. Especifique o ponto de extremidade global do ACR de origem ao importar de um ACR de origem. Além disso, uma importação sempre grava conteúdo na região inicial do ACR downstream. Consulte a referência do ponto de extremidade do Registro de Contêiner do Azure.

Considerações de rede de pontos de extremidade regionais

Regras de firewall

Se você estiver usando regras de firewall do ACR ou firewalls personalizados com pontos de extremidade regionais, configure suas regras de firewall para permitir o acesso a:

Endpoints privados

Quando um ponto de extremidade privado é criado para um registro dentro de uma rede virtual, o recurso de ponto de extremidade privado expõe vários IPs privados de rede virtual que abrangem todas as superfícies de ponto de extremidade do Registro – o ponto de extremidade global, cada ponto de extremidade regional (se os pontos de extremidade regionais estiverem habilitados) e todos os pontos de extremidade de dados dedicados (habilitados automaticamente quando um ponto de extremidade privado é configurado).

Cada ponto de extremidade consome um endereço IP privado da sub-rede da rede virtual. Planeje o dimensionamento da sub-rede de acordo:

• 1 IP para a extremidade global (myregistry.azurecr.io)
• 1 IP por réplica geográfica para pontos de extremidade de dados dedicados (myregistry.<region>.data.azurecr.io) — sempre habilitado em registros com pelo menos um ponto de extremidade privado
• 1 IP por réplica geográfica para pontos de extremidade regionais (myregistry.<region>.geo.azurecr.io) — somente se os pontos de extremidade regionais estiverem habilitados

Exemplo: um registro com três réplicas geográficas e pontos de extremidade regionais habilitados requer 1 (global) + 3 (dados) + 3 (regional) = 7 endereços IP privados por recurso de ponto de extremidade privado. Sem pontos de extremidade regionais, o mesmo registro requer 1 + 3 = 4 endereços IP privados.

Com muitas réplicas geográficas, a criação de ponto de extremidade privado poderá falhar se a sub-rede ficar sem IPs disponíveis. Para obter mais informações, consulte Conectar de forma privada a um registro a partir de uma rede virtual usando endpoints privados.

Pontos de extremidade dos dados dedicados

Quando os pontos de extremidade regionais são habilitados junto com pontos de extremidade de dados dedicados — habilitados explicitamente ou automaticamente por haver pelo menos um ponto de extremidade privado configurado —, os downloads de blobs de camada dos pontos de extremidade regionais são redirecionados automaticamente para o ponto de extremidade de dados dedicado da réplica geográfica (myregistry.<region-name>.data.azurecr.io). O redirecionamento ocorre sempre na mesma região do endpoint regional — um pull feito de myregistry.eastus.geo.azurecr.io sempre redireciona para myregistry.eastus.data.azurecr.io, nunca para um endpoint de dados em uma região diferente.

Essa garantia de mesma região também se aplica ao extrair dados do ponto de extremidade global. O ACR encaminha a solicitação para a réplica geográfica com o melhor perfil de desempenho de rede para o cliente e a réplica geográfica que a atende emite um redirecionamento 307 para seu próprio ponto de extremidade de dados dedicado, nunca entre regiões.

az acr update -n <registry-name> --data-endpoint-enabled true

Para obter mais informações, consulte Pontos de extremidade de dados dedicados no Registro de Contêiner do Azure.

Referência de ponto de extremidade

Para obter uma referência completa de todos os tipos de pontos de extremidade de registro, formatos de URL e os sinalizadores da CLI que os controlam, consulte Referência de pontos de extremidade do Registro de Contêineres do Azure.

Resolução de problemas

O envio falha com erros evidentes

Uma docker push é uma sequência de solicitações HTTP: envios de blobs para cada camada e, em seguida, o envio de um manifesto que faz referência a essas camadas por hash. Alguns resolvedores DNS do Linux não armazenam respostas em cache consistentemente. Se houver várias réplicas geográficas em regiões próximas, o DNS poderá resolver para diferentes réplicas durante um único envio (DNS bouncing), fazendo com que o manifesto enviado faça referência a camadas que foram enviadas para uma réplica geográfica diferente. Como a replicação é eventualmente consistente, o manifesto pode chegar a uma réplica que ainda não tenha as camadas às quais ele faz referência, e a validação do manifesto falha.

Soluções (em ordem de preferência):

1. Use pontos de extremidade regionais para fixar o push em uma única réplica geográfica de ponta a ponta. Cada subsolicitação (login, envios de blobs, envio do manifesto) é direcionada para a mesma réplica geográfica. Essa é a correção mais limpa e a abordagem recomendada para qualquer pipeline em que a consistência de push/pull é importante.
2. Use um cache de DNS de curta duração, como dnsmasq limitado à duração de um único push. Para VMs linux no Azure, consulte as opções de resolução de nomes DNS. A fixação deve durar apenas o tempo de ativação: não execute um cache DNS de longa duração para o ponto de extremidade global, pois isso interfere em --global-endpoint-routing false e no roteamento de failover com reconhecimento de integridade.
3. Projete as etapas de publicação para serem idempotentes, para que novas tentativas acionadas por falhas no meio do push sejam seguras.

Criação de réplicas geográficas travada para registros habilitados para pontos de extremidade privados

Esse problema geralmente ocorre quando a identidade que cria uma réplica geográfica para um registro com pontos de extremidade privados habilitados não tem permissões suficientes para criar recursos de rede de pontos de extremidade privados.

Solução:

• Para resolver, exclua manualmente a réplica geográfica que ficou presa no estado de provisionamento.
• Posteriormente, verifique se a identidade tem a permissão Microsoft.Network/privateEndpoints/privateLinkServiceProxies/write antes de criar uma réplica geográfica.
• Verifique também se cada sub-rede de ponto de extremidade privado conectada ao registro tem capacidade de IP gratuita. Se qualquer sub-rede em qualquer rede virtual conectada não tiver endereços IP livres suficientes, o provisionamento da replicação falhará e será revertido. A réplica aparece brevemente em estado de Creating e, em seguida, é removida. O erro resultante não identifica qual sub-rede ou rede virtual está esgotada. Para obter diretrizes sobre o dimensionamento de sub-redes, consulte Acessar um registro de forma privada usando pontos de extremidade privados.

Falha na criação de réplica geográfica em registros com um ponto de extremidade privado de IP estático

A adição de uma réplica geográfica falha quando o ponto de extremidade privado do registro está configurado com alocação de IP privado estático.

Cada réplica geográfica tem o próprio ponto de extremidade de dados dedicado, que é exposto no ponto de extremidade privado como um membro com a ID do grupo registry e um nome de membro de registry_data_<region>. Quando você adiciona uma nova réplica geográfica, o ACR solicita que o ponto de extremidade privado adicione o membro referente ao ponto de extremidade de dados da nova região. Um ponto de extremidade privado configurado com alocação dinâmica de IP atribui automaticamente o IP do novo membro. Um endpoint privado configurado com alocação estática de IP tem um conjunto fixo de configurações de IP definido no momento da criação e não adiciona automaticamente o novo membro, fazendo com que a criação da réplica falhe com um erro semelhante a:

Failed to replicate private endpoint. Private Endpoint <id> contains static ipconfigurations:
[... GroupId: registry, MemberName: registry_data_<existing-region> ...] and it's missing these
membernames/groupids requested by Private Link service [GroupId: registry, MemberName:
registry_data_<new-region>, IpVersion: IPv4]. Private Endpoint needs to be reconfigured with
missing memberNames.

Para verificar o método de alocação do ponto de extremidade privado de um registro, inspecione o PrivateIPAllocationMethod nas configurações de IP da interface de rede do ponto de extremidade privado. O ponto de extremidade privado se refere a uma interface de rede que mantém essas configurações de IP, portanto, primeiro obtenha o ID da interface de rede e, em seguida, inspecione suas configurações de IP:

nicId=$(az network private-endpoint show \
  --name <private-endpoint-name> \
  --resource-group <resource-group-name> \
  --query "networkInterfaces[0].id" --output tsv)

az network nic show --ids "$nicId" \
  --query "ipConfigurations[].{Name:name, PrivateIPAddress:privateIPAddress, PrivateIPAllocationMethod:privateIPAllocationMethod}" \
  --output table

Soluções:

• Use a alocação de IP dinâmico para o ponto de extremidade privado se você espera adicionar réplicas geográficas mais tarde. Com a alocação dinâmica, o ACR provisiona automaticamente o membro do endpoint de dados para cada nova região. Essa é a abordagem recomendada.
• Crie o ponto de extremidade privado depois que todas as réplicas geográficas existirem se a alocação de IP estático for necessária. Adicione cada réplica geográfica primeiro e, em seguida, crie o ponto de extremidade privado de IP estático para que a configuração de IP inclua um membro para o ponto de extremidade de dados de cada região existente. Depois que um ponto de extremidade privado com IP estático for criado dessa forma, você não poderá adicionar outras georréplicas sem reconfigurar o ponto de extremidade privado para adicionar o novo membro.

Conteúdo relacionado

• SKUs de ACR e níveis de serviço
• Referência de ponto de extremidade
• Webhooks
• Pontos de extremidade privados
• Endpoints de dados dedicados
• Configurar regras de acesso ao firewall