Utiliser l’infrastructure en tant que code pour mettre à jour les zones d’atterrissage Azure

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 au fur et à mesure qu’elles opèrent 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 il excelle lors de la gestion des ressources qu’il 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 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 l’ordinateur. La définition de l’infrastructure est écrite, versionnée, déployée via des pipelines, puis devient une 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 effectuent un ensemble d’actions, et le résultat dépend de l’état actuel et de l’état après les actions.

Par conséquent, si vous avez une infrastructure en tant que définition de code pour une ressource Azure, vous pouvez exécuter cette définition aussi souvent que vous le souhaitez, et elle crée uniquement une modification 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 via de nombreuses modifications.

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

• Azure Bicep, qui est un langage spécifique au domaine utilisé pour déployer des ressources Azure développées par Microsoft. Pour plus d’informations, consultez Zones d’atterrissage Azure – Considérations relatives à la conception des modules Bicep.
• Terraform, produit produit par Hashicorp, pour déployer l’infrastructure dans le cloud et localement. Terraform a des fournisseurs de ressources produits par Microsoft spécifiques pour le déploiement de ressources Azure. Pour plus d’informations, consultez zones d’atterrissage Azure - Considérations relatives à la conception du module Terraform.

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 comme code pour mettre à jour votre zone d’atterrissage.

Réduire les efforts

Il faut moins d’efforts pour utiliser l’infrastructure en tant que code pour effectuer des mises à jour par rapport à apporter des modifications manuelles. Le déploiement IaC vous aide à répondre aux questions suivantes :

• Comment les ressources sont-elles configurées aujourd’hui ?
• Comment sera-t-il configuré 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 pour 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 l'erreur humaine lorsqu'elle apporte des modifications. Il modifie uniquement ce qui est défini et dispose d’options d’aperçu, ce qui réduit les pannes provoquées par des modifications ayant échoué ou incomplètes. Il a également amélioré les options de test.

Contrôle de version et historique

L’infrastructure en tant que déploiements de code est sauvegardée par 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 iaC que vous utilisez, vous pouvez référencer les déploiements dans Azure pour Bicep ou votre fichier d’état pour Terraform pour passer en revue l’historique des déploiements précédents.

Lorsque vous utilisez des pratiques de contrôle de code source, il crée une nouvelle branche de votre iaC 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 des 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, qui fournissent un historique hautement visible.

Utilisez ces méthodes de test avec Bicep à des fins de test générales. Avec 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 sont reproductibles. Vous pouvez donc utiliser la même définition pour déployer un deuxième environnement (ou plus) en fonction du 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.

Détecter les dérives de configuration

IaC offre 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 les instances où la configuration de la ressource 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 traiter ces configurations incorrectes via la mise à jour ou de les traiter 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 fois que vous exécutez 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 identifier 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 avec 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 fastidieuses à implémenter dans IaC. Vous devez mettre à jour le code pour qu’il corresponde à l’état actuel, ce qui implique souvent d’examiner chaque modification de ressource et de mettre à jour ses paramètres pour qu’ils correspondent à la configuration « tel quel ».

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, telles que Privileged Identity Management.

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

• recommandations de conformité opérationnelle
• Recommandations de conception de l'automatisation de plateforme

Étapes suivantes

Explorez une présentation des outils IaC dans les articles suivants :

• Qu’est-ce que Bicep ?
• Qu’est-ce que Terraform ?
• Test du code Terraform