Pulumi: Infrastructure as Code

Bonjour, ici Alex de DEV STORIES DOT EU. Pulumi : Infrastructure as Code, épisode 1 sur 10. Et si tu pouvais écrire ton infrastructure cloud avec le même langage de programmation que celui utilisé pour ton application ? Fini les allers-retours incessants entre la logique de ton application et des milliers de lignes de custom markup. L'épisode The Developer's Infrastructure: Why Pulumi? aborde précisément ce changement. Historiquement, l’Infrastructure as Code impliquait d’écrire des domain-specific languages ou d’innombrables blocs de YAML. Si tu voulais faire un deploy d'une base de données et d'un serveur, tu apprenais une syntaxe exclusive à cet outil de provisioning spécifique. Tu perdais ainsi tout le riche écosystème du software engineering standard. Tu ne pouvais pas facilement écrire une boucle, intégrer des testing frameworks standards ou partager de la logique via des package registries standards. Pulumi change cette fondation. C’est une plateforme d’Infrastructure as Code qui te permet de build, deploy et manage des ressources cloud à l’aide de langages de programmation généralistes. Au lieu d’apprendre un langage de configuration sur mesure, tu utilises TypeScript, Python, Go, C# ou Java. Imagine un développeur qui définit des ressources cloud avec TypeScript. Avec les outils traditionnels, tu changes constamment de contexte pour consulter des schémas YAML dans un navigateur web. Avec Pulumi, tu restes dans ton éditeur. Tu instancies une classe de ressource, tu tapes un point, et l'auto-completion standard de l'IDE te montre exactement quelles propriétés sont disponibles. Tu obtiens un inline type-checking avant même de lancer un deployment. Si tu as besoin de trois storage buckets identiques, tu écris une for-loop standard. Si ton entreprise applique des règles de sécurité spécifiques sur chaque serveur, tu abstrais cette logique dans une fonction standard, tu la publies sur un package registry standard, et tu laisses les autres équipes l'importer comme n'importe quelle code library classique. Voici l'idée clé. Comme tu écris cette infrastructure dans des langages impératifs, tu pourrais penser que Pulumi n'est qu'un script d'automatisation qui appelle des cloud APIs séquentiellement. Ce n'est pas un script d'exécution impératif. Pulumi utilise toujours un declarative state model très robuste en arrière-plan. Quand tu exécutes ton programme Pulumi, il ne va pas immédiatement provision les ressources ligne par ligne. Au lieu de cela, ton code s'exécute pour construire l'état final souhaité de ton infrastructure. Le moteur Pulumi capture ces définitions de ressources et construit un dependency graph strict. Il compare ensuite cet état souhaité à l'état actuel de ton environnement cloud. Pulumi calcule la différence exacte et effectue uniquement les opérations de create, update ou delete spécifiques nécessaires pour que la réalité corresponde à ton code. Tu écris avec la fluidité expressive d'un langage impératif, mais tu obtiens la sécurité et la prévisibilité d'un declarative deployment engine. En adoptant des langages généralistes, tu débloques l'accès aux linters, aux unit testing frameworks et aux continuous integration pipelines existants. Pulumi arrête simplement de traiter l'infrastructure comme un domaine de configuration distinct et la transforme en un logiciel standard, régi par la même rigueur et le même tooling que ton application principale. Si tu souhaites aider à soutenir l'émission, tu peux nous trouver en cherchant DevStoriesEU sur Patreon. Je voudrais prendre un moment pour te remercier pour ton écoute — ça nous aide beaucoup. Passe une excellente journée !

Bonjour, ici Alex de DEV STORIES DOT EU. Pulumi : Infrastructure as Code, épisode 2 sur 10. Tu instancies une classe Python standard dans ton éditeur, tu lances un deploy, et quelques secondes plus tard, un bucket de stockage existe dans le cloud. Comment exactement un objet local en mémoire se traduit-il en une ressource physique distante ? Aujourd'hui, on va répondre à cette question en regardant sous le capot : l'architecture de Pulumi. Il y a une idée reçue très courante sur le fonctionnement de cet outil. Quand tu écris un script de déploiement, ton code ne communique pas avec les API cloud. L'environnement qui exécute ton code Python, Node ou Go n'a absolument aucune idée de comment parler à Amazon Web Services. En fait, Pulumi divise le processus de déploiement entre trois composants distincts : le Language Host, le Deployment Engine, et les Resource Providers. Tout commence avec le Language Host. Ce composant évalue ton programme et en extrait ton intention. Prends l'exemple d'un script Python où tu déclares un bucket AWS S3 en initialisant un objet bucket. Le Language Host Python exécute ton script ligne par ligne. Quand il arrive sur cette déclaration de bucket, il ne fait aucune requête réseau vers AWS. Il envoie simplement une requête d'enregistrement au Deployment Engine. Il dit au moteur que tu veux qu'un bucket avec des propriétés spécifiques existe. Le Language Host communique ce state désiré via une connexion locale, puis se met en pause, en attendant une réponse avant d'évaluer la ligne de code suivante. Le Deployment Engine reçoit cette requête d'enregistrement. Ce composant, c'est l'orchestrateur. Le moteur ne connaît rien à la syntaxe Python, et il ne connaît rien à l'API AWS. Son seul boulot, c'est la gestion du state. Il regarde le state désiré envoyé par le Language Host et le compare au dernier state réel connu de ton infrastructure. Si le moteur voit que ce bucket S3 précis n'existe pas dans le state actuel, il calcule un diff et détermine qu'une opération de création est requise. Pour vraiment construire le bucket, le moteur confie la tâche au troisième composant, le Resource Provider. Les Providers sont des plugins autonomes téléchargés pour des plateformes spécifiques, comme AWS, Azure ou Kubernetes. Le Deployment Engine envoie une instruction au Resource Provider AWS, pour lui dire de créer le bucket avec les propriétés demandées. Voici le point clé. Le Resource Provider est le seul composant de toute cette chaîne qui sait comment parler au cloud. Il prend la commande de création générique du moteur, la traduit en appels d'API REST spécifiques requis par AWS, et les exécute sur le réseau. Une fois qu'AWS provisionne le bucket S3, il renvoie un ID de ressource physique. Le Resource Provider récupère cet ID physique et le renvoie au Deployment Engine. Le moteur met à jour son state interne pour enregistrer que le bucket existe maintenant dans le monde réel. Enfin, le moteur signale en retour au Language Host que la ressource est prête, en lui passant toutes les propriétés d'output comme le nom ou l'URL du bucket. Le Language Host reprend l'exécution, et ton script Python passe à l'instruction suivante. Cette séparation stricte entre l'évaluation du langage, l'orchestration du state et l'exécution cloud est ce qui donne à l'architecture sa flexibilité. Tu peux ajouter un nouveau langage de programmation sans toucher aux cloud providers, et ajouter un nouveau cloud provider sans modifier les Language Hosts. C'est tout pour cet épisode. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. Pulumi : Infrastructure as Code, épisode 3 sur 10. Configurer un projet d'infrastructure cloud, ça voulait dire passer des heures à te battre avec des fichiers boilerplate et des structures de dossiers avant même de pouvoir écrire une seule ligne de logique. Aujourd'hui, tu peux scaffold un environnement complet en quelques secondes. On se concentre sur Hello Azure : Créer ton premier projet, pour voir exactement comment ça se passe. Une erreur courante, c'est de croire que lancer la commande de création de projet va immédiatement build l'infrastructure dans le cloud. Ce n'est pas le cas. La commande dont on parle génère uniquement des fichiers locaux et prépare le tracking de ton state. Aucune vraie ressource Azure n'est créée tant que tu n'exécutes pas explicitement une commande de deploy plus tard. Pour bootstrap un nouveau projet, tu utilises la CLI. D'abord, tu crées un répertoire vide et tu vas dedans. Ensuite, tu lances la commande pulumi new suivie d'un nom de template. Pour Azure, ce template c'est généralement azure dash et ton langage de programmation préféré, comme azure dash typescript ou azure dash python. Quand tu exécutes ça, l'interface devient interactive. Elle te guide à travers une série de prompts pour configurer ton environnement. D'abord, elle te demande un nom de projet, qui par défaut est le nom de ton répertoire. Ensuite, elle te demande une description pour le projet. Puis elle te demande un nom de stack. Une stack, c'est une instance isolée de ton projet, qui représente généralement un environnement comme le développement ou la production. La stack par défaut s'appelle dev. Enfin, les templates Azure te font un prompt pour choisir une location Azure, comme WestUS, qui sera sauvegardée comme ta région de deploy par défaut. Une fois que tu as répondu aux prompts, l'outil télécharge le template, installe les dépendances de langage nécessaires, et crée quelques fichiers dans ton répertoire. Voici le point essentiel. Le fichier généré le plus important, c'est Pulumi dot yaml. C'est le fichier principal de ton projet. Il définit le nom du projet, le runtime qu'il utilise, et la description. En gros, il dit au système comment exécuter ton code. Tu verras aussi un fichier nommé Pulumi dot dev dot yaml si tu as accepté le nom de stack par défaut. Ce fichier secondaire stocke les valeurs de configuration spécifiques à cette stack, y compris la région Azure que tu viens de sélectionner. À côté de ça, tu as tes fichiers de dépendances standards, qui varient selon le langage que tu as choisi, et ton fichier d'entrypoint. À l'intérieur du fichier d'entrypoint, le template Azure par défaut te donne un exemple fonctionnel d'un Azure Storage Account. La logique du code se déroule en trois étapes claires. Premièrement, il importe le package Azure Native. Deuxièmement, il déclare un nouveau Azure Resource Group, en lui donnant un nom logique pour que le fichier de state puisse le tracker. Troisièmement, il déclare un Azure Storage Account. C'est là que ça devient intéressant. Au lieu de hardcoder le nom du resource group, le storage account prend la propriété name directement depuis l'objet resource group créé à l'étape précédente. Ça crée une dépendance implicite. Le système sait maintenant qu'il doit terminer de créer le resource group avant d'essayer de créer le storage account. Le template remplit aussi automatiquement les arguments requis pour le storage account, comme le account replication type et le account tier. Tout à la fin du fichier, le code exporte une valeur. Dans cet exemple scaffoldé, il exporte la primary storage key du storage account qui vient d'être défini. Quand tu vas finalement deploy, cette valeur exportée sera affichée directement dans ta console, ce qui rend super facile la récupération des connection strings ou des endpoints sans avoir à te connecter au portail Azure. Tu passes d'un dossier vide à un programme d'infrastructure entièrement câblé simplement en répondant à quelques prompts, ce qui te donne une base solide et avec la bonne syntaxe pour commencer à build ta propre architecture. Merci d'avoir écouté, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. Pulumi : Infrastructure as Code, épisode 4 sur 10. Ton script de deploy tourne parfaitement sur ton laptop. Tu push ton code, ta pipeline automatisée se déclenche, et le build fail immédiatement parce qu'il ne trouve pas un fichier source. Rien n'a changé dans le code, mais le répertoire où la commande a été exécutée a légèrement bougé. C'est un piège classique avec les paths, et pour l'éviter, tu dois comprendre les Projets et les Paths : Structurer ton code. À la base, un projet Pulumi, c'est juste un dossier qui contient un fichier nommé Pulumi.yaml. Ce fichier, c'est le point d'ancrage. Il indique à la CLI que ce répertoire spécifique contient ta logique d'infrastructure. Dans le fichier Pulumi.yaml, tu déclares des métadonnées comme le nom du projet, une description, et le langage du runtime. La propriété runtime, c'est ce qui décide comment ton code s'exécute vraiment. Si tu spécifies Python, le runtime cherche un fichier Python main dans ce répertoire. Si tu spécifies Node, il cherche l'entrypoint défini dans ton fichier package, qui est généralement un fichier index. Si tu préfères garder ton code source dans un sous-dossier plutôt que dans le répertoire principal du projet, tu peux explicitement overrider ce comportement en configurant la propriété main dans ton fichier Pulumi.yaml pour pointer vers ce sous-dossier spécifique. Maintenant, regardons la confusion classique autour des paths de fichiers. Imaginons que tu buildes une image de container Docker pour ton infrastructure, et que ton Dockerfile se trouve dans un sous-répertoire appelé app, situé juste à côté de ton code Pulumi. Les devs passent souvent un path absolu depuis leur machine locale pour dire à Pulumi où se trouve le Dockerfile. Mais un path absolu inclut ton répertoire utilisateur personnel. Quand un collègue pull le code et lance un update, le moteur voit un path absolu différent sur sa machine. Il enregistre ça comme un changement structurel de la ressource, ce qui crée un drift inutile dans le state de ton infrastructure. Pour corriger ça, tu pourrais passer à un path relatif standard, comme point slash app. Les paths relatifs standards dépendent entièrement du current working directory du terminal qui exécute le code. Si ton système de CI lance la commande depuis un dossier plus haut dans le repository, le path relatif se résout mal, et le deploy crash. Voici le point clé. Tu as besoin de paths qui sont complètement indépendants de la machine sur laquelle ils tournent, et indépendants de l'endroit où l'utilisateur a tapé la commande d'exécution. Il te faut des paths relatifs au projet. Pulumi fournit une fonction built-in pour récupérer l'emplacement exact du fichier Pulumi.yaml pendant l'exécution. Selon ton langage de programmation, cette fonction s'appelle généralement get root directory ou quelque chose de similaire. Quand tu appelles cette fonction, le runtime renvoie le path absolu vers le dossier qui contient ton fichier Pulumi.yaml. Au lieu de hardcoder un path vers ton Dockerfile, tu construis le path dynamiquement. Tu prends le résultat de la fonction root directory et tu y ajoutes ton sous-répertoire app. Parce que cette fonction s'évalue dynamiquement à chaque exécution, le path qui en résulte est toujours parfaitement adapté à l'environnement qui exécute le code. Ta machine locale, le laptop de ton collègue et le serveur de build distant généreront tous le bon path absolu pour leurs systèmes de fichiers spécifiques. Le path du fichier se résout de manière cohérente à chaque fois, et le moteur détecte zéro changement dans la définition de la ressource. Ton code d'infrastructure ne devrait jamais se soucier de l'endroit où il vit sur un disque dur. Ancre toujours tes assets de fichiers à la fonction root directory de Pulumi, pour t'assurer que ton projet reste complètement portable dans n'importe quel environnement. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de builder !

Salut, ici Alex de DEV STORIES DOT EU. Pulumi : Infrastructure as Code, épisode 5 sur 10. Copier-coller ton code d'infrastructure pour créer un environnement de staging est la recette parfaite pour le drift et le désastre. Tu finis par maintenir plusieurs dossiers de fichiers quasi identiques, et tôt ou tard, quelqu'un oublie de mettre à jour la prod. La solution, c'est de traiter tes environnements comme des instances isolées d'une seule codebase grâce aux Stacks. Avant d'aller plus loin, clarifions un truc qui prête souvent à confusion. Un Project dans Pulumi, c'est simplement un répertoire qui contient ton code source. Ce sont juste les instructions. Une Stack, c'est une instance de déploiement active de ce code. Tu écris le Project une seule fois, et tu le déploies plusieurs fois sous forme de différentes Stacks. Les Stacks te permettent de gérer différents environnements, comme le dev, le staging et la prod, sans dupliquer le moindre code. Quand tu lances un update Pulumi, il applique le code de ton Project à la Stack qui est actuellement active. Chaque Stack maintient son propre state file isolé, en trackant uniquement les ressources créées pour cet environnement spécifique. La gestion de ces environnements se fait directement dans ton terminal. Tu crées un nouvel environnement en lançant la commande stack initialize, en lui donnant un nom comme dev ou prod. Pulumi enregistre cette nouvelle instance et crée un nouveau state pour elle. Pour changer de contexte, tu utilises la commande stack select. La CLI Pulumi se souvient de la Stack qui est active. Si tu sélectionnes la Stack dev et que tu lances un update, Pulumi regarde uniquement le state de dev. Il provisionne ou modifie l'infrastructure de dev, en laissant tes environnements de staging et de prod complètement intacts. Voilà pour le déploiement d'environnements isolés. Mais que se passe-t-il quand ces environnements ont besoin de communiquer ? Parfois, une Stack dépend d'informations générées par une autre. Tu peux avoir un Project qui gère l'infrastructure core et un Project totalement séparé qui gère le code applicatif. Disons que tu as un Project d'infrastructure qui provisionne un cluster Kubernetes. Tu le déploies sous forme de Stack appelée base-infra-prod. Pendant le déploiement, le cluster génère une connection string dynamique. Maintenant, tu as un deuxième Project pour un microservice qui doit se déployer dans ce cluster exact. Tu ne veux pas hardcoder la connection string, et tu ne veux pas non plus fusionner les deux Projects dans un seul state file massif et lent. C'est là que ça devient intéressant. Tu peux relier ces déploiements de manière sécurisée en utilisant une Stack Reference. Une Stack Reference permet à une Stack de lire les outputs exportés d'une autre Stack. Pour mettre ça en place, ton programme de cluster Kubernetes doit explicitement exporter la connection string à la fin de son run. Un export, c'est juste une variable que Pulumi sauvegarde dans le state de la Stack spécifiquement pour qu'elle puisse être lue de l'extérieur. Ensuite, du côté de ton programme de microservice, tu crées un objet Stack Reference. Tu lui passes le nom de la Stack d'infrastructure que tu veux lire. Ensuite, tu appelles une méthode get output sur cette référence, en demandant la connection string par son nom exporté. Ton microservice peut maintenant utiliser cette valeur pour configurer son déploiement. La Stack du microservice ne peut pas modifier la Stack du cluster. Elle peut uniquement lire les valeurs spécifiques que la Stack du cluster a choisi d'exporter. Ça impose une frontière bien nette. Tu peux mettre à jour et scaler ton infrastructure réseau core de manière totalement indépendante de tes workloads applicatifs, tout en passant les détails de connexion nécessaires en toute sécurité. En découplant ton code de l'instance d'environnement, tu garantis que chaque couche de ton système passe par exactement la même logique, ce qui élimine les risques cachés de la duplication manuelle. C'est tout pour cet épisode. Merci pour ton écoute, et continue à builder !

Bonjour, ici Alex de DEV STORIES DOT EU. Pulumi : Infrastructure as Code, épisode 6 sur 10. Tu déploies ton code d'infrastructure, la syntaxe est impeccable, et ça plante immédiatement parce qu'un nom de storage bucket est déjà pris. Ou pire, tu mets à jour une instance de base de données, et ton outil supprime l'ancienne avant de créer la nouvelle, provoquant un hard outage. Tu peux résoudre ces deux problèmes en comprenant comment ton outil d'infrastructure gère l'identité. C'est exactement ce qu'on va voir aujourd'hui : Les briques de base : les ressources Pulumi. Dans Pulumi, une ressource est un objet qui représente un élément d'infrastructure. Il y a deux types principaux avec lesquels tu vas travailler. Le premier, c'est une Custom Resource. Elle correspond directement à un objet physique géré par un cloud provider. Quand tu déclares une Custom Resource, Pulumi fait un API call vers Amazon, Azure ou Google Cloud pour créer cet objet précis, comme une virtual machine ou un load balancer. Le deuxième type, c'est une Component Resource. Une Component Resource ne correspond pas à un seul élément d'infrastructure cloud. C'est plutôt un conteneur logique pour d'autres ressources. Tu utilises les Component Resources pour construire des abstractions de plus haut niveau. Par exemple, tu pourrais créer une seule Component Resource appelée Secure Web Server qui provisionne en interne une virtual machine, un security group et une adresse IP. La Component Resource elle-même les regroupe simplement dans ton state file, ce qui rend ton code plus propre et plus facile à gérer. Que tu définisses une Custom Resource ou une Component Resource, chacune d'entre elles a besoin d'un nom. Ça amène une source fréquente de frustration. Les gens tapent un nom dans leur code, le déploient, puis vérifient leur cloud console pour découvrir que leur ressource a une string de caractères aléatoires attachée à la fin de son nom. Ce n'est pas un bug. C'est une feature centrale de la façon dont Pulumi fonctionne, et tu dois comprendre la différence entre un nom logique et un nom physique. Le nom logique, c'est le nom que tu tapes dans ton code comme argument. Pulumi utilise ce nom logique pour suivre la ressource dans son state file. C'est comme ça que Pulumi sait que la base de données dans ton code aujourd'hui est exactement la même base de données que tu as déployée hier. Le nom physique, c'est le nom que le cloud provider donne réellement à la ressource dans son propre système. Par défaut, Pulumi prend ton nom logique, ajoute un suffixe aléatoire, et utilise cette string combinée comme nom physique. C'est ce qu'on appelle l'auto-naming. Voici le point clé. L'auto-naming évite les collisions de noms globales et permet des remplacements zero-downtime. Imagine provisionner plusieurs storage buckets identiques dans une loop en utilisant Azure. Azure exige que les noms de storage accounts soient globalement uniques parmi tous les clients. Si tu essaies de forcer un nom physique strict, le deuxième bucket de ta loop va planter parce que le nom est pris, ou pire, quelqu'un d'autre dans le monde pourrait déjà le posséder. Avec l'auto-naming, tu peux juste utiliser un nom logique comme archive-bucket dans ta loop. Pulumi va suivre chaque itération logiquement tout en s'assurant que chaque bucket obtienne un nom physique mathématiquement unique dans Azure. L'auto-naming protège aussi l'uptime de ton système. Si tu fais un changement qui force une ressource à être remplacée, Pulumi crée d'abord la nouvelle ressource, vérifie qu'elle fonctionne, et seulement après supprime l'ancienne. Si tu overrides l'auto-naming et que tu forces un nom physique strict, le cloud provider ne laissera pas deux ressources partager le même nom en même temps. Pulumi serait forcé de supprimer ton ancienne ressource en premier, causant du downtime pendant que la nouvelle se provisionne. Si tu veux aider à faire vivre l'émission, tu peux chercher DevStoriesEU sur Patreon. Garde tes noms physiques flexibles. Laisse l'outil gérer les suffixes aléatoires, parce que même si ton state file a besoin d'un nom logique pour maintenir l'ordre, ton environnement de production repose sur la flexibilité physique pour rester en ligne. Merci d'avoir écouté. Prenez soin de vous, tout le monde.

Bonjour, ici Alex de DEV STORIES DOT EU. Pulumi : Infrastructure as Code, épisode 7 sur 10. Hardcoder un mot de passe de base de données dans ton code d'infrastructure est une faille de sécurité garantie. Mais injecter manuellement des variables d'environnement dans chaque pipeline de deploy est fragile et difficile à tracker. Tu as besoin d'un moyen d'associer automatiquement des valeurs chiffrées à des environnements spécifiques. Voici Keeping Secrets : Configuration Management. L'idée principale ici, c'est de séparer ton code de ta configuration. Tu veux écrire ta logique d'infrastructure exactement une fois. Ensuite, quand tu fais un deploy sur ta stack de dev, le code provisionne de petites instances. Quand tu fais un deploy en prod, il provisionne de grandes instances et utilise les credentials de la base de données de prod. Pulumi gère ça grâce à un système de configuration intégré. Un point de confusion fréquent, c'est la façon dont ces valeurs sont réellement stockées. Définir une valeur de configuration Pulumi ne définit pas de variables d'environnement sur le système d'exploitation local. À la place, ça stocke les valeurs directement dans un fichier nommé Pulumi point stack-name point yaml. Comme chaque stack a son propre fichier de configuration distinct, ta configuration de dev et ta configuration de prod vivent côte à côte dans ton repository, proprement séparées par le nom du fichier. Tu ajoutes des données à ce fichier en utilisant l'interface en ligne de commande Pulumi. Si tu lances la commande pulumi config set frontendPort 8080, Pulumi écrit cette paire clé-valeur directement dans le fichier yaml de ta stack active. Pour utiliser cette valeur dans ton code d'infrastructure, tu instancies un objet Config. Ensuite, tu appelles une méthode comme get ou require sur cet objet, en passant le nom de la clé. La différence est simple. Appeler get retourne la valeur si elle existe, ou rien si ce n'est pas le cas. Appeler require va throw une erreur et stopper ton deploy si la clé de configuration est manquante. C'est un super moyen de s'assurer qu'un deploy ne continue jamais sans un paramètre obligatoire. Tu n'es pas limité à de simples strings. Tu peux stocker et récupérer des données structurées, comme un bloc JSON qui définit des paramètres de scaling, et le parser directement dans un objet dans ton code. Maintenant, que se passe-t-il quand cette valeur de configuration est très sensible ? Supposons que ton application doive se connecter à une base de données externe, et que tu doives passer le mot de passe de la base de données à ton infrastructure. Tu ne peux absolument pas stocker ça en plaintext dans ton fichier yaml, parce que ce fichier est commité dans le version control. C'est là que les secrets Pulumi entrent en jeu. Tu utilises exactement la même interface en ligne de commande, mais tu ajoutes un flag secret. Tu lances pulumi config set dbPassword ton-mot-de-passe tiret tiret secret. Pulumi chiffre la valeur avant de la sauvegarder dans le fichier yaml. Si quelqu'un regarde le fichier dans ton repository, il verra seulement une string ciphertext chiffrée de manière sécurisée par le provider de chiffrement de ta stack. Dans ton code, tu récupères ça de manière sécurisée en appelant une méthode secrète spécifique sur ton objet Config, comme requireSecret. Voici le point clé. Quand tu récupères un secret de cette façon, Pulumi le wrap dans un type secret spécial. À mesure que cette valeur circule dans ton code d'infrastructure et est passée aux ressources, le moteur Pulumi la track. Il s'assure que la valeur en plaintext est masquée dans la sortie de ta console pendant un deploy, et il garantit que la valeur reste chiffrée à l'intérieur de ton state file Pulumi. La configuration te permet d'écrire ton code d'infrastructure une seule fois et de le promouvoir en toute sécurité à travers tes environnements. Le chiffrement natif des secrets garantit que tes credentials sensibles pilotent ces deploys sans jamais fuiter dans ton version control ou tes state files. Merci d'avoir passé quelques minutes avec moi. À la prochaine, à plus.

Salut, c'est Alex de DEV STORIES DOT EU. Pulumi : Infrastructure as Code, épisode 8 sur 10. Tu copies-colles un bloc de code de stockage et de réseau pour la cinquième fois cette semaine. Ton code d'infrastructure grossit, mais il ne devient pas plus intelligent. Au lieu de répéter des configurations cloud identiques à chaque fois que tu as besoin d'un setup standard, tu peux les générer avec une seule unité logique. C'est le sujet de cet épisode : Scaling Up : les Component Resources sur Azure. Quand tu commences à utiliser Pulumi, tu déclares des ressources brutes. Un resource group par-ci, un storage account par-là. Mais à mesure que ton système grandit, déployer un morceau d'architecture standard nécessite de provisionner exactement le même ensemble de primitives encore et encore. Ça viole la règle de ne pas se répéter. Les Component Resources résolvent ça en te permettant d'encapsuler plusieurs ressources cloud physiques dans une seule abstraction réutilisable. Vois un Component Resource comme une classe custom que tu définis dans le langage de programmation de ton choix. Une fois définie, tu l'instancies exactement comme une ressource Pulumi native. Prends un scénario où tu déploies fréquemment des sites web statiques sur Azure. Un setup minimal nécessite un resource group Azure, un storage account configuré pour l'hébergement de site web statique, et un objet blob qui sert de document d'index. Au lieu d'écrire ces trois définitions dans ton programme principal à chaque fois, tu crées un composant Azure static website. Pour construire ça, tu définis une nouvelle classe qui hérite de la classe de base ComponentResource de Pulumi. Le constructeur de ta classe prend un nom, un ensemble d'arguments pour la customisation, et des resource options standards. La toute première chose que fait ton constructeur, c'est d'appeler le constructeur de la classe de base. Tu lui fournis un type token unique, comme custom deux-points infrastructure deux-points static website, avec le nom. Ce type token indique au moteur comment tracker ta nouvelle abstraction dans le state file. Ensuite, tu définis les primitives Azure directement dans ton constructeur. Tu déclares le resource group. Tu déclares le storage account à l'intérieur de ce groupe. Tu uploades le blob d'index sur ce compte. Voici le point clé. Quand tu crées ces ressources internes, tu dois dire explicitement au moteur qu'elles appartiennent à ton nouveau composant. Tu fais ça en passant l'instance du composant elle-même dans les resource options, sous la propriété parent. Beaucoup d'ingénieurs oublient cette étape. Si tu omets l'option parent, les ressources enfants vont se provisionner avec succès, mais elles seront traitées comme des ressources top-level. L'output de ta ligne de commande sera une liste plate et confuse. En définissant la propriété parent sur ton instance de composant, le moteur organise le state tree. Quand tu lances un update, l'interface imbrique visuellement le resource group, le storage account et le blob directement sous ton composant website custom. Ça permet de garder ton state gérable et ton output lisible. Enfin, ton programme principal a probablement besoin de connaître l'adresse web du site qui vient d'être créé. À l'intérieur de ton composant, après avoir défini le storage account, tu mappes son web endpoint principal vers une propriété publique de ta classe. Ensuite, tu appelles une méthode nommée register outputs. Ça finalise l'initialisation et ça garantit que l'adresse finale est exposée au reste de ton programme et affichée dans la console quand le deploy se termine. Dans ton fichier principal, tu ne vois plus le boilerplate. Tu instancies simplement ton composant website, tu lui passes un fichier index, et tu lances le deploy. Les ressources sous-jacentes sont gérées de manière sécurisée derrière l'abstraction. La véritable puissance de l'Infrastructure as Code, c'est de traiter l'architecture cloud comme du software, et les Component Resources sont le moyen de construire une librairie standard et fiable pour ton équipe. C'est tout pour cet épisode. Merci de m'avoir écouté, et continue de développer !

Bonjour, c'est Alex de DEV STORIES DOT EU. Pulumi : Infrastructure as Code, épisode 9 sur 10. Tu n'as pas besoin de jeter des années de code existant pour commencer à utiliser un nouvel outil d'infrastructure aujourd'hui. La redoutable refonte massive du système est un risque énorme, et heureusement, elle est totalement optionnelle. La stratégie qui rend ça possible s'appelle la coexistence pacifique : lire le state Terraform. Une idée reçue fréquente, c'est que passer à Pulumi signifie que tu dois migrer toute ton infrastructure existante d'un coup. C'est faux. Pulumi peut lire et dépendre nativement de ressources qui sont activement gérées par Terraform. Tu peux adopter de nouveaux outils progressivement, en parallèle de tes pipelines de déploiement existants. Imagine un environnement d'entreprise classique. Ton entreprise possède un VPC, un Virtual Private Cloud AWS, géré par une équipe réseau centrale qui utilise Terraform. Tu es développeur, tu crées une nouvelle application, et tu veux utiliser Pulumi pour déployer des tasks Elastic Container Service. Tes conteneurs doivent tourner exactement dans ce VPC. Tu ne veux pas réécrire le code du VPC dans Pulumi, et tu n'as certainement pas envie de reprendre la gestion du réseau sous-jacent. Pour gérer ça, tu utilises le provider Terraform de Pulumi. Ce provider inclut un composant spécifique conçu pour lire les fichiers de state, appelé remote state reference. Le processus repose sur la façon dont Terraform stocke ses données d'exécution. D'abord, le code Terraform qui gère le réseau doit exposer explicitement les données dont ta nouvelle application a besoin. Il fait ça en utilisant des blocs output Terraform standards. L'équipe réseau configure son code pour renvoyer en output l'identifiant du VPC et une liste d'identifiants de subnets privés. Quand Terraform applique sa configuration, ces outputs sont écrits dans le fichier de state Terraform, qui est généralement stocké à distance dans un backend comme un bucket AWS S3 ou Terraform Cloud. Ensuite, tu passes à ton programme Pulumi. Tu écris le code pour instancier la remote state reference. Tu fournis à cet objet exactement les mêmes détails de configuration de backend que Terraform utilise pour trouver son fichier de state. Ça inclut le type de backend, l'emplacement de stockage, la région, et la clé spécifique du fichier de state. Quand tu exécutes ton déploiement Pulumi, le moteur contacte ce backend distant, ouvre le fichier de state Terraform, et parse les outputs disponibles. Voici le point essentiel. Pulumi traite le state Terraform comme étant strictement en read-only. Il ne modifie jamais le fichier de state Terraform, et il ne s'approprie pas les ressources réseau. Il se contente d'interroger les valeurs actuelles et connues de l'infrastructure. Une fois que Pulumi a récupéré les identifiants du VPC et des subnets depuis le state, tu traites ces valeurs comme n'importe quelle autre variable dans ton code. Tu les passes directement dans la logique de déploiement de ton nouveau cluster de conteneurs. Pulumi provisionne tes nouveaux conteneurs de manière transparente dans le réseau existant. Cette architecture garde les responsabilités complètement séparées. L'équipe centrale continue de gérer le cycle de vie du réseau en utilisant Terraform. Si elle met à jour une table de routage ou ajoute un tag, elle utilise son workflow standard. Si elle modifie un output, par exemple en créant un nouveau subnet, Pulumi lira automatiquement le fichier de state mis à jour lors de son prochain update, et ajustera le déploiement de tes conteneurs en conséquence. Utiliser des remote state references crée une frontière de dépendance propre et unidirectionnelle, ce qui te permet de construire en toute confiance de nouveaux systèmes avec des capacités modernes, tout en t'appuyant sur une base stable gérée par du code legacy. C'est tout pour cet épisode. Merci de ton écoute, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. Pulumi : Infrastructure as Code, épisode 10 sur 10. Tester la logique d'une infrastructure complexe est notoirement difficile. Tu écris des milliers de lignes de configuration, mais vérifier si une combinaison spécifique de règles de firewall se comporte vraiment comme prévu avant le deploy ressemble souvent à de la devinette. La Grande Migration : Convertir HCL vers Pulumi, c'est comme ça que tu règles le problème. Passer de Terraform à Pulumi, ce n'est pas un simple chercher-remplacer syntaxique. Il ne s'agit pas juste de changer des accolades en parenthèses. Il s'agit de prendre une configuration statique et de la transformer en un programme exécutable, ce qui te donne un accès immédiat aux boucles natives, aux fonctions et aux frameworks de test standards. Imagine une configuration de security group Terraform très complexe et répétitive. Tu as probablement des dizaines de plages de ports qui se chevauchent, des allowlists d'IP spécifiques et de lourdes définitions de blocs. En HCL, gérer ça demande des structures rigides, et valider la logique nécessite de lancer un plan contre un state cloud en live. La transition commence avec la commande pulumi convert. Tu navigues vers un répertoire qui contient tes fichiers Terraform existants et tu lances cette commande, en spécifiant ton langage cible, comme TypeScript ou Python. L'outil parse ton code source HCL, lit tes variables, tes ressources principales et tes outputs, et génère un programme Pulumi équivalent. Il traduit l'intention déclarative du HCL vers la structure impérative du langage de programmation que tu as choisi. Une fois ce code généré, les avantages stratégiques de la migration deviennent évidents. Tu peux maintenant refactorer cette liste massive de règles de security group en un array propre d'objets de données, ou les récupérer depuis un fichier de configuration externe. Tu peux itérer sur cet array pour générer des règles de firewall dynamiquement en utilisant des boucles TypeScript ou Python standards. Voici le point clé. Parce que ton infrastructure est maintenant écrite dans un langage généraliste, tu peux la tester exactement comme du code applicatif. Tu peux écrire un test unitaire en utilisant des frameworks standards comme Jest ou PyTest. Tu crées un test case qui mock le runtime Pulumi et qui assert que ta fonction builder de security group n'expose jamais accidentellement le port vingt-deux à tout internet. Tu lances ces tests en quelques millisecondes, complètement offline, en attrapant les erreurs logiques avant même que la phase de plan de l'infrastructure ne commence. Ce changement débloque une intégration profonde du langage. Ton code d'infrastructure peut partager des libraries standards, de la logique de validation et des définitions de typage directement avec ton code applicatif. Tu gagnes accès aux écosystèmes matures des package managers comme NPM ou pip, ce qui te permet de packager et de distribuer des patterns d'infrastructure aussi facilement que n'importe quelle autre library logicielle. La commande de conversion fait le gros du travail pour traduire ton state actuel, mais la vraie migration se produit quand tu changes de mentalité, en passant de l'écriture de fichiers statiques à l'ingénierie de systèmes testables. Le plus grand avantage de la conversion de ton code, c'est de passer d'une simple configuration d'infrastructure à sa véritable programmation. Je t'encourage vivement à lire la documentation officielle de Pulumi, à prendre un petit module Terraform, et à essayer de lancer la conversion toi-même pour voir l'output. Si tu as des idées de sujets techniques qu'on devrait aborder dans notre prochaine série, visite devstories dot eu et fais-le nous savoir. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de builder !