Fiabilité dans Azure VM Image Builder

Azure VM Image Builder est un service managé qui génère et personnalise des images de machine virtuelle, puis distribue les images obtenues à des cibles telles qu’Azure Compute Gallery ou des disques durs virtuels (VHD) dans Stockage Blob Azure. Le service ne vous oblige pas à maintenir l’infrastructure de build de longue durée.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft offre une gamme de fonctionnalités permettant de 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 Azure Vm Image Builder résilient à diverses pannes et problèmes potentiels, notamment les erreurs temporaires, les défaillances de zone de disponibilité, les défaillances à l’échelle de la région et la maintenance du service. Il décrit également les options de sauvegarde et de restauration, les solutions multirégions personnalisées et les informations clés relatives au contrat de niveau de service (SLA) Azure VM Image Builder.

Recommandations concernant le déploiement de production

Tenez compte des recommandations suivantes lorsque vous concevez un pipeline de création d’images de production :

• Définissez vos modèles d’image à l’aide de l’infrastructure en tant que code, comme Bicep ou Terraform, et stockez les définitions dans le contrôle de code source.

• Distribuez les images finalisées dans les régions où vos charges de travail s’exécutent, par exemple via la réplication d’Azure Compute Gallery, afin d’éviter les dépendances interrégions inutiles lors de la création de machines virtuelles, de la mise à l’échelle horizontale et des opérations de réinitialisation.

• Stockez des scripts de personnalisation, des packages et d’autres dépendances de build dans un stockage présentant les caractéristiques de redondance requises par votre charge de travail.

Vue d’ensemble de l’architecture de fiabilité

Cette section décrit certains des aspects importants du fonctionnement du service qui sont les plus pertinents du point de vue de la fiabilité. La section présente l’architecture logique, qui inclut certaines des ressources et fonctionnalités que vous déployez et utilisez. Il traite également de l’architecture physique, qui fournit des détails sur le fonctionnement du service sous les couvertures.

Architecture logique

Lorsque vous utilisez VM Image Builder, vous déployez un modèle d’image dans une seule région Azure, qui devient la région d’origine du modèle.

Après avoir créé le modèle, vous exécutez une génération, qui exécute une série d’étapes pour créer l’image de machine virtuelle. Ces étapes peuvent exécuter des scripts ou inclure des packages que vous souhaitez incorporer dans l’image.

Le service crée ou utilise un groupe de ressources intermédiaire et déploie l’infrastructure de build dans votre abonnement. Après la génération, le service supprime des ressources temporaires, notamment la machine virtuelle de build et les ressources réseau associées. Le groupe de ressources intermédiaire et ses ressources de stockage restent tant que la ressource de modèle d’image existe.

VM Image Builder distribue l’image terminée à une ou plusieurs cibles que vous spécifiez. Les cibles courantes sont les suivantes :

• Azure Compute Gallery (anciennement Shared Image Gallery) : Azure Compute Gallery fournit une réplication multirégion d’images de machine virtuelle. Par exemple, vous pouvez créer une image dans une région et distribuer la version d’image Azure Compute Gallery résultante à plusieurs régions cibles.

• Stockage Blob Azure : le service peut stocker le disque dur virtuel dans le compte de stockage que VM Image Builder déploie ou dans un compte de stockage et un conteneur d’objets blob que vous spécifiez.

  Si vous utilisez le compte de stockage géré par le service comme destination de distribution de VHD, le service stocke le VHD dans le groupe de ressources intermédiaire. Lorsque vous supprimez le modèle d’image, le service supprime également le VHD. Pour conserver le VHD indépendamment du modèle d’image, distribuez-le vers un compte de stockage personnalisé ou copiez-le vers un autre emplacement avant de supprimer le modèle.

Azure Compute Gallery et Stockage Blob sont des services distincts de VM Image Builder. Vous pouvez distribuer des images à plusieurs cibles, y compris des cibles dans différentes régions Azure. Ce modèle de distribution vous permet de séparer la région où vous créez une image des régions où vous utilisez cette image.

Note

VM Image Builder prend également en charge les images gérées, qui sont une cible de distribution héritée. Cet article ne couvre pas les images gérées. Pour les scénarios de production, utilisez Azure Compute Gallery.

Architecture physique

VM Image Builder utilise des builds d’images isolées pour exécuter le processus de personnalisation et de validation de l’image de base. Le service déploie une ressource Azure Container Instances dédiée et une machine virtuelle de build dans le groupe de ressources de préproduction de votre abonnement. La ressource Container Instances exécute HashiCorp Packer pour personnaliser et valider l’image et le Générateur d’images de machine virtuelle coordonne la génération.

Pour exécuter des builds d’images, enregistrez le fournisseur de ressources Microsoft.ContainerInstance et vérifiez que votre abonnement dispose d’un quota de Container Instances suffisant. Pour plus d’informations sur l’architecture du service, les régions prises en charge et le processus de génération, consultez Vue d’ensemble d’Azure VM Image Builder.

Des services Azure distincts, tels que Azure Compute Gallery et Stockage Blob, stockent les images terminées. Configurez chaque cible de distribution pour répondre à vos besoins de résilience.

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, voir Recommandations concernant le traitement des pannes transitoires.

Vous interagissez généralement avec Azure VM Image Builder à l’aide du portail Azure, de Azure CLI, de Azure PowerShell ou de l’infrastructure en tant que code tel que Bicep. Votre pipeline de build gère les échecs temporaires. Si Azure Resource Manager retourne une réponse d’erreur temporaire, réessayez la requête avec une temporisation appropriée.

En cas d’échec d’une build, inspectez ses lastRunStatus, journaux de personnalisation et de validation, ainsi que les sorties d’exécution de distribution avant de la réexécuter. Ces détails vous aident à déterminer si une condition d’erreur temporaire, une étape de personnalisation ou une opération de distribution d’images a provoqué l’échec. Pour plus d’informations, consultez Résoudre les problèmes liés aux échecs de build de VM Image Builder.

Les opérations de génération peuvent également dépendre de systèmes externes, tels que des comptes de stockage, des référentiels de packages, des emplacements d’image source et des cibles de distribution. Concevez vos étapes de personnalisation et vos pipelines pour prendre en charge les nouvelles tentatives après un problème temporaire de réseau, de plateforme ou de dépendance.

Résilience aux échecs de zone de disponibilité

Les opérations de compilation et les images finales se comportent différemment pendant les pannes de zone.

• Builds : VM Image Builder ne prend pas en charge les zones de disponibilité et ne fournit pas de garantie de résilience de zone pour les modèles d’image ou les opérations de génération. Si une défaillance de zone affecte les ressources qu’une build utilise, la build risque de ne pas démarrer ou d’être interrompue. VM Image Builder ne déplace pas automatiquement la build vers une autre zone.

  Si vous devez exécuter des builds d’images pendant les pannes de zone, déployez vos modèles d’image et les ressources de prise en charge dans plusieurs régions Azure. Pour plus d’informations, consultez les solutions multirégions personnalisées pour la résilience.

• Images : Les images finalisées restent disponibles si leur stockage est résilient aux zones.

  • Azure Compute Gallery : les versions d’image de la galerie Azure Compute Gallery peuvent utiliser le stockage redondant interzone (ZRS) dans les régions cibles qui prennent en charge les zones de disponibilité. Pour chaque région cible, sélectionnez ZRS comme type de réplication de compte de stockage. La valeur par défaut est le stockage localement redondant (LRS), qui n’est pas résilient aux défaillances de zone. Pour plus d’informations, consultez haute disponibilité d’Azure Compute Gallery.

  • Disques durs virtuels dans Stockage Blob Azure : si vous n'utilisez pas de compte de stockage personnalisé, vm Image Builder crée un compte de stockage ZRS par défaut dans les régions qui prennent en charge les zones de disponibilité. Si vous utilisez un compte de stockage personnalisé, vous êtes responsable de la configuration de sa redondance pour répondre à vos besoins. Utilisez ZRS pour stocker des copies du VHD sur plusieurs zones de disponibilité. Pour plus d’informations sur le fonctionnement de ZRS, consultez Fiabilité dans Stockage Blob Azure.

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

Les opérations de génération et les images finales se comportent différemment pendant les défaillances à l’échelle de la région.

• Builds : Azure VM Image Builder est un service à région unique et ne fournit pas de basculement multirégion intégré. Si la région qui héberge votre modèle d’image devient indisponible, le modèle d’image et les opérations de génération de cette région sont également indisponibles. Le service ne bascule pas automatiquement en cas de défaillance vers une autre région.

  Si vous devez exécuter des builds d’images pendant les pannes de région, déployez vos modèles d’image et les ressources de prise en charge dans plusieurs régions Azure. Pour plus d’informations, consultez les solutions multirégions personnalisées pour la résilience.

• Images : les images finalisées restent disponibles si leur stockage est résilient aux défaillances à l’échelle de la région.

  • Azure Compute Gallery : vous pouvez configurer Azure Compute Gallery pour répliquer des versions d’images dans plusieurs régions. La réplication est asynchrone et vous pouvez utiliser une version d’image dans une région cible uniquement après la fin de la réplication vers cette région.

    Pendant une panne dans une région, les réplicas terminés restent disponibles pour les déploiements de machines virtuelles dans des régions cibles saines. Toutefois, si la région qui contient la ressource de galerie n’est pas disponible, vous ne pouvez pas créer ou mettre à jour les ressources de la galerie. Si vous devez continuer à publier des versions d’images lors d’une panne de région, conservez des galeries distinctes dans des régions de build distinctes. Pour plus d’informations, consultez Réplication et meilleures pratiques d’Azure Compute Gallery.

  • Disques durs virtuels dans Stockage Blob Azure : la destination de disque dur virtuel gérée par le service par défaut ne fournit pas de géoredondance. Dans les régions qui prennent en charge les zones de disponibilité, elle utilise ZRS, qui ne protège pas contre une défaillance à l’échelle de la région.

    Dans une région avec une région jumelée, vous pouvez distribuer le VHD à un compte de stockage personnalisé qui utilise le stockage géoredondant (GRS) ou le stockage géoredondant interzone (GZRS). Les services GRS avec accès en lecture (RA-GRS) et GZRS en lecture (RA-GZRS) fournissent un accès en lecture seule via un point de terminaison secondaire, mais ils n’effectuent pas de basculement. Pour restaurer l’accès en lecture-écriture normal dans la région jumelée, lancez un basculement géré par le client ou copiez le disque dur virtuel du point de terminaison secondaire vers un compte de stockage distinct. La géoréplication est asynchrone. Par conséquent, un basculement non planifié peut entraîner la perte de données qui n’ont pas été répliquées. Vérifiez la propriété Heure de la dernière synchronisation du compte de stockage avant le basculement si possible.

    Pour plus d’informations sur le comportement de basculement de Stockage Blob et d’autres approches pour répliquer des données entre des régions non appariées, consultez Fiabilité dans Stockage Blob Azure.

Solutions multirégions personnalisées pour la résilience

Si vous devez continuer à générer des images lors d’une panne de région, vous êtes responsable du déploiement et de l’exploitation d’environnements de build indépendants dans plusieurs régions.

Choisissez les régions qui prennent en charge VM Image Builder. Dans chaque région de build, prédéployez un modèle d’image et ses dépendances spécifiques à la région, notamment les identités managées et les attributions de rôles, la configuration réseau, les artefacts de personnalisation, une image source ou un réplica d’image et des cibles de distribution.

Si vous devez publier des images alors que la région d’une galerie n’est pas disponible, utilisez une ressource Compute Gallery indépendante dans chaque région de build. La réplication des versions d’images à partir d’une même galerie ne fait pas de la galerie une ressource entièrement multirégion.

Définissez ces ressources à l’aide de l’infrastructure en tant que code et traitez ces définitions comme source de vérité. Conservez les environnements régionaux synchronisés lorsque la configuration change et testez régulièrement que chaque environnement peut générer et distribuer une image.

Sauvegarde et restauration

Azure Vm Image Builder ne remplace pas votre processus de sauvegarde et de récupération. Dans la plupart des cas, l’artefact qui compte pour la récupération est l’image terminée que vous publiez dans Azure Compute Gallery ou dans le stockage VHD.

Pour améliorer la récupération à partir d’une corruption ou d’une panne non planifiée étendue, suivez les recommandations suivantes :

• Conservez les images publiées dans Azure Compute Gallery ou d’autres cibles de distribution en fonction de vos besoins de rétention.

• Si vous créez un disque dur virtuel et utilisez la destination du disque dur virtuel par défaut, copiez le disque dur virtuel dans votre propre stockage durable avant de supprimer le modèle d’image.

• Utilisez le contrôle de code source pour stocker les définitions de modèle d’image et gérer leurs versions.

• Utilisez le contrôle de code source ou un autre type de stockage durable pour stocker les scripts et les packages de personnalisation et gérer leurs versions.

• Vérifiez régulièrement que chaque environnement de récupération prédéployé peut générer et distribuer une image.

Résilience à la maintenance du service

Microsoft gère la maintenance pour Azure VM Image Builder. Vm Image Builder ne sert pas le trafic d’application au moment de l’exécution. La maintenance n’affecte donc pas les machines virtuelles que vous avez déjà créées à partir d’images publiées. Si une build est retardée ou interrompue pendant la maintenance ou un autre événement de service, inspectez son état et ses journaux, puis réexécutez-la.

Utilisez Azure Service Health pour surveiller la maintenance planifiée et les incidents de service susceptibles d’affecter votre région de build.

Contrat de niveau de service

Azure VM Image Builder ne fournit pas de contrat de niveau de service de disponibilité (SLA).

Tout contrat SLA qui s’applique à une cible de distribution ou à un service de stockage s’applique séparément et ne fournit pas d’engagement de disponibilité pour les opérations de build ou de modèle VM Image Builder.

Contenu connexe

• Vue d’ensemble Azure VM Image Builder
• Créer un modèle VM Image Builder
• Générations d’images isolées pour Azure VM Image Builder
• Résoudre les problèmes liés à Azure VM Image Builder
• Vue d’ensemble d’Azure Compute Gallery