Le principe
Terraform est déclaratif : tu décris l'état voulu (une VM, un réseau, un DNS), Terraform compare avec l'existant et calcule les actions pour y arriver. Le langage s'appelle HCL et les fichiers finissent en .tf.
Structure d'un projet
| Fichier | Rôle |
|---|---|
main.tf | Les ressources |
providers.tf | Les providers et leurs versions |
variables.tf | Les entrées paramétrables |
outputs.tf | Les valeurs affichées après l'apply |
terraform.tfvars | Les valeurs des variables (à ne pas commiter s'il y a des secrets) |
Provider et ressource
Le provider est le plugin qui parle à l'API cible (Proxmox, Azure, vSphere…). Une ressource est un objet géré.
providers.tf
terraform {
required_version = ">= 1.6"
required_providers {
local = {
source = "hashicorp/local"
version = "~> 2.5"
}
}
}
main.tf
resource "local_file" "hello" {
filename = "${path.module}/hello.txt"
content = "Bonjour ${var.nom}"
}Variables et outputs
variables.tf
variable "nom" {
type = string
description = "Nom à saluer"
default = "Jocelin"
}
outputs.tf
output "chemin" {
value = local_file.hello.filename
}Le cycle de travail
terraform init # télécharge les providers
terraform fmt # formate les fichiers
terraform validate # vérifie la syntaxe
terraform plan # affiche ce qui va changer
terraform apply # applique (demande confirmation)
terraform destroy # supprime tout ce qui est géré
À retenir
Toujours lire le plan avant l'apply : les lignes avec -/+ signifient destruction puis recréation.
Le state
Terraform enregistre ce qu'il a créé dans terraform.tfstate. C'est sa source de vérité pour faire le lien entre le code et les objets réels.
Attention
Le state peut contenir des secrets en clair. En équipe, on le stocke dans un backend distant avec verrouillage (backend HTTP de GitLab, S3, azurerm) et on ne le commite jamais.
backend.tf
terraform {
backend "http" {} # configuré par la CI GitLab
}