Formation Pulumi - provisionnement local avec KVM

Cette section vous fait démarrer Pulumi sans compte cloud et sans première demo deforme par un provider public. Vous allez comprendre le modèle mental de l'outil, identifier le role d'une stack, du state et du provider, voir quels langages sont disponibles, puis suivre un parcours local valide sur KVM/libvirt.

Le point de départ n'est pas un bucket AWS ni un exemple trop abstrait. Le parcours actuel va jusqu'à une vraie VM KVM qui demarre localement, après la création d'un réseau NAT, d'un disque clone et d'un disque cloud-init. L'objectif est de montrer ce que Pulumi fait vraiment, avant d'ouvrir vers les sujets plus larges comme les composants, les secrets, la CI ou le multi-cloud.

Ce que couvre déjà la section

Le redémarrage de la section Pulumi se fait volontairement en petit périmètre, mais sur une base testée.

Module	Role	Statut
Hub Pulumi	Vue d'ensemble, concepts, runtimes et parcours	Disponible
Concepts, stacks et state	Modèle mental du projet, du backend, du state et du preview	Disponible
Préparation locale	Projet Python, backend local, stack, provider libvirt	Disponible
Première stack KVM	Réseau, disque, cloud-init et VM visible dans `virsh`	Disponible
Inputs, outputs, config et secrets	Paramétrage de stack, outputs utiles et secret masque	Disponible
Structure de projet et composants	Découpage du projet Python et création d'un ComponentResource reutilisable	Disponible
Preview, tests et CI	Compilation Python, tests unitaires, preview non interactif et workflow self-hosted	Disponible
Sécuriser Pulumi en équipe	Passphrase non vide, permissions strictes et workflow self-hosted sans fuite de secrets	Disponible

Les langages disponibles dans Pulumi

Pulumi peut s'appuyer sur plusieurs runtimes. C'est un de ses points forts, mais aussi une source de confusion au début si on ne clarifie pas le sujet.

TypeScript / JavaScript : très apprecies dans les équipes déjà alignees sur l'écosystème Node.js.
Python : excellent choix pour apprendre, parce que la syntaxe laisse bien voir les ressources et les objets manipules.
Go : utile pour les équipes qui privilegient le typage strict et les binaires simples a intégrer dans des outillages plateforme.
C# / .NET : pertinent dans les environnements déjà structures autour de cet écosystème.
Java : possible également pour des équipes qui veulent rester sur leur langage habituel.
YAML : supporte, mais moins representatif de la promesse centrale de Pulumi, qui est justement de s'appuyer sur un langage generaliste.

Le runtime change, mais le modèle IaC reste le même : ressources, dépendances, state, preview, apply et verification.

Pourquoi on part sur Python

Cette section prend Python comme langage de reference pour une raison pédagogique.

Python est lisible très vite, même pour un lecteur qui debute sur Pulumi.
Il permet de voir clairement les objets Provider, Network, Volume, CloudinitDisk et Domain.
Il s'intègre bien dans un lab Linux local avec KVM/libvirt.
Il ajoute moins de bruit annexe qu'un premier guide en Go ou en TypeScript avec davantage d'outillage autour.

Ce choix ne dit pas que Python est le seul bon runtime pour Pulumi. Il dit simplement que c'est un bon runtime pour apprendre.

Pourquoi Pulumi attire vite les équipes techniques

Pulumi se distingue des autres outils IaC parce qu'il vous laisse décrire l'infrastructure avec un langage generaliste. Cette approche parle souvent plus vite aux développeurs, mais elle peut aussi tromper au début : on écrit en Python, TypeScript, Go ou C#, pourtant le modèle reste bien un modèle de ressources, de state et de réconciliation.

Autrement dit, le langage change, mais les questions importantes restent les mêmes : qu'est-ce qui est déjà cree, qu'est-ce qui doit changer, dans quel ordre, et comment vérifier le résultat. C'est pour cela que cette section commence par un lab local très simple a observer.

Les concepts a garder en tête

Avant d'entrer dans les guides, gardez ces repères en tête :

Projet : le dossier qui contient votre code Pulumi, son runtime et ses dépendances.
Stack : une instance du projet avec sa propre configuration et son propre state.
Provider : le composant qui sait parler a la plateforme cible, ici libvirt.
State : la mémoire de ce que Pulumi a cree, modifie ou supprime.
Preview : la simulation de ce qui va changer avant application.
Destroy : le retour a un état propre pour rejouer le scenario.

Le point le plus important pour un debutant est simple : Pulumi n'est pas un script shell imperatif deguise. Vous décrivez des ressources, puis Pulumi calcule les operations a exécuter.

Ce que vous saurez faire après les premiers guides

Une fois les deux premiers guides termines, vous saurez :

initialiser un projet Pulumi Python depuis un dossier vide ;
activer un backend local avec pulumi login --local ;
ajouter le provider libvirt et comprendre son role ;
créer un réseau, un disque clone, un disque cloud-init et une VM KVM ;
vérifier le résultat avec virsh ;
detruire proprement la stack pour rejouer le scenario.

Parcours recommande

Commencez par préparer le projet local et le backend. Passez ensuite au guide pratique qui fait démarrer une première VM KVM visible dans libvirt.

Comprendre stacks et state Clarifier le role du projet, de la stack, du backend local et du preview avant d'exécuter davantage de commandes.

Preparer le backend local Creer le projet Pulumi Python, activer le backend local, initialiser la stack et ajouter le provider libvirt.

Premiere stack KVM Creer un réseau NAT, un disque clone, un disque cloud-init et une VM KVM qui demarre réellement.

Config, outputs et secrets Parametrer la stack, lire les outputs utiles et stocker un secret sans l'exposer en clair.

Structurer le projet Decouper la stack en point d'entrée, module de config et ComponentResource reutilisable.

Preview, tests et CI Industrialiser ensuite le projet avec compileall, unittest, preview non interactif et workflow GitHub Actions self-hosted.

Securiser Pulumi en équipe Durcir ensuite la stack avec une passphrase d'equipe, des permissions strictes et une CI sans secret versionne.

Revoir les fondamentaux IaC Reprendre les notions transverses avant de comparer Pulumi, Terraform et les autres outils de provisionnement.

Ce que cette section ne cherche pas encore a couvrir

Le but n'est pas encore de traiter tout l'écosystème Pulumi. Les sujets suivants restent a produire après validation en lab :

les backends distants partages avec verrouillage et chiffrement KMS ;
l'ouverture vers des providers cloud publics ou hybrides.

Cette limite est volontaire. Une section qui promet trop tot plus qu'elle ne teste finit par devenir fragile.

A retenir

Pulumi reste un outil IaC pilote par un state, même si le code est écrit dans un langage generaliste.
Cette section part sur Python parce qu'il rend le modèle plus lisible pour debuter.
Le meilleur point d'entrée actuel est un workflow local sur KVM/libvirt.
Le backend local suffit pour apprendre les notions essentielles sans token SaaS.
Le premier objectif n'est pas le cloud public, mais une vraie VM locale créée puis détruite proprement.

Prochaines étapes

Comprendre stacks et state Stabiliser le modèle mental Pulumi avant d'aller vers les secrets, les components ou la CI.

Preparer le projet local Initialiser le dossier Pulumi, la stack locale et le provider libvirt avant le premier preview.

Executer la première stack Rejouer le workflow preview, up, verification virsh, puis destroy sur un réseau, un disque et une VM KVM.

Gerer config et secrets Passer a une stack Pulumi parametree avec outputs utiles et secret masque dans la CLI.

Structurer le projet Passer du gros __main__.py a un projet Pulumi avec config dédiée et ComponentResource reutilisable.

Industrialiser preview et CI Ajouter compileall, tests unitaires, preview non interactif et workflow self-hosted avant de travailler en équipe.

Durcir la stack d'equipe Passer ensuite a une stack Pulumi chiffrée, a des permissions strictes et a une CI qui lit sa passphrase via secret GitHub.