Replicación geográfica en Azure Container Registry

Al habilitar la replicación geográfica para una instancia de Azure Container Registry (ACR), se crean recursos de réplica geográfica en las regiones de Azure que elija. Al insertar imágenes en un registro con replicación geográfica, el contenido se sincroniza automáticamente con todas las réplicas geográficas.

Con la replicación geográfica:

• Administrar un registro: mantenga un único conjunto de credenciales, asignaciones de roles, reglas de red y configuración del Registro en todas las réplicas geográficas.
• Use un punto de conexión global: referencia myregistry.azurecr.io/myimage:tag en todas las compilaciones e implementaciones. Azure enruta las solicitudes a la réplica geográfica con el mejor perfil de rendimiento de red para el cliente, que suele ser la réplica geográfica más cercana. Sin embargo, si el cliente está a la misma distancia de varias réplicas geográficas o la réplica geográfica más cercana no está disponible, es posible que las solicitudes se redirijan a otro lugar.
• Sincronización automática: insertar etiquetas y resúmenes una vez; ACR replica el contenido y los metadatos en todas las réplicas geográficas.

La replicación geográfica requiere la SKU de nivel Premium.

Consideraciones de alta disponibilidad

Modelo de replicación

La replicación geográfica de ACR utiliza un modelo activo-activo.

• Todas las réplicas geográficas están activas y son grabables: puede insertar, extraer y eliminar imágenes desde cualquier réplica geográfica, no solo desde la réplica geográfica de la región de origen.
• Esto difiere de los modelos de replicación principal-secundaria en los que solo una región acepta escrituras y regiones secundarias son pasivas.

Modelo de coherencia

ACR usa la coherencia eventual.

• Después de insertar o eliminar una imagen en cualquier réplica geográfica, ACR replica finalmente el cambio en todas las réplicas geográficas en segundo plano.
• El tiempo de replicación depende del tamaño de la imagen. Es posible que una imagen o etiqueta enviada no esté disponible inmediatamente para su descarga en otras georréplicas si se envían grandes volúmenes de imágenes o imágenes de gran tamaño. De forma similar, es posible que una imagen o etiqueta eliminada todavía esté disponible para extraer otras réplicas geográficas hasta que la eliminación se propague.
• El tiempo necesario para crear una nueva réplica geográfica depende del tamaño total del registro. Al crear una nueva réplica geográfica, las réplicas geográficas existentes siguen gestionando con normalidad el tráfico de push, pull y eliminación. No hay ningún estado restringido ni ventana de degradación mientras la nueva réplica geográfica se recupera en segundo plano.
• Hasta que la replicación se complete en segundo plano, es posible que una réplica geográfica no tenga el contenido o los metadatos más recientes. Puede usar webhooks para recibir notificaciones cuando la replicación de una imagen cargada específica se completa en cada réplica geográfica.

Alta disponibilidad del plano de datos

La replicación geográfica mejora la disponibilidad del plano de datos manteniendo imágenes en varias regiones. Si una región sufre una interrupción, las imágenes siguen siendo accesibles desde otras georréplicas; el envío, la extracción y la eliminación siguen funcionando mediante las georréplicas restantes.

La redundancia de zona siempre está habilitada para réplicas geográficas: ACR propaga automáticamente los datos de réplica en varias zonas de disponibilidad para protegerse frente a interrupciones zonales.

Conmutación por error con reconocimiento de estado

ACR supervisa automáticamente el estado de cada réplica geográfica y vuelve a enrutar el tráfico global del punto de conexión fuera de las réplicas geográficas que no pueden atender solicitudes de forma confiable. Esto se denomina conmutación por error con reconocimiento de estado. ACR dirige el tráfico global de los puntos de conexión en función del estado del servicio ACR y del estado de la infraestructura regional de Azure.

• Automática y por registro: el estado de salud se evalúa de forma individual para cada registro, no por región. Si una degradación afecta solo a un subconjunto de registros de una región, solo se vuelven a enrutar esos registros; otros registros de la misma región siguen siendo servidos localmente sin penalización de latencia innecesaria.
• Tiempo: el reenrutamiento de un extremo a otro está en el orden de los minutos, lo suficientemente rápido como para detectar la degradación regional real y lo suficientemente lento como para alejar los errores transitorios que se resuelven por sí mismos. El TTL de DNS podría agregar un retraso de propagación antes de que todos los clientes cambien a la nueva región.
• No se requiere ninguna acción del cliente: no hay ningún desencadenador invocable por el cliente. La conmutación por error con reconocimiento de estado está administrada totalmente por la plataforma.
• La conmutación por recuperación es automática: una vez que la evaluación del estado regional de una réplica geográfica vuelve a superarse, por ejemplo, cuando se recupera el ACR regional o la infraestructura de Azure, el punto de conexión global puede reanudar el enrutamiento del tráfico a la réplica geográfica de la región de Azure recuperada.
• No se desencadena por limitación: la conmutación por error con reconocimiento de estado se basa en DNS y responde al estado del servicio del ACR regional y al estado de la infraestructura de Azure. No reenruta el tráfico en función de respuestas HTTP 429 (limitación). Si una réplica geográfica está limitando tus solicitudes, pero la infraestructura de la región funciona correctamente, el punto de conexión global sigue dirigiendo tus solicitudes a esa réplica geográfica. Para administrar la limitación, use puntos de conexión regionales para distribuir las cargas de trabajo entre varias réplicas geográficas y lograr una mejor distribución de la capacidad.

Ámbito de la conmutación por error con reconocimiento de estado:

La conmutación por error con reconocimiento de estado solo se aplica a las operaciones en el punto de conexión global (myregistry.azurecr.io). No se aplica a:

• Puntos de conexión regionales : cuando se usa un punto de conexión regional (myregistry.<region>.geo.azurecr.io), se habla directamente con una réplica geográfica específica. Si esa región se degrada, ACR no redirige automáticamente el tráfico. Implemente conmutación por error del lado cliente cambiando a otro punto de conexión regional.
• Puntos de conexión de datos dedicados : una vez que un punto de conexión del Registro le redirige a un punto de conexión de datos dedicado para una descarga de capa, permanece en el punto de conexión de datos de esa región durante toda la descarga. La región se decide de antemano en función del punto de conexión del registro que ha atendido la llamada a ubicación del blob.

Limitación durante la conmutación por error:

Los límites de limitación de las operaciones de la API son por réplica. Durante una conmutación por error con reconocimiento de estado, el tráfico que se distribuía entre varias réplicas geográficas puede concentrarse en gran medida en las réplicas geográficas que permanezcan en el grupo de enrutamiento del punto de conexión global. Plan de capacidad tendrá al menos dos o tres réplicas geográficas para que el tráfico pueda distribuirse entre varias réplicas geográficas correctas durante una conmutación por error. Los registros con solo dos regiones pueden alcanzar los límites de limitación por réplica más fácilmente cuando una región no está disponible. Para mitigarlo, use puntos de conexión regionales para distribuir las cargas de trabajo entre varias réplicas geográficas y planear la capacidad por réplica.

Cómo confirmar una conmutación por error:

• Azure portal: vaya al registro y seleccione Resource health en la sección Help para ver las señales de degradación del lado de la plataforma.
• CLI de Azure: compruebe el estado de replicación con az acr replication list --registry myregistry --output table. Las réplicas geográficas que experimentan problemas muestran un estado distinto de online.
• Azure Monitor: las métricas de la plataforma se recopilan automáticamente. Habilite la configuración de diagnóstico para los registros de recursos para obtener telemetría detallada.

Comportamiento ante interrupciones de la región de origen

La región principal es la región donde creó originalmente el registro. Hospeda el plano de control del Registro, que administra la configuración del Registro. La región principal se fija en la creación y no se puede cambiar después. Para mover un registro a otra región principal, consulte Relocate Azure Container Registry, que describe un procedimiento de reimplementación (creación de un nuevo registro), no un cambio en contexto.

Si la región principal deja de estar disponible, el efecto se limita a las operaciones del plano de control (administración). Todas las operaciones del plano de datos siguen funcionando a través de las réplicas geográficas restantes.

Lo que sigue funcionando durante una interrupción de la región de origen:

• Inserción, extracción y eliminación de imágenes: los clientes pueden insertar, extraer y eliminar imágenes de cualquier réplica geográfica disponible mediante el punto de conexión global (myregistry.azurecr.io) o cualquier punto de conexión regional disponible (myregistry.<region>.geo.azurecr.io). ACR enruta automáticamente las solicitudes de punto de conexión global a una réplica geográfica correcta.
• Autenticación: todos los métodos de autenticación siguen funcionando, incluidos Microsoft Entra ID, entidades de servicio, identidades administradas y tokens con ámbito de repositorio. Los clientes pueden autenticarse en cualquier réplica geográfica disponible sin necesidad de cambiar las credenciales, los tokens o las direcciones URL del Registro.
• Entrega de webhook: los webhooks configurados para las réplicas geográficas disponibles se siguen activando. Una sola inserción genera eventos de webhook desde la réplica geográfica receptora, además de eventos de cada réplica geográfica a medida que se completa la replicación. Los consumidores de webhooks deben diseñarse para controlar varios eventos por cada imagen insertada y eliminar duplicados según sea necesario.
• Puntos de conexión regionales : si los puntos de conexión regionales están habilitados, siguen funcionando de forma independiente. Los clientes pueden comunicarse directamente con réplicas geográficas específicas mediante direcciones URL de punto de conexión regionales.

Lo que no está disponible durante una interrupción de la región principal:

• Enrutamiento del punto de conexión global a la réplica geográfica de la región principal — La detección de estado de ACR detiene automáticamente el enrutamiento del tráfico del punto de conexión global a la réplica geográfica de la región principal y lo redirige a réplicas geográficas en buen estado.
• Punto de conexión regional para la región principal : el punto de conexión regional de la región principal (myregistry.<home-region>.geo.azurecr.io) no está disponible mientras la región principal está inactiva. Los puntos de conexión regionales para otras réplicas geográficas siguen funcionando de forma independiente.
• Cambios en la configuración del Registro : no se pueden modificar las propiedades del Registro, como reglas de red, configuración de replicación o configuraciones de zona de disponibilidad hasta que se recupere la región principal.
• Tareas de ACR : las tareas están enlazadas a la región principal y no se ejecutan mientras no está disponible.

Consideraciones sobre el nivel de servicio y los límites

Azure Container Registry los niveles de servicio y los límites se aplican a cada réplica geográfica de forma independiente.

Algunos límites de nivel de servicio tienen la siguiente consideración especial:

• Límites de almacenamiento: los límites de almacenamiento para el nivel de servicio se comparten en todas las réplicas geográficas. Por ejemplo, si inserta una imagen de 1 GiB y se replica en 5 réplicas geográficas, solo 1 GiB se contabiliza para los límites máximos de almacenamiento del nivel.
• Límites de velocidad de API: los límites de control establecidos para las operaciones de API, como el número de lecturas y escrituras por minuto, son específicos de cada réplica geográfica. Use puntos de conexión regionales para distribuir cargas de trabajo entre varias réplicas geográficas para mejorar la distribución de la capacidad y evitar concentrar todo el tráfico en una sola réplica geográfica.

Para más información sobre los niveles de servicio y los límites, consulte Niveles de servicio de ACR.

Consideraciones sobre precios

• Facturación de almacenamiento: el almacenamiento se factura por réplica geográfica. Por ejemplo, una imagen de 1 GiB replicada en 5 réplicas geográficas se cobra como 5 GiB de almacenamiento (1 GiB × 5 réplicas geográficas).
• Transferencia de datos: la replicación geográfica puede reducir los costos mediante la habilitación de inserciones y extracción de imágenes en la región, lo que evita cargos de transferencia de datos entre regiones durante estas operaciones de inserción o extracción. Sin embargo, los cargos por transferencia de datos entre regiones se siguen aplicando cuando ACR replica el contenido cargado en otras réplicas geográficas como parte de la coherencia eventual.

Para obtener más información, consulte Precios de ACR.

Agregar o eliminar réplicas geográficas

Permisos necesarios

Para administrar réplicas geográficas, tu identidad necesita estos permisos:

Portal de Azure

1. Vaya al registro en Azure Portal.
2. En Servicios, seleccione Replicaciones geográficas.
3. En el mapa:
   • Hexágono azul: región principal (donde creó el registro)
   • Hexágonos verdes: regiones disponibles
   • Hexágonos grises: regiones no disponibles
4. Seleccione un hexágono verde y, a continuación, seleccione Crear.

CLI de 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

Para obtener más comandos, consulte az acr replication.

Punto de conexión global de un registro con replicación geográfica

Después de configurar la replicación geográfica, puede insertar, extraer o eliminar contenido en el registro a través del punto de conexión global del registro (myregistry.azurecr.io).

Funcionamiento de los puntos de conexión globales

Cuando inserta, extrae o elimina a través del punto de conexión global, ACR enruta la solicitud a la réplica geográfica con el mejor perfil de rendimiento de red para el cliente.

• La réplica geográfica con el mejor perfil de rendimiento de red del cliente suele ser la réplica geográfica más cercana.
• Sin embargo, si el cliente está a la misma distancia de varias réplicas geográficas o la réplica geográfica más cercana no está disponible, es posible que las solicitudes se redirijan a otro lugar.
• ACR gestiona este enrutamiento. No puede controlar qué réplica geográfica atiende una solicitud específica.

Uso del punto de conexión global

Autenticación:

az acr login --name myregistry

Etiquete e inserte una imagen:

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

Descargar una imagen:

docker pull myregistry.azurecr.io/myapp:v1

Importar una imagen:

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

Manifiesto de implementación de Kubernetes:

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

Excluir temporalmente una réplica geográfica del enrutamiento global de puntos de conexión

Puede excluir una réplica geográfica del enrutamiento global de puntos de conexión desactivando la configuración --global-endpoint-routing para una réplica geográfica específica. Esto es útil para el mantenimiento o la solución de problemas, o cuando sabe que una réplica geográfica específica o Azure región está experimentando una degradación. Incluso puede deshabilitar el enrutamiento global de puntos de conexión para la réplica geográfica de la región principal: la región principal solo se usa para las operaciones del plano de control y su tráfico del plano de datos se puede excluir de forma segura del enrutamiento global. Para obtener más información sobre los controles de la región principal, consulte Comportamiento de interrupción de la región principal.

• Cuando la configuración --global-endpoint-routing de una réplica geográfica específica se establece en false, ACR deja de enrutar las solicitudes a esa réplica geográfica específica para las solicitudes que se dirigen al punto de conexión global.
• Los datos continúan sincronizando de forma bidireccional con una réplica geográfica incluso si el enrutamiento global de puntos de conexión está deshabilitado para esa réplica geográfica específica. Cada imagen insertada en el registro desde cualquier región, mientras la réplica geográfica esté excluida del enrutamiento global, se sigue replicando en ella. Al volver a habilitar la réplica geográfica, estará lista de inmediato para recibir tráfico, sin necesidad de una ventana de recuperación.
• Por lo tanto, la cuota de almacenamiento y los costos continúan acumulándose para esa réplica geográfica.
• Si los puntos de conexión regionales están habilitados, la dirección URL del punto de conexión regional de la réplica geográfica (myregistry.<region-name>.geo.azurecr.io) sigue funcionando incluso mientras el enrutamiento global de puntos de conexión está deshabilitado. --global-endpoint-routing controla solo la participación de la réplica geográfica en el enrutamiento global de puntos de conexión.

# 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

Puntos de conexión regionales de un registro con replicación geográfica (versión preliminar)

Los puntos de conexión regionales proporcionan direcciones URL dedicadas para cada réplica, lo que le permite especificar exactamente qué réplica geográfica regional controla la solicitud de inserción, extracción o eliminación:

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

Use puntos de conexión regionales cuando necesite:

Los puntos de conexión regionales coexisten con puntos de conexión globales

La habilitación de puntos de conexión regionales no deshabilita ni reemplaza el punto de conexión global. Puede usar ambos simultáneamente:

• Use el punto de conexión global (myregistry.azurecr.io) si prefiere el enrutamiento automático administrado por Azure entre réplicas geográficas.
• Use puntos de conexión regional (myregistry.<region-name>.geo.azurecr.io) si desea un control de enrutamiento más específico del lado cliente, omitiendo completamente el enrutamiento administrado por Azure del punto de conexión global.

Funcionamiento de los puntos de conexión regionales

Los puntos de conexión regionales funcionan como servidores de inicio de sesión para réplicas geográficas específicas. Al autenticar e interactuar con un punto de conexión regional en lugar del punto de conexión global del Registro, todas las operaciones del Registro (autenticación, cargas y descargas de artefactos, operaciones de repositorio y acciones de metadatos) van directamente a esa réplica regional específica, pasando por completo el enrutamiento administrado por Azure.

Las descargas de blobs en capas (las capas de imagen de contenedores reales) siguen la configuración existente del registro:

• Registros sin puntos de conexión privados ni puntos de conexión de datos dedicados: al descargar capas de imagen desde una réplica geográfica específica, las descargas de blobs de capa se redirigen a cuentas de Azure Storage (*.blob.core.windows.net).
• Registros con puntos de conexión privados o puntos de conexión de datos dedicados habilitados: al descargar capas de imagen desde una réplica geográfica específica, la descarga de blobs de capa se redirige al punto de conexión de datos dedicado de la región correspondiente (myregistry.<region-name>.data.azurecr.io).

En el diagrama siguiente se muestra el flujo de solicitud del punto de conexión regional:

Requisitos previos de los puntos de conexión regionales

• SKU Premium : los puntos de conexión regionales están disponibles exclusivamente en los registros de nivel Premium .
• CLI de Azure: versión 2.86.0 o posterior. Todos los comandos de puntos de conexión regionales (--regional-endpoints, az acr show-endpoints, az acr login --endpoint) están disponibles de forma nativa en CLI de Azure 2.86.0+.

az extension remove --name acrregionalendpoint

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

Habilitación de puntos de conexión regionales

Puede habilitar puntos de conexión regionales al crear un nuevo registro o actualizar un registro existente.

Cree un registro con puntos de conexión regionales habilitados:

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

Habilite los puntos de conexión regionales en un registro existente:

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

Los puntos de conexión regionales están habilitados en el nivel del Registro y se aplican a todas las réplicas geográficas. No se pueden habilitar puntos de conexión regionales para réplicas individuales. Al habilitar puntos de conexión regionales, Azure Container Registry crea automáticamente direcciones URL del servidor de inicio de sesión para cada una de las réplicas geográficas.

Trabajar con puntos de conexión regionales

Autenticación y uso de puntos de conexión regionales

Los puntos de conexión regionales admiten los mismos métodos de autenticación que el punto de conexión global: Microsoft Entra ID, entidades de servicio, identidades administradas y credenciales de administrador.

Inicie sesión en un punto de conexión regional específico:

az acr login --name myregistry --endpoint eastus

Etiquete y envíe una imagen a un endpoint regional. Las imágenes y etiquetas insertadas en una réplica geográfica a través del punto de conexión regional se propagarán a todas las demás réplicas geográficas con coherencia final.

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

Extraiga una imagen de un punto de conexión regional:

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

Uso de puntos de conexión regionales insertados en manifiestos de implementación

Puede especificar puntos de conexión regionales directamente en manifiestos de implementación de Kubernetes si necesita anclar cargas de trabajo a regiones específicas. Esto garantiza que los clústeres de regiones específicas siempre extraigan desde su réplica coubicada, lo que proporciona enrutamiento predecible y latencia reducida.

Implementación del clúster este de EE. UU.:

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

Implementación del clúster de Oeste de Europa:

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

Al usar diferentes puntos de conexión regionales en los manifiestos de cada clúster, puede optar por garantizar que cada clúster extraiga desde su réplica local en lugar de depender del enrutamiento administrado por Azure.

Para obtener información sobre cómo autenticar Azure Kubernetes Service (AKS) con ACR, consulte Authenticate con Azure Container Registry de Azure Kubernetes Service.

Uso de puntos de conexión regionales con enrutamiento basado en DNS sin cambiar los manifiestos de implementación

Si no desea mantener diferentes manifiestos de implementación por región, puede mantener todos los manifiestos que apuntan al punto de conexión global (myregistry.azurecr.io) y usar redes definidas por software o un administrador de tráfico regional para resolver el punto de conexión global en el punto de conexión regional adecuado en función del tráfico de la región de origen. Esto logra los mismos objetivos de colocación que los puntos de conexión regionales (enrutamiento predecible y latencia reducida) sin insertar direcciones URL específicas de la región en los manifiestos de implementación.

Para obtener información sobre cómo autenticar Azure Kubernetes Service (AKS) con ACR, consulte Authenticate con Azure Container Registry de Azure Kubernetes Service.

Importación desde réplicas geográficas específicas mediante puntos de conexión regionales

Al importar imágenes entre registros, puede usar puntos de conexión regionales para importar desde una réplica geográfica específica del registro de origen. Esto es útil para escenarios en los que desea rutas de acceso de red predecibles o necesita importar desde una réplica en una región específica.

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

Consideraciones de red de puntos de conexión regionales

Reglas de firewall

Si usa reglas de firewall de ACR o firewalls personalizados con puntos de conexión regionales, configure las reglas de firewall para permitir el acceso a:

Puntos de conexión privados

Cuando se crea un punto de conexión privado para un registro dentro de una red virtual, el recurso de punto de conexión privado expone varias direcciones IP privadas de red virtual que cubren todas las superficies de punto de conexión del Registro, el punto de conexión global, cada punto de conexión regional (si están habilitados los puntos de conexión regionales) y cada punto de conexión de datos dedicado (habilitado automáticamente cuando se configura un punto de conexión privado).

Cada superficie de punto de conexión consume una dirección IP privada de la subred de la red virtual. Planee el ajuste de tamaño de la subred según corresponda:

• 1 IP para el extremo global (myregistry.azurecr.io)
• 1 IP por réplica geográfica para puntos de conexión de datos dedicados (myregistry.<region>.data.azurecr.io): siempre habilitado en registros con al menos un punto de conexión privado
• 1 IP por réplica geográfica para puntos de conexión regionales (myregistry.<region>.geo.azurecr.io): solo si los puntos de conexión regionales están habilitados

Ejemplo: Un registro con 3 réplicas geográficas y puntos de conexión regionales habilitados requiere 1 (global) + 3 (datos) + 3 (regional) = 7 direcciones IP privadas por recurso de punto de conexión privado. Sin puntos de conexión regionales, el mismo registro requiere 1 + 3 = 4 direcciones IP privadas.

Con muchas réplicas geográficas, se puede producir un error en la creación de puntos de conexión privados si la subred se queda sin direcciones IP disponibles. Para más información, consulte Conexión privada a un registro desde una red virtual mediante puntos de conexión privados.

Puntos de conexión de datos dedicados

Cuando los extremos regionales están habilitados junto con extremos de datos dedicados —ya sea habilitados explícitamente o habilitados automáticamente por tener configurado al menos un extremo privado—, las descargas de blobs de capa desde los extremos regionales se redirigen automáticamente al extremo de datos dedicado de la georréplica (myregistry.<region-name>.data.azurecr.io). La redirección siempre permanece dentro de la misma región que el punto de conexión regional: una extracción de myregistry.eastus.geo.azurecr.io siempre redirige a myregistry.eastus.data.azurecr.io, nunca a un punto de conexión de datos en otra región.

Esta garantía de misma región también se aplica al extraer desde el punto de conexión global. ACR enruta la solicitud a la réplica geográfica con el mejor perfil de rendimiento de red para el cliente, y la réplica geográfica de servicio emite una redirección 307 a su propio punto de conexión de datos dedicado, nunca entre regiones.

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

Para obtener más información, consulte Puntos de conexión de datos dedicados en Azure Container Registry.

Referencia de puntos de conexión

Para obtener una referencia completa de todos los tipos de puntos de conexión del registro, los formatos de URL y las opciones de la CLI que los controlan, consulte la referencia de puntos de conexión de Azure Container Registry.

Solución de problemas

Fallo de inserción con errores manifiestos

Un docker push es una secuencia de solicitudes HTTP: cargas de blobs para cada capa, seguidas de una carga de manifiesto que hace referencia a esas capas por resumen. Algunos solucionadores DNS de Linux no almacenan en caché las respuestas de forma coherente. Si hay varias réplicas geográficas en regiones cercanas, el DNS puede solucionar diferentes réplicas durante una sola inserción (rebote del DNS), lo que provoca que el manifiesto insertado haga referencia a capas que se insertaron en una réplica geográfica diferente. Dado que la replicación es finalmente coherente, el manifiesto puede aterrizar en una réplica que aún no tiene las capas a las que hace referencia y se produce un error en la validación del manifiesto.

Soluciones (en orden de preferencia):

1. Utilice extremos regionales para anclar la inserción a una sola réplica geográfica de un extremo a otro. Cada subsolicitud (inicio de sesión, cargas de blobs, carga de manifiesto) se dirige a la misma réplica geográfica. Esta es la solución más limpia y el enfoque recomendado para cualquier flujo de trabajo en el que la coherencia entre push y pull sea importante.
2. Utilice una caché DNS de corta duración como dnsmasq con alcance limitado a la duración de un solo push. Para las máquinas virtuales Linux en Azure, consulte Opciones de resolución de nombres DNS. El anclaje debe durar la inserción y no más; no utilice caché de DNS de larga duración para el punto de conexión global, ya que interfiere con --global-endpoint-routing false y con el enrutamiento de conmutación por error con reconocimiento de estado.
3. Diseñe pasos de publicación idempotentes para que sean seguros los reintentos desencadenados por errores en medio de la inserción.

Creación de réplicas geográficas bloqueada para registros habilitados para puntos de conexión privados

Este problema suele surgir cuando la identidad que crea una réplica geográfica para un registro habilitado para punto de conexión privado no tiene permisos suficientes para crear recursos de red de punto de conexión privado.

Solución:

• Para solucionarlo, elimine manualmente la réplica geográfica que se ha quedado bloqueada en el estado de aprovisionamiento.
• Después, asegúrese de que la identidad tiene el permiso Microsoft.Network/privateEndpoints/privateLinkServiceProxies/write antes de crear una réplica geográfica.
• Compruebe también que todas las subredes de punto de conexión privado conectadas al registro tienen capacidad ip libre. Si alguna subred de cualquier red virtual conectada no tiene suficientes direcciones IP libres, el aprovisionamiento de la replicación falla y se revierte. La réplica aparece brevemente en un estado Creating y luego se quita. El error resultante no identifica qué subred o red virtual se agota. Para obtener instrucciones de ajuste de tamaño de subred, consulte Conexión privada a un registro mediante puntos de conexión privados.

La creación de georréplicas falla en los registros con un punto de conexión privado con IP estática

Se produce un error al agregar una réplica geográfica cuando el punto de conexión privado del Registro está configurado con la asignación de IP privada estática .

Cada réplica geográfica tiene su propio extremo de datos dedicado, que se expone en el extremo privado como miembro con el identificador de grupo registry y el nombre de miembro registry_data_<region>. Al agregar una nueva georréplica, ACR solicita que el endpoint privado agregue el miembro al endpoint de datos de la nueva región. Un punto de conexión privado configurado con asignación de IP dinámica aprovisiona automáticamente la dirección IP del nuevo miembro. Un punto de conexión privado configurado con asignación de IP estática tiene un conjunto fijo de configuraciones IP definidas en el momento de la creación y no agrega automáticamente el nuevo miembro, por lo que se produce un error similar al siguiente:

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.

Para comprobar el método de asignación del punto de conexión privado de un registro, inspeccione las PrivateIPAllocationMethod configuraciones de IP en la interfaz de red del punto de conexión privado. El punto de conexión privado hace referencia a una interfaz de red que contiene estas configuraciones IP, por lo que primero obtiene el identificador de la interfaz de red y, a continuación, inspecciona sus configuraciones 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

Soluciones:

• Utilice la asignación dinámica de direcciones IP para el extremo privado si espera agregar georréplicas más adelante. Con la asignación dinámica, ACR aprovisiona automáticamente el miembro del punto de conexión de datos para cada nueva región. Este es el enfoque recomendado.
• Cree el punto de conexión privado una vez creadas todas las georréplicas si se requiere una asignación estática de direcciones IP. Agregue primero cada réplica geográfica y, a continuación, cree el punto de conexión privado static-IP para que su configuración de IP incluya un miembro para cada punto de conexión de datos de la región existente. Después de crear un punto de conexión privado static-IP de esta manera, no puede agregar más réplicas geográficas sin volver a configurar el punto de conexión privado para agregar el nuevo miembro.

Contenido relacionado

• SKU de ACR y niveles de servicio
• Referencia del punto de conexión
• Webhooks
• Puntos de conexión privados
• Puntos de conexión de datos dedicados
• Configuración de reglas de acceso de firewall