Terraform Fundamentals

Salut, c'est Alex de DEV STORIES DOT EU. Les fondamentaux de Terraform, épisode 1 sur 13. Avant, provisionner des serveurs, ça voulait dire ouvrir un ticket au support et attendre deux semaines que quelqu'un clique un peu partout dans une console cloud. Aujourd'hui, ce même processus se résume à une simple pull request qui se déploie en toute sécurité en quelques minutes. Ce changement est entièrement porté par le paradigme de l'Infrastructure as Code, et HashiCorp Terraform en est le moteur principal. L'Infrastructure as Code, c'est exactement ce que ça dit. Tu gères tes bases de données, tes réseaux virtuels et tes instances de compute avec de simples fichiers texte au lieu de faire des clics manuels. Ces fichiers peuvent être versionnés, revus par tes collègues et testés automatiquement. Pour comprendre pourquoi c'est si puissant, imagine un admin système qui a besoin d'une nouvelle machine virtuelle Azure. Avec un workflow impératif, il pourrait écrire un script PowerShell complexe. Ce script doit définir explicitement chaque action, dans l'ordre. Il dit au système de se connecter, de vérifier si un réseau existe, de le créer s'il n'y en a pas, d'allouer une IP publique, et enfin de démarrer le serveur. Si le script plante à l'étape quatre, tu te retrouves avec une infrastructure à moitié construite. Relancer le script une deuxième fois cause souvent des erreurs parce que certaines ressources existent déjà. Terraform utilise plutôt une approche déclarative. Tu n'écris pas la suite d'étapes. Tu définis simplement l'état final désiré. Tu écris un fichier de configuration qui dit que tu veux une machine virtuelle Azure attachée à un réseau spécifique. Terraform compare l'état que tu as demandé avec ce qui existe actuellement dans le cloud. Il calcule ensuite la séquence exacte d'appels d'API nécessaires pour combler cet écart. Si le réseau existe déjà, Terraform n'y touche pas et construit uniquement le serveur. Voici le point clé. Beaucoup d'ingénieurs confondent les outils de provisionnement d'infrastructure comme Terraform avec les outils de gestion de configuration comme Chef, Puppet ou Ansible. Ce n'est pas la même chose. Terraform construit la maison. Les outils de gestion de configuration placent les meubles. Terraform provisionne les ressources cloud brutes, comme les load balancers et les machines virtuelles. Ansible ou Chef se connectent ensuite à ces machines pour installer des packages logiciels et démarrer des services en arrière-plan. Les outils de gestion de configuration ont été fondamentalement conçus pour de l'infrastructure mutable. Ils s'attendent à ce qu'un serveur vive longtemps et subisse des patchs et des ajustements constants. Terraform te pousse vers une infrastructure immutable. Si un environnement a besoin d'une version différente du système d'exploitation, Terraform ne se connecte pas pour lancer un script d'upgrade. Il détruit l'ancien serveur et en provisionne un tout nouveau avec la bonne image. Cette approche stricte garantit que ton code correspond toujours à la réalité, ce qui élimine complètement le configuration drift. Ce workflow est particulièrement précieux parce qu'il est agnostique en termes de plateforme. Une entreprise utilise rarement un seul fournisseur. Tu pourrais faire tourner tes workloads principaux sur Azure, gérer ton DNS via Cloudflare, et gérer le routage des incidents dans PagerDuty. Terraform gère tout ça grâce à un modèle de provider. Un provider, c'est simplement un plugin qui comprend l'API d'un fournisseur spécifique. En utilisant plusieurs providers, tu peux créer une seule configuration qui déploie une base de données Azure, configure les enregistrements DNS nécessaires, et met en place les alertes de monitoring en même temps. Les appels d'API sous-jacents changent, mais ton workflow reste exactement le même. Si tu veux nous aider à continuer ces épisodes, tu peux chercher DevStoriesEU sur Patreon pour soutenir l'émission. Un outil qui se contente d'automatiser des tâches te rend plus rapide, mais un outil qui impose un état déclaratif rend tout ton système prévisible. Je voudrais prendre un instant pour te remercier de ton écoute, ça nous aide beaucoup. Passe une excellente journée !

Salut, c'est Alex de DEV STORIES DOT EU. Les fondamentaux de Terraform, épisode 2 sur 13. Tu cliques sur deploy, tu regardes la console et tu croises les doigts, en espérant que tu n'as pas juste fait tomber l'environnement de production. Ce saut dans le vide est un risque énorme, et c'est exactement ce que le workflow de base de Terraform élimine. Le workflow se compose de trois étapes strictes : write, plan et apply. Chaque étape fonctionne indépendamment pour traduire tes besoins en ressources actives. Tu commences par la phase write. Tu crées des fichiers de configuration qui déclarent l'infrastructure exacte que tu veux. Tu n'écris pas un script procédural qui explique comment construire un serveur étape par étape. Tu décris l'état final désiré de ton environnement. Tu sauvegardes ces fichiers, et ton code devient la source unique de vérité pour ce qui doit exister. Les nouveaux utilisateurs pensent parfois que l'étape suivante consiste juste à exécuter ces fichiers de manière séquentielle, de haut en bas. Ce n'est pas comme ça que cet outil fonctionne. Il ne lance pas des commandes à l'aveugle. À la place, il passe à la phase plan. La phase plan est le superpouvoir absolu de ce workflow. Quand tu lances la commande plan, l'outil évalue ta nouvelle configuration par rapport à l'état actuel et réel de ton infrastructure. Il calcule un diff précis entre la réalité et le code que tu souhaites. Et c'est là qu'est le point clé. L'outil lit ce diff et génère un dry run ultra détaillé de chaque action qu'il a l'intention de faire. Prends l'exemple d'un ingénieur qui doit ajouter un Load Balancer Azure à un environnement live. Il met à jour ses fichiers de configuration et lance la commande plan. Le système se connecte au cloud provider, vérifie l'état actif et affiche un résumé strict. L'ingénieur lit l'output et voit une ressource à ajouter, zéro à modifier, et zéro à détruire. L'output détaille les propriétés exactes du nouveau Load Balancer. L'ingénieur valide ce dry run. Il sait que le changement est sûr avant même qu'un seul appel API ne modifie l'infrastructure réelle. Pas de place au hasard. Après avoir validé l'output, tu passes à la phase apply. C'est le moment de l'exécution. L'outil prend le diff exact calculé pendant la phase plan et construit un graphe d'exécution strict. Il cartographie toutes les dépendances. Si ton nouveau Load Balancer nécessite une adresse IP publique dédiée, le graphe d'exécution s'assure que l'IP est provisionnée en premier. Le système attend que l'IP devienne disponible, récupère sa nouvelle adresse, et seulement à ce moment-là, crée le Load Balancer. Il gère le timing et l'ordre automatiquement. Parce que la phase apply suit strictement le plan d'exécution approuvé, tu n'as jamais de ressources qui se lancent dans le mauvais ordre, ni de bases de données existantes supprimées accidentellement à cause d'une faute de frappe. Le workflow te force à séparer l'intention de l'exécution. L'aspect le plus puissant de ce processus n'est pas le provisionnement automatisé en lui-même. C'est l'élimination totale de l'anxiété opérationnelle grâce à des dry runs prévisibles et révisables. C'est tout pour cet épisode. Merci de ton écoute, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. Terraform Fundamentals, épisode 3 sur 13. De base, l'application Terraform core ne sait pas vraiment comment builder une machine virtuelle Azure ou créer une base de données. C'est strictement un moteur qui évalue le code, détermine les dépendances et gère le state. Pour faire le vrai travail, il s'appuie sur des milliers de plugins de traduction téléchargeables. Ça nous amène aux providers et à la façon dont tu connectes ton code à Azure. Une erreur courante, c'est de penser que l'application Terraform elle-même contient la logique pour chaque plateforme cloud. Ce n'est pas le cas. Le binaire que tu installes sur ta machine est complètement agnostique en termes d'infrastructure. Il comprend le langage de configuration et le workflow de déploiement, mais il n'a aucune connaissance hardcodée d'une API cloud spécifique. À la place, Terraform utilise des plugins appelés providers. Un provider est un logiciel autonome qui comprend les endpoints, les méthodes d'authentification et les comportements des ressources pour une plateforme spécifique. Il y a un provider pour Microsoft Azure, un pour Amazon Web Services, et d'autres pour des plateformes SaaS comme GitHub ou Datadog. Ces plugins sont publiés et hébergés dans un annuaire central appelé le Terraform Registry. Quand tu démarres un nouveau projet d'infrastructure, tu dois déclarer explicitement quels providers ton code va utiliser. Tu dois aussi spécifier la version exacte du provider que tu veux. Verrouiller une version est une pratique critique. Ça garantit que si l'API cloud change ou si le plugin du provider reçoit une mise à jour majeure demain, ton déploiement ne va pas casser de façon inattendue. C'est toi qui contrôles exactement quand faire l'upgrade. Le simple fait de déclarer le provider dans ton fichier texte ne l'installe pas. Tu dois lancer une commande d'initialisation dans ton terminal. Cette étape d'initialisation va contacter le Terraform Registry, télécharger les plugins des providers requis et les mettre en cache dans un répertoire local caché. Tant que tu n'as pas lancé cette étape, ton projet Terraform ne peut interagir avec aucun système externe. Voyons comment configurer ça pour un nouveau projet qui se connecte à un abonnement Azure d'entreprise. Tu vas utiliser le provider officiel Azure Resource Manager, qu'on appelle azurerm. Après avoir déclaré la version dont tu as besoin, tu dois configurer le comportement spécifique du provider. Chaque provider a ses propres exigences de configuration, basées sur l'API sous-jacente. Pour Azure, le plugin exige que tu déclares explicitement comment il doit gérer certains comportements des ressources. Par exemple, tu dois dire au provider s'il doit supprimer définitivement les disques de stockage attachés quand une machine virtuelle est détruite. Le provider exige cette configuration en amont pour que les actions destructrices soient toujours intentionnelles. Une fois initialisé et configuré, le provider agit comme une couche de traduction plug-and-play. Quand tu exécutes ton code, le moteur core de Terraform calcule la différence entre ton infrastructure actuelle et ton state désiré. Il passe ensuite ces instructions génériques au plugin du provider Azure. Le plugin prend le relais, en traduisant ton intention en requêtes HTTP authentifiées envoyées directement à l'API Azure Resource Manager. Le plugin attend qu'Azure ait fini de créer ou de modifier les ressources, traduit la réponse de l'API dans un format que Terraform comprend, et renvoie les données finales au moteur core. Terraform lui-même ne parle jamais directement à ton environnement cloud ; il délègue chaque appel d'API au plugin du provider, ce qui fait du provider le véritable pont entre ton code et ton infrastructure live. C'est tout pour cet épisode. Merci de ton écoute, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. Les fondamentaux de Terraform, épisode 4 sur 13. Tu regardes ton code et tu vois une base de données appelée primary, mais quand tu te connectes à ta console cloud, cette même base de données porte un nom complètement différent, comme db-cluster-node-one. Si tu veux que quelque chose existe physiquement dans ton environnement cloud, tu dois le demander en utilisant la structure la plus importante de Terraform, mais tu dois aussi comprendre comment Terraform nomme les choses. Aujourd'hui, on parle de la déclaration d'infrastructure avec les ressources. Les ressources sont les composants fondamentaux de ton infrastructure. À chaque fois que tu veux créer, mettre à jour ou détruire un objet, tu écris un bloc resource. Cet objet peut être un composant physique comme une instance compute ou un disque de stockage, ou une structure logique comme un enregistrement DNS ou une assignation de rôle. Le bloc resource, c'est ce qui te permet de traduire l'idée d'un composant d'infrastructure en une requête API que ton cloud provider comprend vraiment. Quand tu déclares un bloc resource, tu définis son identité avec deux labels distincts. D'abord, tu déclares le resource type. Ça indique exactement à Terraform quel genre d'objet tu veux construire et quel provider va le construire. Le type commence toujours par le namespace du provider, comme Azure ou AWS, suivi du service spécifique. En gros, tu dis à Terraform que tu as besoin d'un resource group Azure, ou d'un storage bucket AWS. Juste après le resource type, tu définis l'identifiant local. C'est tout simplement un surnom. Il n'existe que dans ta configuration Terraform. Tu utilises ce surnom pour référencer l'objet depuis d'autres parties de ton code. Ça n'a absolument aucun effet sur ce que voit ton cloud provider. Ce qui nous amène au bloc de configuration lui-même. Une fois que tu as déclaré le type et le surnom local, tu définis les arguments pour cette ressource. Les arguments sont les paramètres et les valeurs spécifiques qui configurent l'objet. C'est là que tu passes les vrais paramètres requis par l'API du cloud provider. Pour mettre tout ça en pratique, imagine que tu déploies un resource group Azure. Tu déclares le resource type pour un resource group Azure, et tu lui donnes un surnom local comme main. À l'intérieur du bloc de configuration, tu fournis les vrais arguments. Tu définis un argument name et tu lui donnes la valeur rg-enterprise-prod, et tu définis un argument location que tu règles sur une région spécifique. Quand tu lances ton deploy, Terraform utilise le resource type pour savoir quelle API du provider appeler. Il utilise tes arguments pour dire exactement à l'API comment configurer la ressource. Dans le portail Azure, ton resource group apparaîtra sous le nom rg-enterprise-prod. Azure ne sait absolument rien du surnom main. Mais de retour dans ton code, à chaque fois que tu as besoin de récupérer l'ID ou la location de ce resource group pour les passer à une machine virtuelle ou à une base de données, tu demandes simplement à Terraform les données contenues dans la ressource locale appelée main. Chaque resource type a son propre ensemble unique d'arguments. Certains sont obligatoires, comme la location pour un resource group ou la taille d'instance pour un serveur virtuel. D'autres sont optionnels, comme le tagging ou des règles de routage spécifiques. La documentation du provider indique exactement quels arguments tu peux utiliser. Tu as juste à mapper les valeurs dont tu as besoin dans le bloc resource, et Terraform gère la traduction en appels API qui vont réellement provisionner ton infrastructure. Ton identifiant local appartient à Terraform pour garder ton code lisible, mais tes arguments appartiennent au cloud pour définir la réalité. Merci d'avoir écouté. À la prochaine !

Bonjour, c'est Alex de DEV STORIES DOT EU. Terraform Fundamentals, épisode 5 sur 13. Si une database doit exister avant qu'un serveur web puisse s'y connecter, comment un outil d'infrastructure sait lequel build en premier sans scripts séquentiels ? Si tu viens d'un background de scripting impératif comme Bash ou Python, tu cherches peut-être un moyen de forcer l'exécution ligne par ligne. Mais dans Terraform, l'ordre des lignes dans ton fichier n'a aucune importance. La seule chose qui compte, ce sont les relations et les dépendances entre les ressources. Terraform est un moteur d'exécution super intelligent. Avant de créer quoi que ce soit, il analyse ta configuration et construit un directed acyclic graph. Ce graphe cartographie exactement comment chaque morceau d'infrastructure se connecte aux autres. Il utilise cette carte pour déterminer l'ordre de création le plus efficace, en créant les ressources indépendantes en parallèle et en séquençant celles qui dépendent les unes des autres. Tu n'écris jamais de scripts de wait ou de sleep manuels. La plupart du temps, Terraform gère ce séquençage automatiquement grâce aux dépendances implicites. Une dépendance implicite se produit quand une ressource fait référence à un attribut d'une autre ressource. Imagine un scénario où tu crées un Virtual Network Azure et un Subnet. Un Subnet ne peut pas exister sans Virtual Network. Dans ta configuration, tu définis le block du Virtual Network, puis tu définis le block du Subnet. À l'intérieur du block du Subnet, tu configures l'argument virtual network name pour qu'il pointe directement sur l'attribut name de la ressource Virtual Network que tu viens de définir. Quand Terraform parse ça, il voit la connexion. Il sait d'office qu'il doit terminer la création du Virtual Network et récupérer son name généré avant même de pouvoir commencer à créer le Subnet. Tu n'as pas besoin de lui dire quoi faire. Tu passes juste la data, et Terraform gère le timing. C'est ça qui est important. Utilise toujours les dépendances implicites si tu peux. En référençant les attributs directement, tu donnes à Terraform les infos exactes dont il a besoin pour optimiser tes deploys en toute sécurité. Parfois, la relation entre deux ressources n'est pas visible dans le code. Tu peux avoir une situation où une ressource a besoin qu'une autre ressource soit complètement active, mais elle n'a pas vraiment besoin d'en tirer de la data. Imagine que tu déploies une Virtual Machine qui fait tourner une application, tout en provisionnant une managed database. L'application a besoin que la database finisse de boot avant de pouvoir démarrer. Cependant, la configuration de la Virtual Machine ne référence aucun attribut de la ressource database. Comme il n'y a pas de lien de data, Terraform part du principe que ces deux ressources n'ont aucun rapport et va essayer de les build en même temps. L'application va boot, chercher une database qui n'existe pas encore, et fail. Pour corriger ça, tu utilises des dépendances explicites. Terraform fournit un meta-argument appelé depends on. Tu ajoutes cet argument au block de la Virtual Machine et tu lui passes une liste contenant la ressource database. Ça dit explicitement à Terraform de mettre en pause la création de la Virtual Machine jusqu'à ce que la database soit complètement provisionnée. Tu devrais traiter les dépendances explicites comme un dernier recours. Elles forcent Terraform à être plus conservateur dans son exécution, ce qui ralentit tes deploys. Elles peuvent aussi rendre ta configuration plus difficile à maintenir avec le temps, car la vraie raison de la dépendance n'est pas toujours évidente pour le prochain ingénieur qui lira le fichier. Laisser le graphe d'exécution faire le gros du travail, c'est ce qui sépare l'infrastructure déclarative des scripts procéduraux. Alors arrête d'essayer de micro-gérer l'ordre d'exécution et laisse le data flow dicter la séquence. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.

Salut, c'est Alex de DEV STORIES DOT EU. Les fondamentaux de Terraform, épisode 6 sur 13. Tu écris ton code d'infrastructure, tu lances un apply, et tes serveurs démarrent parfaitement. Mais si tu relances un apply cinq minutes plus tard, rien ne se passe. Terraform sait que le boulot est déjà fait. Contrairement aux simples scripts d'automatisation qui exécutent des commandes à l'aveugle, Terraform a une mémoire. Sans ça, il serait complètement aveugle face à l'infrastructure qu'il vient tout juste de construire. Cette mémoire, c'est ce qu'on appelle le Terraform State. Quand tu lances Terraform, il crée un fichier local qui s'appelle terraform point tfstate. Au début, beaucoup d'ingénieurs voient ce fichier comme une nuisance. Ça donne l'impression d'être un artefact supplémentaire à gérer et à sécuriser. Mais ce fichier est vraiment le cœur du fonctionnement de Terraform. Terraform a besoin d'un mécanisme pour mapper les ressources logiques définies dans tes fichiers de configuration avec les objets distants physiques qui vivent dans ton environnement cloud. Une idée reçue très courante, c'est que Terraform regarde juste les tags du cloud provider pour savoir ce qu'il gère. Tu pourrais penser qu'il ajoute un tag à un serveur pendant sa création, et que plus tard, il cherche ce tag spécifique dans le cloud pour savoir quoi mettre à jour. Cette approche s'effondre très vite. Toutes les ressources cloud ne supportent pas les tags. En plus, quelqu'un pourrait modifier ou supprimer un tag manuellement, ce qui casserait la connexion. Enfin, chercher des tags spécifiques dans un énorme compte cloud d'entreprise à chaque fois que tu lances un plan serait incroyablement lent. Comme les tags ne sont pas fiables, Terraform utilise un fichier de state dédié et hautement structuré. Le fichier de state agit comme une base de données de mapping privée. Quand tu déclares une ressource dans ton code, Terraform la crée via l'API du provider. Le provider renvoie un identifiant physique unique pour cet objet qui vient d'être créé. Terraform prend le nom logique de ta ressource dans le code, l'associe à cet ID cloud unique, et écrit la paire dans le fichier de state. Prenons un cas pratique. Tu décides de changer la taille d'une machine virtuelle Azure dans ton code. Quand tu lances un apply, Terraform ne devine pas quelle machine modifier. Il vérifie le fichier de state, cherche le nom logique de ta ressource, et récupère l'ID exact de l'instance Azure. Ensuite, il envoie une requête de mise à jour qui cible cet ID spécifique. Sans le fichier de state, Terraform ne saurait pas s'il doit mettre à jour une machine existante ou juste en créer un doublon. Au-delà du mapping, le state gère le suivi des métadonnées. Terraform doit connaître l'ordre exact dans lequel les ressources ont été créées pour pouvoir les mettre à jour ou les détruire en toute sécurité. Si un serveur web a besoin d'une base de données, cette dépendance est écrite dans ton code. Par contre, si tu supprimes tout ce bloc de code pour détruire l'environnement, Terraform ne peut plus lire le code pour trouver la dépendance. Le fichier de state garde une copie de cet historique de métadonnées, ce qui garantit que Terraform détruise le serveur web avant la base de données. Le state fournit aussi un système de cache crucial pour les performances. Interroger l'API d'un cloud provider pour récupérer le statut actuel de milliers de règles réseau, de buckets de stockage et de nœuds de calcul prend un temps fou. Les cloud providers imposent aussi des rate limits très stricts sur leurs API. Le fichier de state agit comme un cache pour les attributs de ton infrastructure. En consultant ce cache, Terraform minimise le nombre d'appels API lents et coûteux qui sont nécessaires pour calculer un plan. Voici le point clé. Ta configuration décrit ce que tu veux, le cloud provider détient ce qui existe réellement, et le fichier de state est le seul pont définitif qui connecte les deux. C'est tout pour aujourd'hui. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. Les fondamentaux de Terraform, épisode 7 sur 13. Coder des valeurs en dur, c'est très bien pour un test rapide, mais que se passe-t-il quand tu dois déployer exactement la même configuration dans un environnement de dev et en production ? Tu ne peux pas dupliquer et réécrire ton code pour chaque nouveau deploy. Le mécanisme qui résout ça, c'est la paramétrisation avec les Input Variables. Les Input Variables servent de paramètres pour un module Terraform. Elles te permettent de personnaliser des aspects de ton infrastructure sans modifier le code source sous-jacent. C'est exactement l'étape où ton code passe d'un proof of concept à un template production-ready. En utilisant des variables, tu écris la configuration une seule fois et tu la réutilises partout. Avant de rentrer dans la mécanique, on doit dissiper une confusion courante. Il y a une stricte différence entre déclarer une variable et lui assigner une valeur. Déclarer une variable indique simplement à Terraform qu'un paramètre existe et définit ses règles. Assigner une valeur, c'est le fait de lui donner concrètement des données pendant un deploy. Tu déclares une variable en utilisant un bloc variable suivi d'un nom unique. À l'intérieur de ce bloc, tu définis le data type attendu. Terraform supporte plusieurs types. Une string, c'est juste du texte normal. Une list est une séquence ordonnée de valeurs, comme plusieurs availability zones. Une map est une collection de paires clé-valeur, ce qui est parfait pour appliquer des tags de ressources standards. À l'intérieur du bloc variable, tu peux aussi définir une valeur par défaut. Si tu fournis une valeur par défaut, la variable devient optionnelle. Si l'utilisateur ne fournit pas de valeur pendant le deploy, Terraform utilise simplement la valeur par défaut. Si tu ne définis pas de valeur par défaut, Terraform forcera l'utilisateur à fournir une valeur avant de continuer. Ancrons ça dans un scénario pratique. Supposons que tu aies un deploy Azure. En ce moment, ta configuration demande explicitement une petite taille de machine virtuelle appelée Standard B2s, et elle code en dur un tag d'environnement à dev. Pour rendre ça réutilisable, tu remplaces ce texte codé en dur par une référence. Dans Terraform, tu références une Input Variable en tapant var point suivi du nom de la variable. Donc, au lieu d'écrire Standard B2s, tu écris var point vm size. Au lieu de dev, tu écris var point environment. Maintenant ton code est flexible, mais Terraform a toujours besoin de savoir quelles valeurs utiliser quand il s'exécute réellement. C'est là qu'interviennent les fichiers de définition de variables. Ce sont des fichiers qui se terminent par point tfvars. Un fichier tfvars est simplement une liste de noms de variables et de leurs valeurs correspondantes. Pour ton deploy en production, tu crées un fichier nommé prod point tfvars. Dedans, tu définis la variable environment sur prod, et la variable vm size sur une instance plus grande, comme Standard D4s. Quand tu lances Terraform, tu le pointes vers ce fichier. Terraform lit le fichier tfvars, injecte ces valeurs dans tes références var point, et provisionne l'environnement de production. Demain, tu pourras pointer exactement le même code Terraform vers un fichier dev point tfvars pour monter un petit environnement de test. Voici l'idée clé. Garder ta logique complètement séparée de tes données spécifiques à l'environnement, c'est ce qui rend l'infrastructure vraiment répétable. Si tu trouves ces épisodes utiles et que tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour celui-ci. Merci d'avoir écouté, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. Terraform Fundamentals, épisode 8 sur 13. Ton infrastructure cloud a fini de se déployer parfaitement, mais tu as toujours un problème majeur : tu dois connaître son adresse IP publique pour pouvoir t'y connecter. Fouiller dans les dashboards de ton cloud provider, ça casse tout l'intérêt de l'automatisation. Tu as besoin d'un moyen d'extraire cette donnée spécifique directement depuis Terraform. C'est là qu'intervient l'exposition des données avec les output values. Les output values sont en gros les return values d'une configuration Terraform. Quand tu définis et crées une ressource, le cloud provider génère certains attributs dynamiquement. Ce sont des choses que tu ne peux pas connaître avant le déploiement, comme une adresse IP assignée, un mot de passe de base de données généré, ou un nom de domaine spécifique. Tu utilises des blocs output pour capturer ces attributs générés dynamiquement et les exposer au monde extérieur. Pour en définir un, tu écris un bloc output suivi d'un label. Ce label est juste le nom que tu veux assigner à l'output. À l'intérieur du bloc, tu définis un seul argument requis appelé value. Cet argument pointe vers la donnée spécifique que tu veux extraire. Par exemple, si tu crées une machine virtuelle, tu pourrais configurer l'argument value pour qu'il pointe directement vers l'attribut d'IP publique de cette ressource machine spécifique. Prends un scénario concret. Tu as un pipeline automatisé qui déploie un nouveau cluster Azure Kubernetes Service. Quand le déploiement se termine, tes développeurs ont besoin du endpoint Kubernetes brut généré automatiquement pour configurer leurs outils de connexion locaux. Sans un output, quelqu'un devrait se connecter au portail cloud, trouver le cluster et copier l'URL manuellement. À la place, tu écris un bloc output nommé cluster endpoint. Tu configures sa value pour référencer l'attribut fully qualified domain name du cluster Kubernetes fraîchement construit. Quand Terraform a fini d'appliquer ta configuration, il rassemble toutes les output values définies et les affiche directement dans la command line interface. Ton pipeline d'automatisation peut alors lire ce texte et passer le endpoint directement aux développeurs. Tu peux aussi récupérer ces valeurs plus tard sans lancer un nouveau déploiement. Tu as juste à lancer la commande Terraform output dans ton terminal. Pour les scripts d'automatisation, tu peux même dire à cette commande de renvoyer les données en raw text ou au format JSON, ce qui les rend faciles à parser pour d'autres outils logiciels. Parfois, les données que tu dois passer en output sont confidentielles, comme un mot de passe de base de données ou une clé privée. Tu ne veux pas que ces strings défilent sur un écran de terminal partagé ou restent de façon permanente dans tes logs de continuous integration. Pour éviter ça, tu ajoutes l'argument sensitive à l'intérieur du bloc output et tu le mets sur true. Terraform va alors masquer la vraie value dans l'affichage de la console, en la remplaçant par un tag placeholder indiquant que la value est sensitive. Voici le point essentiel. Mettre un output sur sensitive le masque uniquement de l'affichage du terminal. Ça ne chiffre pas et ne masque pas les données à l'intérieur du state file de Terraform. Le mot de passe ou la clé est toujours stocké en plain text dans tes données de state sur le disque ou dans ton remote backend. Le flag sensitive est purement un filtre d'affichage pour la command line interface, pas un mécanisme de sécurité pour ton stockage. Les output values agissent au final comme ton API de configuration. C'est le moyen structuré et prévisible par lequel tu renvoies des informations critiques aux humains ou aux outils d'automatisation au moment où un run se termine. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. Les fondamentaux de Terraform, épisode 9 sur 13. Toute l'infrastructure de ton environnement cloud n'a pas été construite par le code Terraform que tu es en train d'écrire. Pourtant, ton code a quand même besoin d'un moyen de se connecter à ces systèmes existants en toute sécurité, sans les modifier par accident. Faire des requêtes avec des data sources, c'est exactement comme ça que tu gères le problème. Un gros point de confusion quand on apprend Terraform, c'est la différence entre un resource block et un data block. Mettons les choses au clair tout de suite. Un resource block dit à Terraform de créer, de mettre à jour et de posséder un objet d'infrastructure. Un data block fait seulement une recherche en read-only. Il demande à l'API du provider de trouver un objet existant et de renvoyer ses détails pour que ta configuration puisse les lire. Cette capacité read-only est la base d'une architecture d'infrastructure découplée. Prends l'exemple d'une configuration d'entreprise standard. Une équipe réseau centralisée construit et gère le Virtual Network de l'entreprise. En tant que développeur d'applications, tu dois deploy une Virtual Machine Azure et l'attacher à ce réseau précis. Tu ne possèdes pas le code du réseau. Tu ne devrais pas non plus hardcoder l'ID unique du réseau dans tes fichiers Terraform, parce que les IDs hardcodés cassent facilement si les environnements sont recréés. À la place, tu fais juste une recherche pour trouver le réseau. Tu fais ça en définissant un data block. La syntaxe ressemble beaucoup à celle d'un resource block. Tu commences avec le mot-clé data. Ensuite, tu spécifies le type de data source, comme azurerm virtual network. Puis tu lui donnes un nom local, comme corporate, que tu utiliseras pour le référencer plus tard dans ton code. À l'intérieur du bloc, tu définis les arguments de recherche. Ils agissent comme des filtres stricts. Tu pourrais passer le nom lisible par un humain du Virtual Network et le resource group auquel il appartient. Terraform utilise ces arguments pour construire une query. Quand tu lances un Terraform plan, Terraform contacte l'API Azure et cherche un Virtual Network qui correspond à tes filtres. Si l'API renvoie exactement une correspondance, Terraform télécharge les propriétés de ce réseau en mémoire. Si la query renvoie zéro correspondance, ou si les filtres sont trop larges et renvoient plusieurs correspondances, Terraform s'arrête immédiatement et lève une erreur. Cette rigueur est intentionnelle. Ça t'empêche de deploy ton application par accident dans le mauvais subnet ou environnement. Une fois que la data source a récupéré les informations avec succès, tu peux en extraire n'importe quel attribut exporté. La syntaxe pour référencer une data source est très structurée. Tu commences avec le mot data, suivi d'un point, du type de data source, d'un point, de ton nom local, et enfin de l'attribut spécifique dont tu as besoin. Dans notre scénario, tu taperais data point azurerm virtual network point corporate point id. Tu passes cette string spécifique directement dans le resource block de ta Virtual Machine, ce qui t'évite complètement d'avoir à hardcoder une valeur statique. Voici la partie qui compte. Les data sources te permettent de traiter l'infrastructure qui t'entoure comme un service dynamique. Tu n'as pas besoin de construire l'environnement pour interagir avec, et tu peux relier des workspaces indépendants en toute sécurité, simplement en faisant une query sur les identifiants exacts dont tu as besoin au runtime. Merci d'avoir écouté. J'espère que tu as appris quelque chose de nouveau.

Salut, c'est Alex de DEV STORIES DOT EU. Terraform Fundamentals, épisode 10 sur 13. Si tu as besoin de deploy cinquante serveurs web identiques, la dernière chose que tu as envie de faire, c'est de copier-coller le même block de code cinquante fois. Tu pourrais chercher une boucle while ou une boucle for classique, mais Terraform ne fonctionne pas comme ça. À la place, tu gères le scale au niveau du block en utilisant count et for each. Par défaut, un block resource configure exactement un seul objet d'infrastructure. Pour provisionner plusieurs objets, tu ajoutes le méta-argument count à l'intérieur de ce block. Il accepte un nombre entier. Si tu mets count à trois, Terraform provisionne trois objets à partir de ce seul block de configuration. Dans le monde réel, ces objets ne peuvent généralement pas être strictement identiques. Ils ont besoin de noms ou d'adresses IP uniques. Pour gérer ça, Terraform fournit l'objet count dot index. C'est une variable spéciale disponible uniquement dans les blocks qui ont un argument count. Disons que tu dois deploy trois Azure Virtual Machines. Tu écris un seul block resource pour la machine virtuelle et tu mets le count à trois. À l'intérieur du block, tu assignes le nom de la machine en combinant le mot web, un tiret, et la valeur de count dot index. Comme l'index commence à zéro, Terraform évalue ce block et génère trois machines distinctes nommées web-zero, web-one, et web-two. Ajouter count change la façon dont Terraform track la ressource en interne. Une ressource unique est adressée simplement par son type et le nom qu'on lui a donné. Une fois que tu ajoutes count, cette adresse devient un array. Tu peux maintenant référencer des instances spécifiques ailleurs dans ton code en utilisant leurs numéros d'index entre crochets. Count est très efficace, mais il présente un risque mécanique spécifique lié à l'ordre de la liste. Voici le point essentiel. Count identifie les ressources entièrement par leur position d'entier. Si tu utilises une liste de valeurs pour configurer un block avec count, la position de l'index est la seule chose qui intéresse Terraform. Si tu as trois éléments et que tu passes le count à deux, Terraform détruit le dernier élément de l'array, l'index deux. Si tu injectes une nouvelle string au milieu de ta liste source, toutes les positions d'index suivantes se décalent vers le bas. Terraform va remarquer que la configuration pour l'index un a changé, que l'index deux a changé, et ainsi de suite. Il va probablement détruire et recréer une infrastructure parfaitement fonctionnelle juste parce que l'ordre de la liste source a changé. Pour résoudre cette vulnérabilité, tu utilises plutôt le méta-argument for each. Alors que count prend un nombre entier, for each accepte une map ou un set de strings. Plutôt que de créer un array d'objets indexés par des nombres séquentiels, for each crée une map d'objets trackés par des clés de type string explicites. Si tu lui passes un set contenant les strings frontend et backend, Terraform crée des ressources adressées par ces noms exacts. Si tu ajoutes une nouvelle string plus tard, ou que tu en retires une, Terraform ajoute ou détruit uniquement cette ressource spécifique. Le reste est intact car leurs identifiants sont des clés de type string fixes, et non des positions numériques fragiles. Utilise count quand les objets d'infrastructure sont vraiment interchangeables, mais passe à for each dès l'instant où ces objets nécessitent des identités distinctes qui doivent survivre aux changements de ta liste de configuration. Merci d'avoir écouté. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. Terraform Fundamentals, épisode 11 sur 13. Ton seul fichier de configuration Terraform faisait l'affaire pour un simple serveur web, mais à mesure que ton infrastructure grandit, il devient vite un monolithe fouillis et illisible. Tu copies-colles sans arrêt les mêmes blocs resource juste pour changer une seule string de nom ou un tag d'environnement. Il est temps d'arrêter de te répéter en créant des composants réutilisables avec des modules. Un module est un conteneur pour plusieurs ressources qui sont utilisées ensemble. Si tu connais un langage de programmation, tu peux voir un module comme une fonction. Tu écris la logique complexe une seule fois, tu l'encapsules, et ensuite tu l'appelles plusieurs fois depuis d'autres endroits. Dans Terraform, chaque configuration a déjà au moins un module. Les fichiers qui se trouvent dans ton répertoire de travail principal forment ce qu'on appelle le root module. Quand ton root module référence un autre ensemble de fichiers de configuration, ce deuxième ensemble est appelé un child module. Prenons un scénario spécifique. Une équipe DevOps centralisée veut s'assurer que chaque compte de stockage créé dans l'entreprise est sécurisé par défaut, avec le chiffrement, des private endpoints et des logs de diagnostic strictement appliqués. Au lieu de faire confiance à chaque développeur d'application pour configurer correctement dix ressources complexes différentes, l'équipe DevOps crée un module standard Secure Azure Storage. Quand une équipe applicative a besoin de stockage, elle n'écrit pas un énorme bloc de définitions de ressources. Elle écrit juste un bloc module dans sa configuration root. À l'intérieur de ce bloc module, la toute première chose qu'elle définit, c'est un argument source. La source indique à Terraform exactement où trouver les fichiers du child module, que ce soit un chemin de répertoire local ou un repository distant. En dessous de la source, l'équipe applicative passe des arguments. Tout comme on passe des arguments à une fonction, elle fournit les données spécifiques dont le child module a besoin pour s'exécuter, comme un nom d'application unique ou un identifiant d'environnement. Ces arguments mappent directement aux variables d'input définies à l'intérieur du child module. Le child module prend ces inputs, exécute les configurations de ressources sous-jacentes, et construit l'infrastructure. L'équipe applicative obtient automatiquement un stockage conforme, complètement isolée de la complexité sous-jacente. Voici le point clé. Les gens sont souvent confus sur la façon dont Terraform gère le scope entre ces modules. Quand tu appelles un child module, les ressources à l'intérieur sont strictement encapsulées. Ton root module ne peut pas lire directement une adresse IP, une connection string ou un ID de stockage généré à l'intérieur de ce child module. Le child module est une boîte noire. Si ton root module a besoin d'une donnée qui a été générée à l'intérieur du child module, le child module doit l'exporter explicitement en utilisant un bloc output. Les variables agissent comme les paramètres d'input, et les outputs agissent comme les valeurs de retour. Ils forment une interface stricte. Une fois que le child module exporte cette donnée en tant qu'output, le root module peut enfin la lire. Tu accèdes à cette donnée en référençant le mot module, suivi du nom spécifique que tu as assigné à ton bloc module, puis du nom de l'output. Si le child module renvoie un ID de compte de stockage généré, ton root module peut le récupérer en utilisant cette syntaxe et le passer à une base de données ou une machine virtuelle qui a besoin de s'y connecter. La vraie puissance des modules, ce n'est pas juste d'économiser des lignes de code. C'est la capacité de définir un standard d'architecture une bonne fois pour toutes, de masquer la complexité, et de présenter une interface propre et prévisible au reste de ton organisation. Merci de m'avoir écouté. Prenez soin de vous, tout le monde.

Bonjour, ici Alex de DEV STORIES DOT EU. Les fondamentaux de Terraform, épisode 12 sur 13. Un state file local sur ton disque dur fonctionne parfaitement quand tu développes tout seul. Mais à la seconde où deux ingénieurs essaient de mettre à jour la même infrastructure en même temps, tu vas droit vers un environnement corrompu. C'est la limite entre l'expérimentation individuelle et la collaboration en équipe, et ça nous amène à l'enterprise readiness : le remote state et le locking. Par défaut, Terraform écrit sa vue actuelle de ton infrastructure dans un fichier local appelé terraform point tfstate. Ce fichier est la source de vérité critique qui mappe ton code de configuration aux ressources du monde réel. Le problème se pose quand tu ajoutes d'autres personnes à ton projet. Si ton collègue fait une modif depuis sa machine, ton ordi n'a aucune idée que l'environnement vient de changer. Tu travailles sur des infos obsolètes. Parfois, les équipes essaient de résoudre ça en commitant le state file dans leur système de version control. C'est un énorme risque de sécurité. Les state files stockent très souvent des données sensibles, comme des mots de passe de base de données ou des clés privées, en plain text. La bonne approche, c'est de configurer un remote backend. Au lieu de sauvegarder le state file sur une machine locale, Terraform lit et écrit ces données depuis un data store centralisé et sécurisé. C'est généralement un service d'object storage comme un bucket Amazon S3, un container Azure Blob Storage ou un bucket Google Cloud Storage. Quand tu utilises un remote backend, à chaque fois que quelqu'un lance une commande, Terraform requête ce stockage central pour récupérer la vision la plus précise et à jour de l'infrastructure. Passer à cette configuration nécessite d'ajouter un bloc de configuration backend à ton code, pour définir où le state doit vivre. Fais bien attention à cette partie. Une erreur très courante, c'est d'écrire cette configuration, de sauvegarder le fichier et de supposer que le state est maintenant remote. Ce n'est pas le cas. Après avoir ajouté le bloc backend, tu dois relancer terraform init. Lancer cette commande d'initialisation, c'est le trigger qui dit à Terraform de copier physiquement ton state file local existant et de le migrer vers le backend cloud. Déplacer le state file vers un emplacement partagé résout le problème de visibilité, mais ça t'expose aux modifications concurrentes. Si deux pipelines de déploiement déclenchent une mise à jour en même temps, ils pourraient tous les deux essayer d'écrire dans le remote state file en même temps, ce qui le corromprait complètement. C'est pour ça que les remote backends supportent le state locking. Prends l'exemple d'un environnement qui utilise Azure Blob Storage pour son remote state. Deux ingénieurs travaillent sur des mises à jour différentes. L'ingénieur A lance un apply. Avant de faire la moindre modification sur les ressources cloud réelles, Terraform contacte le container de stockage Azure et place un lock sur le remote state file. Une fraction de seconde plus tard, l'ingénieur B essaie de lancer son propre apply. Terraform vérifie le remote backend, détecte le lock actif, et intercepte immédiatement le run de l'ingénieur B. Au lieu de créer une collision, Terraform s'arrête proprement et renvoie une erreur, en expliquant qu'un autre process détient actuellement le lock. Une fois que le premier run se termine avec succès, Terraform relâche automatiquement le lock. Implémenter un remote backend avec du locking est l'étape décisive pour faire de l'infrastructure as code en entreprise. Ça sécurise tes données sensibles et élimine les race conditions dangereuses. Le remote state garantit que, peu importe qui lance le code, ou d'où, toute ton équipe est fermement ancrée dans la même réalité. Merci de ton écoute, bon code à tous !

Salut, c'est Alex de DEV STORIES DOT EU. Les fondamentaux de Terraform, épisode 13 sur 13. Tu as écrit ta configuration, tu l'as testée en local et tu as déployé tes ressources. Mais exécuter des changements d'infrastructure depuis le laptop d'un développeur, c'est un goulot d'étranglement, pas une stratégie. Les apply manuels entraînent des conflits de state, des changements non revus et des risques de sécurité. La vraie automatisation s'exécute de manière sécurisée dans un pipeline, déclenché automatiquement par le version control. Ça nous amène aux workflows d'entreprise et à la CI/CD. Quand tu passes d'un travail en solo à une équipe, le workflow principal Write, Plan et Apply quitte complètement ta machine locale. Le version control devient la source de vérité absolue. Tu arrêtes de lancer des commandes directement, et tu commences à laisser les pipelines de continuous integration orchestrer les changements de state. Voici l'idée clé. Le pipeline divise la phase de plan traditionnelle en deux concepts distincts : les speculative plans et les concrete plans. Comprendre la différence est crucial pour le design du pipeline. Prends l'exemple d'un développeur qui a besoin d'augmenter la taille d'une machine virtuelle Azure. Il met à jour la taille de l'instance dans la configuration, il commit le code et il ouvre une Pull Request. À ce moment précis, le pipeline déclenche automatiquement un speculative plan. Un speculative plan montre simplement ce que Terraform a l'intention de faire. Il vérifie le code proposé par rapport au remote state pour calculer le delta, mais il est strictement en read-only. Il ne peut en aucun cas être apply. Le pipeline prend l'output de ce speculative plan et le poste directement comme commentaire texte sur la Pull Request. Quand un ingénieur senior review le code, il ne voit pas juste le changement de syntaxe. Il voit l'impact exact sur l'infrastructure. Il sait précisément quelles ressources Azure seront modifiées, créées ou détruites avant de donner son approval. Une fois que la Pull Request est approuvée et mergée dans la main branch, le pipeline déclenche la deuxième phase. Il génère un concrete plan pour cette main branch. C'est un fichier de plan exécutable. Comme la main branch est la source de vérité de confiance, le pipeline prend ce concrete plan et l'apply immédiatement. L'infrastructure live est mise à jour automatiquement par le robot, pas par l'humain. Faire tourner Terraform en automatisation ouvre la porte à des contrôles d'entreprise avancés. Le policy-as-code, en utilisant des frameworks comme Sentinel, s'intègre directement dans ce pipeline. Sentinel évalue le plan avant même que le apply n'ait lieu. Si un développeur demande accidentellement une instance de base de données qui viole les restrictions de coûts ou les règles de compliance, le policy engine le signale et stoppe le pipeline immédiatement. Ce workflow automatisé est ce qui permet un modèle d'infrastructure en self-service. Les platform engineers construisent et testent des modules réutilisables, pendant que les développeurs d'applications soumettent simplement une Pull Request pour demander les ressources dont ils ont besoin. Le pipeline planifie le changement, le policy-as-code vérifie la compliance, et un collègue review l'intention. L'équipe applicative obtient son infrastructure rapidement, et la platform team applique la sécurité sans agir comme un point de blocage manuel. Ça conclut notre série sur les fondamentaux. Tu sais maintenant comment Terraform scale d'une simple commande locale à un moteur d'entreprise automatisé. La meilleure façon de consolider ces connaissances, c'est de construire quelque chose, de lire la documentation officielle, et d'expérimenter avec ces pipelines toi-même. Si tu as des idées pour de futurs sujets, visite devstories dot eu. J'aimerais prendre un moment pour te remercier de ton écoute — ça nous aide beaucoup. Passe une bonne journée !