IaC (2/6) — Terraform : le langage & le provider

L’idée reçue

« Terraform, c’est un outil pour Proxmox / pour AWS / pour le cloud. »

Terraform ne connaît aucune plateforme en particulier. C’est un moteur générique qui parle à des plateformes via des providers — des plugins « traducteurs ». Le même Terraform gère Proxmox, AWS, Azure, GitHub, Cloudflare… Comprendre ça, c’est comprendre pourquoi ce que tu apprends ici te servira partout.

On travaille depuis la VM mgmt (là où vivent déjà ton code et Git). Terraform y sera installé, et pilotera Proxmox à distance via son API.

À la fin de ce module, tu sauras…

Installer Terraform et vérifier son fonctionnement
Expliquer ce qu’est un provider et pourquoi il rend Terraform universel
Écrire un bloc terraform, provider et resource en HCL
Préparer l’accès à l’API Proxmox (token) et lancer terraform init

01Installer Terraform

Expérience 1

Le binaire, sur mgmt

Manipule

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update &amp;&amp; sudo apt install -y terraform
terraform version

Observe

Terraform v1.x.x
on linux_amd64

Tu reconnais la « chaîne de confiance » de la Phase 3 (clé GPG + dépôt signé) : les bons réflexes se réutilisent. Terraform est un binaire unique, sans service ni agent.

Comprends un outil client, pas un serveur

Terraform n’est pas un service qui tourne en permanence : c’est un outil en ligne de commande que tu lances quand tu veux appliquer des changements. Il lit tes fichiers, parle aux APIs, puis se termine. Pas de démon, pas d’agent sur les machines cibles — contrairement à ce qu’on pourrait croire.

02Le concept central : le provider

Avant d’écrire quoi que ce soit, LE concept à intégrer : Terraform ne sait rien faire seul. Toute son action passe par un provider.

Comprends le provider, un traducteur d’API

Le cœur de Terraform ne connaît que des concepts génériques : ressources, état, dépendances, plan. Un provider est un plugin qui traduit ces concepts vers l’API d’une plateforme précise. bpg/proxmox traduit vers l’API Proxmox ; hashicorp/aws vers AWS ; hashicorp/azurerm vers Azure. Change le provider, et le même Terraform pilote une autre plateforme — la logique (plan, state, apply) ne change pas. C’est exactement ce qui rend Terraform universel : tu apprends un moteur, pas un outil mono-plateforme.

03Préparer l’accès à Proxmox (API token)

Expérience 2

Une identité pour Terraform sur Proxmox

Terraform doit s’authentifier auprès de l’API Proxmox. Dans l’interface Proxmox : Datacenter → Permissions → API Tokens, crée un token pour un utilisateur dédié (ex. terraform@pve), avec les droits de gérer des VMs. Note l’ID du token et son secret.

Moindre privilège, encore. Comme le robot Harbor (Phase 4) et le ServiceAccount Jenkins (Phase 6), Terraform reçoit une identité dédiée et limitée, jamais le compte root. Un token révocable, avec juste les droits nécessaires.

Comprends le pattern récurrent d’identité machine

Tu retrouves partout le même schéma : chaque outil automatisé a sa propre identité machine, à droits restreints, avec un secret stocké hors du code. Harbor robot, Jenkins ServiceAccount, et maintenant Terraform token Proxmox : c’est un principe de sécurité universel, pas une spécificité d’un outil.

04Tes premiers fichiers HCL

Expérience 3

terraform, provider, resource

Crée un dossier de travail et un fichier main.tf :

Manipule

mkdir -p ~/iac-soria &amp;&amp; cd ~/iac-soria

Dans main.tf — le bloc qui déclare le provider Proxmox :

Manipule

terraform {
required_providers {
  proxmox = {
    source  = "bpg/proxmox"
    version = "~> 0.66"
  }
}
}

provider "proxmox" {
endpoint  = "https://192.168.10.2:8006/"
api_token = var.proxmox_api_token
insecure  = true
}

Deux blocs, deux rôles : terraform{} déclare quel provider utiliser (et sa version) ; provider “proxmox”{} le configure (où est l’API, comment s’authentifier).

Comprends l’anatomie, bloc par bloc

required_providers : Terraform ira télécharger bpg/proxmox depuis le registre. version = “~> 0.66” : accepte les versions 0.66.x compatibles (on épingle pour éviter les surprises — prends la dernière version stable compatible avec ton Proxmox). source désigne le provider ; endpoint/api_token le configurent. Sur AWS, ce bloc deviendrait source = “hashicorp/aws” avec region et des clés — même structure, autre traducteur.

05La variable pour le secret

Expérience 4

Ne jamais coder un secret en dur

Crée variables.tf :

Manipule

variable "proxmox_api_token" {
type      = string
sensitive = true
}

Et un fichier terraform.tfvars (à ne jamais committer — ajoute-le au .gitignore) :

Manipule

proxmox_api_token = "terraform@pve!mon-token=xxxxxxxx-xxxx-xxxx"

Comprends variables & sensitive

Une variable paramètre ta configuration sans coder les valeurs en dur. sensitive = true empêche Terraform d’afficher la valeur dans ses sorties. Le secret vit dans terraform.tfvars, exclu de Git — même principe que les credentials Jenkins ou les Secrets Kubernetes : le secret n’entre jamais dans le dépôt.

06terraform init

Expérience 5

Initialiser le projet

Manipule

terraform init

Observe

Initializing provider plugins...
- Installing bpg/proxmox v0.66.x...
- Installed bpg/proxmox (signed by a HashiCorp partner)
Terraform has been successfully initialized!

Terraform a téléchargé le provider déclaré et préparé le dossier de travail (un sous-dossier .terraform/ est apparu). Le projet est prêt à décrire des ressources.

Comprends ce que fait init, précisément

terraform init lit required_providers, télécharge les plugins depuis le registre, et les verrouille dans un fichier .terraform.lock.hcl (pour que toute l’équipe utilise les mêmes versions). C’est toujours la première commande d’un projet Terraform, quel que soit le provider. Rien n’est encore créé sur Proxmox : on a juste préparé l’outillage.

✓Ce que tu retiens

Terraform est un moteur générique ; ce sont les providers (plugins traducteurs d’API) qui lui permettent de parler à Proxmox, AWS, Azure… La configuration s’écrit en HCL : terraform{} (quels providers), provider{} (comment s’y connecter), variables pour les secrets. terraform init télécharge les providers — première commande de tout projet. Change le provider, la logique reste.

Mini-projet

Un projet Terraform initialisé

À faire

Installe Terraform sur mgmt et vérifie sa version.
Crée un token API Proxmox dédié à Terraform (droits limités).
Écris main.tf (provider Proxmox) et variables.tf, avec le secret dans terraform.tfvars (gitignoré).
Lance terraform init et prouve l’installation du provider.
Documente dans BookStack : le rôle d’un provider, et ce que fait init.

Fil rouge — Ton projet est initialisé, mais tu n’as encore rien créé. Avant de lancer apply, il faut comprendre comment Terraform pense : au module suivant, on décortique plan et state — le cœur du raisonnement de Terraform, identique sur toutes les plateformes.

?Auto-évaluation

1. Qu’est-ce qu’un provider Terraform ?

Un plugin qui traduit les concepts génériques de Terraform vers l’API d’une plateforme précise (Proxmox, AWS…). C’est ce qui rend Terraform universel.

2. À quoi sert terraform init ?

À télécharger les providers déclarés et préparer le dossier de travail. C’est toujours la première commande d’un projet.

3. Pourquoi mettre le token dans une variable sensible et un tfvars gitignoré ?

Pour ne jamais coder de secret en dur ni le committer : le secret reste hors du dépôt, comme pour tous les outils du projet.