David/veylant
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
b30c1147ea
veylant/docs/adr/001-terraform-vs-pulumi.md
David 6b1ba49922 First commit
2026-02-23 13:35:04 +01:00

3.2 KiB
Raw Blame History

ADR-001 — Choix de l'outil Infrastructure-as-Code : Terraform vs Pulumi

Date : 2026-02-19 Statut : ACCEPTÉ Décideurs : CTO, DevOps Sprint : Sprint 1 (Spike de 4h)

Contexte

Veylant IA requiert un outil IaC pour provisionner et gérer :

  • Cluster EKS AWS (eu-west-3), 3 nodes
  • VPC, subnets, security groups, NAT gateway
  • Services managés futurs (RDS, ElastiCache)
  • Ingress Traefik, certificats TLS

Le spike Sprint 1 avait pour objectif d'évaluer Terraform et Pulumi afin de choisir l'outil avant que l'infra ne soit créée.

Options évaluées

Option A — Terraform / OpenTofu

Pour :

  • Module terraform-aws-eks v20.x (LTS) — EKS provisionné en <100 lignes HCL, testé par des milliers d'équipes
  • HCL : déclaratif, diff lisible en PR, facile à code-reviewer
  • Plan d'exécution (terraform plan) explicite et déterministe — pas de side-effects dans le code IaC
  • Gestion d'état mature : S3 + DynamoDB lock (zéro lock cassé en prod)
  • Documentation AWS exhaustive, Stack Overflow dense
  • OpenTofu (fork open-source BSL → MPL) : pas de vendor lock-in HashiCorp

Contre :

  • HCL limité pour la logique complexe (boucles for_each peuvent être verbeux)
  • Pas de typage fort — erreurs découvertes à l'apply, pas à la compilation

Option B — Pulumi (TypeScript)

Pour :

  • TypeScript natif → réutilisable avec le reste du projet
  • Logique complexe (conditions, boucles, fonctions réutilisables) en code natif
  • Typage fort avec vérification à la compilation

Contre :

  • Runtime intermédiaire (Pulumi engine) → debugging moins transparent qu'un plan HCL
  • Communauté plus petite, moins de modules AWS prêts à l'emploi pour EKS
  • Stack d'état hébergée par Pulumi Cloud par défaut (alternative self-hosted plus complexe)
  • Courbe d'apprentissage pour le DevOps habitué à Terraform

Décision

Terraform / OpenTofu est retenu.

Raisons

  1. Risque réduit story E1-04 : Le module terraform-aws-eks est stable et documenté → réduit le risque principal de la story (EKS peut prendre 3+ jours sans outil mature).
  2. Expérience équipe : Le profil DevOps a de l'expérience Terraform existante — pas de courbe d'apprentissage en Sprint 1.
  3. Lisibilité des PR : Le terraform plan en HCL est lisible par tous (CTO, Backend) lors des reviews de changements infra.
  4. État sécurisé : S3 + DynamoDB lock est éprouvé et simple à opérer.
  5. OpenTofu : Le fork open-source est désormais stable (v1.7+) et évite le risque de changement de licence HashiCorp.

Conséquences

  • Créer un bucket S3 veylant-terraform-state-eu-west-3 + table DynamoDB veylant-terraform-lock avant le premier terraform apply
  • Structure : deploy/terraform/ avec modules séparés (vpc/, eks/, monitoring/)
  • Utiliser terraform-aws-eks v20.x
  • Pinning des versions providers dans versions.tf (pas de ~> ouvert)
  • OpenTofu CLI installé via Homebrew : brew install opentofu

Révision

Cette décision sera réexaminée si :

  • La logique IaC devient significativement plus complexe (>500 lignes par module)
  • L'équipe passe à TypeScript pour l'ensemble du stack (SDK natif V2)