Geografická replikace ve službě Azure Container Registry

Povolení geografické replikace pro Službu Azure Container Registry (ACR) vytváří prostředky geografické repliky v oblastech Azure podle vašeho výběru. Když nahrajete image do registru s geografickou replikací, obsah se automaticky synchronizuje se všemi georeplikami.

S geografickou replikací:

  • Správa jednoho registru: Udržujte jednu sadu přihlašovacích údajů, přiřazení rolí, síťová pravidla a konfiguraci registru ve všech geografických replikách.
  • Použijte jeden globální koncový bod: Odkazujte myregistry.azurecr.io/myimage:tag ve všech sestaveních a nasazeních. Azure směruje požadavky na geografickou repliku s nejlepším profilem výkonu sítě pro klienta, což je obvykle nejbližší geografická replika. Pokud je však klient ve stejné vzdálenosti od více geografických replik nebo nejbližší geografická replika není k dispozici, požadavky mohou být směrovány jinam.
  • Automatická synchronizace: Odesílání značek a hash souhrnů jednou; ACR replikuje obsah a metadata do všech geo-replik.

Geografická replikace vyžaduje skladovou položku Premium.

Poznámka:

Úvahy o vysoké dostupnosti

Model replikace

ACR používá geografickou replikaci s modelem aktivní-aktivní.

  • Všechny geografické repliky jsou aktivní a zapisovatelné – můžete odesílat, stahovat a odstraňovat image z jakékoli geografické repliky, nejen z domovské oblasti geografické repliky.
  • To se liší od modelů replikace primární-sekundární, kde pouze jedna oblast přijímá zápisy a sekundární oblasti jsou pasivní.

Model konzistence

ACR používá eventuální konzistenci.

  • Po nahrání nebo odstranění bitové kopie v kterékoli geografické replice služba ACR nakonec tuto změnu replikuje na pozadí do všech geografických replik.
  • Doba replikace závisí na velikosti image. Nahraná image nebo značka nemusí být v jiných geografických replikách okamžitě k dispozici ke stažení, pokud se nahraje velké množství imagí nebo image o velké velikosti. Podobně může být odstraněná image nebo značka stále k dispozici pro vyžádání dalších geografických replik, dokud se odstranění nešíší.
  • Doba potřebná k vytvoření nové geografické repliky závisí na celkové velikosti registru. Při vytváření nové geografické repliky stávající geografické repliky nadále normálně obsluhují provoz operací push, pull a delete. Když se nová geografická replika průběžně synchronizuje na pozadí, nedochází k omezenému režimu ani k období sníženého výkonu.
  • Dokud se replikace nakonec nedokončí na pozadí, nemusí mít geografická replika nejnovější obsah ani metadata. Webhooky můžete použít k příjmu oznámení, když se replikace konkrétní nabízené image dokončí v každé geografické replice.

Important

Scénáře selhání eventuální konzistence, se kterými je třeba počítat:

  • Push-then-immediate-pull-cross-region – Nahrání image do jedné geografické repliky a její okamžité stažení z jiné geografické repliky může selhat s chybou manifest unknown, dokud se replikace nedoběhne. To běžně ovlivňuje CI/CD pipeline, kde CI runner nahraje image kontejneru a pody ve více regionech se ji okamžitě pokusí stáhnout.
  • Kolize při přepisování tagů — Nahrání myapp:v1 a následné opětovné nahrání myapp:v1 krátce poté s jiným digestem (stejný tag, jiný obsah) může způsobit, že různé geografické repliky budou během replikačního okna vyhodnocovat tentýž tag na různé digesty.
  • Odstranění šíření – Rozšíření značky nebo úložiště v jedné oblasti nějakou dobu trvá. Načítá z geografických replik, u kterých se odstranění ještě nerozšírovalo, stále může vrátit odstraněný obsah.
  • Rozptýlení při převzetí služeb při selhání uprostřed odesílání — Vícevrstvé odesílání, které překračuje hranici převzetí služeb při selhání řízeného podle stavu nebo během něj dojde k přepnutí DNS, může uložit vrstvy na jednu geografickou repliku a manifest na jinou, což se při následných staženích projeví jako chyby ověření manifestu nebo blob unknown. Viz Selhání push operace kvůli chybám manifestu, kde najdete postupy nápravy.

Zmírnění rizik:

  • Do stahování, která bezprostředně následují po nahrání do jiné oblasti, zahrňte logiku opakování pokusů — buď opakujte pokus s prodlužující se prodlevou, nebo před stažením zkontrolujte stav replikace.
  • Pomocí webhooků můžete dostávat oznámení po dokončení replikace v každé geografické replice před aktivací vyžádání mezi oblastmi.

Vysoká dostupnost datové roviny

Geografická replikace zlepšuje dostupnost roviny dat udržováním imagí v několika oblastech. Pokud dojde k výpadku v jedné oblasti, image zůstanou přístupné z ostatních geo-replik – nahrávání, stahování i odstraňování budou nadále fungovat prostřednictvím zbývajících geo-replik.

Redundance zón je vždy povolená pro geografické repliky – ACR automaticky rozloží data repliky do několika zón dostupnosti, aby se chránila před výpadky zón.

Poznámka:

Pokud váš registr používá klíč spravovaný zákazníkem, seznamte se s pokyny k převzetí služeb při selhání a redundanci trezoru klíčů, abyste zajistili maximální odolnost.

Převzetí při selhání na základě stavu

Služba ACR automaticky monitoruje stav každé geografické repliky a přesměrovává provoz globálního koncového bodu od geografických replik, které nemohou spolehlivě obsluhovat požadavky. Tomu se říká přepnutí při selhání s ohledem na stav. ACR směruje provoz globálních koncových bodů na základě stavu služby ACR a stavu regionální infrastruktury Azure.

  • Automatické a podle registru: Stav se vyhodnocuje podle jednotlivých registrů, nikoli podle oblasti. Pokud snížení výkonu ovlivní pouze podmnožinu registrů v oblasti, přesměrují se pouze tyto registry – ostatní registry ve stejné oblasti se budou dál obsluhovat místně bez zbytečné latence.
  • Čas: Kompletní přesměrování provozu trvá řádově minuty, což je dostatečně rychlé na zachycení skutečného zhoršení výkonu v regionu a zároveň dostatečně pomalé na to, aby překlenulo přechodné chyby, které se samy vyřeší. Hodnota DNS TTL může způsobit prodlevu při propagaci, než se všichni klienti přepnou do nového regionu.
  • Nevyžaduje se žádná akce zákazníka: Neexistuje žádná aktivační událost, která by byla vyvoláná zákazníkem. Převzetí služeb při selhání s ohledem na stav je plně spravováno platformou.
  • Návrat po přepnutí je automatický: Jakmile regionální kontrola stavu georepliky znovu proběhne úspěšně, například po obnovení regionální služby ACR nebo infrastruktury Azure, může globální koncový bod znovu směrovat provoz na georepliku v obnovené oblasti Azure.
  • Není vyvoláno omezováním: Převzetí služeb při selhání zohledňující stav je založeno na DNS a reaguje na regionální stav služby ACR a stav infrastruktury Azure. Nepřesměrovává provoz na základě odpovědí HTTP 429 (omezování). Pokud georeplika omezuje vaše požadavky, ale infrastruktura oblasti je v pořádku, globální koncový bod vás bude i nadále směrovat do této georepliky. Při řízení omezování použijte regionální koncové body k rozložení úloh napříč více geografickými replikami pro lepší rozložení kapacity.

Rozsah převzetí služeb při selhání se zohledněním stavu:

Převzetí služeb při selhání na základě stavu platí pouze pro operace vůči globálnímu koncovému bodu (myregistry.azurecr.io). Nevztahuje se na:

  • Regionální koncové body – Když používáte regionální koncový bod (myregistry.<region>.geo.azurecr.io), mluvíte přímo s jednou konkrétní geografickou replikou. Pokud dojde ke zhoršení této oblasti, ACR se automaticky nepřesměruje. Zajistěte přepnutí při selhání na straně klienta přepnutím na jiný regionální koncový bod.
  • Vyhrazené koncové body dat – Jakmile vás koncový bod registru přesměruje na vyhrazený koncový bod dat ke stažení vrstvy, zůstanete na koncovém bodu dat dané oblasti během stahování. Region je předem určen tím koncovým bodem registru, který zpracoval volání blob-location.

Omezování během přepnutí při selhání:

Limity omezování operací rozhraní API jsou pro jednotlivé repliky. Během převzetí služeb při selhání na základě stavu služby se může provoz, který byl rozložen mezi více geografických replik, ve velké míře přesunout na ty geografické repliky, které zůstanou ve směrovacím fondu globálního koncového bodu. Kapacitu naplánujte tak, abyste měli alespoň dvě nebo tři geografické repliky, aby se provoz při převzetí služeb při selhání mohl rozložit mezi několik funkčních geografických replik. Registry s pouze dvěma oblastmi můžou snadněji dosáhnout limitů omezování pro jednotlivé repliky, pokud jedna oblast není dostupná. Pokud chcete zmírnit omezení, použijte regionální koncové body k rozložení úloh mezi několik geografických replik a naplánujte kapacitu jednotlivých replik.

Jak potvrdit přepnutí při selhání:

  • Azure portal: Přejděte do registru a vyberte Zdrojový stav v části Help a podívejte se na signály snížení výkonu na straně platformy.
  • Azure CLI: Zkontrolujte stav replikace pomocí az acr replication list --registry myregistry --output table. U geografických replik, u kterých dochází k problémům, se zobrazuje jiný stav než online.
  • Azure Monitor: Metriky platformy se shromažďují automaticky. Pokud chcete získat podrobnou telemetrii, povolte nastavení diagnostiky pro protokoly prostředků.

Chování výpadku domovské oblasti

Domovská oblast je oblast, ve které jste původně vytvořili registr. Hostuje řídicí rovinu registru, která spravuje konfiguraci registru. Domovský region je pevně stanoven při vytvoření a poté jej nelze změnit. Pokud chcete přesunout registr do jiné domovské oblasti, přečtěte si článek Relocate Azure Container Registry, který popisuje postup opětovného nasazení (vytvoření nového registru), nikoli místní změnu.

Pokud je domovská oblast nedostupná, účinek je omezen na operace řídicí roviny (správy). Všechny operace datové roviny budou dál fungovat přes zbylé geografické repliky.

Co nadále funguje během výpadku domácí oblasti:

  • Nahrávání, stahování a odstraňování imagí — Klienti mohou nahrávat, stahovat a odstraňovat image z libovolné dostupné geografické repliky pomocí globálního koncového bodu (myregistry.azurecr.io) nebo libovolného dostupného regionálního koncového bodu (myregistry.<region>.geo.azurecr.io). ACR automaticky směruje požadavky na globální koncový bod do funkční geografické repliky.
  • Ověřování – všechny metody ověřování nadále fungují, včetně Microsoft Entra ID, instančních objektů, spravovaných identit a tokenů s vymezeným oborem úložiště. Klienti se můžou ověřit u jakékoli dostupné geografické repliky, aniž by museli měnit přihlašovací údaje, tokeny nebo adresy URL registru.
  • Doručování webhooků – Webhooky nakonfigurované pro dostupné georepliky se budou nadále aktivovat. Jediné odeslání vede k událostem webhooku z přijímající geografické repliky a k událostem z každé geografické repliky po dokončení replikace. Příjemci webhooků by měli být navrženi tak, aby zvládli zpracovat více událostí pro každý odeslaný image a podle potřeby odstraňovat duplicity.
  • Regionální koncové body – Pokud jsou povolené regionální koncové body, budou dál fungovat nezávisle. Klienti mohou komunikovat přímo s konkrétními georeplikami pomocí adres URL regionálních koncových bodů.

Co je během výpadku domovské oblasti nedostupné:

  • Globální směrování provozu koncového bodu do geografické repliky domovského regionu – detekce stavu v ACR automaticky zastaví směrování provozu globálního koncového bodu do geografické repliky domovského regionu a přesměruje jej na funkční geografické repliky.
  • Regionální koncový bod pro domovskou oblast – Místní koncový bod domovské oblasti () není dostupný,myregistry.<home-region>.geo.azurecr.io když je domovská oblast mimo provoz. Regionální koncové body pro ostatní geografické repliky nadále fungují nezávisle.
  • Změny konfigurace registru – Nelze upravovat vlastnosti registru, jako jsou pravidla sítě, nastavení replikace nebo konfigurace zón dostupnosti, dokud se domovská oblast neobnoví.
  • Úlohy ACR – Úlohy jsou vázané na domovskou oblast a nespustí se, když nejsou k dispozici.

Důležité informace o úrovni služby a omezeních

Úrovně služby a omezení služby Azure Container Registry platí pro každou geografickou repliku samostatně.

Některé limity úrovně služby mají následující zvláštní aspekty:

  • Limity úložiště: Limity úložiště pro vaši úroveň služby jsou sdílené napříč všemi geografickými replikami. Pokud například nahrajete bitovou kopii o velikosti 1 GiB a zreplikuje se do 5 geografických replik, do maximálního limitu úložiště vaší úrovně se započítá jen 1 GiB.
  • Omezení rychlosti rozhraní API: Omezení operací rozhraní API, jako je počet čtení a zápisů za minutu, jsou specifické pro geografickou repliku. Pomocí regionálních koncových bodů rozložte úlohy mezi několik geografických replik pro lepší distribuci kapacity a vyhněte se soustředění veškerého provozu na jednu geografickou repliku.

Další informace o úrovních a limitech služby najdete v tématu Úrovně služby ACR.

Aspekty cen

  • Fakturace úložiště: Úložiště se účtuje na každou geografickou repliku. Například bitová kopie o velikosti 1 GiB replikovaná do 5 geografických replik je účtována jako 5 GiB úložiště (1 GiB × 5 geografických replik).
  • Přenos dat: Geografická replikace může snížit náklady tím, že povolí nabízení a vyžádání imagí v oblasti, což zabraňuje poplatkům za přenos dat mezi oblastmi během těchto operací nabízení nebo vyžádání. Poplatky za přenos dat mezi oblastmi se však nadále účtují, když ACR v rámci eventuální konzistence replikuje nahraný obsah do dalších geografických replik.

Další informace najdete v tématu O cenách ACR.

Přidání nebo odstranění geografických replik

Požadovaná oprávnění

Ke správě geografických replik potřebuje vaše identita tato oprávnění:

Povolení Description
Microsoft.ContainerRegistry/registries/read Získání vlastností registru
Microsoft.ContainerRegistry/registries/write Vytvoření nebo aktualizace vlastností registru
Microsoft.ContainerRegistry/registries/replications/read Seznam geografických replik
Microsoft.ContainerRegistry/registries/replications/write Vytvoření nebo aktualizace geografické repliky
Microsoft.ContainerRegistry/registries/replications/delete Odstraňte geografickou replikaci
Microsoft.ContainerRegistry/registries/replications/operationStatuses/read Získání stavu operace geografické repliky

Azure Portal

  1. Přejděte do svého registru na webu Azure Portal.
  2. V části Služby vyberte Geografické replikace.
  3. Na mapě:
    • Modrý šestiúhelník: Domovská oblast (kde jste registr vytvořili)
    • Zelené šestiúhelníky: Dostupné oblasti
    • Šedé šestiúhelníky: Nedostupné oblasti
  4. Vyberte zelený šestiúhelník a pak vyberte Vytvořit.

Snímek obrazovky mapy geografické replikace na webu Azure Portal

Azure CLI (příkazový řádek nástroje 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

Další příkazy najdete v az acr replication.

Globální koncový bod geograficky replikovaného registru

Po konfiguraci geografické replikace můžete prostřednictvím globálního koncového bodumyregistry.azurecr.io registru odeslat, vyžádat nebo odstranit obsah v registru.

Jak fungují globální koncové body

Když přes globální koncový bod nahrajete, stáhnete nebo odstraníte obsah, ACR směruje požadavek na geografickou repliku, která má pro daného klienta nejlepší síťový výkon.

  • Georeplika s nejlepším profilem síťového výkonu z pohledu klienta je obvykle ta nejbližší.
  • Pokud je však klient ve stejné vzdálenosti od více geografických replik nebo nejbližší geografická replika není k dispozici, požadavky mohou být směrovány jinam.
  • ACR spravuje toto směrování. Nemáte pod kontrolou, která geografická replika zpracuje konkrétní požadavek.

Diagram znázorňující tok požadavků na globální koncový bod: klient se připojí k myregistry.azurecr.io, směrování spravované Azure vybere geografickou repliku s nejlepším profilem síťového výkonu a geografická replika vrátí přesměrování 307 na svůj datový koncový bod pro stahování objektů blob.

Použití globálního koncového bodu

Ověření:

az acr login --name myregistry

Označte a odešlete image:

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

Načíst obrázek:

docker pull myregistry.azurecr.io/myapp:v1

Importujte obrázek:

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

Manifest nasazení Kubernetes:

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

Dočasné vyloučení geografické repliky z globálního směrování koncových bodů

Geografickou repliku můžete vyloučit ze směrování globálních koncových bodů zakázáním --global-endpoint-routing nastavení pro konkrétní geografickou repliku. To je užitečné pro údržbu nebo řešení potíží nebo když víte, že u konkrétní geografické repliky nebo Azure oblasti dochází ke snížení výkonu. Můžete dokonce zakázat globální směrování koncových bodů pro geografickou repliku domovské oblasti – domovská oblast se používá jenom pro operace řídicí roviny a provoz roviny dat se dá bezpečně vyloučit z globálního směrování. Další informace o tom, co řídí domovská oblast, najdete v tématu Chování při výpadku domovské oblasti.

  • --global-endpoint-routing Pokud je nastavení pro konkrétní geografickou repliku nastavené falsena , ACR zastaví směrování požadavků na danou konkrétní geografickou repliku pro požadavky, které přejdou do globálního koncového bodu.
  • Data se budou synchronizovat obousměrně s geografickou replikou, i když je pro danou geografickou repliku zakázané globální směrování koncových bodů. Každá image vložená do registru z libovolné oblasti, zatímco geografická replika je vyloučená z globálního směrování, se do něj stále replikuje. Když ji znovu povolíte, je geografická replika okamžitě připravená obsluhovat provoz bez doby potřebné k dosynchronizaci.
  • Proto se kvóta úložiště a náklady nadále vztahují na danou geografickou repliku.
  • Pokud jsou povoleny regionální koncové body, adresa URLmyregistry.<region-name>.geo.azurecr.io regionálního koncového bodu geografické repliky () bude fungovat i v době, kdy je globální směrování koncových bodů zakázané. --global-endpoint-routing řídí pouze účast geografické repliky na globálním směrování koncových bodů.
# 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

Poznámka:

  • Parametr --name určuje název prostředku pro geografickou replikaci, nikoli oblast Azure. Použijte hodnotu Name vrácenou funkcí az acr replication list.
  • V Azure CLI 2.86.0 a novějších se --region-endpoint-enabled přejmenoval na --global-endpoint-routing. Starý název příznaku je zastaralý a bude odstraněn v Azure CLI 2.87.0 (v červnu 2026). Pokud máte existující skripty nebo automatizaci, které používají --region-endpoint-enabled, aktualizujte je tak, aby používaly --global-endpoint-routing.

Important

Pro globální koncový bod nespustíte dlouhou mezipaměť DNS. Když zakážete globální směrování koncových bodů pro geografickou repliku, ACR na straně serveru urychleně odstraní záznamy DNS. Pokud však klienti používají pro globální koncový bod vlastní DNS mezipaměť s dlouhou dobou platnosti, budou se tito klienti až do vypršení platnosti mezipaměti na straně klienta nadále překládat na zakázanou geografickou repliku. Mezipaměť s dlouhou dobou platnosti způsobuje, že se z pohledu klienta zdá, jako by --global-endpoint-routing false nemělo žádný účinek.

Tip

Volitelně můžete použít krátkodobou mezipaměť DNS pro zápisy do globálního koncového bodu. Dočasné připnutí DNS omezené na dobu trvání jedné operace push pomáhá zajistit konzistenci této operace tím, že všechny vrstvy i manifest směřují do stejné geografické repliky. To také zabraňuje přeskakování DNS, které může způsobit chyby v manifestu — viz Řešení potíží.

Regionální koncové body geograficky replikovaného registru (Preview)

Regionální koncové body vám poskytují vyhrazené adresy URL pro každou repliku, takže můžete přesně určit, která regionální geografická replika zpracuje váš požadavek push, pull nebo delete:

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

Pokud potřebujete, použijte regionální koncové body:

Scenario Description
Předvídatelné směrování Zajistěte, aby pracovní zátěž vždy používala konkrétní repliku pro afinitu v rámci oblasti.
Převzetí služeb při selhání na straně klienta Implementujte vlastní logiku přepnutí při selhání, která výslovně přepíná mezi oblastmi na základě vašich vlastních kontrol stavu na straně klienta, nezávisle na vlastních kontrolách stavu Azure, na nichž je globální koncový bod založen.
Push-pull konzistence Zaměřte operace push, pull a delete na konkrétní geografickou repliku, aby se předešlo zpoždění replikace a souběhovým konfliktům při eventual consistency v CI/CD pipelinech nebo manifestech nasazení kontejnerů.
Troubleshooting Otestujte nebo laďte konkrétní regionální repliku.
Plánování kapacity Přesně víte, která replika obsluhuje jednotlivé úlohy, abyste mohli naplánovat kapacitu jednotlivých replik a vyhnout se omezování.

Important

Převzetí služeb při selhání na základě stavu služby se nevztahuje na regionální koncové body. Když používáte regionální koncový bod, mluvíte přímo s jednou konkrétní geografickou replikou. Pokud dojde ke zhoršení této oblasti, ACR se automaticky nepřesměruje. Převzetí služeb při selhání s ohledem na stav se vztahuje pouze na operace vůči globálnímu koncovému bodu (myregistry.azurecr.io). Viz scénář převzetí služeb při selhání na straně klienta v předchozí tabulce.

Poznámka:

Omezování se provádí na úrovni jednotlivých replik, nikoli na úrovni registru. Když připnete úlohy do jednoho regionálního koncového bodu, soustředíte veškerý provoz na tuto jednu geografickou repliku. Pokud všechny vaše clustery používají stejný regionální koncový bod, můžete narazit na limity omezování geografické repliky pro jednotlivé oblasti ve špičce. Pokud chcete zmírnit, rozložte úlohy mezi několik regionálních koncových bodů pro lepší distribuci kapacity nebo použijte globální koncový bod pro úlohy, které nevyžadují explicitní připnutí.

Místní koncové body existují společně s globálními koncovými body.

Povolení regionálních koncových bodů nezakážuje ani nenahrazuje globální koncový bod. Můžete použít obojí současně:

  • Použijte globální koncový bod (myregistry.azurecr.io), pokud dáváte přednost automatickému směrování spravovanému službou Azure napříč geografickými replikami.
  • Použijte regionální koncové body (myregistry.<region-name>.geo.azurecr.io), pokud chcete podrobnější řízení směrování na straně klienta a zcela obejít směrování globálního koncového bodu spravované Azure.

Jak fungují endpointy v jednotlivých oblastech

Místní koncové body fungují jako přihlašovací servery pro konkrétní geografické repliky. Při ověřování a interakci s regionálním koncovým bodem místo globálního koncového bodu registru se všechny operace registru (ověřování, nahrávání a stahování artefaktů, operace úložiště a akce metadat) přecházejí přímo na konkrétní regionální repliku a zcela se obcházejí směrování spravované Azure.

Stahování blobů vrstev (skutečných vrstev bitové kopie kontejneru) se i nadále řídí stávající konfigurací vašeho registru:

  • Registry bez privátních koncových bodů nebo vyhrazených datových koncových bodů: Když stahujete vrstvy imagí z konkrétní geografické repliky, stahování blobů vrstev se přesměruje na účty úložiště Azure (*.blob.core.windows.net).
  • Registry s povolenými privátními koncovými body nebo vyhrazenými koncovými body dat: Když stáhnete vrstvy obrázků z konkrétní geografické repliky, objekt blob vrstvy se přesměruje na vyhrazený koncový bod dat odpovídající oblasti (myregistry.<region-name>.data.azurecr.io).

Následující diagram znázorňuje tok žádostí o regionální koncový bod:

Diagram znázorňující tok žádostí o regionální koncový bod: klient se připojí k myregistry.region.geo.azurecr.io, požadavek přejde přímo do konkrétní regionální geografické repliky a geografická replika vydá přesměrování 307 do koncového bodu dat pro stahování objektů blob.

Poznámka:

Image a značky vložené do geografické repliky prostřednictvím regionálního koncového bodu se budou dál šířit do všech ostatních geografických replik v rámci konečné konzistence.

Požadavky na regionální koncové body

  • SKU Premium — Regionální koncové body jsou k dispozici výhradně v registrech úrovně Premium.
  • Azure CLI – verze 2.86.0 nebo novější. Všechny příkazy místních koncových bodů (--regional-endpoints, az acr show-endpoints, az acr login --endpoint) jsou nativně dostupné v Azure CLI 2.86.0+.

Important

Pokud jste dříve nainstalovali rozšíření CLI pro soukromý náhled: Pokud jste se zúčastnili soukromého náhledu regionálních koncových bodů a nainstalovali jste rozšíření acrregionalendpoint CLI, odinstalujte ho, abyste předešli konfliktům s integrovanými příkazy CLI:

az extension remove --name acrregionalendpoint

Můžete ověřit, že rozšíření už není nainstalované:

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

Poznámka:

Místní koncové body je možné povolit v libovolném registru skladové položky Premium, a to i bez geografické replikace. Registr bez geografické replikace má v domovské oblasti jednu geografickou repliku, která získá jednu adresu URL koncového bodu oblasti. Funkce je ale nejužitečnější, pokud má registr aspoň dvě geografické repliky.

Povolení regionálních koncových bodů

Místní koncové body můžete povolit při vytváření nového registru nebo aktualizaci existujícího registru.

Vytvořte nový registr s povolenými regionálními koncovými body:

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

Povolení regionálních koncových bodů v existujícím registru:

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

Místní koncové body jsou povolené na úrovni registru a platí pro každou geografickou repliku. U jednotlivých replik nemůžete povolit regionální koncové body. Když povolíte regionální koncové body, Azure Container Registry automaticky vytvoří adresy URL přihlašovacího serveru pro každou z vašich geografických replik.

Práce s regionálními koncovými body

Ověřování a používání regionálních koncových bodů

Regionální koncové body podporují stejné metody ověřování jako globální koncový bod: Microsoft Entra ID, instanční objekty, spravované identity a přihlašovací údaje správce.

Important

Znovu se ověřte při přepínání koncových bodů. Tokeny ACR fungují napříč globálními i regionálními koncovými body. Kontejnerové nástroje, jako jsou Docker a containerd, však ukládají přihlašovací údaje podle názvu hostitele, takže přechod z globálního koncového bodu na regionální koncový bod (nebo mezi regionálními koncovými body) vyžaduje pro daný název hostitele nový az acr login. Informace o službě AKS najdete v tématu Použití regionálních koncových bodů s ověřováním spravované identity AKS.

Přihlaste se ke konkrétnímu regionálnímu koncovému bodu:

az acr login --name myregistry --endpoint eastus

Označte a nahrajte image do regionálního koncového bodu. Image a značky vložené do geografické repliky prostřednictvím regionálního koncového bodu se budou dál šířit do všech ostatních geografických replik v rámci konečné konzistence.

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

Stáhněte obraz z regionálního koncového bodu:

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

Používejte regionální koncové body s ověřováním pomocí spravované identity AKS

Stahování imagí v AKS, která se ověřují vůči ACR pomocí spravované identity, podporují regionální koncové body v imagi uzlu AKS verze 202607.29 nebo novější. Zkontrolujte aktuální image pro každý fond uzlů:

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

Chcete-li po zpřístupnění kompatibilního image virtuálního pevného disku (VHD) uzlu ve vaší oblasti a cloudovém prostředí tento image získat automaticky, použijte NodeImage kanál automatických upgradů operačního systému uzlu. AKS Automatic používá NodeImage; pro AKS Standard vyberte NodeImage.

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

Pro uzly AKS, které používají starší verzi image, použijte při stahování imagí z regionálních endpointů Kubernetes image pull secret, nebo místo něj odkazujte na globální endpoint (<registry-name>.azurecr.io).

Použití regionálních koncových bodů vložených do manifestů nasazení

Místní koncové body můžete zadat přímo v manifestech nasazení Kubernetes, pokud potřebujete připnout úlohy do konkrétních oblastí. Tím je zajištěno, že clustery v konkrétních regionech vždy načítají z repliky umístěné ve stejném místě, což zajišťuje předvídatelné směrování a nižší latenci.

Nasazení clusteru USA – východ:

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

Nasazení clusteru Západní Evropa:

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

Použitím různých regionálních koncových bodů v manifestech jednotlivých clusterů můžete zajistit, že každý cluster bude stahovat z místní repliky, místo aby se spoléhal na směrování spravované službou Azure.

Informace o tom, jak ověřovat Azure Kubernetes Service (AKS) pomocí služby Azure Container Registry (ACR), najdete v článku Ověřování pomocí služby Azure Container Registry z Azure Kubernetes Service.

Použití regionálních koncových bodů se směrováním založeným na DNS beze změny manifestů nasazení

Pokud nechcete udržovat různé manifesty pro nasazení pro jednotlivé oblasti, můžete ponechat všechny manifesty tak, aby odkazovaly na globální koncový bod (myregistry.azurecr.io), a použít softwarově definované síťování nebo regionální traffic manager k nasměrování globálního koncového bodu na příslušný regionální koncový bod na základě toho, ze které oblasti provoz pochází. Dosáhnete tak stejných cílů kolokace jako regionální koncové body (předvídatelné směrování a nižší latence) bez vkládání adres URL specifických pro oblast do manifestů nasazení.

Informace o tom, jak ověřovat Azure Kubernetes Service (AKS) pomocí služby Azure Container Registry (ACR), najdete v článku Ověřování pomocí služby Azure Container Registry z Azure Kubernetes Service.

Import z konkrétních geografických replik pomocí regionálních koncových bodů

Azure Container Registry podporuje import imagí z různých zdrojových registrů napříč poskytovateli cloudu. Pokud je zdrojem importu služba ACR, můžete importovat pouze z domovské oblasti zdrojové služby ACR. Regionální koncové body zdrojového registru ACR nejsou podporovány jako zdroje importu. Při importu ze zdrojové služby ACR zadejte globální koncový bod služby ACR zdroje. Import navíc vždy zapisuje obsah do domovské oblasti podřízené služby ACR. Viz referenční informace ke koncovému bodu Azure Container Registry.

Aspekty sítě regionálních koncových bodů

Pravidla firewallu

Pokud používáte pravidla brány firewall ACR nebo vlastní brány firewall s regionálními koncovými body, nakonfigurujte pravidla brány firewall tak, aby umožňovala přístup k:

Endpoint Purpose
myregistry.<region-name>.geo.azurecr.io Regionální koncový bod pro operace registru
myregistry.azurecr.io Globální koncový bod (pokud se používá také)
myregistry.<region-name>.data.azurecr.io Stahování vrstev (pokud používáte privátní koncové body nebo vyhrazené koncové body dat)
*.blob.core.windows.net Stahování vrstev (pokud nepoužíváte privátní koncové body nebo vyhrazené koncové body dat)

Privátní koncové body

Když se vytvoří privátní koncový bod pro registr ve virtuální síti, prostředek privátního koncového bodu zpřístupní několik privátních IP adres virtuální sítě, které pokrývají všechny koncové body registru – globální koncový bod, každý regionální koncový bod (pokud jsou povolené regionální koncové body) a každý vyhrazený koncový bod dat (automaticky povolený při konfiguraci privátního koncového bodu).

Každá plocha koncového bodu využívá jednu privátní IP adresu z podsítě virtuální sítě. Odpovídajícím způsobem naplánujte velikost podsítě:

  • 1 IP adresa globálního koncového bodu (myregistry.azurecr.io)
  • 1 IP adresa na geografickou repliku pro vyhrazené koncové body dat (myregistry.<region>.data.azurecr.io) – vždy povolená u registrů s alespoň jedním privátním koncovým bodem
  • 1 IP adresa pro každou geografickou repliku pro regionální koncové body (myregistry.<region>.geo.azurecr.io) – pouze pokud jsou povoleny regionální koncové body

Příklad: Registr se 3 geografickými replikami a povolenými regionálními koncovými body vyžaduje 1 (globální) + 3 (data) + 3 (regionální) = 7 privátních IP adres na prostředek privátního koncového bodu. Bez regionálních koncových bodů vyžaduje stejný registr 1 + 3 = 4 privátní IP adresy.

U mnoha geografických replik může vytvoření privátního koncového bodu selhat, pokud podsíť vyčerpá dostupné IP adresy. Další informace najdete v tématu Privátní připojení k registru z virtuální sítě pomocí privátních koncových bodů.

Vyhrazené datové koncové body

Když jsou regionální koncové body povolené společně s vyhrazenými datovými koncovými body — buď explicitně, nebo automaticky při konfiguraci alespoň jednoho privátního koncového bodu — stahování blobů vrstev z regionálních koncových bodů se automaticky přesměruje na vyhrazený datový koncový bod geografické repliky (myregistry.<region-name>.data.azurecr.io). Přesměrování vždy zůstává ve stejném regionu jako regionální koncový bod — pull z myregistry.eastus.geo.azurecr.io se vždy přesměruje na myregistry.eastus.data.azurecr.io, nikdy na datový koncový bod v jiném regionu.

Tato záruka stejného regionu platí také při stahování z globálního koncového bodu. ACR směruje požadavek k geografické replice s nejlepším profilem síťového výkonu pro klienta a obsluhující geografická replika vydá přesměrování 307 na svůj vlastní vyhrazený datový koncový bod — nikdy do jiné oblasti.

Tip

Povolte vyhrazené koncové body dat pro optimální výkon v oblasti a vyhrazenou adresu URL pro stahování vrstev:

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

Další informace najdete v tématu Vyhrazené koncové body pro data v Azure Container Registry.

Referenční informace ke koncovému bodu

Úplný přehled všech typů koncových bodů registru, formátů adres URL a přepínačů nástroje CLI, které je určují, najdete v tématu Referenční informace ke koncovým bodům služby Azure Container Registry.

Řešení problémů

Selže odeslání kvůli chybám manifestu

docker push je posloupnost požadavků HTTP: nahrávání blobů pro každou vrstvu a poté nahrání manifestu, který na tyto vrstvy odkazuje pomocí digestu. Některé překladače DNS linuxu neukládá odpovědi konzistentně do mezipaměti. Pokud existuje několik geografických replik v blízkých regionech, může DNS během jednoho odeslání přeložit požadavek na různé repliky (DNS bouncing), což způsobí, že odeslaný manifest bude odkazovat na vrstvy, které byly odeslány do jiné geografické repliky. Vzhledem k tomu, že replikace je nakonec konzistentní, může manifest přistát na replice, která ještě nemá vrstvy, na které odkazuje, a ověření manifestu selže.

Řešení (v pořadí podle preference):

  1. Použijte regionální endpointy k tomu, aby se push v celém řetězci připnul k jediné geografické replice. Každý dílčí požadavek (přihlášení, nahrání blobů, nahrání manifestu) směřuje na stejnou geo-repliku. Jde o nejčistší řešení a doporučený postup pro jakoukoli pipeline, u níž je důležitá konzistence push/pull.
  2. Použijte krátkodobou mezipaměť DNS, jako je dnsmasq omezenou na dobu trvání jednoho push. Informace o virtuálních počítačích s Linuxem v Azure najdete v tématu Možnosti překladu názvů DNS. Připnutí by mělo trvat jen po dobu daného odeslání a ne déle — pro globální koncový bod nepoužívejte dlouhodobou mezipaměť DNS, protože narušuje --global-endpoint-routing false i směrování převzetí služeb při selhání zohledňující stav.
  3. Navrhněte kroky publikování tak, aby byly idempotentní, aby opakované pokusy vyvolané selháním uprostřed publikování byly bezpečné.

Vytvoření geografické repliky se zablokuje pro registry s podporou privátního koncového bodu

K tomuto problému obvykle dochází v případě, že identita, která vytváří geografickou repliku pro registr s podporou privátního koncového bodu, nemá dostatečná oprávnění k vytvoření síťových prostředků privátního koncového bodu.

Řešení:

  • Pokud chcete problém vyřešit, odstraňte ručně geografickou repliku, která se zasekla ve stavu zřizování.
  • Potom se ujistěte, že identita má oprávnění Microsoft.Network/privateEndpoints/privateLinkServiceProxies/write před vytvořením geografické repliky.
  • Ověřte také, že každá podsíť soukromého koncového bodu připojená k registru má k dispozici volnou kapacitu IP adres. Pokud nějaká podsíť v jakékoli připojené virtuální síti nemá dostatek volných IP adres, zřizování replikace selže a vrátí se zpět. Replika se zobrazí krátce ve Creating stavu a pak se odebere. Výsledná chyba neidentifikuje, která podsíť nebo virtuální síť se vyčerpá. Pokyny k určení velikosti podsítě najdete v tématu Privátní připojení k registru pomocí privátních koncových bodů.

Vytvoření geografické repliky selže u registrů s privátním koncovým bodem se statickou IP adresou

Přidání geografické repliky selže, když je privátní koncový bod registru nakonfigurovaný s přidělováním statických privátních IP adres.

Každá geografická replika má vlastní vyhrazený datový koncový bod, který je na privátním koncovém bodu zpřístupněn jako člen se skupinovým ID registry a názvem člena registry_data_<region>. Když přidáte novou geografickou repliku, služba ACR požádá privátní koncový bod, aby přidal člena pro datový koncový bod nového regionu. Privátní koncový bod nakonfigurovaný s dynamickým přidělováním IP adres automaticky zřídí IP adresu nového člena. Privátní koncový bod nakonfigurovaný se statickým přidělením IP adres má pevně definovanou sadu konfigurací IP adres definovaných při vytváření a nepřidá nový člen automaticky, takže vytvoření repliky selže s chybou podobnou této:

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.

Pokud chcete zkontrolovat metodu přidělování privátního koncového bodu registru, zkontrolujte PrivateIPAllocationMethod konfiguraci IP adres v síťovém rozhraní privátního koncového bodu. Privátní koncový bod odkazuje na síťové rozhraní, které obsahuje tyto konfigurace IP adres, takže nejprve získejte ID síťového rozhraní a pak zkontrolujte jeho konfigurace IP adres:

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

Řešení:

  • Pokud budete chtít přidat geografické repliky později, použijte dynamické přidělování IP adres privátního koncového bodu. S dynamickým přidělováním ACR automaticky zřídí člena koncového bodu dat pro každou novou oblast. Toto je doporučený přístup.
  • Pokud je vyžadováno přidělení statické IP adresy, vytvořte privátní koncový bod až po vytvoření všech geografických replik. Nejprve přidejte každou geografickou repliku a pak vytvořte privátní koncový bod statické IP adresy, aby jeho konfigurace IP adresy zahrnovala člena pro každý koncový bod dat každé existující oblasti. Po vytvoření privátního koncového bodu se statickou IP adresou tímto způsobem nemůžete přidat další geografické repliky, aniž byste privátní koncový bod znovu nakonfigurovali tak, aby zahrnoval nového člena.

Související obsah

  • Poslední aktualizace v