Partager via

Fiabilité dans Azure Container Registry

Azure Container Registry est un service de registre de conteneurs géré utilisé pour stocker et gérer vos images conteneur Docker privées et les artefacts associés pour vos déploiements de conteneurs.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre Container Registry résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il décrit également comment utiliser des sauvegardes pour récupérer à partir d’autres types de problèmes et met en évidence certaines informations clés sur le contrat de niveau de service Container Registry (SLA).

Recommandations de déploiement de production pour la fiabilité

Pour les charges de travail de production, nous vous recommandons de prendre les mesures suivantes :

  • Utilisez le niveau Premium de Container Registry, qui fournit les fonctionnalités de fiabilité les plus complètes. Le niveau Premium offre également des limites de performances plus élevées, des fonctionnalités de sécurité améliorées et des fonctionnalités avancées essentielles pour les charges de travail de conteneur de production. Pour plus d'informations sur les niveaux de service et les fonctionnalités, consultez la section Niveaux de service de Container Registry..

  • Provisionnez votre Registre de conteneurs dans une région qui prend en charge les zones de disponibilité.

  • Pour les scénarios multirégions, configurez la géoréplication pour distribuer votre registre dans plusieurs régions en fonction de vos exigences géographiques et de conformité spécifiques.

Vue d’ensemble de l’architecture de fiabilité

Container Registry est basé sur une infrastructure Azure distribuée pour offrir une haute disponibilité et une durabilité des données. Le service se compose de plusieurs composants clés qui fonctionnent ensemble pour garantir la fiabilité. Le diagramme suivant illustre l’architecture du service principal.

Diagramme montrant l’architecture du service Container Registry avec l’accès client, le plan de contrôle, le plan de données et les composants de couche de stockage.

  • Le plan de contrôle est un composant de gestion centralisé dans la région d’origine pour la configuration du registre, la configuration de l’authentification et les stratégies de réplication.

  • Le plan de données est un service distribué qui gère les opérations push et pull d'images de conteneurs dans les régions et les zones de disponibilité.

  • La couche de stockage est une solution de stockage Azure adressable par contenu qui conserve les images et les artefacts de conteneur. Il comprend la déduplication automatique, le cryptage au repos et la réplication intégrée.

Microsoft est responsable de la gestion de l'infrastructure sous-jacente de Container Registry, qui comprend les types de maintenance suivants :

  • Maintenance du plan de contrôle pour la gestion du registre

  • Maintenance du plan de données pour les opérations d'image de conteneur dans les régions et les zones de disponibilité

En tant que client, vous êtes responsable des actions suivantes :

  • Résilience au niveau de l’application : implémentez une logique de nouvelle tentative et une gestion de basculement appropriées dans vos applications de conteneur et vos plates-formes d’orchestration.

  • Configuration de résilience de zone : Vérifiez que votre registre de conteneurs est déployé dans une région qui prend en charge les zones de disponibilité.

  • Configuration de la géo-réplication : choisissez les régions appropriées pour la géo-réplication en fonction de vos exigences de distribution géographique, de conformité et de performances.

Container Registry prend également en charge les tâches qui peuvent vous aider à automatiser vos créations de conteneurs et vos opérations de maintenance. Les tâches s’exécutent sur une infrastructure de calcul gérée par Microsoft et prennent en charge les déclencheurs manuels, basés sur des événements ou planifiés. Pour plus d'informations, consultez Automatiser les créations et la maintenance des images de conteneur à l'aide des tâches Container Registry.

Note

Container Registry prend en charge les registres connectés, qui sont des répliques locales ou distantes qui se synchronisent avec votre Container Registry basé sur le cloud. Lorsque vous utilisez des registres connectés, vous êtes chargé de les configurer pour répondre à vos exigences de fiabilité. Les registres connectés ne sont pas abordés dans cet article.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Container Registry gère les défauts transitoires en interne via plusieurs mécanismes. Le service implémente une logique de nouvelle tentative automatique pour les opérations de registre et maintient le pool de connexions pour une utilisation efficace des ressources. Les opérations de Container Registry sont conçues pour être idempotentes, ce qui permet de nouvelles tentatives sécurisées d'opérations push et pull. Les tâches gèrent automatiquement les défauts transitoires lorsqu'elles exécutent de nombreux types d'opérations.

Pour les applications clientes qui utilisent Container Registry, implémentez des stratégies de nouvelle tentative appropriées avec un recul exponentiel lors de l'exécution d'opérations de registre. Utilisez le client Docker officiel ou les SDK Container Registry, qui incluent des mécanismes de nouvelle tentative intégrés pour les échecs transitoires courants.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

La redondance de zone protège votre registre de conteneurs contre les défaillances de zone unique en distribuant les données et les opérations du Registre sur plusieurs zones de disponibilité au sein de la région. Les opérations d’envoi (push) et de tirage (pull) d’images de conteneur continuent de fonctionner pendant les interruptions de zone avec un basculement automatique vers des zones fonctionnelles.

La redondance de zone est activée par défaut pour tous les registres des régions qui prennent en charge les zones de disponibilité, rendant vos ressources plus résilientes automatiquement et sans coût supplémentaire. Cette amélioration s’applique à tous les niveaux de service, notamment De base et Standard, et a été appliquée aux registres nouveaux et existants.

Important

Le portail Azure et d’autres outils peuvent ne pas encore refléter la mise à jour de redondance de zone avec précision.

La zoneRedundancy propriété de la configuration de votre registre peut toujours s’afficher comme étant false, mais la redondance de zone est active pour tous les registres dans les régions prises en charge.

Nous mettons activement à jour le portail et les surfaces d’API pour refléter ce comportement par défaut de manière plus transparente. Toutes les fonctionnalités précédemment activées continuent de fonctionner comme prévu.

Considerations

Considerations

  • Tâches: Les tâches container Registry ne prennent actuellement pas en charge les zones de disponibilité. La redondance de zone s’applique au service de Registre lui-même, mais pas aux tâches ou à leurs opérations.

  • Géoréplication : Si votre registre utilise la géoréplication, tous les réplicas créés dans des régions avec des zones de disponibilité sont automatiquement redondants interzone.

Cost

La redondance de zone est incluse dans les registres de conteneurs sans coût supplémentaire.

Configurez la prise en charge des zones de disponibilité

  • Créez un registre redondant de zone. Lorsque vous créez un registre dans une région prise en charge, il est automatiquement redondant interzone. Pour plus d’informations sur la création d’un registre, consultez Créer un registre redondant interzone dans Container Registry.

  • Activer la redondance de zone sur un registre existant. Les registres qui se trouvent dans des régions avec des zones de disponibilité sont automatiquement redondants interzone. Vous n’avez pas besoin d’activer la redondance de zone.

  • Désactivez la redondance de zone. La redondance de zone ne peut pas être désactivée.

Comportement lorsque toutes les zones sont saines

Cette section décrit à quoi s'attendre lorsque les ressources Container Registry sont configurées pour la redondance de zone et que toutes les zones de disponibilité sont opérationnelles.

Diagramme montrant la redondance de zone Container Registry pendant les opérations normales.

  • Acheminement du trafic entre les zones : Container Registry utilise la fonctionnalité de routage interne pour distribuer automatiquement les opérations du plan de données sur toutes les zones de disponibilité d'une région. Le service de Registre achemine automatiquement les requêtes vers des zones saines sans nécessiter d’équilibreurs de charge externes.

  • Réplication des données entre les zones : Les données de registre, y compris les images de conteneur, les manifestes et les métadonnées, sont répliquées de manière asynchrone sur plusieurs zones de disponibilité. Les modifications sont répliquées rapidement entre les zones pour maintenir la haute disponibilité et la durabilité des données. La réplication est asynchrone, mais elle se termine généralement en quelques minutes et toutes les zones restent disponibles pour les opérations de lecture et d'écriture pendant la réplication.

Comportement lors d’une défaillance de zone

Cette section décrit à quoi s'attendre lorsque les ressources de Container Registry sont configurées pour la redondance de zone et qu'une panne de zone de disponibilité se produit.

Lorsqu'une zone devient indisponible, Container Registry gère automatiquement le processus de basculement avec un impact minimal sur les opérations de registre.

Diagramme montrant le comportement de Container Registry lors de l’échec de la zone. Itinéraires de basculement automatique vers des zones saines. Une zone est marquée comme indisponible.

  • Détection et réponse : La plateforme Container Registry détecte automatiquement les pannes dans une zone de disponibilité et lance une réponse. Le service achemine automatiquement le trafic vers les zones saines restantes. Aucune intervention manuelle n’est nécessaire pour lancer un basculement de zone.

  • Notifications: Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

    Vous pouvez également surveiller les métriques de disponibilité du Registre dans Azure Monitor.

  • Requêtes actives : Lorsqu'une zone de disponibilité n'est pas disponible, toutes les requêtes en cours qui sont connectées aux ressources de la zone de disponibilité défectueuse sont interrompues. Elles doivent faire l’objet d’une nouvelle tentative.

  • Perte de données attendue : Il est possible que les écritures récentes effectuées dans la zone défectueuse ne soient pas répliquées dans d’autres régions, ce qui signifie qu’elles peuvent être perdues jusqu’à ce que la zone soit récupérée. La perte de données devrait généralement durer moins de 15 minutes, mais cela n'est pas garanti.

  • Temps d'arrêt prévu : Un petit temps d'arrêt peut se produire lors du basculement automatique, car le trafic est redirigé vers des zones saines. Ce temps d’arrêt est généralement de quelques secondes pour la plupart des opérations de registre. Nous vous recommandons de suivre les meilleures pratiques de gestion des pannes transitoires afin de minimiser l’effet du basculement de zone sur vos applications.

  • Redirection du trafic : La plateforme redirige automatiquement le trafic vers des zones saines sans que vous ayez à apporter de modifications de configuration.

Récupération de la zone

Lorsque la zone de disponibilité affectée est récupérée, Container Registry distribue automatiquement les opérations sur toutes les zones disponibles, y compris la zone récupérée. Le service rééquilibrée le trafic et la distribution des données sans nécessiter d’intervention manuelle ou provoquer une interruption de service.

Tester les pannes de zone

La plateforme Container Registry gère le routage du trafic, le basculement et la restauration pour les registres redondants par zone. Cette fonctionnalité étant complètement managée, vous n’avez pas besoin de lancer ou de valider les processus de défaillance de zone de disponibilité.

Résilience aux défaillances à l’échelle de la région

Container Registry fournit une prise en charge multirégionale native via la géo-réplication lorsque votre registre utilise le niveau Premium. La géoréplication crée des réplicas de registre dans plusieurs régions de votre choix. La région dans laquelle vous déployez la ressource de registre est appelée région d'origine.

La géoréplication permet la résilience aux pannes régionales. Si votre registre est géo-répliqué et qu'une panne régionale se produit, les données du registre continuent d'être disponibles dans les autres régions que vous avez sélectionnées. Si vous n'activez pas la géoréplication, vos données risquent de devenir indisponibles en cas de panne régionale.

Vous pouvez également utiliser la géo-réplication pour obtenir un accès local aux images de conteneurs dans ces régions et pour réduire la latence des applications distribuées à l'échelle mondiale.

Lorsque vous déployez Container Registry et activez la géoréplication, Microsoft utilise Azure Traffic Manager pour distribuer les requêtes de plan de données entre vos réplicas et pour basculer automatiquement entre les réplicas si un réplica régional n’est pas disponible.

La géoréplication de Container Registry ne repose pas sur les régions jumelées Azure. Vous pouvez sélectionner n’importe quelle combinaison de régions Azure pour la réplication en fonction de vos exigences géographiques, de performances et de conformité spécifiques. Chaque registre géo-répliqué fonctionne comme un point de terminaison de registre. Il prend en charge la plupart des opérations de registre, y compris les envois d'images, les extractions et les tâches de gestion.

Cette section récapitule les informations relatives à la géoréplication en ce qui concerne la fiabilité. Pour plus d'informations, consultez Géo-réplication dans Container Registry.

Soutien régional

La géoréplication est disponible dans toutes les régions Azure où le niveau Premium est pris en charge. Vous pouvez répliquer vers n’importe quelle combinaison de régions, qu’Azure associe ou non ces régions.

Requirements

Vous devez utiliser le niveau Premium pour activer la géoréplication.

Considerations

  • Réplicas redondants interzone : Tout réplica que vous créez dans une région avec des zones de disponibilité est automatiquement redondant interzone.

  • Plan de contrôle : Le plan de contrôle s'exécute dans la région d'origine. Si la région d’origine n’est pas disponible, les opérations du plan de contrôle ne sont pas disponibles et vous ne pouvez peut-être pas modifier la configuration du Registre.

  • Tâches : Les tâches Container Registry ne prennent actuellement pas en charge les géo-répliques. Les tâches s’exécutent toujours dans la région d’accueil. Si la région d’origine n’est pas disponible, la tâche ne s’exécute pas.

Cost

Chaque région géorépliquée est facturée séparément en fonction de la tarification du niveau Premium pour la région concernée. Des frais de sortie s'appliquent également au transfert de données entre les régions pendant la réplication initiale et la synchronisation continue.

Configurer la prise en charge multirégion

La géoréplication peut être configurée lors de la création du Registre ou ajoutée aux registres Premium existants. La géoréplication peut être configurée via le Portail Microsoft Azure, l’interface de ligne de commande Azure, Azure PowerShell ou les modèles Azure Resource Manager.

  • Créer un registre géo-répliqué. Configurez la géo-réplication après la création du registre en spécifiant des régions supplémentaires.

  • Activer la géo-réplication sur un registre existant. Pour activer les fonctionnalités de géo-réplication, mettez à niveau les registres de niveau Basic ou Standard existants vers le niveau Premium. Vous pouvez modifier les régions de réplication à tout moment. Pour plus d'informations, voir Configurer la géo-réplication.

  • Désactiver la géo-réplication. Supprimez des réplicas régionaux individuels via le portail Azure ou les outils en ligne de commande. Impossible de supprimer le registre de région d’origine.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce qu’il faut attendre lorsqu’un registre est configuré pour la géoréplication et que toutes les régions sont opérationnelles.

Diagramme montrant les opérations multirégions de Container Registry. Les clients globaux se connectent via Traffic Manager aux points de terminaison de Registre dans plusieurs régions.

  • Acheminement du trafic entre les régions : Container Registry fonctionne dans une configuration active-active où chaque point de terminaison régional peut traiter toutes les opérations du plan de données de manière indépendante, y compris les lectures et les écritures. Les opérations du plan de données, telles que les opérations push et pull de conteneur, sont automatiquement acheminées à l'aide de Traffic Manager avec des critères basés sur les performances pour déterminer le point de terminaison régional optimal pour les performances.

  • Réplication des données entre les régions : La géo-réplication synchronise automatiquement les images et les artefacts des conteneurs dans toutes les régions configurées en utilisant la réplication asynchrone avec une cohérence éventuelle. Le service utilise un stockage adressable par contenu pour répliquer efficacement uniquement les couches d'image uniques. Cette approche minimise l’utilisation de la bande passante et le temps de réplication. Les opérations de lecture et d’écriture fonctionnent sur toutes les régions géo-répliquées. Les modifications apportées dans une région sont répliquées dans toutes les autres régions.

    La réplication se termine généralement quelques minutes après les modifications. Cependant, il n’y a aucune garantie quant au délai de réplication des données. Les images de conteneurs volumineuses ou les mises à jour à haute fréquence peuvent prendre plus de temps à se répliquer dans toutes les régions.

Comportement lors d’une défaillance de région

Cette section décrit ce qu’il faut attendre lorsqu’un registre est configuré pour la géoréplication et qu’il existe une panne dans la région primaire.

Lorsqu'une région devient indisponible, les opérations de conteneurs peuvent continuer à utiliser des points de terminaison régionaux alternatifs.

Diagramme montrant le comportement de Container Registry lors de l’échec régional.

  • Détection et réponse : Container Registry surveille l’état de chaque réplique régionale et est responsable de la redirection du trafic vers une autre région.

  • Notifications: Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de région, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

    Vous pouvez également surveiller les métriques de disponibilité du Registre pour chaque point de terminaison régional dans Azure Monitor.

  • Requêtes actives : Toutes les requêtes actives actuellement en cours de transfert vers une région indisponible échoueront et devront être réessayées afin de pouvoir être dirigées vers une région saine.

  • Perte de données attendue : Les écritures récentes effectuées dans la région défectueuse peuvent ne pas être répliquées dans d’autres régions. Cet échec signifie qu’ils pourraient être perdus jusqu’à ce que la région se rétablisse. En règle générale, la perte de données devrait durer moins de 15 minutes, mais cela n'est pas garanti.

  • Temps d'arrêt prévu : Pour les opérations du plan de données, un petit temps d'arrêt est prévu pour les opérations du plan de données pendant que le basculement se termine, ce qui prend généralement 1 à 2 minutes.

    Si la région principale n’est pas disponible, les opérations du plan de contrôle ne sont pas disponibles jusqu’à ce que la région soit rétablie.

  • Redirection du trafic : Lorsqu'une région devient indisponible, les opérations de conteneur sont automatiquement acheminées vers une autre réplique dans une région saine. Les clients n’ont pas besoin de modifier le point de terminaison dans lequel ils interagissent avec le registre. Microsoft gère automatiquement le routage, le basculement et la restauration.

Récupération de la région

Lorsqu’une région récupère, les opérations de plan de données reprendnt automatiquement pour ce point de terminaison régional via le routage Traffic Manager. Le service synchronise toutes les modifications qui se produisent pendant la panne en utilisant une réplication asynchrone avec une cohérence éventuelle.

Tester les défaillances régionales

Vous ne pouvez pas simuler la défaillance de l’une des régions associées à votre registre, mais vous pouvez tester la capacité de votre application à basculer entre les régions. Vous pouvez simuler un basculement régional en désactivant temporairement les géo-répliques, ce qui les supprime du routage Traffic Manager. Vous pouvez ensuite vérifier que les opérations de conteneur basculent avec succès vers des régions alternatives sans subir de panne régionale. Pour plus d'informations, consultez Désactiver temporairement le routage vers la réplication.

Lorsque vous réactivez le réplica, Traffic Manager reprend le routage du trafic vers le réplica réactivé. De plus, les métadonnées et les images sont synchronisées avec une cohérence éventuelle avec la réplique réactivée pour garantir la cohérence des données dans toutes les régions.

Sauvegarde et restauration

Container Registry prend en charge l'exportation d'images et d'artefacts de conteneurs depuis votre registre vers un stockage externe ou des registres alternatifs. Utilisez les fonctionnalités d’importation et d’exportation de Container Registry ou les commandes Docker standard pour créer des copies d’images de conteneurs critiques pour les scénarios de reprise après sinistre.

Pour la plupart des solutions, vous ne devez pas vous appuyer exclusivement sur les sauvegardes. Utilisez plutôt les autres fonctionnalités décrites dans ce guide pour prendre en charge vos exigences de résilience. Toutefois, les sauvegardes protègent contre certains risques que d’autres approches ne le font pas. Pour plus d’informations, consultez Que sont la redondance, la réplication et la sauvegarde ?.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Contenu connexe

  • Last updated on