Confiabilidad en Azure Container Registry

Azure Container Registry es un servicio de registro de contenedor administrado que se usa para almacenar y administrar las imágenes de contenedor privadas de Docker y los artefactos relacionados para las implementaciones de contenedor.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que Container Registry sea resistente a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad y interrupciones de regiones. También se describe cómo puede usar copias de seguridad para recuperarse de otros tipos de problemas y se resalta cierta información clave sobre el acuerdo de nivel de servicio (SLA) de Container Registry.

Recomendaciones de implementación de producción para la confiabilidad

Para las cargas de trabajo de producción, le recomendamos que realice las siguientes acciones:

• Use el nivel Premium de Container Registry, que proporciona las características de confiabilidad más completas. El nivel Premium también proporciona límites de rendimiento más altos, características de seguridad mejoradas y funcionalidades avanzadas que son esenciales para las cargas de trabajo de contenedor de producción. Para más información sobre los niveles de servicio y las características, consulte Niveles de servicio de Container Registry.

• Aprovisione su registro de contenedores en una región que admita zonas de disponibilidad.

• En escenarios de varias regiones, configure la replicación geográfica para distribuir el registro en varias regiones en función de sus requisitos geográficos y de cumplimiento específicos.

Introducción a la arquitectura de confiabilidad

Container Registry se basa en la infraestructura distribuida de Azure para proporcionar alta disponibilidad y durabilidad de los datos. El servicio consta de varios componentes clave que funcionan conjuntamente para garantizar la confiabilidad. En el siguiente diagrama se muestra la arquitectura de servicio principal.

• El plano de control es un componente de administración centralizado en la región principal para la configuración del registro, la configuración de autenticación y las directivas de replicación.

• El plano de datos es un servicio distribuido que controla las operaciones de inserción y extracción de imágenes de contenedor entre regiones y zonas de disponibilidad.

• La capa de almacenamiento es una solución de Azure Storage direccionable con contenido que conserva imágenes y artefactos de contenedor. Incluye desduplicación automática, cifrado en reposo y replicación integrada.

Microsoft es responsable de administrar la infraestructura subyacente de Container Registry, que incluye los siguientes tipos de mantenimiento:

• Mantenimiento del plano de control para la administración del registro

• Mantenimiento del plano de datos para las operaciones de imagen de contenedor en regiones y zonas de disponibilidad

Como cliente, es responsable de las siguientes acciones:

• Resistencia de nivel de aplicación: Implemente la lógica de reintento adecuada y el control de conmutación por error en las aplicaciones de contenedor y las plataformas de orquestación.

• Configuración de resistencia de zona: Asegúrese de que el registro de contenedor está implementado en una región que admita zonas de disponibilidad.

• Configuración de replicación geográfica: Elija las regiones adecuadas para la replicación geográfica en función de los requisitos de distribución geográfica, cumplimiento y rendimiento.

Container Registry también admite tareas, lo que puede ayudarle a automatizar las compilaciones de contenedor y las operaciones de mantenimiento. Las tareas se ejecutan en una infraestructura informática administrada por Microsoft y admiten desencadenadores manuales, basados en eventos o programados. Para más información, consulte Automatizar la creación y el mantenimiento de imágenes de contenedores mediante tareas de Container Registry.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que sus aplicaciones puedan administrar errores transitorios, generalmente reintentando las solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Container Registry controla los errores transitorios internamente a través de varios mecanismos. El servicio implementa una lógica de reintento automático para las operaciones del registro y mantiene un grupo de conexiones para un uso eficiente de los recursos. Las operaciones de Container Registry están diseñadas para ser idempotentes, lo que permite reintentos seguros de las operaciones de envío y extracción. Las tareas administran automáticamente los fallos transitorios cuando realizan muchos tipos de operaciones.

En el caso de las aplicaciones cliente que usan Container Registry, implemente las directivas de reintento adecuadas con retroceso exponencial al realizar operaciones del Registro. Use el cliente oficial de Docker o los SDK de Container Registry, que incluyen mecanismos de reintento integrados para los errores transitorios más comunes.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

La redundancia de zona protege su registro de contenedores contra errores de una sola zona distribuyendo los datos y las operaciones del registro entre varias zonas de disponibilidad dentro de la región. Las operaciones de extracción e inserción de imágenes de contenedor continúan funcionando durante las interrupciones de zona, con conmutación automática por error a zonas correctas.

La redundancia de zona está habilitada de forma predeterminada para todos los registros de regiones que admiten zonas de disponibilidad, lo que hace que los recursos sean más resistentes automáticamente y sin costo adicional. Esta mejora se aplica a todos los niveles de servicio, incluidos Básico y Estándar, y se ha aplicado a registros nuevos y existentes.

Considerations

• Compatibilidad con regiones: Los registros con redundancia de zona se pueden implementar en cualquier región que admita zonas de disponibilidad. Si su registro está en una región que no admite zonas de disponibilidad, para que sea redundante en zonas, debe crear un nuevo registro en una región que admita zonas de disponibilidad. A continuación, debe migrar las imágenes de contenedor mediante la creación de una canalización de transferencia o mediante la importación de imágenes de contenedor.

Considerations

• Tareas: Las tareas de Container Registry no admiten actualmente zonas de disponibilidad. La redundancia de zona se aplica al propio servicio del registro, pero no a las tareas ni a sus operaciones.

• Replicación geográfica: Si el registro usa replicación geográfica, las réplicas creadas en regiones con zonas de disponibilidad son automáticamente redundantes a nivel de zona.

Cost

La redundancia de zona se incluye con registros de contenedor sin coste adicional.

Configurar soporte de zonas de disponibilidad

• Cree un registro con redundancia de zona. Cuando creas un registro en una región admitida, es automáticamente redundante a nivel de zona. Para más información sobre cómo crear un registro, consulte Creación de un registro con redundancia de zona en Container Registry.

• Habilite la redundancia de zona en un registro existente. Los registros que se encuentran en regiones con zonas de disponibilidad automáticamente tienen redundancia de zona. No es necesario habilitar la redundancia de zona.

• Desactivar la redundancia de zona. No se puede deshabilitar la redundancia de zona.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar cuando los recursos de Container Registry están configurados para la redundancia de zona y todas las zonas de disponibilidad están operativas.

• Enrutamiento de tráfico entre zonas: Container Registry usa la funcionalidad de enrutamiento interno para distribuir automáticamente las operaciones del plano de datos en todas las zonas de disponibilidad dentro de una región. El servicio del Registro enruta automáticamente las solicitudes a zonas correctas sin necesidad de equilibradores de carga externos.

• Replicación de datos entre zonas: Los datos del Registro, incluidas las imágenes de contenedor, los manifiestos y los metadatos, se replican de forma asincrónica en varias zonas de disponibilidad. Los cambios se replican rápidamente entre zonas para mantener una alta disponibilidad y durabilidad de los datos. La replicación es asíncrona, pero normalmente se completa en cuestión de minutos, y todas las zonas permanecen disponibles para operaciones de lectura y escritura durante la replicación.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando los recursos de Container Registry están configurados para la redundancia de zona y hay una interrupción de zona de disponibilidad.

Cuando una zona deja de estar disponible, Container Registry administra automáticamente el proceso de conmutación por error con un impacto mínimo en las operaciones del registro.

• Detección y respuesta: La plataforma Container Registry detecta automáticamente errores en una zona de disponibilidad e inicia una respuesta. El servicio enruta automáticamente el tráfico a las zonas correctas restantes. No se requiere ninguna intervención manual para iniciar una conmutación por error de zona.

• Notificaciones: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

  También puede supervisar las métricas de disponibilidad del Registro en Azure Monitor.

• Solicitudes activas: Cuando una zona de disponibilidad no está disponible, se finalizan las solicitudes en curso conectadas a los recursos de la zona de disponibilidad errónea. Deben reintentarse.

• Pérdida de datos esperada: Las escrituras recientes realizadas en la zona defectuosa podrían no replicarse en otras regiones, lo que significa que podrían perderse hasta que la zona se recupere. Normalmente, se espera que la pérdida de datos sea inferior a 15 minutos, pero eso no está garantizado.

• Tiempo de inactividad esperado: Es posible que se produzca un breve periodo de inactividad durante la conmutación automática por error, ya que el tráfico se redirige a zonas correctas. Este tiempo de inactividad suele ser de unos segundos para la mayoría de las operaciones del registro. Se recomienda seguir los procedimientos recomendados de control de errores transitorios para minimizar el efecto de la conmutación por error de zona en las aplicaciones.

• Reenrutamiento del tráfico: La plataforma vuelve a enrutar automáticamente el tráfico a zonas correctas sin necesidad de realizar ningún cambio de configuración.

Recuperación de zona

Cuando se recupera la zona de disponibilidad afectada, Container Registry distribuye automáticamente las operaciones en todas las zonas disponibles, incluida la zona recuperada. El servicio reequilibra el tráfico y la distribución de datos sin necesidad de intervención manual ni provoca interrupciones del servicio.

Prueba de fallos de zona

La plataforma Container Registry administra el enrutamiento del tráfico, la conmutación por error y la conmutación por recuperación para registros redundantes por zona. Dado que esta característica está totalmente administrada, no es necesario iniciar ni validar los procesos de error de zona de disponibilidad.

Resistencia a errores en toda la región

Container Registry proporciona compatibilidad nativa con varias regiones a través de la replicación geográfica cuando el registro usa el nivel Premium. La replicación geográfica crea réplicas del Registro en varias regiones de su elección. La región en la que se implementa el recurso de registro se conoce como la región principal.

La replicación geográfica permite la resistencia a interrupciones regionales. Si su registro está replicado geográficamente y se produce una interrupción regional, los datos del registro seguirán estando disponibles desde las otras regiones que haya seleccionado. Si no habilita la replicación geográfica, es posible que sus datos no estén disponibles durante una interrupción del servicio en la región.

También puede utilizar la replicación geográfica para obtener acceso local a imágenes de contenedores dentro de esas regiones y reducir la latencia de las aplicaciones distribuidas a nivel mundial.

Al implementar Container Registry y habilitar la replicación geográfica, Microsoft usa Azure Traffic Manager para distribuir las solicitudes del plano de datos entre las réplicas y conmutar automáticamente por error entre réplicas si una réplica regional no está disponible.

La replicación geográfica de Container Registry no depende de las regiones emparejadas de Azure. Puede seleccionar cualquier combinación de regiones de Azure para la replicación en función de sus requisitos específicos de ubicación geográfica, rendimiento y cumplimiento normativo. Cada registro replicado geográficamente funciona como un punto de conexión de registro. Admite la mayoría de las operaciones del registro, incluyendo tareas de envío, extracción y administración de imágenes.

En esta sección se resume la información sobre la replicación geográfica en relación con la confiabilidad. Para más información, consulte Replicación geográfica en Container Registry.

Soporte para regiones

La replicación geográfica está disponible en todas las regiones de Azure en las que se admite el nivel Premium. Puede replicar en cualquier combinación de regiones, independientemente de si Azure empareja esas regiones.

Requirements

Debe usar el nivel Premium para habilitar la replicación geográfica.

Considerations

• Réplicas con redundancia de zona: cualquier réplica que cree en una región con zonas de disponibilidad tiene redundancia de zona de manera automática.

• Plano de control: El plano de control se ejecuta en la región principal. Si la región principal no está disponible, las operaciones del plano de control no están disponibles y es posible que no pueda modificar la configuración del Registro.

• Tareas: Las tareas de Container Registry no admiten actualmente réplicas geográficas. Las tareas siempre se ejecutan en la región principal. Si la región principal no está disponible, la tarea no se ejecuta.

Cost

Cada región con replicación geográfica se factura por separado según los precios del plan Premium de la región correspondiente. Los cargos de salida también se aplican a la transferencia de datos entre regiones durante la replicación inicial y la sincronización continua.

Configuración de la compatibilidad con varias regiones

La replicación geográfica se puede configurar durante la creación del registro o agregarse a los registros Premium existentes. La replicación geográfica se puede configurar a través de Azure Portal, la CLI de Azure, Azure PowerShell o las plantillas de Azure Resource Manager.

• Crear un registro con replicación geográfica Configure la replicación geográfica después de crear el registro especificando regiones adicionales.

• Habilitar la replicación geográfica en un registro existente. Para habilitar las funciones de replicación geográfica, actualice los registros existentes de nivel Básico o Estándar al nivel Premium. Puede cambiar las regiones de replicación en cualquier momento. Para obtener más información, consulte Configuración de replicación geográfica.

• Deshabilitar la replicación geográfica. Quite las réplicas regionales individuales a través de Azure Portal o las herramientas de línea de comandos. No se puede quitar el registro de la región principal.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar cuando un registro está configurado para la replicación geográfica y todas las regiones están operativas.

• Enrutamiento del tráfico entre regiones: Container Registry funciona en una configuración activa-activa donde cada punto de conexión regional puede atender todas las operaciones del plano de datos de forma independiente, incluidas las lecturas y escrituras. Las operaciones del plano de datos, como las operaciones de envío y extracción de contenedores, se enrutan automáticamente mediante Traffic Manager con criterios basados en el rendimiento para determinar el punto de conexión regional óptimo para el rendimiento.

• Replicación de datos entre regiones: La replicación geográfica sincroniza automáticamente las imágenes de contenedor y los artefactos en todas las regiones configuradas mediante la replicación asincrónica con coherencia final. El servicio utiliza almacenamiento direccionable por contenido para replicar de manera eficiente solo las capas de imagen únicas. Este enfoque minimiza el uso del ancho de banda y el tiempo de replicación. Las operaciones de lectura y escritura funcionan en todas las regiones con replicación geográfica. Los cambios realizados en cualquier región se replican en todas las demás regiones.

  La replicación se completa normalmente en cuestión de minutos después de los cambios. Sin embargo, no hay garantía sobre el tiempo de replicación de los datos. Las imágenes de contenedores grandes o las actualizaciones de alta frecuencia pueden tardar más tiempo en replicarse en todas las regiones.

Comportamiento durante una falla de región

En esta sección se describe qué esperar cuando se configura un registro para la replicación geográfica y hay una interrupción en la región primaria.

Cuando una región deja de estar disponible, las operaciones de contenedor pueden seguir usando puntos de conexión regionales alternativos.

• Detección y respuesta: Container Registry supervisa el estado de cada réplica regional y es responsable de redirigir el tráfico a otra región.

• Notificaciones: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.

  También puede supervisar las métricas de disponibilidad del Registro para cada punto de conexión regional en Azure Monitor.

• Solicitudes activas: Cualquier solicitud activa actualmente en tránsito hacia una región no disponible tendrá un error y deberá reintentarse para que pueda dirigirse a una región correcta.

• Pérdida de datos esperada: Es posible que las escrituras recientes realizadas en la región defectuosa no se repliquen en otras regiones. Este error significa que podrían perderse hasta que se recupere la región. Normalmente, se espera que la pérdida de datos sea inferior a 15 minutos, pero no se garantiza.

• Tiempo de inactividad esperado: En cuanto a las operaciones del plano de datos, se espera un breve periodo de inactividad mientras se completa la conmutación por error, lo que suele tardar entre 1 y 2 minutos.

  Si la región principal no está disponible, las operaciones del plano de control no estarán disponibles hasta que se recupere la región.

• Reenrutamiento del tráfico: Cuando una región deja de estar disponible, las operaciones de contenedor se enrutan automáticamente a otra réplica dentro de una región saludable. Los clientes no necesitan cambiar el punto de conexión en el que interactúan con el registro. Microsoft controla automáticamente el enrutamiento, la conmutación por error y la conmutación por recuperación.

Recuperación de regiones

Cuando se recupera una región, las operaciones del plano de datos se reanudan automáticamente para ese punto de conexión regional a través del enrutamiento de Traffic Manager. El servicio sincroniza cualquier cambio que se produzca durante la interrupción mediante la replicación asíncrona con coherencia eventual.

Prueba de fallos de región

No se puede simular el error de una de las regiones asociadas con el registro, pero se puede probar la capacidad de la aplicación para realizar una conmutación por error entre regiones. Puede simular una conmutación por error regional deshabilitando temporalmente las réplicas geográficas, lo que las quita del enrutamiento de Traffic Manager. A continuación, puede verificar que las operaciones de contenedores se transfieren correctamente a regiones alternativas en caso de error sin experimentar realmente una interrupción regional. Para obtener más información, consulte Deshabilitar temporalmente el enrutamiento a la replicación.

Al volver a activar la réplica, Traffic Manager reanuda el enrutamiento del tráfico a la réplica que se ha vuelto a habilitar. Además, los metadatos y las imágenes se sincronizan con coherencia eventual con la réplica reactivada para garantizar la coherencia de los datos en todas las regiones.

Copias de seguridad y restauración

Container Registry admite la exportación de imágenes de contenedor y artefactos desde el registro al almacenamiento externo o a registros alternativos. Use las funciones de importación y exportación de Container Registry o los comandos estándar de Docker para crear copias de imágenes de contenedores críticas para escenarios de recuperación ante desastres.

Para la mayoría de las soluciones, no debe confiar exclusivamente en copias de seguridad. En su lugar, utilice las otras capacidades descritas en esta guía para apoyar los requisitos de resiliencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no. Para más información, consulte ¿Qué son la redundancia, la replicación y la copia de seguridad?.

Acuerdo de nivel de servicio

El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Contenido relacionado

• Fiabilidad de Azure
• Niveles de servicio de Container Registry
• Procedimientos recomendados de Container Registry
• Supervisión de Container Registry
• Precios de Container Registry
• Importación de imágenes de contenedor en un registro de contenedor