82 lines
3.2 KiB
Markdown
82 lines
3.2 KiB
Markdown
# 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)
|