Terraform et l'infrastructure as code, plus en profondeur

Quand tu débutes, tu vas dans la console AWS ou GCP et tu cliques pour créer ton serveur. Moi, j'appelle ça le ClickOps. Ça marche. Mais avec Terraform, tu l'écris dans un fichier.

Dans la vidéo, je te montre trois lignes : le serveur. Le fichier complet en compte un peu plus, parce qu'il faut aussi dire à Terraform chez quel hébergeur le créer.

Trois blocs, de haut en bas.

Tu ne dis pas à Terraform comment créer le serveur, étape par étape. Tu décris ce que tu veux, et il se débrouille pour te le créer. C'est pour ça que c'est facile : ce n'est quasiment pas de la programmation.

Le fichier s'appelle main.tf par usage. Terraform lit tous les fichiers .tf du dossier comme un seul document.

Plan, apply, destroy : ce sont les trois de la vidéo. La quatrième passe en premier, et tu ne la lances qu'une fois par dossier : terraform init.

terraform init prépare le dossier. Il télécharge le provider demandé, et note la version choisie dans un fichier, .terraform.lock.hcl, que tu gardes dans Git avec ton code. Tu peux relancer init autant de fois que tu veux.

terraform plan regarde ce qui existe déjà, le compare à ton fichier, et t'affiche ce qu'il ferait. Il ne touche à rien. Pour le fichier du dessus, voilà ce qu'il affiche, en raccourci :

# aws_instance.serveur will be created
+ resource "aws_instance" "serveur" {
    + ami           = "resolve:ssm:/aws/…"
    + instance_type = "t3.micro"
    + id            = (known after apply)
    …
  }

Plan: 1 to add, 0 to change, 0 to destroy.

terraform apply refait le plan, te le montre, et attend. Il te prévient : « Only 'yes' will be accepted to approve. » Tu tapes yes, et il crée le serveur.

terraform destroy supprime tout ce que ce dossier a créé. Lui aussi montre son plan et attend ton yes, avec un avertissement en plus : « There is no undo. »

Lire un plan, c'est repérer quatre symboles en début de ligne.

Dans la vidéo, je le dis en une phrase : tout l'état de Terraform est maintenu dans un fichier, le Terraform State. Par défaut, il s'appelle terraform.tfstate, et il apparaît dans ton dossier au premier apply.

C'est un fichier JSON. Il fait le lien entre ce que tu as écrit et ce qui existe vraiment : ton aws_instance.serveur, c'est telle machine chez AWS, avec tel identifiant. C'est avec lui que Terraform décide quoi créer, quoi modifier et quoi laisser tranquille.

Sans son state, Terraform ne sait plus que ton serveur existe. Tu relances plan, et il te propose d'en créer un autre.

Où garder le state, selon ta situation :

En entreprise, en startup, ou même sur tes projets perso sérieux, tu as en général trois environnements : dev, intégration et production. L'idée, c'est d'avoir une configuration identique dans les trois, pour développer, tester ton code ou le déployer en production dans les mêmes conditions.

Avec Terraform, tu ne copies pas le fichier trois fois. Ce qui change d'un environnement à l'autre, tu le sors dans une variable. Puis tu donnes sa valeur dans un petit fichier par environnement.

Un point que je ne dis pas dans la vidéo : chaque environnement a son propre state. Si tu lances la commande de prod avec le state de dev, Terraform ne crée pas un deuxième serveur. Pour lui, c'est le même, et il te propose de modifier celui de dev.

Un state par environnement, les deux façons prévues par Terraform :

Ce n'est pas toi qui déploies, c'est la CI/CD : elle automatise les déploiements en fonction de la branche sur laquelle le code est mergé. Quelle branche déploie dans quel environnement, c'est chaque équipe qui le décide.

La CI/CD lance les mêmes commandes que toi, à deux différences près. Elle ne peut pas répondre à une question au clavier. Et le plan qui a été relu doit être exactement celui qui est appliqué.

-input=false dit à Terraform de ne rien demander au clavier. -out=tfplan enregistre le plan dans un fichier. Et apply tfplan applique ce fichier-là, sans redemander yes.

La validation se passe donc entre les deux étapes : quelqu'un relit le plan avant que l'apply parte. C'est le déroulé que décrit HashiCorp.

Il existe aussi -auto-approve, qui applique sans rien demander à personne. HashiCorp le réserve aux infrastructures non critiques.

C'est là que c'est contre-intuitif. L'IA a du mal à écrire ce code. Pas parce que c'est dur : d'ailleurs, chez toi, elle y arrivera. Mais l'IA te fait des configs de projets simples.

En entreprise, les responsabilités sont découpées. Il y a plusieurs projets, et plusieurs responsables. Par exemple, si tu veux faire un projet IA, tu vas le faire sur une plateforme d'agents. Cette plateforme est elle-même posée sur la plateforme cloud de ton entreprise. Chacun a ses responsabilités.

Donc en entreprise, Terraform, ce n'est pas une seule brique, mais un empilement de Lego.

Et quand ça ne marche pas, il faut trouver l'étage. Parfois, c'est ton projet qui est mal configuré. Parfois, c'est mal configuré côté plateforme. Ça, l'IA a du mal à le savoir : elle a ton code sous les yeux, pas les étages qui ne sont pas à toi.

Les commandes ne tranchent pas à sa place. terraform validate vérifie que ton code est cohérent, sans rien demander à ton hébergeur. terraform plan lit ce qui existe et propose. Aucune des deux ne crée quoi que ce soit. La création n'est tentée qu'à l'apply : c'est là que tu apprends si la plateforme te laisse faire.

Chez moi, ça donne ça. Quand je fais de l'infra as code avec Claude, il m'arrive de discuter dix à vingt minutes pour corriger une ligne. Ensuite, pour tester, j'envoie le code se déployer, et ça prend encore quinze minutes. Sur une feature qui pose problème, je peux passer la journée sur un problème d'infrastructure. La boucle d'itération est extrêmement longue. En ce moment, dans mon boulot, c'est ce qui me prend le plus de temps.

L'IA écrit vite. Ce qu'elle ne peut pas deviner, c'est comment ton entreprise est découpée. C'est à toi de le lui dire.

Ce que tu lui donnes, avant de lui demander une ligne :

Ce que tu relis : le plan, avant l'apply. La dernière ligne d'abord, puis chaque - et chaque -/+. Si le plan veut détruire quelque chose que tu n'as pas demandé, tu t'arrêtes là.

Deux règles à lui fixer, qui viennent de la doc de Terraform. Pas de -auto-approve sur une infra qui compte : cette option applique sans demander, suppressions comprises. Et personne n'édite le state à la main, elle non plus.

Et quand elle tourne en rond, pose la question qu'elle ne pose pas : est-ce que le problème est dans mon projet, ou dans l'étage du dessous ? Si c'est la plateforme, aucune ligne de ton code ne le corrigera. Tu vas voir ceux qui en sont responsables.

Mon conseil, si tu veux bosser dans le cloud : commence directement à développer dans le cloud, et directement avec de l'infrastructure as code comme Terraform.

1. Installe Terraform. Il existe pour Mac, Windows et Linux, sur la page d'installation de Terraform.
2. Ouvre un compte chez un hébergeur cloud. Pour AWS, le compte, le plan gratuit et l'alerte de budget sont expliqués dans Apprendre AWS.
3. Donne tes identifiants à Terraform par des variables d'environnement : AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY. Jamais écrits dans le fichier .tf.
4. Recopie le fichier de la partie 1, et déroule les quatre commandes. Regarde ton serveur apparaître dans la console AWS, puis disparaître.
5. Recommence en changeant une ligne, et lis le plan avant de taper yes.

Ce que tu crées dans ton compte se paie comme le reste : lance terraform destroy quand tu as fini.

Pour la suite, HashiCorp publie un parcours officiel, en anglais : Get Started - AWS. Six tutoriels : installer Terraform, créer une infrastructure, la modifier, la détruire.