Une startup que je connais avait toute son infra dans un seul compte AWS. Pas de code, juste un mec qui savait sur quels boutons cliquer dans le bon ordre

Ce mec démissionne. Deux semaines de préavis. Avant de partir, il écrit un Google Doc de 47 pages qui explique comment tout est monté. Security groups, load balancers, configs RDS, tout. Il l’imprime, le file, et se barre

Trois mois plus tard, ils doivent donner accès à la base de prod au nouveau service d’analytics. Ça devrait être simple. Sauf qu’il y a six security groups, trois rôles IAM, et deux VPCs dans le mix. Le doc dit “utilise le security group de la base” mais lequel? Il y a prod-db-sg, database-prod-sg, et rds-production-sg

Ils essaient d’ajouter des règles à différents security groups. Rien ne marche. Puis quelqu’un se rappelle qu’il y a aussi une network ACL quelque part. Et au fait, le service analytics il tourne dans quel subnet déjà?

Quatre heures plus tard, ça marche. Personne ne sait vraiment lequel des douze changements a réglé le truc. Faut surtout plus y toucher maintenant

Cette boîte utilise maintenant Terraform. Toute leur infra c’est 300 lignes de code. Tu veux savoir quel security group fait quoi? Tu lis le fichier. Ça prend deux minutes

La recette vs l’improvisation

Cliquer dans une console c’est comme cuisiner sans recette. Ouais tu peux réussir une fois. Mais refais le même plat la semaine prochaine. Pas les mêmes quantités, t’as oublié un ingrédient, la température du four est pas la bonne. Proche, mais pas tout à fait pareil

Terraform c’est la recette. Mêmes ingrédients, mêmes étapes, même résultat à chaque fois. Et tu peux filer cette recette à quelqu’un d’autre. Il fera exactement le même plat

Voilà de la vraie infrastructure as code:

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-cool-bucket"

  tags = {
    ManagedBy = "terraform"
  }
}

Tu sauvegardes ça, tu lances terraform apply, boum. Bucket S3. T’en veux dix de plus? Tu copies le bloc dix fois, tu changes les noms, tu lances apply. Ou mieux, tu fais une boucle. Deux minutes, dix buckets identiques

Essaie de faire ça en cliquant. Je t’attends

Ce qui foire sans code

Laisse-moi te raconter un incident réel. Une boîte avait trois environnements: dev, staging, prod. Des personnes différentes les ont montés à des moments différents en cliquant dans la console AWS

Dev avait une base t2.micro. Staging une t2.small. Prod une t2.large. Sauf que quelqu’un s’est planté sur prod et c’était en fait une t2.xlarge. Personne l’a remarqué pendant six mois

Puis staging a cassé. Quelqu’un a essayé de le réparer en “le mettant comme prod”. Devine ce qu’il a copié? La t2.xlarge. Maintenant staging coûte quatre fois plus cher et personne ne sait pourquoi

Ce genre de trucs arrive tous les jours. Quelqu’un clique quelque part. Oublie de documenter. Six mois après ça casse et personne ne se rappelle ce qu’il y avait

Avec Terraform, ton infra est littéralement dans un fichier. Tu peux le lire. Tu peux le versionner. Tu sais exactement ce qui tourne parce que c’est là dans git

Les bases

Terraform utilise HCL. C’est comme du JSON mais moins chiant. T’écris ce que tu veux, Terraform le fait

Serveur web simple:

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "my-web-server"
  }
}

C’est tout. Tu lances terraform apply, t’as une instance EC2

Tu veux passer en t3.small? Tu édites le fichier, tu relances apply. Terraform voit la diff et met à jour l’instance. Pas de clic, pas de console, zéro chance de te planter en tapant

Le state: la mémoire de Terraform

Terraform garde un fichier de state. C’est comme ça qu’il se rappelle ce qu’il a créé. Quand tu lances terraform plan, il compare ton code à ce state et te dit ce qui va changer

Le state par défaut est local. Parfait en solo, catastrophe en équipe. Quelqu’un d’autre lance Terraform sans ton fichier de state? Il va essayer de tout créer from scratch. Ressources en double, conflits, mauvais délire

Stocke le state à distance:

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
  }
}

Maintenant tout le monde dans l’équipe utilise le même state. Fini le “ça marchait sur ma machine”

Les modules: écris une fois, utilise partout

T’as monté un VPC une fois. Trois subnets, routing tables, internet gateway, tout le bazar. Ça t’a pris une heure pour que ce soit bon

Maintenant t’en as besoin du même en staging. Et en dev. Et dans cet environnement de demo pour les commerciaux

Sans Terraform, tu vas cliquer pendant encore trois heures

Avec les modules Terraform, tu packages ce setup VPC une fois:

module "vpc" {
  source = "./modules/vpc"

  environment = "staging"
}

Même code, environnement différent. Dev, staging, prod ont tous le même réseau. Tu changes le module, tout se met à jour. Une seule source de vérité

L’histoire d’horreur du clickops

Histoire vraie d’un pote. Une boîte sans infrastructure as code. Tout configuré à la main dans la console AWS

Un nouveau dev arrive. A besoin d’un accès AWS. Quelqu’un lui file des droits admin parce que “c’est plus simple que de trouver les permissions exactes”

Le dev expérimente dans la console. Il croit être en dev. Il est en prod. Il termine une instance RDS. “Ça disait database-test, je pensais que c’était l’environnement de test”

C’était la base de prod. Les backups? Il y avait des snapshots manuels. De trois semaines. Parce que quelqu’un devait se rappeler de cliquer sur le bouton backup

Avec Terraform, cette config de base est dans le code:

resource "aws_db_instance" "prod" {
  identifier = "production-database-do-not-touch"
  # ...
  backup_retention_period = 7
  skip_final_snapshot = false
}

Nom clair. Backups automatiques. Dans git. Tu vois qui a changé quoi et quand. Tu peux revenir à la config de la semaine dernière si besoin

Plus important, cette base est protégée. Terraform te laissera pas la supprimer par accident. Faudrait que tu l’enlèves explicitement du code, que tu commit, que tu push, que ça passe la review, et après que tu lances apply. Plusieurs chances d’attraper l’erreur

Quand Terraform a du sens

Utilise-le si:

• T’as besoin de plus d’un environnement
• Plusieurs personnes touchent l’infra
• Tu veux bien dormir la nuit
• Tu tiens à ton temps

Passe ton chemin si:

• Expérience ponctuelle que tu vas delete dans une heure
• T’apprends AWS et t’as besoin de cliquer pour comprendre

Si tu fais un truc plus d’une fois, Terraform fait gagner du temps. Si t’explores, cliquer c’est bien

Trois commandes dont t’as besoin

terraform init    # Télécharge les providers, setup le backend
terraform plan    # Vois ce qui va changer
terraform apply   # Fais-le

Voilà. T’écris ta config, tu plan, tu apply. Ton infra se met à jour

Tu veux tout détruire?

terraform destroy

Tout ce que t’as créé, disparu. Essaie de faire ça en cliquant. Tu vas oublier un truc et le payer pendant des mois

Le fond du truc

L’infrastructure ça devrait être:

• Versionné
• Reviewable
• Répétable
• Documenté automatiquement

Le clic te donne rien de tout ça. Terraform te donne tout

Ton infra c’est du code. Traite-la comme du code. Review, teste, versionne. Arrête de cliquer en prod