Apprendre Terraform sans compte cloud ni carte bancaire

Ce que vous allez obtenir

À la fin de ce guide, vous aurez écrit une configuration Terraform, l'aurez appliquée, modifiée, cassée puis réparée, autant de fois que vous le souhaitez, sur votre machine. Vous aurez vu ce qu'est une variable, un output, une dépendance entre ressources, un état et une convergence, et vous aurez lu une vraie erreur de provider.

Le tout sans compte cloud, sans clé d'API, sans carte bancaire et sans attendre qu'une machine se provisionne.

Pourquoi apprendre ainsi

Apprendre Terraform coûte cher, et pas seulement en argent. Ouvrir un compte, générer des clés, comprendre la facturation et se souvenir de tout détruire avant de fermer son ordinateur : ces obstacles arrivent avant la première ligne de HCL, et ils découragent au moment où l'on devrait être en train d'expérimenter.

Or apprendre Terraform, c'est surtout répéter. Écrire, appliquer, se tromper, recommencer. Une boucle qui coûte quelques centimes et deux minutes d'attente est une boucle qu'on n'ose pas parcourir vingt fois dans la soirée. Ici, elle est gratuite et instantanée, et c'est ce qui change la façon d'apprendre.

Prérequis

Terraform 1.7 ou plus récent, ou OpenTofu.
feint 0.13.0, et un premier lab réussi.

Rien d'autre. Si vous n'avez pas encore fait tourner l'émulateur une première fois, commencez par le guide des premiers pas : celui-ci suppose que feint start fonctionne déjà chez vous.

La boucle d'apprentissage

Démarrer l'émulateur et brancher le client, une fois pour toute la session de travail.
Fenêtre de terminal
```
feint start
eval "$(feint env scaleway)"
```
Écrire une configuration avec une variable et un output. Ces deux notions arrivent tôt dans tout apprentissage, et elles se voient mieux sur un exemple qu'on peut relancer que dans une définition.
```
variable "nom" {
  type        = string
  default     = "web"
  description = "Nom du serveur"
}

resource "scaleway_instance_ip" "web" {}

resource "scaleway_instance_server" "web" {
  name  = var.nom
  type  = "DEV1-S"
  image = "ubuntu_jammy"
  ip_id = scaleway_instance_ip.web.id
}

output "adresse" {
  value = scaleway_instance_ip.web.address
}
```
La ligne qui compte pédagogiquement est ip_id = scaleway_instance_ip.web.id : elle ne se contente pas de passer une valeur, elle crée une dépendance. Terraform en déduit seul qu'il faut créer l'adresse avant le serveur.

Appliquer, et lire l'output.

terraform apply

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

adresse = "203.0.113.2"

Regarder l'état, qui est le concept que les débutants découvrent le plus tard alors qu'il explique presque tout.
Fenêtre de terminal
```
terraform state list
```
```
scaleway_instance_ip.web
scaleway_instance_server.web
```
L'état est la mémoire de Terraform : ce qu'il croit avoir créé, et sous quel nom. C'est en le comparant au monde réel qu'il décide quoi faire.
Modifier une variable, et lire le plan avant d'appliquer.
Fenêtre de terminal
```
terraform plan -var 'nom=web-02'
```
```
  ~ update in-place
  ~ resource "scaleway_instance_server" "web" {
      ~ name = "web" -> "web-02"
Plan: 0 to add, 1 to change, 0 to destroy.
```
Trois informations en quatre lignes : le changement est une modification sur place, il ne concerne qu'une ressource, et rien ne sera détruit. Apprendre à lire ce résumé avant chaque apply est le réflexe le plus utile que vous puissiez prendre, et il vaut aussi bien sur un vrai compte.

Casser, puis réparer

Un apprentissage sans erreur ne prépare à rien. Changez le type du serveur pour une valeur qui n'existe pas :

type = "DEV1-XXL"

terraform apply

Error: cannot change server type: scaleway-sdk-go: could not find server type "DEV1-XXL"

Prenez le temps de lire cette erreur en entier, parce qu'elle vous apprend trois choses. Elle vient du SDK Scaleway, pas de Terraform : c'est le fournisseur qui refuse. Elle nomme la valeur fautive, ce qui n'est pas toujours le cas. Et elle est arrivée à l'apply, pas au plan : Terraform ne pouvait pas savoir que ce type n'existe pas, seule l'API le sait.

Remettez DEV1-S, relancez, et l'infrastructure repart. Vous venez de faire gratuitement ce qui, sur un vrai compte, aurait pu créer une machine facturée à l'heure.

Ce que ce terrain d'entraînement vous apprend vraiment

Les compétences ci-dessous se transposent sans modification sur un vrai compte cloud, parce qu'elles appartiennent à Terraform et non à l'émulateur.

Le langage HCL : blocs, variables, outputs, expressions.
Le graphe de dépendances, et comment une référence le construit.
Le cycle de vie : création, modification sur place, remplacement, destruction.
L'état et sa relation avec le monde réel.
L'idempotence : appliquer deux fois ne doit rien changer la seconde fois.
La lecture d'un plan, qui est la compétence la plus rentable du lot.

Ce qu'il ne vous apprend pas

Les prix et la facturation, qui ne sont simulés nulle part ici.
Les quotas et la capacité réelle d'une zone, qui restent des valeurs de décor.
Les délais : ici une machine passe à l'état démarré immédiatement, là où un vrai cloud prend une minute et fait parfois patienter votre configuration.
Les permissions IAM, l'émulateur acceptant toute identité sans jamais la vérifier.

Aucune de ces limites n'empêche d'apprendre le langage et le modèle. Elles disent seulement à quel moment passer sur un vrai compte : quand vous voudrez apprendre l'exploitation, et non plus l'outil.

Poursuivre avec la formation Terraform

Ce guide vous a donné un terrain d'entraînement, pas un programme. Pour apprendre Terraform dans l'ordre, du langage jusqu'aux modules, à l'état distant et aux environnements, le site propose un parcours complet que vous pouvez désormais suivre sans ouvrir de compte cloud : il suffit de pointer ses exemples sur l'émulateur comme vous venez de le faire.

Formation Terraform : apprendre l'Infrastructure as Code Le parcours complet, de HCL aux modules et à l'état distant, jusqu'aux certifications.

C'est la combinaison qui rend l'apprentissage vraiment gratuit : la formation donne la progression, feint fournit le cloud sur lequel la dérouler.

Prochaines étapes

Tester une vraie stack Passer de deux ressources à une architecture réaliste, avec réseau et base de données.

Environnement reproductible Distribuer votre lab pour que d'autres le rejouent en une commande.

Ce que feint prouve La frontière exacte entre ce qui est vérifié ici et ce qui ne l'est pas.