Partager via

Utiliser l’infrastructure comme code pour mettre à jour les zones d’atterrissage Azure

  • Article

Cet article décrit les avantages de l’utilisation de l’infrastructure en tant que code (IaC) pour mettre à jour les zones d’atterrissage Azure. Les organisations doivent mettre à jour leurs zones d’atterrissage pendant leur fonctionnement pour s’assurer que les configurations sont correctes et qu’elles répondent au besoin de modifications.

IaC peut gérer l’ensemble du cycle de vie et excelle dans la gestion des ressources qu’elle déploie. Les organisations doivent planifier le déploiement de leurs zones d’atterrissage Azure avec IaC. Cela nécessite une planification pour aligner les ressources non IaC existantes avec les ressources IaC qui sont soutenues par la gestion de l’état. Vous devez mapper les ressources existantes à l’état souhaité.

Pour plus d’informations, consultez Maintenir votre zone d’atterrissage Azure à jour.

Fonctionnement de l’infrastructure en tant que code (IaC)

IaC fait référence à la pratique et aux outils de gestion du cycle de vie des ressources d’infrastructure à l’aide de fichiers de définition lisibles par ordinateur. La définition de l’infrastructure est écrite, versionnée, déployée via des pipelines, puis fait partie du déploiement pour les charges de travail.

Les technologies IaC sont déclaratives, ce qui signifie que lorsque l’IaC s’exécute, elle définit la configuration sur ce qui est décrit dans le code, quel que soit son état actuel. Lorsque vous configurez l’infrastructure par le biais de scripts, tels que Azure CLI ou Azure PowerShell, elles sont impératives. Les scripts impératifs exécutent un ensemble d’actions, et le résultat dépend de l’état actuel plus de l’état après les actions.

Par conséquent, si vous disposez d’une définition d’infrastructure en tant que code pour une ressource Azure, vous pouvez exécuter cette définition aussi souvent que vous le souhaitez, et cela crée une modification uniquement si :

  • La définition change pour ajouter de nouvelles ressources, supprimer des ressources précédemment déployées ou modifier les ressources précédemment déployées.
  • La ressource déployée dérive de la configuration pour réinitialiser la configuration à celle définie.

Vous pouvez utiliser IaC pour restaurer l’état en supprimant les ressources qui ne sont plus nécessaires et en gérant le cycle de vie des ressources par le biais de nombreuses modifications.

Notes

Les mécanismes spécifiques permettant de supprimer des ressources avec IaC varient. Par exemple, Azure Bicep nécessite l’utilisation d’un type de déploiement complete pour corriger les ressources hors de portée. Cette commande fonctionne uniquement dans des portées spécifiques. Pour Terraform, les ressources ont un méta-argument lifecycle qui fournit des instructions sur la façon dont Terraform doit gérer les ressources.

Pour les zones d’atterrissage Azure, il existe deux principales options pour l’infrastructure en tant que code :

Avantages de la mise à jour d’ALZ avec l’infrastructure en tant que code

Les avantages suivants décrivent pourquoi vous devez utiliser l’infrastructure en tant que code pour effectuer les mises à jour de votre zone d’atterrissage.

Réduire les efforts

Utiliser l’infrastructure en tant que code pour effectuer des mises à jour requiert moins d’efforts que les modifications manuelles. Le déploiement IaC permet de répondre aux questions suivantes :

  • Comment les ressources sont-elles configurées aujourd’hui ?
  • Comment sera-t-elle configurée par cette mise à jour ?
  • Quelles modifications seront apportées pour l’aligner sur cette mise à jour ?

Lorsqu’une infrastructure en tant qu’ensemble d’outils de code s’exécute, elle peut produire une comparaison ou une lecture « différentielle » des modifications. Passez en revue cette lecture avant de valider les modifications apportées à l’environnement.

L’ensemble d’outils peut compiler les informations relatives à la modification plutôt qu’un opérateur ou un ingénieur.

Réduire l’erreur

En raison de la nature programmatique des déploiements, l’infrastructure en tant que code réduit les erreurs humaines pendant qu’elle apporte des modifications. Il ne modifie que ce qui est défini et propose des options d’aperçu pour réduire les pannes causées par des modifications incomplètes ou ayant échoué. Il offre également des options de test améliorées.

Contrôle de version et historique de version

Les déploiements d’infrastructure en tant que code s’appuyant sur un fichier de définition, vous pouvez donc utiliser le contrôle de code source pour gérer les versions de vos définitions. Selon la méthode d’IaC que vous utilisez, vous pouvez référencer les déploiements dans Azure pour Bicep ou votre fichier d’état pour Terraform afin de passer en revue l’historique des déploiements précédents.

Lorsque vous utilisez des pratiques de contrôle de code source, une branche de votre IaC est créée pour ajouter des modifications et des révisions. L’historique de la branche dans votre système de contrôle de code source capture les itérations et les modifications. Vous pouvez l’utiliser pour déployer des modifications dans un environnement de test jusqu’à ce que vous soyez prêt à fusionner et à déployer les modifications en production. Pour plus d’informations, consultez Approche de test pour les zones d’atterrissage Azure. Tout au long de ce cycle, les enregistrements de déploiement capturent la version utilisée et les ressources déployées, ce qui fournit un historique très visible.

Utilisez ces méthodes de test avec Bicep à des fins de test. Grâce à ces méthodes, vous pouvez effectuer des tests avant de déployer le code, et vous pouvez effectuer des tests dans des environnements hors production à partir de votre branche.

Environnements de test

Les déploiements IaC étant reproductibles, vous pouvez utiliser la même définition pour déployer un deuxième environnement (ou plus) basé sur le déploiement. Cette méthode est utile pour tester les modifications.

Par exemple, si vous souhaitez remplacer votre Pare-feu Azure à l’aide de la référence SKU Premium, vous pouvez déployer un environnement de test et valider les modifications sans modifier la production.

Intercepter les dérives de configuration

IaC fournit une option unique pour intercepter les dérives de configuration pendant les mises à jour. Le déploiement intercepte les modifications apportées au fichier de définition et présente des instances où la configuration des ressources diffère de la définition.

Les mises à jour de zone d’atterrissage avec IaC peuvent vous aider à intercepter cette dérive de configuration et vous permettent de mettre à jour le code de manière appropriée, de résoudre ces erreurs de configuration via la mise à jour ou de les résoudre d’une autre manière.

Lorsque vous apportez une modification aux ressources via le portail, l’interface CLI ou une méthode non IaC, la modification est implémentée. À la prochaine exécution d’un déploiement via IaC, il signale la comparaison entre l’état défini par le code et l’état réel dans le portail à l’aide de fonctions de scénario ou de plan. Utilisez cette méthode pour déterminer si un environnement est modifié en dehors du fichier de code.

Une fois l’alignement incorrect identifié, vous pouvez exécuter IaC pour tenter d’aligner le déploiement sur la définition. Utilisez cette méthode pour identifier les problèmes et corriger les scénarios en fonction de la nature des problèmes, de la nature de l’exécution et de la façon dont les modifications ont été apportées. Par exemple, Terraform tente de restaurer la base de référence sur les ressources qu’il a déployées, et un déploiement en mode Complete dans Bicep supprime les ressources d’un groupe de ressources qui ne font pas partie de la définition. Ces outils détectent et réparent la dérive de configuration, mais ils peuvent ne pas résoudre tous les problèmes.

Pour plus d’informations, consultez Modifications hors bande et Détection et gestion de la dérive avec Terraform.

Les modifications définies dans le portail sont difficiles à implémenter à nouveau dans l’IaC. Vous devez mettre à jour le code pour qu’il corresponde à l’état actuel, ce qui implique souvent l’examen de chaque modification de ressource et la mise à jour de ses paramètres pour qu’ils correspondent à la configuration « telle quelle ».

Si vous utilisez IaC pour gérer votre zone d’atterrissage ou d’autres ressources, vous devez uniquement apporter des modifications en dehors de l’IaC dans le cadre d’une urgence. Prenez des précautions avec les comptes qui ont accès pour apporter des modifications directement, par exemple Privileged Identity Management.

Passez en revue les pratiques générales d’automatisation et de sécurité dans les articles suivants :

Étapes suivantes

Découvrez une introduction aux outils IaC dans les articles suivants :