Geo-replikering i Azure Container Registry

När du aktiverar geo-replikering för ett Azure Container Registry (ACR) skapas geo-replikresurser i valfria Azure-regioner. När du skickar avbildningar till ett geo-replikerat register synkroniseras innehållet automatiskt till alla geo-repliker.

Med geo-replikering:

• Hantera ett register: Underhålla en enda uppsättning autentiseringsuppgifter, rolltilldelningar, nätverksregler och registerkonfiguration för alla geo-repliker.
• Använd en global slutpunkt: Referens myregistry.azurecr.io/myimage:tag i alla dina byggen och distributioner. Azure dirigerar begäranden till geo-repliken med den bästa nätverksprestandaprofilen för klienten, som vanligtvis är den närmaste geo-repliken. Men om klienten är på samma avstånd från flera geo-repliker, eller om den närmaste geo-repliken inte är tillgänglig, kan förfrågningar dirigeras någon annanstans.
• Automatisk synkronisering: Dela taggar och sammandrag en gång; ACR replikerar innehåll och metadata till alla geo-replikat.

Geo-replikering kräver Premium SKU.

Överväganden för hög tillgänglighet

Replikeringsmodell

ACR geo-replikering använder en aktiv-aktiv modell.

• Alla geo-repliker är aktiva och skrivbara – du kan skicka, hämta och ta bort bilder från valfri geo-replik, inte bara hemregionens geo-replik.
• Detta skiljer sig från primär-sekundära replikeringsmodeller där endast en region accepterar skrivningar och sekundära regioner är passiva.

Konsekvensmodell

ACR använder eventuell konsistens.

• När du har push-överfört eller tagit bort en bild i en geo-replik replikerar ACR slutligen ändringen till alla geo-repliker i bakgrunden.
• Replikeringstiden beror på bildens storlek. En bild eller tagg som har pushats kanske inte omedelbart är tillgänglig för pullning från andra geografiska repliker om stora mängder bilder pushas eller om bilderna är stora. På samma sätt kan en borttagen bild eller tagg fortfarande vara tillgänglig för att hämta andra geo-repliker tills borttagningen sprids.
• Den tid det tar att skapa en ny georeplik ökar med registrets totala storlek. När du skapar en ny geo-replik fortsätter befintliga geo-repliker att hantera push-, pull- och borttagningstrafik normalt. Det finns inget begränsat läge eller någon period med försämrad prestanda medan den nya geo-repliken hinner ikapp i bakgrunden.
• Tills replikeringen slutligen slutförs i bakgrunden kanske en geo-replik inte har det senaste innehållet eller metadata. Du kan använda webhooks för att ta emot meddelanden när replikeringen för en specifik push-avbildning slutförs i varje geo-replik.

Hög tillgänglighet för dataplan

Geo-replikering förbättrar tillgängligheten för dataplanet genom att behålla bilder i flera regioner. Om en region drabbas av ett avbrott förblir avbildningar tillgängliga från andra geo-repliker – push, pull och borttagning fortsätter att fungera via de återstående geo-replikerna.

Zonredundans är alltid aktiverat för geo-repliker – ACR sprider automatiskt replikdata över flera tillgänglighetszoner för att skydda mot zonindelat avbrott.

Hälsomedveten redundans

ACR övervakar automatiskt hälsotillståndet för varje geo-replik och omdirigerar global slutpunktstrafik bort från geo-repliker som inte kan hantera begäranden på ett tillförlitligt sätt. Detta kallas hälsomedveten redundansväxling. ACR dirigerar global slutpunktstrafik baserat på ACR-tjänstens hälsa och Azure regional infrastrukturhälsa.

• Automatisk och per register: Hälsotillstånd utvärderas per register, inte per region. Om en försämring endast påverkar en delmängd av register i en region omdirigeras endast dessa register – andra register i samma region fortsätter att hanteras lokalt utan onödiga svarstidsstraff.
• Timing: Omroutning från ände till ände sker i storleksordningen minuter, tillräckligt snabbt för att upptäcka verklig regional degradering och tillräckligt långsamt för att stå emot tillfälliga fel som löser sig av sig själva. DNS TTL kan lägga till spridningsfördröjning innan alla klienter växlar till den nya regionen.
• Ingen kundåtgärd krävs: Det finns ingen utlösare som kan anropas av kunden. Hälsomedveten redundansväxling är helt plattformshanterad.
• Failback är automatisk: När en geo-replikas regionala hälsoutvärdering godkänns igen, till exempel efter att regional ACR eller Azure-infrastruktur har återställts, kan den globala slutpunkten återuppta routningen av trafik till geo-replikan i den återställda Azure-regionen.
• Påverkas inte av strypning: Hälsobaserad redundansväxling är DNS-baserad och reagerar på den regionala ACR-tjänstens hälsa och hälsan i Azure-infrastrukturen. Den omdirigerar inte trafiken baserat på HTTP 429-svar (begränsning av begärandefrekvens). Om en geo-replika begränsar dina förfrågningar men regionens infrastruktur fungerar som den ska, fortsätter den globala slutpunkten att dirigera trafiken till den geo-replikan. För att hantera begränsning använder du regionala slutpunkter för att sprida arbetsbelastningen över flera georepliker för bättre kapacitetsfördelning.

Omfång för hälsomedveten redundans:

Hälsomedveten redundans gäller endast åtgärder mot den globala slutpunkten (myregistry.azurecr.io). Den gäller inte för:

• Regionala slutpunkter – När du använder en regional slutpunkt (myregistry.<region>.geo.azurecr.io) pratar du direkt med en specifik geo-replik. Om den regionen försämras omdirigeras inte ACR automatiskt. Implementera redundans på klientsidan genom att växla till en annan regional slutpunkt.
• Dedikerade dataslutpunkter – När en registerslutpunkt omdirigerar dig till en dedikerad dataslutpunkt för en skiktnedladdning stannar du kvar på regionens dataslutpunkt under nedladdningen. Regionen avgörs på förhand av den registerslutpunkt som besvarade anropet om blobbplats.

Begränsning vid växling vid fel:

Strypningsgränser för API-åtgärder gäller per replik. Vid en hälsobaserad redundansväxling kan trafik som var fördelad över flera geo-repliker skifta kraftigt till de geo-repliker som finns kvar i den globala slutpunktens routningspool. Kapacitetsplanera för att ha minst två eller tre geo-repliker så att trafiken kan fördelas över flera fungerande geo-repliker vid en redundansväxling. Register med endast två regioner kan lättare nå strypningsgränser per replik om en region blir otillgänglig. För att minska detta använder du regionala slutpunkter för att sprida arbetsbelastningar över flera georepliker och planera kapaciteten för varje replik.

Så här bekräftar du en redundansomkoppling:

• Azure portal: Navigera till registret och välj Resource health under avsnittet Help för att se nedbrytningssignaler på plattformssidan.
• Azure CLI: Kontrollera replikeringsstatus med az acr replication list --registry myregistry --output table. Geo-repliker som upplever problem visar en annan status än online.
• Azure Monitor: Plattformsmått samlas in automatiskt. Aktivera Diagnostikinställningar för resursloggar för att få detaljerad telemetri.

Avbrottsbeteende i hemregion

Hemregionen är den region där du ursprungligen skapade registret. Det är värd för registrets kontrollplan, som hanterar registerkonfigurationen. Hemregionen är fast när den skapas och kan inte ändras efteråt. Information om hur du flyttar ett register till en annan hemregion finns i Allokera Azure Container Registry, som beskriver en omdistributionsprocedur (skapa ett nytt register), inte en ändring på plats.

Om hemregionen blir otillgänglig begränsas effekten till kontrollplansåtgärder (hantering). Alla dataplanoperationer fortsätter att fungera genom de återstående geo-replikerna.

Vad fortsätter att fungera under ett avbrott i hemregionen:

• Överföra, hämta och ta bort bilder — Klienter kan överföra, hämta och ta bort bilder från valfri tillgänglig georeplik med hjälp av den globala slutpunkten (myregistry.azurecr.io) eller valfri tillgänglig regional slutpunkt (myregistry.<region>.geo.azurecr.io). ACR dirigerar automatiskt globala slutpunktsbegäranden till en felfri geo-replik.
• Authentication — Alla autentiseringsmetoder fortsätter att fungera, inklusive Microsoft Entra ID, tjänsthuvudnamn, hanterade identiteter och databaslagerspecifika token. Klienter kan autentisera till alla tillgängliga geo-repliker utan att behöva ändra autentiseringsuppgifter, token eller register-URL:er.
• Webhook-leverans – Webhooks som konfigurerats för tillgängliga geografiska repliker fortsätter att aktiveras. En enda push-överföring resulterar i webhook-händelser från den mottagande geo-repliken plus händelser från varje geo-replik när replikeringen slutförs. Webhook-konsumenter bör utformas för att hantera flera händelser per push-överförd bild och deduplicera efter behov.
• Regionala slutpunkter – Om regionala slutpunkter är aktiverade fortsätter de att arbeta oberoende av varandra. Klienter kan kommunicera direkt med specifika geo-repliker med hjälp av regionala slutpunkts-URL:er.

Vad är otillgängligt under ett avbrott i hemregionen:

• Global slutpunktsroutning till hemregionens geo-replik – ACR:s hälsoidentifiering stoppar automatiskt routning av global slutpunktstrafik till hemregionens geo-replik och omdirigerar den till felfria geo-repliker.
• Regional ändpunkt för hemregionen — Hemregionens regionala ändpunkt (myregistry.<home-region>.geo.azurecr.io) är inte tillgänglig när hemregionen ligger nere. Regionala slutpunkter för andra geo-repliker fortsätter att fungera oberoende av varandra.
• Ändringar i registerkonfiguration – Du kan inte ändra registeregenskaper som nätverksregler, replikeringsinställningar eller konfigurationer av tillgänglighetszoner förrän hemregionen återställs.
• ACR-uppgifter – Aktiviteter är bundna till hemregionen och körs inte när de inte är tillgängliga.

Överväganden för tjänstnivå och gränser

Azure Container Registrys tjänstskikt och gränser gäller för varje georeplik oberoende av varandra.

Vissa gränser för tjänstnivå har följande särskilda överväganden:

• Lagringsgränser: Lagringsgränserna för din tjänstnivå är gemensamma för alla geografiska repliker. Om du till exempel pushar upp en avbild på 1 GiB och den replikeras till 5 geo-repliker, räknas endast 1 GiB mot den maximala lagringsgränsen för din nivå.
• API-hastighetsgränser: Begränsningsgränser för API-åtgärder, till exempel antalet läsningar och skrivningar per minut, är geo-replikspecifika. Använd regionala slutpunkter för att sprida arbetsbelastningar över flera geo-repliker för bättre kapacitetsdistribution och för att undvika att all trafik koncentreras på en enda geo-replik.

Mer information om tjänstnivåer och gränser finns i ACR-tjänstnivåer.

Överväganden för prissättning

• Debitering för lagring: Lagring debiteras per georeplika. Till exempel debiteras en 1 GiB-avbildning som replikeras till 5 geo-repliker som 5 GiB-lagring (1 GiB-× 5 geo-repliker).
• Dataöverföring: Geo-replikering kan minska kostnaderna genom att möjliggöra pushar och hämtningar av avbildningar inom regionen, vilket undviker avgifter för dataöverföring mellan regioner vid dessa push- eller hämtningsåtgärder. Avgifter för dataöverföring mellan regioner gäller dock fortfarande när ACR replikerar innehåll som överförts genom push till andra geografiska repliker inom ramen för eventuell konsistens.

Mer information finns i ACR-priser.

Lägga till eller ta bort geo-repliker

Privilegier som krävs

För att hantera geo-repliker behöver din identitet följande behörigheter:

Azure Portal

1. Gå till registret i Azure-portalen.
2. Under tjänster väljer du Geo-replikeringar.
3. På kartan:
   • Blå sexhörning: Hemregion (där du skapade registret)
   • Gröna sexhörningar: Tillgängliga regioner
   • Grå sexhörningar: Otillgängliga regioner
4. Välj en grön sexhörning och välj sedan Skapa.

Azure CLI (kommandoradsgränssnittet för 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

För fler kommandon, se az acr replication.

Global slutpunkt för ett geo-replikerat register

När du har konfigurerat geo-replikering kan du skicka, hämta eller ta bort innehåll i registret via registrets globala slutpunkt (myregistry.azurecr.io).

Så här fungerar globala slutpunkter

När du skickar, hämtar eller tar bort via den globala slutpunkten dirigerar ACR begäran till den georeplik som har bäst nätverksprestandaprofil för klienten.

• Geo-repliken med bäst nätverksprestanda sett från klienten är vanligtvis den närmaste geo-repliken.
• Men om klienten är på samma avstånd från flera geo-repliker, eller om den närmaste geo-repliken inte är tillgänglig, kan förfrågningar dirigeras någon annanstans.
• ACR hanterar den här routningen. Du styr inte vilken geo-replik som hanterar en specifik begäran.

Använda den globala slutpunkten

Autentisera:

az acr login --name myregistry

Tagga och överför en avbild:

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

Hämta en bild:

docker pull myregistry.azurecr.io/myapp:v1

Importera en avbildning:

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

Kubernetes-driftsättningsmanifest:

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

Undanta tillfälligt en geo-replik från global slutpunktsroutning

Du kan undanta en geo-replik från global slutpunktsroutning genom att inaktivera --global-endpoint-routing inställningen för en specifik geo-replik. Detta är användbart för underhåll eller felsökning, eller när du vet att en specifik geo-replik eller Azure region upplever försämring. Du kan till och med inaktivera global slutpunktsroutning för hemregionens geo-replik – hemregionen används bara för kontrollplansåtgärder och dess dataplanstrafik kan på ett säkert sätt undantas från global routning. Mer information om vad hemregionen styr finns i Beteende för avbrott i hemregionen.

• --global-endpoint-routing När inställningen för en specifik geo-replik är inställd på falseslutar ACR att dirigera begäranden till den specifika geo-repliken för begäranden som går till den globala slutpunkten.
• Data fortsätter att synkroniseras dubbelriktat med en geo-replik även om global slutpunktsroutning är inaktiverad för den specifika geo-repliken. Varje avbildning som skickas till registret från valfri region medan geo-repliken undantas från global routning replikeras fortfarande till den. När du återaktiverar geo-repliken är den omedelbart redo att hantera trafik utan något upphämtningsfönster.
• Därför fortsätter lagringskvoten och kostnaderna att ackumuleras för det geo-replikatet.
• Om regionala slutpunkter är aktiverade fortsätter geo-replikens regionala slutpunkts-URL (myregistry.<region-name>.geo.azurecr.io) att fungera även när global slutpunktsroutning är inaktiverad. --global-endpoint-routing styr endast geo-replikens deltagande i global slutpunktsroutning.

# 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

Regionala slutpunkter för ett geo-replikerat register (förhandsversion)

Regionala slutpunkter ger dig dedikerade URL:er för varje replik, så att du kan ange exakt vilken regional geo-replik som hanterar din push-, pull- eller borttagningsbegäran:

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

Använd regionala slutpunkter när du behöver:

Regionala slutpunkter samexisterar med globala slutpunkter

Om du aktiverar regionala slutpunkter inaktiveras eller ersätts inte den globala slutpunkten. Du kan använda båda samtidigt:

• Använd global slutpunkt (myregistry.azurecr.io) om du föredrar automatisk routning som hanteras av Azure över geo-repliker.
• Använd regionala slutpunkter (myregistry.<region-name>.geo.azurecr.io) om du vill ha en finare routningskontroll på klientsidan och kringgå Azure hanterad routning av den globala slutpunkten helt.

Så här fungerar regionala slutpunkter

Regionala slutpunkter fungerar som inloggningsservrar för specifika geo-repliker. När du autentiserar och interagerar med en regional slutpunkt i stället för registrets globala slutpunkt, går alla registeråtgärder (autentisering, artefaktuppladdningar/nedladdningar, lagringsplatsåtgärder och metadataåtgärder) direkt till den specifika regionala repliken och kringgår Azure hanterad routning helt.

Lagringsblobnedladdningar (de faktiska behållaravbildningsskikten) följer fortfarande registrets befintliga konfiguration:

• Register utan privata slutpunkter eller dedikerade dataslutpunkter: När du laddar ned bildlager från en specifik geo-replik omdirigerar hämtningar av lagerblobar till Azure lagringskonton (*.blob.core.windows.net).
• Register med privata slutpunkter eller dedikerade dataslutpunkter aktiverade: När du laddar ned bildlager från en specifik geo-replik omdirigeras hämtningar av lagerblob till motsvarande regions dedikerade dataslutpunkt (myregistry.<region-name>.data.azurecr.io).

Följande diagram illustrerar det regionala flödet för slutpunktsbegäran:

Krav för regionala slutpunkter

• Premium SKU – Regionala slutpunkter är endast tillgängliga på Premium-nivåregister .
• Azure CLI – version 2.86.0 eller senare. Alla regionala slutpunktskommandon (--regional-endpoints, az acr show-endpoints, az acr login --endpoint) är tillgängliga internt i Azure CLI 2.86.0+.

az extension remove --name acrregionalendpoint

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

Aktivera regionala slutpunkter

Du kan aktivera regionala slutpunkter när du skapar ett nytt register eller uppdaterar ett befintligt register.

Skapa ett nytt register med regionala slutpunkter aktiverade:

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

Aktivera regionala slutpunkter i ett befintligt register:

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

Regionala slutpunkter aktiveras på registernivå och gäller för varje geo-replik. Du kan inte aktivera regionala slutpunkter för enskilda repliker. När du aktiverar regionala slutpunkter skapar Azure Container Registry automatiskt inloggningsserver-URL:er för var och en av dina geo-repliker.

Arbeta med regionala slutpunkter

Autentisera och använda regionala slutpunkter

Regionala slutpunkter stöder samma autentiseringsmetoder som den globala slutpunkten: Microsoft Entra ID, tjänstens huvudnamn, hanterade identiteter och administratörsautentiseringsuppgifter.

Logga in på en specifik regional ändpunkt:

az acr login --name myregistry --endpoint eastus

Tagga och pusha en image till en regional ändpunkt. Bilder och taggar som pushas till en georeplik via den regionala slutpunkten kommer fortfarande att propageras vidare till alla övriga georepliker med eventualkonsistens.

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

Hämta en avbildning från en regional slutpunkt:

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

Använda regionala slutpunkter med AKS-hanterad identitetsautentisering

Avbildningshämtningar i AKS som autentiseras mot ACR med en hanterad identitet har stöd för regionala slutpunkter i AKS-nodavbildning 202607.29 eller senare. Kontrollera den aktuella avbildningen för varje nodpool:

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

Om du vill ta emot en kompatibel VHD för nodavbildning automatiskt när den blir tillgänglig i din region och ditt moln använder du NodeImage den automatiska uppgraderingskanalen för nodens operativsystem. AKS Automatic uses NodeImage; för AKS Standard väljer du NodeImage.

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

För AKS-noder som kör en äldre nodavbild använder du en Kubernetes-image pull secret när du hämtar avbildningar från regionala slutpunkter, eller använder den globala slutpunkten (<registry-name>.azurecr.io) i stället.

Använda regionala slutpunkter inbäddade i distributionsmanifest

Du kan ange regionala slutpunkter direkt i Kubernetes-distributionsmanifest om du behöver fästa arbetsbelastningar i specifika regioner. Detta säkerställer att kluster i specifika regioner alltid hämtar från sin samlokaliserade replik, vilket ger förutsägbar routning och kortare svarstid.

Klusterdriftsättning i 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

Klusterdistribution i Västeuropa:

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

Genom att använda olika regionala slutpunkter i varje klusters manifest kan du välja att garantera att varje kluster hämtar från sin lokala replik i stället för att förlita sig på Azure hanterad routning.

Information om hur du autentiserar Azure Kubernetes Service (AKS) med ACR finns i Autentisera med Azure Container Registry från Azure Kubernetes Service.

Använda regionala slutpunkter med DNS-baserad routning utan att ändra distributionsmanifest

Om du inte vill underhålla olika distributionsmanifest per region kan du behålla alla manifest som pekar på den globala slutpunkten (myregistry.azurecr.io) och använda programvarudefinierade nätverk eller en regional trafikhanterare för att matcha den globala slutpunkten till lämplig regional slutpunkt baserat på den ursprungliga regionens trafik. Detta uppnår samma samlokaliseringsmål som regionala slutpunkter (förutsägbar routning och kortare svarstid) utan att bädda in regionspecifika URL:er i distributionsmanifesten.

Information om hur du autentiserar Azure Kubernetes Service (AKS) med ACR finns i Autentisera med Azure Container Registry från Azure Kubernetes Service.

Importera från specifika geo-repliker med hjälp av regionala slutpunkter

Azure Container Registry stöder import av avbildningar från en mängd olika källregister mellan molnleverantörer. Om importkällan är en ACR kan du endast importera från käll-ACR:ns hemregion. Käll-ACR:s regionala slutpunkter stöds inte som importkällor. Ange källans globala slutpunkt för ACR när du importerar från en käll-ACR. Dessutom skriver en import alltid innehåll till den underordnade ACR-hemregionen. Se referens för slutpunkt i Azure Container Registry.

Nätverksöverväganden för regionala slutpunkter

Brandväggsregler

Om du använder ACR-brandväggsregler eller anpassade brandväggar med regionala slutpunkter konfigurerar du brandväggsreglerna för att tillåta åtkomst till:

Privata slutpunkter

När en privat slutpunkt skapas för ett register i ett virtuellt nätverk exponerar den privata slutpunktsresursen flera privata IP-adresser för virtuella nätverk som täcker alla registrets slutpunktsytor – den globala slutpunkten, varje regional slutpunkt (om regionala slutpunkter är aktiverade) och varje dedikerad dataslutpunkt (aktiveras automatiskt när en privat slutpunkt konfigureras).

Varje slutpunktsyta förbrukar en privat IP-adress från det virtuella nätverkets undernät. Planera storleksändringen för undernätet i enlighet med detta:

• 1 IP-adress för den globala slutpunkten (myregistry.azurecr.io)
• 1 IP per georeplika för dedikerade dataslutpunkter (myregistry.<region>.data.azurecr.io) – alltid aktiverat på register med minst en privat slutpunkt
• 1 IP per georeplik för regionala ändpunkter (myregistry.<region>.geo.azurecr.io) – endast om regionala ändpunkter är aktiverade

Exempel: Ett register med 3 geo-repliker och regionala slutpunkter aktiverade kräver 1 (global) + 3 (data) + 3 (regional) = 7 privata IP-adresser per privat slutpunktsresurs. Utan regionala slutpunkter kräver samma register 1 + 3 = 4 privata IP-adresser.

Med många geo-repliker kan skapande av privata slutpunkter misslyckas om undernätet får slut på tillgängliga IP-adresser. Mer information finns i Ansluta privat till ett register från ett virtuellt nätverk med privata slutpunkter.

Dedikerade dataslutpunkter

När regionala slutpunkter aktiveras tillsammans med dedikerade dataslutpunkter – antingen explicit aktiverade eller automatiskt aktiverade genom att minst en privat slutpunkt har konfigurerats – omdirigerar skiktblobhämtningar från regionala slutpunkter automatiskt till geo-replikens dedikerade dataslutpunkt (myregistry.<region-name>.data.azurecr.io). Omdirigeringen sker alltid inom samma region som den regionala slutpunkten – en hämtning från myregistry.eastus.geo.azurecr.io omdirigeras alltid till myregistry.eastus.data.azurecr.io, aldrig till en dataslutpunkt i en annan region.

Den här garantin om samma region gäller även när du hämtar från den globala slutpunkten. ACR dirigerar begäran till den geo-replik som har bäst nätverksprestanda för klienten, och geo-repliken som hanterar begäran skickar en 307-omdirigering till sin egen dedikerade dataändpunkt – aldrig över regionsgränser.

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

Mer information finns i Dedicerade dataslutpunkter i Azure Container Registry.

Referens för slutpunkt

En fullständig referens för alla typer av registerslutpunkter, URL-format och CLI-flaggor som styr dem finns i Azure Container Registry slutpunktsreferens.

Felsökning

Push misslyckas med manifestfel

En docker push är en sekvens av HTTP-begäranden: uppladdning av blobbar för varje lager, följt av uppladdning av ett manifest som hänvisar till dessa lager med digest. Vissa Linux-DNS-resolvers cachelagrar inte svar konsekvent. Om det finns flera geo-repliker i närliggande regioner kan DNS peka på olika repliker under en och samma pushning (DNS-hoppande), vilket gör att det pushade manifestet refererar till lager som pushades till en annan geo-replik. Eftersom replikeringen så småningom är konsekvent kan manifestet landa på en replik som ännu inte har de lager som den refererar till, och manifestverifieringen misslyckas.

Lösningar (i prioritetsordning):

1. Använd regionala ändpunkter för att styra pushen till en enda geografisk replik hela vägen. Varje delbegäran (inloggning, blobuppladdningar, manifestuppladdning) skickas till samma georeplik. Det här är den bästa lösningen och det rekommenderade tillvägagångssättet för alla pipelines där konsekvens mellan push och pull är viktig.
2. Använda en kortlivad DNS-cache som dnsmasq begränsad till varaktigheten för en enda push-överföring. För Linux-virtuella datorer i Azure, se alternativ för DNS-namnuppslagning. Bindningen bör bara gälla under pushen och inte längre än så – använd inte en DNS-cache med lång livslängd för den globala slutpunkten, eftersom den stör --global-endpoint-routing false och failover-routning som tar hänsyn till hälsostatus.
3. Utforma publiceringssteg så att de är idempotenta så att återförsök som utlöses av fel mitt under en push kan göras säkert.

Skapandet av geo-repliker har fastnat för register med aktiverade privata slutpunkter

Det här problemet uppstår vanligtvis när identiteten som skapar en geo-replik för ett privat slutpunktsaktiverat register inte har tillräcklig behörighet för att skapa privata slutpunktsnätverksresurser.

Lösning:

• För att lösa problemet, ta manuellt bort geo-repliken som fastnade i tillståndet för provisionering.
• Därefter kontrollerar du att identiteten har behörigheten Microsoft.Network/privateEndpoints/privateLinkServiceProxies/write innan du skapar en geo-replik.
• Kontrollera också att varje privat slutpunktsundernät som är anslutet till registret har kostnadsfri IP-kapacitet. Om något undernät i något anslutet virtuellt nätverk inte har tillräckligt med lediga IP-adresser, misslyckas etableringen av replikeringen och rullas tillbaka. Repliken visas kort i ett Creating tillstånd och tas sedan bort. Det resulterande felet identifierar inte vilket undernät eller virtuellt nätverk som är uttömt. Vägledning för storleksändring för undernät finns i Ansluta privat till ett register med hjälp av privata slutpunkter.

Det går inte att skapa geo-repliker i register med en privat slutpunkt för statisk IP-adress

Det går inte att lägga till en geo-replik när registrets privata slutpunkt konfigureras med statisk privat IP-allokering.

Varje geo-replik har en egen dedikerad dataslutpunkt som exponeras på den privata slutpunkten som medlem med grupp-ID:t registry och ett medlemsnamn för registry_data_<region>. När du lägger till en ny georeplika begär ACR att den privata slutpunkten lägger till medlemmen för den nya regionens dataslutpunkt. En privat slutpunkt som konfigurerats med dynamisk IP-allokering etablerar den nya medlemmens IP-adress automatiskt. En privat slutpunkt som konfigurerats med statisk IP-allokering har en fast uppsättning IP-konfigurationer som definierats vid skapandetillfället och lägger inte till den nya medlemmen automatiskt, så replikskapandet misslyckas med ett fel som liknar:

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.

Om du vill kontrollera allokeringsmetoden för ett registers privata slutpunkt kontrollerar du PrivateIPAllocationMethod IP-konfigurationerna i den privata slutpunktens nätverksgränssnitt. Den privata slutpunkten refererar till ett nätverksgränssnitt som innehåller dessa IP-konfigurationer, så först hämtar du nätverksgränssnitts-ID:t och kontrollerar sedan dess IP-konfigurationer:

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

Lösningar:

• Använd dynamisk IP-allokering för den privata slutpunkten om du förväntar dig att lägga till geo-repliker senare. Med dynamisk allokering etablerar ACR dataslutpunktsmedlemmen för varje ny region automatiskt. Det här är den rekommenderade metoden.
• Skapa den privata slutpunkten när alla geo-repliker finns om statisk IP-allokering krävs. Lägg till varje geo-replik först och skapa sedan den statiska privata IP-slutpunkten så att ip-konfigurationen innehåller en medlem för varje befintlig regions dataslutpunkt. När en privat slutpunkt för statisk IP har skapats på det här sättet kan du inte lägga till ytterligare geo-repliker utan att konfigurera om den privata slutpunkten för att lägga till den nya medlemmen.

Relaterat innehåll

• ACR-SKU:er och tjänstnivåer
• Slutpunktsreferens
• Webhooks
• Privata slutpunkter
• Dedikerade dataslutpunkter
• Konfigurera åtkomstregler för brandvägg