Replicación geográfica en Azure Container Registry
Las empresas que quieran tener una presencia local o una copia de seguridad activa, pueden optar por ejecutar servicios desde varias regiones de Azure. Como procedimiento recomendado, si coloca un registro de contenedor en cada región donde se ejecuten imágenes, podrá realizar operaciones cercanas a la red y habilitar transferencias de capa de imagen rápidamente y de forma fiable. La replicación geográfica permite que un registro de contenedor de Azure funcione como un registro único que atienda a varias regiones con varios registros regionales maestros.
Un registro con replicación geográfica le proporciona las siguientes ventajas:
- Nombres de registro, imagen y etiqueta únicos que se pueden usar en varias regiones.
- Mejora el rendimiento y la confiabilidad de las implementaciones regionales con acceso al registro de cierre de red.
- Reduce los costos de transferencia de datos mediante la extracción de capas de imagen de un registro local y replicado en la misma región del host de contenedor, o en una región cercana.
- Administración única de un registro en varias regiones.
- Resistencia del registro si se produce una interrupción regional
Nota
- Si necesita mantener copias de las imágenes de contenedor en más de un registro de contenedor de Azure, Azure Container Registry también admite la importación de imágenes. Por ejemplo, en un flujo de trabajo de DevOps, puede importar una imagen desde un registro de desarrollo a un registro de producción, sin necesidad de usar comandos de Docker.
- Si quiere mover un registro a otra región de Azure en lugar de replicarlo geográficamente, consulte Traslado manual de un registro de contenedor a otra región.
Ejemplo de caso de uso
Contoso ejecuta un sitio web de presencia pública ubicado en los Estados Unidos, Canadá y Europa. Para poder atender a estos mercados con contenido local y cercano a la red, Contoso ejecuta los clústeres de Azure Kubernetes Service (AKS) en el Este y Oeste de EE. UU, Centro de Canadá y Oeste de Europa. La aplicación del sitio web se implementa como una imagen de Docker y utiliza el mismo código e imagen en todas las regiones. El contenido (que es local en esa región) se recupera de una base de datos que se aprovisiona de forma única en cada región. Cada implementación regional tiene su configuración única para recursos tales como la base de datos local.
El equipo de desarrollo que está ubicado en Seattle (WA) usará el centro de datos del Oeste de EE. UU.
Inserciones en varios registros
Antes de usar las características de replicación geográfica, Contoso tenía un registro basado en los Estados Unidos de la zona Oeste de EE. UU. con un registro adicional en Oeste de Europa. Para dar servicio a estas regiones, el equipo de desarrollo tenía que insertar imágenes en dos registros diferentes.
docker push contoso.azurecr.io/public/products/web:1.2
docker push contosowesteu.azurecr.io/public/products/web:1.2
Extracciones desde varios registros
Entre los desafíos típicos de tener varios registros se incluyen:
- Todos los clústeres del Este de EE. UU., el Oeste de EE. UU. y Centro de Canadá extraen contenido del registro del Oeste de EE. UU., por lo que se aplican cuotas de salida cada vez que uno de esos hosts de contenedor remotos extrae imágenes de los centros de datos del Oeste de EE. UU.
- El equipo de desarrollo debe insertar imágenes en los registros del Oeste de EE. UU. y Oeste de Europa.
- El equipo de desarrollo debe configurar y mantener todas las implementaciones regionales con nombres de imagen que hagan referencia al registro local.
- El acceso al registro debe configurarse para cada región.
Ventajas de la replicación geográfica
Al usar la característica de replicación geográfica de Azure Container Registry, disfrutará de las siguientes ventajas:
- Podrá administrar un registro único en todas las regiones:
contoso.azurecr.io. - Podrá administrar una única configuración de las implementaciones de imagen, ya que todas las regiones usan la misma dirección URL de imagen:
contoso.azurecr.io/public/products/web:1.2. - Inserción en un único registro, mientras ACR administra automáticamente la replicación geográfica. ACR solo replica capas únicas, lo que reduce la transferencia de datos entre regiones.
- Configure webhooks regionales para recibir notificaciones sobre los eventos de réplicas específicas.
- Proporcione un registro de alta disponibilidad que sea resistente a las interrupciones regionales.
Azure Container Registry también admite zonas de disponibilidad para crear un registro de contenedor de Azure de alta disponibilidad y resistente en una región de Azure. La combinación de zonas de disponibilidad para la redundancia dentro de una región y la replicación geográfica en varias regiones mejora la confiabilidad y el rendimiento de un registro.
Configuración de la replicación geográfica
Configurar la replicación geográfica es tan fácil como hacer clic en las regiones de un mapa. También puede administrar la replicación geográfica mediante herramientas como los comandos az acr replication de la CLI de Azure, o implementar un registro habilitado para la replicación geográfica con una plantilla de Azure Resource Manager.
La replicación geográfica es una característica de los registros Premium. Si el registro no es Premium, puede cambiarlo de Básico y Estándar a Premium en Azure Portal:
Para configurar la replicación geográfica del registro Premium, inicie sesión en Azure Portal en https://portal.azure.com.
Vaya a Azure Container Registry y seleccione Replicaciones:
Se mostrará un mapa que indica todas las regiones de Azure actuales:
- Los hexágonos azules representan las réplicas actuales.
- Los hexágonos verdes representan las regiones de réplica posibles.
- Los hexágonos grises representan regiones de Azure que aún no están disponibles para la replicación.
Para configurar una réplica, seleccione un hexágono verde y, a continuación, seleccione Crear:
Para configurar réplicas adicionales, seleccione los hexágonos verdes de otras regiones y, a continuación, haga clic en Crear.
ACR comenzará entonces a sincronizar imágenes entre las réplicas configuradas. Una vez completada la operación, el portal muestra el mensaje Listo. Tenga en cuenta que el estado de la réplica no se actualiza de forma automática en el portal. Para ver el estado actualizado, use el botón Actualizar.
Consideraciones sobre el uso de un registro con replicación geográfica
- Cada región de un registro con replicación geográfica es independiente una vez configurada. Los Acuerdos de Nivel de Servicio de Azure Container Registry se aplican a cada región con replicación geográfica.
- Al insertar o extraer imágenes de un registro con replicación geográfica, Azure Traffic Manager en segundo plano envía la solicitud al registro ubicado en la región más cercana a usted en cuanto a latencia de red.
- Después de insertar una imagen o una actualización de etiqueta en la región más cercana, Azure Container Registry tarda un rato en replicar los manifiestos y las capas en el resto de regiones que participan. Las imágenes más grandes tardan más en replicarse que las más pequeñas. Las imágenes y etiquetas se sincronizan entre las regiones de replicación con un modelo de coherencia final.
- Para administrar flujos de trabajo que dependen de actualizaciones de inserción para un registro con replicación geográfica, se recomienda configurar webhooks para responder a los eventos de inserción. Puede configurar webhooks regionales dentro de un registro con replicación geográfica para realizar un seguimiento de los eventos de inserción a medida que se completan en las regiones con replicación geográfica.
- Para prestar servicio a los blobs que representan capas de contenido, Azure Container Registry usa puntos de conexión de datos. Puede habilitar puntos de conexión de datos dedicados para el registro en cada una de las regiones con replicación geográfica del registro. Estos puntos de conexión permiten la configuración de reglas de acceso de firewall con ámbito estricto. Para solucionar los problemas, tiene la opción de deshabilitar el enrutamiento a una replicación mientras mantiene los datos replicados.
- Si configura un vínculo privado para el registro mediante puntos de conexión privados de una red virtual, los puntos de conexión de datos dedicados de cada una de las regiones con replicación geográfica se habilitan de forma predeterminada.
Consideraciones para la alta disponibilidad
- Para lograr alta disponibilidad y resistencia, se recomienda crear un registro en una región que admita la habilitación de la redundancia de zona. También se recomienda habilitar la redundancia de zona en todas las regiones de réplica.
- Si se produce una interrupción en la región principal del registro (la región donde se ha creado) o en una de sus regiones de réplica, un registro con replicación geográfica sigue estando disponible para las operaciones del plano de datos, como las de inserción o extracción de imágenes de contenedor.
- Si la región principal del registro deja de estar disponible, es posible que no pueda realizar operaciones de administración de registros, incluida la configuración de reglas de red, la habilitación de zonas de disponibilidad y la administración de réplicas.
- Para planificar la alta disponibilidad de un registro con replicación geográfica cifrado con una clave administrada por el cliente almacenada en un almacén de claves de Azure, revise las instrucciones para la conmutación por error y la redundancia del almacén de claves.
Eliminación de una réplica
Después de configurar una réplica para el registro, puede eliminarla en cualquier momento cuando ya no sea necesaria. Elimine una réplica mediante Azure Portal u otras herramientas, como el comando az acr replication delete de la CLI de Azure.
Para eliminar una réplica en Azure Portal:
- Vaya a Azure Container Registry y seleccione Replicaciones.
- Seleccione el nombre de una réplica y, luego, Eliminar. Confirme que quiere eliminar la réplica.
Para usar la CLI de Azure para eliminar una réplica de myregistry en la región Este de EE. UU.:
az acr replication delete --name eastus --registry myregistry
Precios de la replicación geográfica
La replicación geográfica es una característica del nivel de servicio Premium de Azure Container Registry. Cuando replica un registro en las áreas indicadas, se aplica la tarifa del registro Premium para cada región.
En el ejemplo anterior, Contoso consolidó dos registros en uno y agregó réplicas en el Este de EE. UU., Centro de Canadá y Oeste de Europa. Por ello, pagaría cuatro veces al mes la tarifa Premium y sin tener ninguna configuración o administración adicional. Ahora, cada región extrae sus imágenes de forma local, lo que mejora el rendimiento y la confiabilidad sin tener que aplicar ninguna tarifa de salida de red desde las regiones del Oeste de EE. UU., Canadá y el Este de EE. UU.
Solución de problemas de operaciones de inserción con registros con replicación geográfica
Es posible que un cliente de Docker que inserte una imagen en un registro con replicación geográfica no inserte todas las capas de imagen y su manifiesto en una sola región replicada. Esto puede deberse a que Azure Traffic Manager enruta las solicitudes del registro al registro replicado más cercano a la red. Si el registro tiene dos regiones de replicación cercanas, las capas de imagen y el manifiesto se pueden distribuir a los dos sitios, y se produce un error en la operación de extracción cuando se valida el manifiesto. Este problema se produce debido a la manera en que el nombre DNS del registro se resuelve en algunos hosts de Linux. Este problema no se produce en Windows, que proporciona una memoria caché de DNS del lado cliente.
Si ocurre este problema, una solución consiste en aplicar una caché DNS del lado cliente como dnsmasq en el host de Linux. Ayuda a garantizar que el nombre del registro se resuelva de forma coherente. Si usa una máquina virtual Linux en Azure para enviarla a un registro, consulte las opciones en Opciones de resolución de nombres DNS para máquinas virtuales Linux en Azureen Azure.
Para optimizar la resolución DNS para la réplica más cercana al insertar imágenes, configure un registro con replicación geográfica en las mismas regiones de Azure que el origen de las operaciones de inserción o la región más cercana cuando trabaje fuera de Azure.
Deshabilitación temporal del enrutamiento a replicaciones
Para solucionar los problemas de las operaciones con un registro con replicación geográfica, debería deshabilitar temporalmente el enrutamiento de Traffic Manager a una o más replicaciones. A partir de la CLI de Azure versión 2.8, puede configurar una opción --region-endpoint-enabled (versión preliminar) al crear o actualizar una región replicada. Cuando se establece la opción --region-endpoint-enabled de una replicación en false, Traffic Manager deja de enrutar las solicitudes de inserción o incorporación de cambios de Docker a esa región. De forma predeterminada, el enrutamiento está habilitado a todas las replicaciones y la sincronización de datos en todas las replicaciones tiene lugar independientemente de si el enrutamiento está habilitado o deshabilitado.
Para deshabilitar el enrutamiento a una replicación existente, ejecute primero az acr replication list para mostrar las replicaciones en el registro. A continuación, ejecute az acr replication update y establezca --region-endpoint-enabled false para una replicación concreta. Por ejemplo, para configurar las opciones de la replicación de westus en 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
Para restaurar el enrutamiento a una replicación:
az acr replication update --name westus \
--registry myregistry --resource-group MyResourceGroup \
--region-endpoint-enabled true
Pasos siguientes
Consulte la serie de tres partes del tutorial Geo-replication in Azure Container Registry (Replicación geográfica en Azure Container Registry). Aprenda a crear un registro con replicación geográfica, a compilar un contenedor y a implementarlo con un solo comando docker push en varias instancias regionales de Web App for Containers.