Formation Pulumi - provisionnement local avec KVM

Cette section vous fait demarrer Pulumi sans compte cloud et sans premiere demo deforme par un provider public. Vous allez comprendre le modele 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 depart n’est pas un bucket AWS ni un exemple trop abstrait. Le parcours actuel va jusqu’a une vraie VM KVM qui demarre localement, apres la creation d’un reseau 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 deja la section

Le redemarrage de la section Pulumi se fait volontairement en petit perimetre, mais sur une base testee.

Module	Role	Statut
Hub Pulumi	Vue d’ensemble, concepts, runtimes et parcours	Disponible
Concepts, stacks et state	Modele mental du projet, du backend, du state et du preview	Disponible
Preparation locale	Projet Python, backend local, stack, provider libvirt	Disponible
Premiere stack KVM	Reseau, disque, cloud-init et VM visible dans `virsh`	Disponible
Inputs, outputs, config et secrets	Parametrage de stack, outputs utiles et secret masque	Disponible
Structure de projet et composants	Decoupage du projet Python et creation d’un ComponentResource reutilisable	Disponible
Preview, tests et CI	Compilation Python, tests unitaires, preview non interactif et workflow self-hosted	Disponible
Securiser Pulumi en equipe	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 debut si on ne clarifie pas le sujet.

TypeScript / JavaScript : tres apprecies dans les equipes deja alignees sur l’ecosysteme Node.js.
Python : excellent choix pour apprendre, parce que la syntaxe laisse bien voir les ressources et les objets manipules.
Go : utile pour les equipes qui privilegient le typage strict et les binaires simples a integrer dans des outillages plateforme.
C# / .NET : pertinent dans les environnements deja structures autour de cet ecosysteme.
Java : possible egalement pour des equipes 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 modele IaC reste le meme : ressources, dependances, state, preview, apply et verification.

Pourquoi on part sur Python

Cette section prend Python comme langage de reference pour une raison pedagogique.

Python est lisible tres vite, meme pour un lecteur qui debute sur Pulumi.
Il permet de voir clairement les objets Provider, Network, Volume, CloudinitDisk et Domain.
Il s’integre 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 equipes techniques

Pulumi se distingue des autres outils IaC parce qu’il vous laisse decrire l’infrastructure avec un langage generaliste. Cette approche parle souvent plus vite aux developpeurs, mais elle peut aussi tromper au debut : on ecrit en Python, TypeScript, Go ou C#, pourtant le modele reste bien un modele de ressources, de state et de reconciliation.

Autrement dit, le langage change, mais les questions importantes restent les memes : qu’est-ce qui est deja cree, qu’est-ce qui doit changer, dans quel ordre, et comment verifier le resultat. C’est pour cela que cette section commence par un lab local tres simple a observer.

Les concepts a garder en tete

Avant d’entrer dans les guides, gardez ces reperes en tete :

Projet : le dossier qui contient votre code Pulumi, son runtime et ses dependances.
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 memoire de ce que Pulumi a cree, modifie ou supprime.
Preview : la simulation de ce qui va changer avant application.
Destroy : le retour a un etat 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 decrivez des ressources, puis Pulumi calcule les operations a executer.

Ce que vous saurez faire apres 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 ;
creer un reseau, un disque clone, un disque cloud-init et une VM KVM ;
verifier le resultat avec virsh ;
detruire proprement la stack pour rejouer le scenario.

Parcours recommande

Commencez par preparer le projet local et le backend. Passez ensuite au guide pratique qui fait demarrer une premiere 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'executer 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 reseau NAT, un disque clone, un disque cloud-init et une VM KVM qui demarre reellement.

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'entree, 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 equipe 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’ecosysteme Pulumi. Les sujets suivants restent a produire apres 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, meme si le code est ecrit dans un langage generaliste.
Cette section part sur Python parce qu’il rend le modele plus lisible pour debuter.
Le meilleur point d’entree 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 creee puis detruite proprement.

Prochaines etapes

Comprendre stacks et state Stabiliser le modele 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 premiere stack Rejouer le workflow preview, up, verification virsh, puis destroy sur un reseau, 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 dediee et ComponentResource reutilisable.

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

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