L’Infrastructure as Code consiste à décrire les ressources et leurs paramètres dans des fichiers versionnés. Son intérêt apparaît lorsqu’une équipe peut expliquer un changement, le revoir et le reproduire. L’outil ne suffit pas : les responsabilités, les accès et les procédures restent à construire autour du code.
Définir un premier résultat observable
Choisissez un ensemble de ressources assez petit pour être compris et assez utile pour être conservé : un environnement de test, un réseau applicatif ou un socle de déploiement. Notez ce qui existe déjà et qui le modifie. Il faut éviter qu’un premier pipeline reprenne accidentellement la responsabilité d’une ressource partagée. Prévoyez une validation du résultat avec la personne chargée de son exploitation.
Choisir l’outil et les frontières
Bicep est un langage déclaratif destiné aux ressources Azure. Terraform s’appuie sur des fournisseurs pour gérer les ressources qu’ils exposent. Le choix dépend du parc, de la couverture nécessaire et des compétences disponibles. Une règle pratique consiste à attribuer clairement la gestion de chaque ressource : plusieurs outils ou équipes qui modifient les mêmes propriétés rendent l’état final difficile à comprendre. Les exceptions doivent être documentées.
Faire passer les changements par une revue
Un dépôt Git conserve les modules, paramètres non secrets et explications des décisions. Chaque modification doit pouvoir répondre à trois questions : pourquoi, sur quel environnement et avec quel impact ? Les vérifications syntaxiques et la prévisualisation des changements aident à préparer cette revue. Le what-if de Bicep ou le plan Terraform ne garantissent toutefois pas que l’application fonctionnera après la modification : une validation métier et technique reste nécessaire.
Protéger le state et les secrets
Terraform utilise un state pour associer les objets décrits aux ressources réelles. Ce fichier peut contenir des informations sensibles. Son emplacement, ses droits, sa sauvegarde et le verrouillage fourni par le backend doivent être définis avant le travail en équipe. Un attribut marqué « sensitive » peut masquer une valeur dans l’affichage sans supprimer sa présence dans le state. Les journaux, plans et artefacts de pipeline demandent aussi une politique d’accès.
Séparer les identités de déploiement
Préparez une identité de pipeline avec des droits limités au lot à gérer. Distinguez les paramètres et autorisations des environnements de test et de production. Définissez qui approuve une modification sensible et comment une intervention urgente est réintégrée dans le code. Cette organisation facilite le traitement de la dérive : un écart entre les fichiers et la réalité doit conduire à une décision, sans réappliquer aveuglément une configuration devenue inadaptée.
Tester une reprise réelle
Revenir à une ancienne version du dépôt ne rétablit pas nécessairement les données, les identifiants ou les effets d’une suppression. Préparez une procédure de reprise comprenant les sauvegardes et les dépendances de l’application. Un exercice sur l’environnement de test permet de vérifier les accès, la documentation et les étapes manquantes. Le livrable utile est un ensemble que votre équipe peut reprendre, avec ses limites et ses modalités de maintenance.
TheWayITis peut cadrer un premier lot IaC, préparer les modules et accompagner votre équipe dans leur revue, leur déploiement et leur exploitation.
Sources et repères
Microsoft — Infrastructure déclarative avec BicepMicrosoft — Prévisualiser les changements BicepHashiCorp — Protéger les données sensibles de TerraformHashiCorp — Verrouillage du state TerraformPasser du conseil à votre situation
Décrivez votre infrastructure dans des fichiers versionnés pour mieux comprendre, revoir et reproduire ses configurations. TheWayITis vous aide à introduire l’Infrastructure as Code, ou IaC, de façon progressive.
Infrastructure as Code et automatisation