Pulumi
| Fiche express | |
|---|---|
| Type | Infrastructure as Code déclarative, en langage de programmation généraliste |
| Éditeur | Pulumi Corporation |
| Langages | TypeScript, Python, Go, C#/.NET, Java, YAML (à vérifier selon les versions) |
| Cycle de vie | pulumi up (équivalent plan+apply) · pulumi destroy
|
| Pièce sensible | le state (backend Pulumi Cloud par défaut, ou self-hosted) |
| Voir aussi | Terraform — Concepts fondamentaux · OpenTofu |
Pulumi est un outil d'Infrastructure as Code qui adopte une approche différente de Terraform ou OpenTofu : au lieu d'un langage de description dédié (DSL) comme le HCL, l'infrastructure est décrite dans un langage de programmation généraliste — TypeScript, Python, Go, C#, Java. Le modèle reste déclaratif (on décrit l'état souhaité, pas une suite d'actions), mais l'outillage du langage hôte (boucles, fonctions, tests unitaires, gestion de paquets) devient directement disponible pour construire cette description.
Principe
Un programme Pulumi importe un SDK (par langage) qui expose les ressources cloud comme des objets/classes du langage. À l'exécution, le programme ne modifie rien lui-même : il déclare un graphe de ressources désirées, que le moteur Pulumi (écrit en Go, indépendant du langage utilisé côté utilisateur) compare à l'état enregistré puis converge, exactement comme le fait Terraform avec son propre moteur.
<mermaid> flowchart LR
P[Programme Pulumi
*.ts / *.py / *.go] --> E[Moteur Pulumi
langage-agnostique] E --> D[Diff état souhaité / réel] D --> A[pulumi up
convergence via API] A --> S[(State)] S -.lecture.-> D
</mermaid>
Exemple (TypeScript)
import * as aws from "@pulumi/aws";
const bucket = new aws.s3.Bucket("mon-bucket", {
tags: { projet: "demo", gerePar: "pulumi" },
});
export const bucketName = bucket.id;
Équivalent en Python :
import pulumi
import pulumi_aws as aws
bucket = aws.s3.Bucket("mon-bucket", tags={"projet": "demo", "gerePar": "pulumi"})
pulumi.export("bucket_name", bucket.id)
Les deux extraits produisent le même appel au moteur Pulumi et au provider AWS ; seul le langage d'expression change.
Positionnement face à Terraform / OpenTofu
| Terraform / OpenTofu | Pulumi | |
|---|---|---|
| Langage | HCL (DSL dédié à l'IaC) | Langage de programmation généraliste (TypeScript, Python, Go, C#, Java) |
| Logique impérative (boucles, conditions complexes) | Limitée aux constructions HCL (for_each, count, expressions) |
Native — celle du langage hôte |
| Tests unitaires | Outillage tiers (Terratest, etc.) | Frameworks de test du langage hôte directement utilisables |
| Courbe d'apprentissage | Langage dédié à apprendre, mais périmètre restreint et prévisible | Pas de nouveau langage si l'équipe connaît déjà TypeScript/Python/Go ; mais surface fonctionnelle du SDK plus large |
| Écosystème providers | Registre Terraform, très large et mature | Génération automatique de SDK à partir des providers Terraform (pont technique), plus jeune |
| State | Fichier/backend, format propre à Terraform | Fichier/backend, format propre à Pulumi (Pulumi Cloud gratuit par défaut, ou self-hosted) |
L'argument principal en faveur de Pulumi est d'éviter un DSL supplémentaire quand une équipe de développement maîtrise déjà un langage généraliste : la même compétence sert à écrire l'application et son infrastructure, avec les mêmes outils (linters, IDE, gestion de dépendances, revue de code). En contrepartie, la puissance du langage hôte permet aussi d'introduire une complexité ou des effets de bord que le HCL, plus contraint, décourage structurellement — un compromis expressivité contre simplicité/prévisibilité à arbitrer selon l'équipe.
State
Comme pour Terraform, le state Pulumi trace le lien entre les objets déclarés dans le programme et les ressources réelles, et constitue la pièce sensible à protéger. Par défaut, Pulumi stocke le state sur Pulumi Cloud (offre gérée par l'éditeur, avec un niveau gratuit) ; un stockage self-hosted reste possible (S3/objet, Azure Blob, systèmes de fichiers locaux) pour des contraintes de souveraineté ou de coût, avec les mêmes précautions que celles décrites pour le state Terraform (chiffrement au repos, verrouillage, restriction d'accès).
Quand préférer Pulumi
- Une équipe déjà orientée développement (pas seulement ops) qui souhaite garder un seul écosystème de langage.
- Des besoins de logique de génération d'infrastructure complexe (boucles conditionnelles avancées, appels à des bibliothèques métier existantes).
- Des tests unitaires ou d'intégration sur le code d'infrastructure via le framework de test natif du langage.
Pour un socle on-prem stable et une équipe majoritairement infra/ops déjà à l'aise avec HCL, Terraform ou OpenTofu restent le choix par défaut le plus répandu — voir aussi Terraform — Providers on-prem pour l'exemple vSphere/Rancher.