Geo-replikering i Azure Container Registry

Företag som vill ha en lokal närvaro eller en snabb säkerhetskopiering väljer att köra tjänster från flera Azure-regioner. Ett bra tips är att placera ett containerregister i varje region där avbildningar körs, så att åtgärder utförs närmare nätverket och du får snabba och tillförlitliga överföringar på avbildningsnivå. Med geo-replikering kan ett Azure-containerregister fungera som ett enda register som betjänar flera regioner med flera primära regionala register.

Ett georeplikerat register ger följande fördelar:

• Namn på enskilda register, avbildningar och taggar kan användas i flera regioner
• Förbättra prestanda och tillförlitlighet för regionala distributioner med nätverksnära registeråtkomst
• Minska kostnaderna för dataöverföring genom att hämta avbildningslager från ett lokalt, replikerat register i samma eller närliggande region som containervärden
• Enkel hantering av ett register i flera regioner
• Registerresiliens om ett regionalt avbrott inträffar

Kommentar

• Om du behöver upprätthålla kopior av containeravbildningar i mer än ett Azure-containerregister har Azure Container Registry även stöd för avbildningsimport. I ett DevOps-arbetsflöde kan du till exempel importera en avbildning från ett utvecklingsregister till ett produktionsregister utan att behöva använda Docker-kommandon.
• Om du vill flytta ett register till en annan Azure-region, i stället för att georeplikera registret, kan du läsa Flytta ett containerregister manuellt till en annan region.

Förutsättningar

• Användaren kräver följande behörigheter (på registernivå) för att skapa/ta bort replikering:

  Behörighet	beskrivning
  Microsoft.ContainerRegistry/registries/write	Skapa en replikering
  Microsoft.ContainerRegistry/registries/replications/write	Ta bort en replikering

Exempel på användningsfall

Contoso kör en webbplats med offentlig närvaro i USA, Kanada och Europa. För att betjäna dessa marknader med lokalt och nätverksnära innehåll kör Contoso Azure Kubernetes Service-kluster (AKS) i USA, västra; USA, östra; Kanada, centrala samt Europa, västra. Webbappen, som distribueras som en Docker-avbildning, använder samma kod och avbildning i alla regioner. Innehåll som är lokalt för den regionen hämtas från en databas som etableras unikt i varje region. Varje regional distribution har en unik konfiguration för resurser som den lokala databasen.

Utvecklingsteamet finns i Seattle, WA, och använder datacentret för USA, västra.

Push-överföra till flera register

Innan Contoso började använda de geo-replikerade funktionerna hade de ett USA-baserat register i USA, västra med ytterligare ett register i Europa, västra. För att betjäna dessa olika regioner push-överförde utvecklingsteamet till två olika register.

docker push contoso.azurecr.io/public/products/web:1.2
docker push contosowesteu.azurecr.io/public/products/web:1.2

Hämta från flera register

Typiska utmaningar med flera register är:

• Alla kluster i USA, östra, USA, västra och Kanada, centrala hämtas från registret USA, västra, vilket medför utgående avgifter när var och en av dessa fjärranslutna containervärdar hämtar avbildningar från datacenter i USA, västra.
• Utvecklingsteamet måste push-överföra avbildningar till registren för USA, västra och Europa, västra.
• Utvecklingsteamet måste konfigurera och underhålla varje regional distribution med avbildningsnamn som refererar till det lokala registret.
• Registeråtkomst måste konfigureras för varje region.

Fördelar med geo-replikering

Geo-replikeringsfunktionen i Azure Container Registry har följande fördelar:

• Hantera ett enskilt register i alla regioner: contoso.azurecr.io
• Hantera en enda konfiguration av avbildningsdistributioner eftersom alla regioner använder samma bild-URL: contoso.azurecr.io/public/products/web:1.2
• Push-överför till ett enda register medan ACR automatiskt hanterar geo-replikering. ACR replikerar bara unika lager, vilket minskar dataöverföringen mellan regioner.
• Konfigurera regionala webhooks för att meddela dig om händelser i specifika repliker.
• Tillhandahålla ett register med hög tillgänglighet som är motståndskraftigt mot regionala avbrott.

Azure Container Registry har också stöd för tillgänglighetszoner för att skapa ett motståndskraftigt och högtillgängligt Azure-containerregister i en Azure-region. Kombinationen av tillgänglighetszoner för redundans i en region och geo-replikering i flera regioner förbättrar både tillförlitligheten och prestandan för ett register.

Konfigurera geo-replikering

Konfiguration av geo-replikering är så enkelt som att klicka på regioner på en karta. Du kan också hantera geo-replikering med hjälp av verktyg som az acr-replikeringskommandon i Azure CLI eller distribuera ett register som är aktiverat för geo-replikering med en Azure Resource Manager-mall.

Geo-replikering är en funktion i Premium-register. Om ditt register ännu inte är Premium kan du ändra från Basic och Standard till Premium i Azure-portalen:

Om du vill konfigurera geo-replikering för ditt Premium-register loggar du in på Azure Portal.

Gå till ditt Azure Container Registry och välj Replikeringar:

En karta visas med alla aktuella Azure-regioner:

• Blå sexhörningar representerar aktuella repliker
• Gröna sexhörningar representerar möjliga replikregioner
• Grå sexhörningar representerar Azure-regioner som ännu inte är tillgängliga för replikering

Om du vill konfigurera en replik markerar du en grön sexhörning och väljer Skapa:

Om du vill konfigurera ytterligare repliker markerar du de gröna sexhörningarna för andra regioner och klickar på Skapa.

ACR börjar synkronisera avbildningar mellan de konfigurerade replikerna. När det är klart visar portalen Klar. Replikstatus i portalen uppdateras inte automatiskt. Använd uppdateringsknappen om du vill visa uppdaterad status.

Överväganden för att använda ett geo-replikerat register

• Varje region i ett geo-replikerat register är oberoende när det har konfigurerats. Serviceavtal för Azure Container Registry gäller för varje geo-replikerad region.
• För varje push- eller pull-avbildningsåtgärd i ett geo-replikerat register skickar Azure Traffic Manager i bakgrunden en begäran till registrets närmaste plats i regionen för att upprätthålla nätverksfördröjningen.
• När du har push-överfört en avbildning eller tagguppdatering till närmaste region tar det lite tid för Azure Container Registry att replikera manifesten och lagren till de återstående regioner som du valde. Större avbildningar tar längre tid att replikera än vad mindre avbildningar gör. Avbildningar och taggar synkroniseras i replikeringsregionerna med hjälp av en eventuell konsekvensmodell.
• För att hantera arbetsflöden som är beroende av push-uppdateringar till ett geo-replikerat register rekommenderar vi att du konfigurerar webhooks för att svara på push-händelserna. Du kan konfigurera regionala webhooks i ett geo-replikerat register för att spåra push-händelser när de slutförs i de geo-replikerade regionerna.
• För att hantera blobar som representerar innehållslager använder Azure Container Registry dataslutpunkter. Du kan aktivera dedikerade dataslutpunkter för registret i var och en av registrets geo-replikerade regioner. Dessa slutpunkter tillåter konfiguration av strikt begränsade brandväggsåtkomstregler. I felsökningssyfte kan du inaktivera routning till en replikering samtidigt som replikerade data bibehålls.
• Om du konfigurerar en privat länk för registret med privata slutpunkter i ett virtuellt nätverk aktiveras dedikerade dataslutpunkter i var och en av de geo-replikerade regionerna som standard.

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

• För hög tillgänglighet och återhämtning rekommenderar vi att du skapar ett register i en region som stöder aktivering av zonredundans. Du rekommenderas också att aktivera zonredundans i varje replikregion.
• Om ett avbrott inträffar i registrets hemregion (den region där det skapades) eller en av dess replikregioner förblir ett geo-replikerat register tillgängligt för dataplansåtgärder som att push-överföra eller hämta containeravbildningar.
• Om registrets hemregion blir otillgänglig kan det hända att du inte kan utföra registerhanteringsåtgärder, inklusive att konfigurera nätverksregler, aktivera tillgänglighetszoner och hantera repliker.
• Om du vill planera för hög tillgänglighet för ett geo-replikerat register krypterat med en kundhanterad nyckel som lagras i ett Azure-nyckelvalv läser du vägledningen för redundans och redundans för nyckelvalvet.

Ta bort en replik

När du har konfigurerat en replik för registret kan du ta bort den när som helst om den inte längre behövs. Ta bort en replik med hjälp av Azure Portal eller andra verktyg, till exempel kommandot az acr replication delete i Azure CLI.

Så här tar du bort en replik i Azure Portal:

1. Gå till Azure Container Registry och välj Replikering.
2. Välj namnet på en replik och välj Ta bort. Bekräfta att du vill ta bort repliken.

Så här använder du Azure CLI för att ta bort en replik av myregistry i regionen USA, östra:

az acr replication delete --name eastus --registry myregistry

Prissättning för Geo-replikering

Geo-replikering är en funktion i Premium-tjänstnivån i Azure Container Registry. När du replikerar ett register till din önskade regioner debiteras du avgifter för Premium-register för varje region.

I föregående exempel konsoliderade Contoso två register till ett och lade till repliker i USA, östra; Kanada, centrala samt Europa, västra. Contoso betalade då fyra gånger Premium per månad, utan ytterligare konfiguration eller hantering. Varje region hämtar nu sina bilder lokalt, vilket förbättrar prestanda och tillförlitlighet utan avgifter för utgående nätverk från USA, västra till Kanada och USA, östra.

Felsöka push-åtgärder med geo-replikerade register

En Docker-klient som push-överför en avbildning till ett geo-replikerat register kanske inte skickar alla avbildningslager och dess manifest till en enda replikerad region. Detta kan inträffa eftersom Azure Traffic Manager dirigerar registerbegäranden till det nätverksnära replikerade registret. Om registret har två närliggande replikeringsregioner kan avbildningsskikt och manifestet distribueras till de två platserna, och push-åtgärden misslyckas när manifestet verifieras. Det här problemet uppstår på grund av hur registrets DNS-namn löses på vissa Linux-värdar. Det här problemet uppstår inte i Windows, som tillhandahåller en DNS-cache på klientsidan.

Om det här problemet uppstår är en lösning att tillämpa en DNS-cache på klientsidan, till exempel dnsmasq på Linux-värden. Det säkerställer att registrets namn matchas på ett konsekvent sätt. Om du använder en virtuell Linux-dator i Azure för att skicka till ett register kan du läsa alternativen i ALTERNATIV för DNS-namnmatchning för virtuella Linux-datorer i Azure.

Om du vill optimera DNS-matchningen till närmaste replik vid push-överföring av avbildningar konfigurerar du ett geo-replikerat register i samma Azure-regioner som källan till push-åtgärderna, eller den närmaste regionen när du arbetar utanför Azure.

Inaktivera tillfälligt routning till replikering

Om du vill felsöka åtgärder med ett geo-replikerat register kanske du tillfälligt vill inaktivera Traffic Manager-routning till en eller flera repliker. Från och med Azure CLI version 2.8 kan du konfigurera ett --region-endpoint-enabled alternativ (förhandsversion) när du skapar eller uppdaterar en replikerad region. När du anger alternativet för replikering --region-endpoint-enabled till falsedirigerar Traffic Manager inte längre docker-push- eller pull-begäranden till den regionen. Som standard är routning till alla repliker aktiverad och datasynkronisering för alla repliker sker oavsett om routning är aktiverad eller inaktiverad.

Om du vill inaktivera routning till en befintlig replikering kör du först az acr-replikeringslistan för att lista replikeringen i registret. Kör sedan az acr replication update och ange --region-endpoint-enabled false för en specifik replikering. Om du till exempel vill konfigurera inställningen för westus-replikeringen i myregistry:

# Show names of existing replications
az acr replication list --registry --output table

# Disable routing to replication
az acr replication update --name westus \
  --registry myregistry --resource-group MyResourceGroup \
  --region-endpoint-enabled false

Så här återställer du routningen till en replikering:

az acr replication update --name westus \
  --registry myregistry --resource-group MyResourceGroup \
  --region-endpoint-enabled true

Skapa replikering för ett register som har privat slutpunkt aktiverad

När du skapar en ny registerreplikering för det primära registret som är aktiverat med privat slutpunkt rekommenderar vi att du verifierar att användaridentiteten har giltiga behörigheter för att skapa privata slutpunkter. Annars kommer åtgärden fastna i etableringstillståndet när replikeringen skapas.

Följ stegen nedan om du fastnade i etableringstillståndet när du skapade registerreplikeringen:

• Ta bort replikeringen som fastnade i etableringstillståndet manuellt.
• Lägg till behörigheten Microsoft.Network/privateEndpoints/privateLinkServiceProxies/write för användaridentiteten.
• Återskapa begäran om registerreplikering.

Den här behörighetskontrollen gäller endast för register med privat slutpunkt aktiverat.

Nästa steg

Läs självstudieserien i tre delar, Geo-replikering i Azure Container Registry. Gå igenom att skapa ett geo-replikerat register samt skapa en container och sedan distribuera den med ett enda docker push-kommando till flera regionala Web Apps for Containers-instanser.

Geo-replikering i Azure Container Registry