Replica geografica nel servizio Registro Azure Container

L'abilitazione della replica geografica per un Registro Azure Container crea risorse di replica geografica nelle aree di Azure a scelta. Quando si esegue il push delle immagini in un registro con replica geografica, il contenuto viene sincronizzato automaticamente con tutte le repliche geografiche.

Con la replica geografica:

• Gestire un unico registro: gestire un singolo set di credenziali, assegnazioni di ruolo, regole di rete e configurazione del Registro di sistema in tutte le repliche geografiche.
• Usare un endpoint globale: riferimento myregistry.azurecr.io/myimage:tag in tutte le compilazioni e distribuzioni. Azure instrada le richieste alla replica geografica con il miglior profilo di prestazioni di rete per il client, che in genere è la replica geografica più vicina. Tuttavia, se il client è equidistante da più repliche geografiche o la replica geografica più vicina non è disponibile, le richieste potrebbero essere instradate altrove.
• Sincronizzazione automatica: eseguire il push di tag e digest una sola volta; Registro Azure Container replica il contenuto e i metadati in tutte le repliche geografiche.

La replica geografica richiede lo SKU Premium.

Considerazioni sulla disponibilità elevata

Modello di replica

La replica geografica di Registro Azure Container usa un modello attivo-attivo.

• Tutte le repliche geografiche sono attive e scrivibili: è possibile eseguire il push, il pull e l'eliminazione di immagini da qualsiasi replica geografica, non solo dalla replica geografica dell'area principale.
• Ciò differisce dai modelli di replica primaria-secondaria in cui solo un'area accetta scritture e aree secondarie è passiva.

Modello di coerenza

ACR usa la consistenza eventuale.

• Dopo aver caricato o eliminato un'immagine in una qualsiasi replica geografica, ACR replica poi la modifica in tutte le repliche geografiche in background.
• Il tempo di replica dipende dalle dimensioni dell'immagine. Un'immagine o un tag inviati tramite push potrebbero non essere immediatamente disponibili per il pull in altre repliche geografiche se vengono inviati tramite push grandi volumi di immagini o immagini di grandi dimensioni. Analogamente, un'immagine o un tag eliminato potrebbe essere ancora disponibile per il download in altre georepliche finché l'eliminazione non si è propagata.
• Il tempo necessario per creare una nuova replica geografica dipende dalle dimensioni complessive del registro. Durante la creazione di una nuova replica geografica, le repliche geografiche esistenti continuano a gestire normalmente il traffico di push, pull ed eliminazione. Non è presente alcuno stato limitato o finestra di riduzione delle prestazioni mentre la nuova replica geografica viene aggiornata in background.
• Fino al completamento della replica in background, una replica geografica potrebbe non avere il contenuto o i metadati più recenti. È possibile usare webhook per ricevere notifiche quando la replica per un'immagine push specifica viene completata in ogni replica geografica.

Alta disponibilità del piano dati

La replica geografica migliora la disponibilità del piano dati mantenendo le immagini in più aree. Se una regione subisce un'interruzione, le immagini restano accessibili da altre repliche geografiche: il push, il pull e l'eliminazione continuano a funzionare tramite le restanti repliche geografiche.

Ridondanza della zona è sempre abilitata per le georepliche: ACR distribuisce automaticamente i dati delle repliche in più zone di disponibilità per proteggere dalle interruzioni a livello di zona.

Failover basato sullo stato di integrità

ACR verifica automaticamente lo stato di integrità di ogni georeplica e instrada il traffico dell'endpoint globale verso georepliche diverse da quelle che non sono in grado di gestire le richieste in modo affidabile. Si chiama failover consapevole dello stato di salute. ACR instrada il traffico dell'endpoint globale in base all'integrità del servizio ACR e all'integrità dell'infrastruttura regionale di Azure.

• Automatico e per singolo registro: lo stato di integrità viene valutato per ogni registro, non per regione. Se una riduzione delle prestazioni influisce solo su un subset di registri in un'area, vengono reindirizzati solo i registri, altri registri nella stessa area continuano a essere serviti localmente senza penalità di latenza non necessarie.
• Tempi: il reindirizzamento end-to-end richiede dell’ordine di alcuni minuti, un tempo sufficientemente rapido da rilevare un degrado regionale reale e sufficientemente lento da assorbire errori transitori che si risolvono da soli. Il TTL DNS potrebbe aggiungere un ritardo di propagazione prima che tutti i client passino alla nuova area.
• Nessuna azione del cliente necessaria: non è presente alcun trigger chiamabile dal cliente. Il failover basato sullo stato di integrità è completamente gestito dalla piattaforma.
• Il failback è automatico: una volta che la valutazione dell'integrità regionale di una replica geografica torna a essere positiva, ad esempio quando ACR o l'infrastruttura di Azure nell'area vengono ripristinati, l'endpoint globale può riprendere a instradare il traffico verso la replica geografica nell'area di Azure ripristinata.
• Non attivato dal throttling: il failover basato sullo stato di integrità usa il DNS e risponde allo stato di integrità del servizio ACR a livello regionale e a quello dell'infrastruttura Azure. Non reindirizza il traffico in base alle risposte HTTP 429 (limitazione della velocità). Se una replica geografica sta limitando le tue richieste, ma l'infrastruttura della regione è funzionante, l'endpoint globale continua a instradarti verso tale replica geografica. Per gestire la limitazione delle richieste, usare gli endpoint a livello di area per distribuire i carichi di lavoro tra più repliche geografiche per una migliore distribuzione della capacità.

Ambito del failover basato sullo stato di integrità:

Il failover basato sullo stato di integrità si applica solo alle operazioni verso l'endpoint globale (myregistry.azurecr.io). Non si applica a:

• Endpoint regionali — Quando utilizzi un endpoint regionale (myregistry.<region>.geo.azurecr.io), comunichi direttamente con una specifica replica geografica. Se l'area diventa non disponibile, Azure Container Registry (ACR) non reindirizza automaticamente il traffico. Implementa il failover lato client passando a un altro endpoint regionale.
• Endpoint di dati dedicati — Una volta che un endpoint del registro reindirizza a un endpoint di dati dedicato per il download di un livello, si rimane sull'endpoint di dati di quella regione per tutta la durata del download. La regione viene determinata in anticipo da qualsiasi endpoint del registro che ha gestito la chiamata blob-location.

Limitazione durante il failover:

I limiti di limitazione della frequenza delle operazioni dell'API sono per replica. Durante un failover basato sullo stato di integrità, il traffico precedentemente distribuito tra più geo-repliche può concentrarsi in larga misura su quelle che rimangono nel pool di routing dell'endpoint globale. Pianificare la capacità in modo da avere almeno due o tre georepliche, affinché durante un failover il traffico possa distribuirsi tra più georepliche integre. I registri con solo due regioni possono incorrere più facilmente nei limiti di limitazione per replica quando una regione non è disponibile. Per mitigare, usa gli endpoint regionali per distribuire i carichi di lavoro tra più repliche geografiche e pianificare la capacità per replica.

Come confermare un failover:

• Azure portal: passare al Registro di sistema e selezionare Resource health nella sezione Help per visualizzare i segnali di riduzione delle prestazioni lato piattaforma.
• interfaccia della riga di comando di Azure: controllare lo stato della replica con az acr replication list --registry myregistry --output table. Le repliche geografiche che riscontrano problemi presentano uno stato diverso da online.
• Monitoraggio di Azure: le metriche della piattaforma vengono raccolte automaticamente. Abilitare Le impostazioni di diagnostica per i log delle risorse per ottenere dati di telemetria dettagliati.

Comportamento di interruzione dell'area iniziale

L'area principale è l'area in cui è stato originariamente creato il Registro di sistema. Ospita il piano di controllo del Registro di sistema, che gestisce la configurazione del Registro di sistema. L'area principale è fissa durante la creazione e non può essere modificata in seguito. Per spostare un registro in un'area home diversa, vedere Relocate Registro Azure Container, che descrive una procedura di ridistribuzione (creazione di un nuovo registro), non una modifica sul posto.

Se l'area principale non è più disponibile, l'effetto è limitato alle operazioni del piano di controllo (gestione). Tutte le operazioni del piano dati continuano a funzionare con le repliche geografiche rimanenti.

Cosa continua a funzionare durante un'interruzione della regione domestica:

• Push, pull ed eliminazione di immagini: i client possono eseguire il push, il pull e l'eliminazione di immagini da qualsiasi replica geografica disponibile usando l'endpoint globale () o qualsiasi endpoint a livello di area disponibile (myregistry.azurecr.iomyregistry.<region>.geo.azurecr.io). ACR indirizza automaticamente le richieste agli endpoint globali verso una geo-replica integra.
• Autenticazione — Tutti i metodi di autenticazione continuano a funzionare, inclusi Microsoft Entra ID, le entità servizio, le identità gestite e i token con ambito del repository. I client possono eseguire l'autenticazione a qualsiasi replica geografica disponibile senza dover modificare credenziali, token o URL del Registro di sistema.
• Consegna dei webhook: i webhook configurati per le repliche geografiche disponibili continuano ad attivarsi. Un singolo push genera eventi webhook dalla geo-replica ricevente, oltre a eventi da ciascuna geo-replica man mano che la replica viene completata. I consumer di Webhook devono essere progettati per gestire eventi multipli per ogni immagine inviata tramite push e rimuovere eventuali duplicati se necessario.
• Endpoint regionali — se gli endpoint regionali sono abilitati, continuano a funzionare in modo indipendente. I client possono comunicare direttamente con repliche geografiche specifiche usando GLI URL degli endpoint a livello di area.

Cosa non è disponibile durante un'interruzione dell'area domestica:

• Instradamento degli endpoint globali alla replica geografica dell'area home — Il rilevamento dello stato di integrità di ACR interrompe automaticamente l'instradamento del traffico degli endpoint globali verso la replica geografica dell'area home e lo reindirizza a repliche geografiche integre.
• Endpoint regionale per la regione principale — L'endpoint regionale della regione principale (myregistry.<home-region>.geo.azurecr.io) non è disponibile quando la regione principale non è disponibile. Gli endpoint a livello di area per altre repliche geografiche continuano a funzionare in modo indipendente.
• Modifiche alla configurazione del Registro di sistema : non è possibile modificare le proprietà del Registro di sistema, ad esempio regole di rete, impostazioni di replica o configurazioni della zona di disponibilità fino al ripristino dell'area principale.
• Attività del Registro Azure Container — le attività sono associate all'area iniziale e non vengono eseguite se questa non è disponibile.

Considerazioni sul livello di servizio e i limiti

Registro Azure Container livelli di servizio e limiti si applicano a ogni replica geografica in modo indipendente.

Alcuni limiti del livello di servizio hanno le considerazioni speciali seguenti:

• Limiti di archiviazione: i limiti di archiviazione per il livello di servizio vengono condivisi tra tutte le repliche geografiche. Ad esempio, se si esegue il push di un'immagine da 1 GiB e questa viene replicata in 5 georepliche, solo 1 GiB viene conteggiato ai fini dei limiti massimi di archiviazione del livello.
• Limiti di frequenza API: i limiti di limitazione delle operazioni API, ad esempio il numero di letture e scritture al minuto, sono specifici della replica geografica. Usare gli endpoint a livello di area per distribuire i carichi di lavoro tra più repliche geografiche per una migliore distribuzione della capacità ed evitare di concentrare tutto il traffico su una singola replica geografica.

Per ulteriori informazioni sui livelli di servizio e sui limiti, vedere ACR service tiers.

Considerazioni sui prezzi

• Fatturazione dell'archiviazione: l'archiviazione viene fatturata per ogni replica geografica. Ad esempio, un'immagine da 1 GiB replicata in 5 geo-repliche comporta l'addebito di 5 GiB di archiviazione (1 GiB × 5 geo-repliche).
• Trasferimento dei dati: la replica geografica può ridurre i costi abilitando push e pull di immagini nell'area, evitando addebiti per il trasferimento dei dati tra aree durante queste operazioni push o pull. Tuttavia, gli addebiti per il trasferimento dei dati tra aree continuano ad applicarsi quando ACR replica il contenuto inviato ad altre repliche geografiche nell'ambito della consistenza eventuale.

Per ulteriori informazioni, vedere Prezzi ACR.

Aggiungere o eliminare repliche geografiche

Autorizzazioni necessarie

Per gestire le repliche geografiche, la tua identità necessita di questi permessi:

Portale di Azure

1. Passare al registro nel portale di Azure.
2. In Servizi, selezionare Repliche geografiche.
3. Sulla mappa:
   • Esagono blu: area principale (in cui è stato creato il registro)
   • Esagoni verdi: aree disponibili
   • Esagoni grigi: aree non disponibili
4. Selezionare un esagono verde, quindi selezionare Crea.

interfaccia della riga di comando di 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

Per altri comandi, vedere az acr replication.

Endpoint globale di un registro con replica geografica

Dopo aver configurato la replica geografica, è possibile eseguire il push, il pull o eliminare il contenuto nel Registro di sistema tramite l'endpoint globale del Registro di sistema (myregistry.azurecr.io).

Funzionamento degli endpoint globali

Quando si esegue il push, il pull o l'eliminazione tramite l'endpoint globale, ACR indirizza la richiesta alla replica geografica con il profilo di prestazioni di rete ottimale per il client.

• La replica geografica con le migliori prestazioni di rete rispetto al client è in genere quella geograficamente più vicina.
• Tuttavia, se il client è equidistante da più repliche geografiche o la replica geografica più vicina non è disponibile, le richieste potrebbero essere instradate altrove.
• ACR gestisce questo routing. Non è possibile controllare quali repliche geografiche gestiscono una richiesta specifica.

Utilizzo dell'endpoint globale

Autenticare:

az acr login --name myregistry

Contrassegna ed effettua il push di un'immagine:

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

Scaricare un'immagine:

docker pull myregistry.azurecr.io/myapp:v1

Importare un'immagine:

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

Manifesto della distribuzione kubernetes:

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

Escludere temporaneamente una replica geografica dall'instradamento dell'endpoint globale

È possibile escludere una replica geografica dal routing dell'endpoint globale disabilitando l'impostazione --global-endpoint-routing per una replica geografica specifica. Ciò è utile per la manutenzione o la risoluzione dei problemi o quando si conosce una replica geografica specifica o Azure'area sta riscontrando una riduzione delle prestazioni. È anche possibile disabilitare il routing degli endpoint globali per la replica geografica dell'area principale. L'area principale viene usata solo per le operazioni del piano di controllo e il traffico del piano dati può essere escluso in modo sicuro dal routing globale. Per ulteriori informazioni su ciò che controlla l'area geografica home, vedere Comportamento in caso di interruzione dell'area geografica home.

• Quando l'impostazione --global-endpoint-routing per una replica geografica specifica è impostata su false, Registro Azure Container smette di instradare a una replica geografica specifica le richieste dirette all'endpoint globale.
• I dati continuano a eseguire la sincronizzazione bidirezionale con una replica geografica anche se il routing degli endpoint globali è disabilitato per tale replica geografica specifica. Ogni immagine caricata nel registro da qualsiasi area geografica, quando la replica geografica è esclusa dal routing globale, continua comunque a essere replicata su di essa. Quando si riabilita la replica geografica, è immediatamente pronto per gestire il traffico senza finestra di recupero.
• Di conseguenza, la quota di archiviazione e i costi continuano ad accumularsi per la replica geografica.
• Se gli endpoint a livello di area sono abilitati, l'URL dell'endpoint a livello di area della replica geografica (myregistry.<region-name>.geo.azurecr.io) continua a funzionare anche mentre il routing degli endpoint globali è disabilitato. --global-endpoint-routing controlla solo la partecipazione della replica geografica all'instradamento dell'endpoint globale.

# 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

Endpoint regionali di un registro con replica geografica (Anteprima)

Gli endpoint a livello di area offrono URL dedicati per ogni replica, consentendo di specificare esattamente quale replica geografica a livello di area gestisce la richiesta di push, pull o eliminazione:

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

Usare gli endpoint a livello di area quando è necessario:

Gli endpoint a livello di area coesistono con endpoint globali

L'abilitazione degli endpoint a livello di area non disabilita o sostituisce l'endpoint globale. È possibile usare entrambi contemporaneamente:

• Usare l'endpoint globale (myregistry.azurecr.io) se si preferisce il routing automatico gestito da Azure tra repliche geografiche.
• Usa endpoint regionali (myregistry.<region-name>.geo.azurecr.io) se vuoi un controllo più granulare del routing lato client, bypassando completamente il routing dell'endpoint globale gestito da Azure.

Funzionamento degli endpoint a livello di area

Gli endpoint a livello di area funzionano come server di accesso per repliche geografiche specifiche. Quando si esegue l'autenticazione e si interagisce con un endpoint a livello di area anziché con l'endpoint globale del Registro di sistema, tutte le operazioni del Registro di sistema (autenticazione, caricamenti/download degli artefatti, operazioni del repository e azioni di metadati) passano direttamente a tale replica a livello di area specifica, ignorando completamente il routing gestito Azure.

I download dei BLOB di livello (i livelli effettivi dell'immagine del contenitore) seguono comunque la configurazione esistente del registro:

• Registri senza endpoint privati o endpoint dati dedicati: quando si scaricano i layer dell'immagine da una replica geografica specifica, i download dei BLOB dei layer vengono reindirizzati agli account di archiviazione di Azure (*.blob.core.windows.net).
• Registri con endpoint privati o endpoint dati dedicati abilitati: quando si scaricano i layer di un'immagine da una specifica replica geografica, il download dei BLOB dei layer viene reindirizzato all'endpoint dati dedicato della regione corrispondente (myregistry.<region-name>.data.azurecr.io).

Il diagramma seguente illustra il flusso di richiesta dell'endpoint a livello di area:

Prerequisiti degli endpoint regionali

• SKU Premium — Gli endpoint regionali sono disponibili esclusivamente nei registri del livello Premium.
• interfaccia della riga di comando di Azure - Versione 2.86.0 o successiva. Tutti i comandi degli endpoint a livello di area (--regional-endpoints, az acr show-endpoints, az acr login --endpoint) sono disponibili in modo nativo in interfaccia della riga di comando di Azure 2.86.0+.

az extension remove --name acrregionalendpoint

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

Abilitare gli endpoint a livello di area

È possibile abilitare gli endpoint a livello di area quando si crea un nuovo registro o si aggiorna un registro esistente.

Crea un nuovo registro con gli endpoint regionali abilitati:

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

Abilitare gli endpoint a livello di area in un registro esistente:

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

Gli endpoint a livello di area sono abilitati a livello di Registro di sistema e si applicano a ogni replica geografica. Non è possibile abilitare gli endpoint a livello di area per le singole repliche. Quando si abilitano gli endpoint a livello di area, Registro Azure Container crea automaticamente gli URL del server di accesso per ognuna delle repliche geografiche.

Utilizzare gli endpoint regionali

Eseguire l'autenticazione e usare endpoint regionali

Gli endpoint a livello di area supportano gli stessi metodi di autenticazione dell'endpoint globale: Microsoft Entra ID, entità servizio, identità gestite e credenziali di amministratore.

Accedere a un endpoint regionale specifico:

az acr login --name myregistry --endpoint eastus

Taggare ed eseguire il push di un'immagine in un endpoint regionale. Le immagini e i tag inviati a una replica geografica tramite l'endpoint regionale verranno comunque propagati a tutte le altre repliche geografiche in regime di coerenza finale.

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

Recupera un'immagine da un endpoint regionale:

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

Usare gli endpoint a livello di area incorporati nei manifesti di distribuzione

È possibile specificare gli endpoint a livello di area direttamente nei manifesti della distribuzione kubernetes se è necessario aggiungere carichi di lavoro a aree specifiche. Ciò garantisce che i cluster in regioni specifiche prelevino sempre dalla replica locale, assicurando un instradamento prevedibile e una latenza ridotta.

Distribuzione del cluster East US:

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

Distribuzione del cluster nell'Europa occidentale:

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

Utilizzando endpoint regionali diversi nei file manifest di ogni cluster, puoi scegliere di fare in modo che ogni cluster effettui il pull dalla propria replica locale anziché affidarsi al routing gestito da Azure.

Per informazioni su come autenticare Servizio Azure Kubernetes (AKS) con ACR, vedere Authenticate with Registro Azure Container from servizio Azure Kubernetes.

Usare gli endpoint a livello di area con il routing basato su DNS senza modificare i manifesti di distribuzione

Se non si vogliono mantenere manifesti di distribuzione diversi per area, è possibile mantenere tutti i manifesti che puntano all'endpoint globale (myregistry.azurecr.io) e usare la rete definita dal software o un gestore traffico a livello di area per risolvere l'endpoint globale nell'endpoint a livello di area appropriato in base al traffico dell'area di origine. Questo consente di raggiungere gli stessi obiettivi di condivisione degli endpoint a livello di area (routing prevedibile e latenza ridotta) senza incorporare URL specifici dell'area nei manifesti della distribuzione.

Per informazioni su come autenticare Servizio Azure Kubernetes (AKS) con ACR, vedere Authenticate with Registro Azure Container from servizio Azure Kubernetes.

Importare da repliche geografiche specifiche usando endpoint regionali

Quando si importano immagini tra registry, è possibile usare endpoint regionali per importare da una replica geografica specifica del registry di origine. Ciò è utile per gli scenari in cui si desiderano percorsi di rete prevedibili o è necessario importare da una replica in un'area specifica.

az acr import \
  --name mydownstreamregistry \
  --source myupstreamregistry.westeurope.geo.azurecr.io/myapp:v1 \
  --image myapp:v1

Considerazioni sulla rete per gli endpoint regionali

Regole del firewall

Se si utilizzano regole del firewall di ACR o firewall personalizzati con endpoint regionali, configurare le regole del firewall per consentire l'accesso a:

Gli endpoint privati

Quando viene creato un endpoint privato per un registro all'interno di una rete virtuale, la risorsa endpoint privato espone diversi INDIRIZZI IP privati della rete virtuale che coprono tutte le superfici dell'endpoint del Registro di sistema, ovvero l'endpoint globale, ogni endpoint a livello di area (se gli endpoint a livello di area sono abilitati) e ogni endpoint dati dedicato (abilitato automaticamente quando viene configurato un endpoint privato).

Ogni endpoint consuma un indirizzo IP privato della subnet della rete virtuale. Pianifica di conseguenza il dimensionamento della subnet:

• 1 IP per l'endpoint globale (myregistry.azurecr.io)
• 1 IP per replica geografica per endpoint dati dedicati (myregistry.<region>.data.azurecr.io) - Sempre abilitato nei registri con almeno un endpoint privato
• 1 IP per replica geografica per endpoint a livello di area (myregistry.<region>.geo.azurecr.io) - solo se gli endpoint a livello di area sono abilitati

Esempio: un registro con 3 repliche geografiche ed endpoint internazionali abilitati richiede 1 (globale) + 3 (dati) + 3 (area) = 7 indirizzi IP privati per risorsa endpoint privato. Senza endpoint a livello di area, lo stesso registro richiede 1 + 3 = 4 indirizzi IP privati.

Con molte repliche geografiche, la creazione di endpoint privati può non riuscire se la subnet esaurisce gli indirizzi IP disponibili. Per altre informazioni, vedere Connettersi privatamente a un registro tramite una rete virtuale usando gli endpoint privati.

Endpoint dati dedicati

Quando gli endpoint regionali sono abilitati insieme agli endpoint dati dedicati, sia se abilitati esplicitamente sia se abilitati automaticamente quando è configurato almeno un endpoint privato, i download dei blob di livello dagli endpoint regionali vengono reindirizzati automaticamente all'endpoint dati dedicato della geo-replica (myregistry.<region-name>.data.azurecr.io). Il reindirizzamento rimane sempre all'interno della stessa area dell'endpoint a livello di area, ovvero un pull da myregistry.eastus.geo.azurecr.io reindirizza sempre a myregistry.eastus.data.azurecr.io, mai a un endpoint dati in un'area diversa.

Questa garanzia della stessa regione si applica anche quando si effettua il pull dall'endpoint globale. ACR instrada la richiesta alla replica geografica con il miglior profilo di prestazioni di rete per il client e la replica geografica che gestisce la richiesta emette un reindirizzamento 307 al proprio endpoint dati dedicato, mai tra aree geografiche.

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

Per ulteriori informazioni, vedere endpoint dati dedicati in Registro Azure Container.

Riferimento dell'endpoint

Per un riferimento completo a tutti i tipi di endpoint del registro, ai formati URL e ai flag della CLI che li controllano, vedere riferimento agli endpoint di Registro Azure Container.

Risoluzione dei problemi

Il push non riesce con errori del manifesto

Un docker push è una sequenza di richieste HTTP: caricamenti di BLOB per ciascun livello, quindi un caricamento del manifesto che fa riferimento a tali livelli tramite digest. Alcuni resolver DNS Linux non memorizzano nella cache le risposte in modo coerente. Se sono presenti più geo-repliche in aree geografiche vicine, DNS potrebbe risolversi in repliche diverse durante un singolo push (DNS bouncing), facendo sì che il manifest caricato faccia riferimento a layer caricati in una geo-replica diversa. Poiché la replica è alla fine coerente, il manifesto può atterrare su una replica che non ha ancora i livelli a cui fa riferimento e la convalida del manifesto non riesce.

Soluzioni (in ordine di preferenza):

1. Usare gli endpoint a livello di area per aggiungere il push a una singola replica geografica end-to-end. Ogni sottorichiesta (accesso, caricamenti di blob, caricamento del manifest) viene indirizzata alla stessa replica geografica. Questa è la soluzione più pulita e l'approccio consigliato per qualsiasi pipeline in cui la coerenza tra push e pull è importante.
2. Usare una cache DNS di breve durata, ad esempio dnsmasq con ambito per la durata di un singolo push. Per le macchine virtuali Linux in Azure, vedere Opzioni di risoluzione dei nomi DNS. Il pin deve durare solo per il push, non oltre: non usare una cache DNS persistente per l'endpoint globale, poiché interferisce con --global-endpoint-routing false e con l'instradamento di failover basato sullo stato di integrità.
3. Progettare le fasi di pubblicazione in modo che siano idempotenti così che i nuovi tentativi attivati da errori durante il push siano sicuri.

La creazione di repliche geografiche è bloccata per i registri abilitati agli endpoint privati

Questo problema si verifica in genere quando l'identità che crea una replica geografica per un registro abilitato per gli endpoint privati non dispone di autorizzazioni sufficienti per creare risorse di rete degli endpoint privati.

Soluzione:

• Per risolvere il problema, eliminare manualmente la replica geografica bloccata nello stato di provisioning.
• In seguito, verificare che l'identità disponga dell'autorizzazione Microsoft.Network/privateEndpoints/privateLinkServiceProxies/write prima di creare una replica geografica.
• Verificare anche che ogni subnet di endpoint privato connessa al registro disponga di indirizzi IP liberi. Se qualsiasi subnet in una qualsiasi rete virtuale connessa non dispone di indirizzi IP liberi sufficienti, il provisioning della replica ha esito negativo e viene eseguito il rollback. La replica appare brevemente in uno stato Creating e quindi viene rimossa. L'errore risultante non identifica la subnet o la rete virtuale esaurita. Per indicazioni sul ridimensionamento delle subnet, vedere Connettersi privatamente a un registro tramite endpoint privati.

Contenuti correlati

• SKU e livelli di servizio di Azure Container Registry
• Riferimento all'endpoint
• Webhook
• Endpoint privati
• Endpoint di dati dedicati
• Configurare le regole di accesso al firewall