Géoréplication dans Azure Container Registry

L'activation de la géoréplication pour un Azure Container Registry (ACR) crée des ressources de géoréplica dans les régions Azure que vous choisissez. Lorsque vous envoyez (push) des images vers un registre géorépliqué, le contenu se synchronise automatiquement avec tous les géoréplicas.

Avec la géoréplication :

• Gérer un registre : conservez un seul ensemble d’informations d’identification, d’attributions de rôles, de règles de mise en réseau et de configuration du Registre sur tous les géoréplicas.
• Utilisez un point de terminaison global : référence myregistry.azurecr.io/myimage:tag dans toutes vos builds et déploiements. Azure achemine les requêtes vers le géoréplica avec le meilleur profil de performances réseau pour le client concerné, qui est généralement le géoréplica le plus proche. Toutefois, si le client se trouve à égale distance de plusieurs géorépliques ou si la géoréplique la plus proche n’est pas disponible, les requêtes peuvent être redirigées ailleurs.
• Synchronisation automatique : envoyez (push) les balises et synthèses une seule fois, ACR réplique le contenu et les métadonnées sur tous les géoréplicas.

La géoréplication nécessite le SKU Premium.

Considérations relatives à la haute disponibilité

Modèle de réplication

La géoréplication ACR utilise un modèle actif-actif .

• Tous les géoréplicas sont actifs et accessibles en écriture : vous pouvez envoyer (push), extraire (pull) et supprimer des images à partir de n’importe quel géoréplica, et pas seulement celui de la région d’origine.
• Cela diffère des modèles de réplication primaire-secondaire où une seule région accepte les écritures et les régions secondaires sont passives.

Modèle de cohérence

ACR utilise la cohérence éventuelle.

• Une fois que vous avez poussé ou supprimé une image dans n’importe quel géo-réplica, ACR finit par répliquer ces modifications vers tous les géo-réplicas en arrière-plan.
• Le temps de réplication dépend de la taille de l’image. Une image ou une balise envoyée (push) peut ne pas être immédiatement disponible au tirage (pull) dans d’autres géoréplicas si de grands volumes d’images ou des images de grande taille sont envoyés. De même, une image ou une balise supprimée peut toujours être disponible pour l’extraction dans d’autres géoréplicas jusqu’à ce que la suppression se propage.
• Le temps nécessaire à la création d’une nouvelle géoréplique augmente en fonction de la taille totale du registre. Lors de la création d’un nouveau géoréplica, les géoréplicas existants continuent de traiter normalement le trafic de transmission, d’extraction et de suppression. Il n’y a ni mode restreint ni période de dégradation pendant que le nouveau géoréplica se synchronise en arrière-plan.
• Tant que la réplication n’est pas terminée en arrière-plan, un géo-réplica n’a peut-être pas le contenu ou les métadonnées les plus récents. Vous pouvez utiliser des webhooks pour recevoir des notifications lorsque la réplication d’une image spécifique envoyée est terminée dans chaque géoréplica.

Haute disponibilité du plan de données

La géoréplication améliore la disponibilité du plan de données en conservant des images dans plusieurs régions. Si une région subit une panne, les images restent accessibles à partir d’autres géoréplicas : l’envoi (push), l’extraction (pull) et la suppression continuent de fonctionner via les géoréplicas restants.

La redondance de zone est toujours activée pour les géoréplicas : ACR répartit automatiquement les données des réplicas sur plusieurs zones de disponibilité afin de se prémunir contre les pannes zonales.

Basculement avec surveillance de l’état de santé

ACR surveille automatiquement l’état de santé de chaque géoréplica et redirige le trafic du point de terminaison global en le détournant des géoréplicas qui ne peuvent pas répondre aux requêtes de manière fiable. Ceci est appelé un basculement avec prise en compte de l’état de santé. ACR achemine le trafic vers les points de terminaison globaux en fonction de l’intégrité du service ACR et de l’intégrité de l’infrastructure régionale d’Azure.

• Automatique et par registre : l’état de santé est évalué pour chaque registre, et non pour chaque région. Si une dégradation n’affecte qu’un sous-ensemble de registres d’une région, seuls ces registres sont routés : d’autres registres de la même région continuent d’être traités localement sans pénalité de latence inutile.
• Délai: le réacheminement de bout en bout est de l’ordre de quelques minutes, ce qui est suffisamment rapide pour détecter une véritable dégradation à l’échelle régionale et suffisamment lent pour laisser passer les erreurs temporaires qui se résorbent d’elles-mêmes. Le TTL DNS peut entraîner un délai de propagation avant que tous les clients soient redirigés vers la nouvelle région.
• Aucune action du client n’est requise : il n’existe aucun déclencheur invocable pour le client. Le basculement avec prise en compte de l’état de santé est entièrement géré par la plateforme.
• La restauration est automatique : une fois que l'évaluation régionale de l'intégrité d'un géoréplica passe à nouveau, par exemple lorsque l'infrastructure régionale ACR ou Azure est rétablie, le point de terminaison global peut reprendre le routage du trafic vers le géoréplica dans la région Azure récupérée.
• Non déclenché par la limitation du débit : le basculement avec prise en compte de l’état de santé est basé sur le DNS et réagit à l’état de santé du service ACR régional et à celui de l’infrastructure Azure. Il ne réachemine pas le trafic en fonction des réponses HTTP 429 (limitation du débit). Si une géoréplique applique une limitation à vos requêtes, mais que l’infrastructure de la région fonctionne normalement, le point de terminaison global continue à acheminer vos requêtes vers cette géoréplique. Pour gérer la limitation, utilisez des points de terminaison régionaux pour répartir les charges de travail sur plusieurs géoréplicas et garantir une meilleure distribution des capacités.

Portée du basculement tenant compte de l’état de santé :

Le basculement tenant compte de l’état de santé s’applique uniquement aux opérations sur le point de terminaison global (myregistry.azurecr.io). Elle ne s’applique pas aux points suivants :

• Points de terminaison régionaux : lorsque vous utilisez un point de terminaison régional (myregistry.<region>.geo.azurecr.io), vous parlez directement à un géoréplica spécifique. Si cette région se dégrade, ACR ne réachemine pas automatiquement. Mettez en place le basculement côté client en passant à un point de terminaison d’une autre région.
• Points de terminaison de données dédiés : une fois qu’un point de terminaison de Registre vous redirige vers un point de terminaison de données dédié pour un téléchargement de couche, vous restez sur le point de terminaison de données de cette région tout au long du téléchargement. La région est décidée dès le départ par le point de terminaison du registre qui a traité la requête d’emplacement du blob.

Limitation du débit lors du basculement :

Les limites de débit des opérations d’API s’appliquent à chaque réplica. Lors d’un basculement tenant compte de l’état de santé, le trafic auparavant réparti entre plusieurs géoréplicas peut se reporter massivement sur ceux qui sont encore présents dans le pool de routage du point de terminaison global. Prévoyez une capacité permettant de disposer d’au moins deux ou trois géoréplicas afin que le trafic puisse se répartir entre plusieurs géoréplicas sains lors d’un basculement. Les registres comportant seulement deux régions peuvent atteindre plus facilement les limites de limitation de débit par réplica en cas d’indisponibilité de l’une des régions. Pour atténuer cela, utilisez des points de terminaison régionaux pour répartir les charges de travail sur plusieurs géoréplicas et planifier la capacité pour chaque réplica.

Comment confirmer un basculement :

• Azure portail : accédez à votre registre et sélectionnez Resource health sous la section Help pour voir les signaux de dégradation côté plateforme.
• Azure CLI : vérifiez l’état de la réplication avec az acr replication list --registry myregistry --output table. Les géoréplicas présentant des problèmes affichent un état autre que online.
• Azure Monitor : les métriques de plateforme sont collectées automatiquement. Activez les paramètres de diagnostic pour les journaux de ressources pour obtenir des données de télémétrie détaillées.

Comportement de panne de région d'origine

La région d’origine est la région où vous avez créé le Registre à l’origine. Il héberge le plan de contrôle du Registre, qui gère la configuration du Registre. La région d’accueil est fixe lors de la création et ne peut pas être modifiée par la suite. Pour déplacer un registre vers une autre région d’origine, consultez Relocaliser Azure Container Registry, qui décrit une procédure de redéploiement (création d’un registre), et non pas une modification sur place.

Si la région d’origine devient indisponible, l’effet est limité aux opérations de plan de contrôle (gestion). Toutes les opérations du plan de données continuent de fonctionner via les géoréplicas restants.

Ce qui continue de fonctionner pendant une panne de région d’origine :

• Envoi d’images, extraction et suppression : les clients peuvent envoyer, extraire et supprimer des images de n’importe quel géoréplica disponible à l’aide du point de terminaison global (myregistry.azurecr.io) ou d’un point de terminaison régional disponible (myregistry.<region>.geo.azurecr.io). ACR achemine automatiquement les requêtes du point de terminaison global vers une géo-réplique en bon état.
• Authentification : toutes les méthodes d’authentification continuent de fonctionner, y compris Microsoft Entra ID, les principaux de service, les identités managées et les jetons délimités par le référentiel. Les clients peuvent s’authentifier auprès de n’importe quel geo-replica disponible sans avoir à modifier les informations d’identification, les jetons ou les URL de Registre.
• Remise de webhook : les webhooks configurés pour les géoréplicas disponibles continuent de se déclencher. Une seule opération push génère des événements webhook provenant du géoréplica de destination, ainsi que des événements de chaque géoréplica une fois la réplication terminée. Les consommateurs de webhooks doivent être conçus pour gérer plusieurs événements par image envoyée et éliminer les doublons si nécessaire.
• Points de terminaison régionaux : si les points de terminaison régionaux sont activés, ils continuent de fonctionner indépendamment. Les clients peuvent se connecter directement à des géoréplicas spécifiques en utilisant des URL de points de terminaison régionaux.

Qu’est-ce qui n’est pas disponible lors d’une panne de région d’origine :

• Routage global du point de terminaison vers le géoréplica de la région d’origine : la détection d’intégrité d’ACR arrête automatiquement le routage du trafic de point de terminaison global vers le géoréplica de la région d'origine et le redirige vers des géoréplicas sains.
• Point de terminaison régional pour la région d’origine : le point de terminaison régional de la région d’origine (myregistry.<home-region>.geo.azurecr.io) n’est pas disponible pendant que la région d’origine est en panne. Les points de terminaison régionaux des autres géoréplicats continuent de fonctionner indépendamment.
• Modifications de configuration du Registre : vous ne pouvez pas modifier les propriétés du Registre telles que les règles réseau, les paramètres de réplication ou les configurations de zone de disponibilité tant que la région d’accueil n’est pas récupérée.
• Tâches ACR : les tâches sont liées à la région d’accueil et ne s’exécutent pas pendant qu’elles ne sont pas disponibles.

Considérations relatives au niveau de service et aux limites

Les niveaux de service et les limites du service Azure Container Registry s’appliquent indépendamment à chaque géo-réplicat.

Certaines limites de niveau de service ont la considération spéciale suivante :

• Limites de stockage : les limites de stockage de votre niveau de service sont partagées entre tous les géoréplicas. Par exemple, si vous envoyez une image d'1 Gio et qu’elle est répliquée vers 5 géoréplicas, seul 1 Gio est pris en compte dans les limites de stockage maximales de votre niveau.
• Limites de débit d’API : les seuils de limitation relatifs aux opérations d’API, par exemple le nombre de lectures et d’écritures par minute, sont spécifiques des géoréplicas. Utilisez des points de terminaison régionaux pour répartir les charges de travail sur plusieurs géo-réplicas afin de mieux répartir la capacité et d’éviter de concentrer tout le trafic sur un seul géo-réplica.

Pour plus d’informations sur les niveaux de service et les limites, consultez les niveaux de service ACR.

Considérations relatives aux tarifs

• Facturation du stockage : le stockage est facturé par géoréplica. Par exemple, une image d'1 Gio répliquée vers 5 géoréplicas est facturée en tant que 5 Gio de stockage (1 Gio × 5 géoréplicas).
• Transfert de données : la géoréplication peut réduire les coûts en activant les envois d’images et les extractions d’images dans la région, ce qui évite les frais de transfert de données inter-régions pendant ces opérations push ou pull. Toutefois, les frais de transfert de données inter-régions s’appliquent toujours lorsque ACR réplique le contenu envoyé vers d’autres réplicas géographiques dans le cadre de la cohérence éventuelle.

Pour plus d’informations, consultez la tarification ACR.

Ajouter ou supprimer des géoréplicas

Autorisations nécessaires

Pour gérer les géoréplicas, votre identité a besoin des autorisations suivantes :

Portail Azure

1. Accédez à votre registre dans le portail Azure.
2. Sous Services, sélectionnez Géoréplications.
3. Sur la carte :
   • Hexagone bleu : région d’accueil (où vous avez créé le registre)
   • Hexagones verts : régions disponibles
   • Hexagones gris : régions indisponibles
4. Sélectionnez un hexagone vert, puis sélectionnez Créer.

Azure CLI

# 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

Pour plus de commandes, consultez az acr replication.

Point de terminaison global d’un registre géorépliqué

Après avoir configuré la géoréplication, vous pouvez envoyer, extraire ou supprimer du contenu dans votre Registre via le point de terminaison global du registre (myregistry.azurecr.io).

Fonctionnement des points de terminaison globaux

Lorsque vous envoyez (push), extrayez (pull) ou supprimez des images via le point de terminaison global, ACR achemine la requête vers le géoréplica présentant le meilleur profil de performances réseau pour le client.

• Le géoréplica dont le profil de performances réseau est le meilleur par rapport au client est généralement le géoréplica le plus proche.
• Toutefois, si le client se trouve à égale distance de plusieurs géorépliques ou si la géoréplique la plus proche n’est pas disponible, les requêtes peuvent être redirigées ailleurs.
• ACR gère ce routage. Vous ne contrôlez pas quel géoréplica traite une requête donnée.

Utilisation du point de terminaison global

Authentifiez :

az acr login --name myregistry

Étiquetez et poussez une image:

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

Tirez une image :

docker pull myregistry.azurecr.io/myapp:v1

Importez une image :

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

Manifeste de déploiement Kubernetes :

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

Exclure temporairement une géo-réplique du routage de point de terminaison global

Vous pouvez exclure un géoréplica du routage de point de terminaison global en désactivant le --global-endpoint-routing paramètre d’un géoréplica spécifique. Cela est utile pour la maintenance ou le dépannage, ou lorsque vous savez qu’une géoréplica spécifique ou une région Azure spécifique subit une dégradation. Vous pouvez même désactiver le routage global des points de terminaison pour le géoréplica de la région d’origine : la région d’accueil est utilisée uniquement pour les opérations du plan de contrôle et son trafic de plan de données peut être exclu en toute sécurité du routage global. Pour plus d’informations sur ce que contrôle la région d’accueil, consultez Comportement en cas de panne de la région d’accueil.

• Lorsque le --global-endpoint-routing paramètre d’un géo-réplica spécifique est défini sur false, ACR arrête le routage des requêtes vers ce géo-réplica spécifique pour les requêtes destinées au point de terminaison global.
• Les données continuent de se synchroniser de manière bidirectionnelle avec un géo-réplica, même si le routage de point de terminaison global est désactivé pour ce géo-réplica spécifique. Chaque image envoyée vers le registre depuis n’importe quelle région, alors même que le géoréplica est exclu du routage global, y est quand même répliquée. Lorsque vous réactivez le géoréplica, il est immédiatement prêt à traiter le trafic, sans phase de rattrapage.
• Par conséquent, le quota de stockage et les coûts continuent de s’accumuler pour ce géoréplica.
• Si les points de terminaison régionaux sont activés, l’URL du point de terminaison régional du géoréplica (myregistry.<region-name>.geo.azurecr.io) continue de fonctionner même si le routage global des points de terminaison est désactivé. --global-endpoint-routing contrôle uniquement la participation du géoréplica au routage des points de terminaison globaux.

# 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

Points de terminaison régionaux d’un registre géorépliqué (préversion)

Les points de terminaison régionaux fournissent des URL dédiées pour chaque réplique, vous permettant d’indiquer précisément quelle géo-réplique régionale traite votre requête d’envoi, d’extraction ou de suppression :

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

Utilisez des points de terminaison régionaux lorsque vous avez besoin des éléments suivants :

Les points de terminaison régionaux coexistent avec les points de terminaison globaux

L’activation des points de terminaison régionaux ne désactive pas ou ne remplace pas le point de terminaison global. Vous pouvez utiliser les deux simultanément :

• Utilisez le point de terminaison global (myregistry.azurecr.io) si vous préférez le routage automatique géré par Azure entre les géoréplicas.
• Utilisez des points de terminaison région (myregistry.<region-name>.geo.azurecr.io) si vous souhaitez un contrôle de routage côté client plus précis, en contournant entièrement le routage géré par Azure du point de terminaison global.

Fonctionnement des points de terminaison régionaux

Les points de terminaison régionaux fonctionnent en tant que serveurs de connexion pour des géoréplicas spécifiques. Lorsque vous authentifiez et interagissez avec un point de terminaison régional au lieu du point de terminaison global du Registre, toutes vos opérations de Registre (authentification, chargements/téléchargements d'artefacts, opérations de référentiel et actions de métadonnées) accédez directement à ce réplica régional spécifique, en contournant entièrement le routage géré par Azure.

Le téléchargement des blobs de couche (les couches réelles des images de conteneur) suit toujours la configuration existante de votre registre :

• Registres sans points de terminaison privés ou points de terminaison de données dédiés : lorsque vous téléchargez des couches d’images à partir d’un géoréplica spécifique, les téléchargements des blobs de couche sont redirigés vers des comptes de stockage Azure (*.blob.core.windows.net).
• Registres avec des points de terminaison privés ou des points de terminaison de données dédiés activés : lorsque vous téléchargez des couches d’images à partir d’un géoréplica spécifique, les téléchargements de blobs de couche sont redirigés vers le point de terminaison de données dédié de la région correspondante (myregistry.<region-name>.data.azurecr.io).

Le diagramme suivant illustre le flux de demande de point de terminaison régional :

Conditions préalables aux points de terminaison régionaux

• SKU Premium — les points de terminaison régionaux sont disponibles exclusivement sur les registres du niveau Premium.
• Azure CLI — version 2.86.0 ou ultérieure. Toutes les commandes de points de terminaison régionaux (--regional-endpoints, az acr show-endpoints, az acr login --endpoint) sont disponibles en mode natif dans Azure CLI 2.86.0+.

az extension remove --name acrregionalendpoint

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

Activer les points de terminaison régionaux

Vous pouvez activer les points de terminaison régionaux lors de la création d’un registre ou mettre à jour un registre existant.

Créez un registre avec des points de terminaison régionaux activés :

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

Activez les points de terminaison régionaux sur un registre existant :

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

Les points de terminaison régionaux sont activés au niveau du registre et s’appliquent à chaque réplica géographique. Vous ne pouvez pas activer les points de terminaison régionaux pour des répliques individuelles. Lorsque vous activez des points de terminaison régionaux, Azure Container Registry crée automatiquement des URL de serveur de connexion pour chacun de vos géoréplicas.

Utiliser des points de terminaison régionaux

Authentifier et utiliser des points de terminaison régionaux

Les points de terminaison régionaux prennent en charge les mêmes méthodes d’authentification que le point de terminaison global : Microsoft Entra ID, principaux de service, identités managées et informations d’identification d’administrateur.

Connectez-vous à un point de terminaison régional spécifique :

az acr login --name myregistry --endpoint eastus

Balisez et envoyez une image à un point de terminaison régional. Les images et les balises poussées vers une géoréplique via le point de terminaison régional seront quand même propagées à toutes les autres géorépliques selon le principe de cohérence à terme.

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

Extrayez une image à partir d’un point de terminaison régional :

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

Utiliser des points de terminaison régionaux avec l’authentification d’identité managée AKS

Les extractions d’images AKS qui s’authentifient auprès d’ACR à l’aide d’une identité managée prennent en charge les points de terminaison régionaux sur l’image de nœud AKS 202607.29 ou version ultérieure. Vérifiez l’image actuelle pour chaque pool de nœuds :

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

Pour recevoir automatiquement une image de nœud VHD compatible dès qu’elle devient disponible dans votre région et votre environnement cloud, utilisez le canal de mise à niveau automatique du système d’exploitation du NodeImagenœud. AKS Automatic utilise NodeImage ; pour AKS Standard, sélectionnez NodeImage.

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

Pour les nœuds AKS exécutant une image antérieure, utilisez un secret d’extraction d’image Kubernetes lors de l’extraction d’images à partir de points de terminaison régionaux, ou référencez le point de terminaison global (<registry-name>.azurecr.io) à la place.

Utiliser des points de terminaison régionaux incorporés dans les manifestes de déploiement

Vous pouvez spécifier des points de terminaison régionaux directement dans les manifestes de déploiement Kubernetes si vous devez épingler des charges de travail à des régions spécifiques. Cela garantit que les clusters situés dans des régions spécifiques utilisent toujours leur réplica colocalisé, assurant ainsi un routage prévisible et une latence réduite.

Déploiement de cluster USA Est :

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

Déploiement de cluster Europe Ouest :

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

En utilisant différents points de terminaison régionaux dans les manifestes de chaque cluster, vous pouvez choisir de faire en sorte que chaque cluster récupère depuis sa réplique locale au lieu de s’appuyer sur le routage géré par Azure.

Pour plus d’informations sur l’authentification des Azure Kubernetes Service (AKS) avec ACR, consultez Authenticate avec Azure Container Registry à partir de Azure Kubernetes Service.

Utiliser des points de terminaison régionaux avec le routage basé sur DNS sans modifier les manifestes de déploiement

Si vous ne souhaitez pas conserver différents manifestes de déploiement par région, vous pouvez conserver tous les manifestes pointant vers le point de terminaison global (myregistry.azurecr.io) et utiliser la mise en réseau définie par logiciel ou un gestionnaire de trafic régional pour résoudre le point de terminaison global vers le point de terminaison régional approprié en fonction du trafic de la région d’origine. Cela permet d’atteindre les mêmes objectifs de colocalisation que les points de terminaison régionaux (routage prévisible et latence réduite) sans incorporer des URL spécifiques à une région dans vos manifestes de déploiement.

Pour plus d’informations sur l’authentification des Azure Kubernetes Service (AKS) avec ACR, consultez Authenticate avec Azure Container Registry à partir de Azure Kubernetes Service.

Importer à partir de géoréplicas spécifiques à l’aide de points de terminaison régionaux

Azure Container Registry prend en charge l’importation d’images à partir d’un large éventail de registres sources entre les fournisseurs de cloud. Si la source d’importation est une ACR, vous ne pouvez importer qu’à partir de la région d’origine de l’ACR source. Les points de terminaison régionaux d’ACR source ne sont pas pris en charge en tant que sources d’importation. Spécifiez le point de terminaison global d’ACR source lors de l’importation à partir d’une ACR source. En outre, une importation écrit toujours du contenu dans la région d’accueil d’ACR en aval. Consultez la référence des points de terminaison d’Azure Container Registry.

Considérations relatives au réseau des points de terminaison régionaux

Règles de pare-feu

Si vous utilisez des règles de pare-feu ACR ou des pare-feu personnalisés avec des points de terminaison régionaux, configurez vos règles de pare-feu pour autoriser l’accès à :

Points de terminaison privés

Lorsqu’un point de terminaison privé est créé pour un registre à l’intérieur d’un réseau virtuel, la ressource de point de terminaison privé expose plusieurs adresses IP privées de réseau virtuel qui couvrent toutes les surfaces de point de terminaison du Registre , le point de terminaison global, chaque point de terminaison régional (si les points de terminaison régionaux sont activés) et chaque point de terminaison de données dédié (activé automatiquement lorsqu’un point de terminaison privé est configuré).

Chaque surface de point de terminaison consomme une adresse IP privée à partir du sous-réseau de réseau virtuel. Planifiez le dimensionnement de votre sous-réseau en conséquence :

• 1 ADRESSE IP pour le point de terminaison global (myregistry.azurecr.io)
• 1 adresse IP par géo-réplique pour les points de terminaison de données dédiés (myregistry.<region>.data.azurecr.io) — toujours activé pour les registres avec au moins un point de terminaison privé
• 1 adresse IP par géoréplique pour les points de terminaison régionaux (myregistry.<region>.geo.azurecr.io) — uniquement si les points de terminaison régionaux sont activés

Exemple : un registre avec 3 géoréplicas et points de terminaison régionaux activés nécessite 1 (global) + 3 (données) + 3 (régional) = 7 adresses IP privées par ressource de point de terminaison privé. Sans points de terminaison régionaux, le même registre nécessite 1 + 3 = 4 adresses IP privées.

Avec de nombreux géoréplicas, la création d’un point de terminaison privé peut échouer si le sous-réseau manque d’adresses IP disponibles. Pour plus d’informations, consultez Se connecter en privé à un registre à partir d’un réseau virtuel à l’aide de points de terminaison privés.

Points de terminaison de données dédiés

Lorsque les points de terminaison régionaux sont activés avec des points de terminaison de données dédiés ( activés explicitement ou activés automatiquement en ayant au moins un point de terminaison privé configuré), les téléchargements d’objets blob de couche à partir de points de terminaison régionaux redirigent automatiquement vers le point de terminaison de données dédié du géoréplica (myregistry.<region-name>.data.azurecr.io). La redirection reste toujours dans la même région que le point de terminaison régional — une extraction depuis myregistry.eastus.geo.azurecr.io redirige toujours vers myregistry.eastus.data.azurecr.io, jamais vers un point de terminaison de données situé dans une autre région.

Cette garantie de même région s’applique également lors de l’extraction à partir du point de terminaison global. ACR achemine la requête vers la géoréplique offrant le meilleur profil de performances réseau pour ce client, et la géoréplique qui traite la requête renvoie une redirection 307 vers son propre point de terminaison de données dédié, jamais vers une autre région.

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

Pour plus d’informations, consultez Points de terminaison de données dédicés dans Azure Container Registry.

Référence du point de terminaison

Pour une référence complète de tous les types de points de terminaison du registre, des formats d’URL et des options de l’interface CLI qui les contrôlent, consultez Référence des points de terminaison d’Azure Container Registry.

Résolution des problèmes

Échec de l’envoi (push) avec des erreurs de manifeste

Un docker push est une séquence de requêtes HTTP : des téléversements de blobs pour chaque couche, puis le téléversement d’un manifeste qui référence ces couches par condensat. Certains résolveurs DNS Linux ne cachent pas les réponses de manière cohérente. S'il existe plusieurs géoréplicas dans des régions voisines, le DNS peut résoudre vers différents réplicas lors d'un seul envoi (push) (DNS bouncing), ce qui amène le manifeste envoyé à référencer des couches qui ont été envoyées vers un autre géoréplica. Étant donné que la réplication est finalement cohérente, le manifeste peut atterrir sur un réplica qui n’a pas encore les couches qu’il référence, et la validation du manifeste échoue.

Solutions (par ordre de préférence) :

1. Utilisez des points de terminaison régionaux pour épingler l’envoi vers un seul géoréplica de bout en bout. Chaque sous-demande (connexion, chargements de blobs, chargement du manifeste) est envoyée vers le même géoréplica. Il s’agit du correctif le plus propre et de l’approche recommandée pour tout pipeline où la cohérence push/pull est importante.
2. Utiliser un cache DNS de courte durée comme dnsmasq limité à la durée d’un seul envoi (push). Pour les machines virtuelles Linux dans Azure, consultez les options de résolution de noms DNS. L’épinglage doit durer uniquement le temps du push, et pas plus longtemps. N’utilisez pas de cache DNS persistant pour le point de terminaison global, car cela interfère avec --global-endpoint-routing false ainsi qu’avec le routage de basculement tenant compte de l’état de santé.
3. Concevez les étapes de publication pour qu’elles soient idempotentes afin que les nouvelles tentatives déclenchées par des échecs en cours de déploiement soient sans risque.

Création de géoréplica bloquée pour les registres avec un point de terminaison privé activé

Ce problème se produit généralement lorsque l’identité qui crée un géoréplica pour un registre avec un point de terminaison privé activé ne dispose pas des autorisations suffisantes pour créer les ressources réseau du point de terminaison privé.

Solution:

• Pour résoudre ce problème, supprimez manuellement le géoréplica bloqué dans l’état de provisionnement.
• Ensuite, vérifiez que l’identité dispose de l’autorisation Microsoft.Network/privateEndpoints/privateLinkServiceProxies/write avant de créer un géoréplica.
• Vérifiez également que chaque sous-réseau de point de terminaison privé connecté au Registre dispose d’une capacité IP gratuite. Si n’importe quel sous-réseau dans n’importe quel réseau virtuel connecté n’a pas assez d’adresses IP libres, le provisionnement de la réplication échoue et est annulé. La réplique passe brièvement dans un état Creating avant d’être supprimée. L’erreur résultante n’identifie pas le sous-réseau ou le réseau virtuel épuisé. Pour obtenir des conseils de dimensionnement de sous-réseau, consultez Se connecter en privé à un registre à l’aide de points de terminaison privés.

La création de géorépliques échoue pour les registres avec un point de terminaison privé à IP statique

L’ajout d’un géo-réplica échoue lorsque le point de terminaison privé du registre est configuré avec une allocation d’adresse IP privée statique.

Chaque géoréplique possède son propre point de terminaison de données dédié, qui est exposé sur le point de terminaison privé sous la forme d’un membre ayant pour ID de groupe registry et pour nom de membre registry_data_<region>. Lorsque vous ajoutez un nouveau géoréplica, ACR demande au point de terminaison privé d’ajouter le membre correspondant au point de terminaison de données dans la nouvelle région. Un point de terminaison privé configuré avec l’allocation d’adresses IP dynamiques provisionne automatiquement l’adresse IP du nouveau membre. Un point de terminaison privé configuré avec l’allocation d’adresses IP statiques a un ensemble fixe de configurations IP définies au moment de la création et n’ajoute pas automatiquement le nouveau membre, de sorte que la création du réplica échoue avec une erreur similaire à :

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.

Pour vérifier la méthode d’allocation du point de terminaison privé d’un registre, inspectez les PrivateIPAllocationMethod configurations IP sur l’interface réseau du point de terminaison privé. Le point de terminaison privé fait référence à une interface réseau qui contient ces configurations IP. Obtenez d’abord l’ID de l’interface réseau, puis inspectez ses configurations IP :

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

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

Solutions :

• Utilisez l’allocation d’adresses IP dynamiques pour le point de terminaison privé si vous prévoyez d’ajouter des géoréplicas ultérieurement. Avec l’allocation dynamique, ACR provisionne automatiquement le membre de point de terminaison de données pour chaque nouvelle région. Il s’agit de l’approche recommandée.
• Créez le point de terminaison privé une fois que tous les géoréplicas existent si l’allocation d’adresses IP statiques est requise. Ajoutez d’abord chaque géo-réplica, puis créez le point de terminaison privé static-IP afin que sa configuration IP inclut un membre pour le point de terminaison de données de chaque région existante. Une fois qu’un point de terminaison privé IP statique est créé de cette façon, vous ne pouvez pas ajouter d’autres géoréplicas sans reconfigurer le point de terminaison privé pour ajouter le nouveau membre.

Contenu connexe

• Références SKU ACR et niveaux de service
• Informations de référence sur le point de terminaison
• Webhooks
• Points de terminaison privés
• Points de terminaison de données dédiés
• Configurer des règles d’accès au pare-feu