⚙️ Pulumi – Infrastructure as Code programmable

Choisir son runtime

Pattern “component” réutilisable

// TypeScript
import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

export class WebApp extends pulumi.ComponentResource {
    public readonly url: pulumi.Output<string>;

    constructor(name: string, opts?: pulumi.ComponentResourceOptions) {
        super("ideolab:component:WebApp", name, {}, opts);

        const bucket = new aws.s3.Bucket(`${name}-static`);
        const site = new aws.s3.BucketWebsiteConfigurationV2(`${name}-site`, {
            bucket: bucket.id,
            indexDocument: { suffix: "index.html" },
        });

        this.url = pulumi.interpolate`http://${bucket.websiteEndpoint}`;
        this.registerOutputs({ url: this.url });
    }
}
                    

On peut packager ces composants dans des libs internes (npm, wheel, module Go…) pour les réutiliser sur tout IDEO-Lab.

Clouds principaux

Au-delà du Cloud “classique”

• Cloudflare (DNS, WAF, CDN).
• GitHub / GitLab (repos, teams, permissions).
• DBaaS (MongoDB Atlas, Neon, etc.).
• Monitoring & logs (Datadog, New Relic…).

Idéal pour gérer à la fois l’infra “physique” (VPC, K8s) et les couches services / SaaS autour (CI/CD, observabilité).

Ce que contient le state

• Liste des ressources créées (type, nom, ID provider).
• Valeurs d’inputs et d’outputs.
• Versioning des déploiements, historique.

pulumi stack export > state.json
# snapshot JSON complet de la stack
                    

Bonnes pratiques d’organisation

• Un org Pulumi par entreprise (ex: ideolab).
• Projets alignés sur les domaines (infra-core, data-platform…).
• Stacks par environnement / client.
• Backups réguliers des buckets de state si backend S3/Azure/GCS.

Déployer un manifest K8s

import * as k8s from "@pulumi/kubernetes";

const appLabels = { app: "ideolab-api" };

const deployment = new k8s.apps.v1.Deployment("ideolab-api", {
    spec: {
        selector: { matchLabels: appLabels },
        replicas: 3,
        template: {
            metadata: { labels: appLabels },
            spec: {
                containers: [{
                    name: "api",
                    image: "ghcr.io/ideolab/api:latest",
                    ports: [{ containerPort: 8000 }],
                }],
            },
        },
    },
});
                    

Helm charts avec Pulumi

const nginxIngress = new k8s.helm.v3.Chart("ingress", {
    chart: "ingress-nginx",
    version: "4.10.0",
    fetchOpts: { repo: "https://kubernetes.github.io/ingress-nginx" },
    values: {
        controller: {
            replicaCount: 2,
            service: { type: "LoadBalancer" },
        },
    },
});
                    

Pulumi devient un “orchestrateur d’infra” complet : Cloud + cluster + workloads, avec un seul pulumi up.

Network + S3 (TypeScript)

import * as aws from "@pulumi/aws";

const vpc = new aws.ec2.Vpc("ideolab-vpc", {
    cidrBlock: "10.0.0.0/16",
    enableDnsHostnames: true,
});

const publicSubnet = new aws.ec2.Subnet("ideolab-public", {
    vpcId: vpc.id,
    cidrBlock: "10.0.1.0/24",
    mapPublicIpOnLaunch: true,
});

const bucket = new aws.s3.Bucket("ideolab-artifacts", {
    versioning: { enabled: true },
});
                    

EC2 bastion + outputs

const sg = new aws.ec2.SecurityGroup("bastion-sg", {
    vpcId: vpc.id,
    ingress: [{
        protocol: "tcp", fromPort: 22, toPort: 22,
        cidrBlocks: ["0.0.0.0/0"],   // à restreindre en prod !
    }],
    egress: [{ protocol: "-1", fromPort: 0, toPort: 0, cidrBlocks: ["0.0.0.0/0"] }],
});

const bastion = new aws.ec2.Instance("bastion", {
    ami: "ami-0c02fb55956c7d316",   // Ubuntu (ex.)
    instanceType: "t3.micro",
    subnetId: publicSubnet.id,
    vpcSecurityGroupIds: [sg.id],
    keyName: "ideolab-key",
});

export const bastionIp    = bastion.publicIp;
export const bucketName   = bucket.id;
export const vpcId        = vpc.id;
                    

Ces outputs sont visibles via pulumi stack output (et via Pulumi Cloud si tu l’utilises).

Quand Pulumi est particulièrement intéressant

• Tu as déjà des équipes très dev-oriented (TS / Python / Go).
• Tu veux factoriser un max le code infra, faire des libs internes.
• Tu as des stacks dynamiques (multi-clients, multi-regions) calculées à partir de données.
• Tu veux tester ton infra comme du code (TDD infra).

Coexistence possible

Tu peux très bien garder Terraform sur certains périmètres (legacy, équipes déjà outillées) et introduire Pulumi pour les nouvelles plateformes :

• Terraform pour la “landing zone” globale.
• Pulumi pour les workloads applicatifs / K8s / SaaS.
• Interop via les IDs de ressources (VPC existant, subnets, etc.).

GitHub Actions (exemple)

name: Pulumi Deploy

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: pulumi/actions@v4
        with:
          command: up
          stack-name: ideolab/dev
        env:
          PULUMI_ACCESS_TOKEN: $
          AWS_ACCESS_KEY_ID: $
          AWS_SECRET_ACCESS_KEY: $
          AWS_REGION: eu-west-1
                    

Bonnes pratiques

• 1 job “preview” (PR) + 1 job “deploy” (merge sur main).
• Token Pulumi en secret CI, jamais commité.
• Utiliser des stack tags pour tracer l’origine des déploiements.
• Logs centralisés vers CloudWatch / Datadog / ELK.

Gestion des secrets

# En CLI
pulumi config set db:password super-secret --secret

# En TypeScript
const dbPassword = pulumi.secret(
    pulumi.config.require("db:password")
);

# Propager au provider
const db = new aws.rds.Instance("db", {
    username: "ideolab",
    password: dbPassword,
    ...
});
                    

Policy as Code (CrossGuard)

CrossGuard permet de définir des politiques de sécurité (Node/TS) qui s’appliquent aux stacks :

// Exemple de règle simplifiée
policy.resourceOfType(aws.s3.Bucket, (bucket, args, reportViolation) => {
    if (!bucket.versioning || !bucket.versioning.enabled) {
        reportViolation("Les buckets S3 doivent avoir le versioning activé.");
    }
});
                    

Ces règles peuvent être intégrées dans les pipelines CI/CD pour bloquer un pulumi up non conforme (sécurité, coûts, best practices).

Commandes essentielles

pulumi new aws-typescript     # init projet
pulumi stack ls               # lister les stacks
pulumi stack select dev       # sélectionner une stack
pulumi config set key value   # config
pulumi config set key value --secret  # secret
pulumi preview                # plan
pulumi up                     # apply
pulumi destroy                # détruire
pulumi stack output           # lire les outputs
                    

Debug & inspection

pulumi stack export > state.json   # snapshot JSON
pulumi logs                        # logs de la dernière opération
pulumi whoami                      # organisation / user
                    

Tu peux ajouter un petit alias shell par environnement (ex: pud pour “pulumi up dev”, pup pour prod avec confirmation renforcée).