Les providers Terraform : connecter l'infrastructure

Vous écrivez resource "libvirt_domain" "vm" et Terraform bloque immédiatement : il ne sait pas ce qu’est libvirt_domain. Sans provider, Terraform est un moteur sans pièces : il sait orchestrer, pas interagir avec les APIs.

Les providers sont des plugins compilés qui traduisent les blocs HCL en appels API vers une plateforme cible — libvirt, AWS, Kubernetes, GitHub. Chaque provider expose ses propres types de ressources et data sources. Déclarer un provider dans required_providers, épingle sa version et garantit la reproductibilité : le même terraform init donne le même résultat sur toutes les machines de l’équipe. Le fichier .terraform.lock.hcl enregistre le hash exact du provider téléchargé — c’est lui qu’on commite dans Git pour éviter les “ça marchait hier”.

Ce que vous allez apprendre

• Comprendre le rôle d’un provider et du registry
• Déclarer required_providers dans le bloc terraform {}
• Configurer le bloc provider {} : URI, région, credentials
• Contraintes de version : ~>, >=, = — choisir la bonne
• terraform init : ce qui se passe lors du téléchargement
• .terraform.lock.hcl : verrouiller les versions pour la reproductibilité
• terraform providers : inspecter les providers actifs

Prérequis

• Terraform ≥ 1.11 installé (installer Terraform)
• Compréhension du workflow init/plan/apply (le workflow Terraform)

L’idée derrière les providers

Pensez à un système d’exploitation et ses drivers matériels :

# Windows sans driver GPU → impossible de contrôler la carte graphique
# Windows + driver NVIDIA → le système peut enfin interagir avec le GPU

Terraform sans provider c’est pareil : c’est un moteur sans plugin pour interagir avec rien. Un provider est un plugin qui traduit vos instructions HCL en appels API vers une plateforme (AWS, libvirt, Kubernetes, etc.).

Analogie

Un provider Terraform c’est comme un driver : c’est ce qui permet au système (Terraform) de communiquer avec la plateforme cible (libvirt, AWS, Azure).

Rôle d’un provider

Un provider est un plugin compilé qui traduit les blocs HCL en appels API vers une plateforme cible. Terraform lui-même ne connaît aucune infrastructure concrète — il délègue entièrement aux providers.

Configuration HCL  →  Terraform Core  →  Provider plugin  →  API plateforme

Les providers sont publiés sur le registry public : registry.terraform.io. On y trouve des providers officiels (HashiCorp), partenaires (AWS, Google, Azure…) et communautaires (libvirt, OVH, Scaleway…).

Déclarer les providers requis

La déclaration se fait dans le bloc terraform {}, dans versions.tf :

versions.tf

terraform {
  required_version = ">= 1.11.0"

  required_providers {
    libvirt = {
      source  = "dmacvicar/libvirt"
      version = "~> 0.8"
    }
  }
}

Chaque entrée dans required_providers a trois champs :

Champ	Rôle	Exemple
clé locale	Alias utilisé dans le code HCL	libvirt
source	Adresse complète sur le registry	"dmacvicar/libvirt"
version	Contrainte de version	"~> 0.8"

Glissez pour voir

La source suit le format namespace/type. Pour les providers officiels HashiCorp (aws, azurerm, google…), le préfixe hashicorp/ est implicite. Pour les communautaires, il est obligatoire.

Contraintes de version

Opérateur	Signification	Exemple	Résolution
~> 0.8	Toute 0.x ≥ 0.8, mais pas 1.0	~> 0.8	0.8, 0.9, 0.9.7…
~> 0.9.0	Toute 0.9.x, mais pas 0.10	~> 0.9.0	0.9.0, 0.9.7…
>= 1.0	Toute version ≥ 1.0	>= 1.0	1.0, 2.5, 3.0…
= 0.9.7	Exactement 0.9.7	= 0.9.7	0.9.7 uniquement
>= 0.8, < 1.0	Plage explicite	—	0.8.x, 0.9.x

Glissez pour voir

~> (pessimistic constraint) est le plus courant : il autorise les patches et mineures mais bloque les breaking changes majeurs.

Quelle contrainte choisir ?

• Providers stables et établis (AWS, azurerm) → ~> 5.0 (majeure fixée)
• Providers communautaires actifs → ~> 0.9 (mineure fixée)
• Reproduction exacte d’un environnement → = 0.9.7

À retenir

required_providers épingle la version du provider. terraform init télécharge la version spécifiée et enregistre le hash exact dans .terraform.lock.hcl — c’est ce fichier qu’on commite pour garantir la reproductibilité.

Configurer le provider

Le bloc provider {} fournit la configuration d’authentification et de connexion. Placez-le en général dans providers.tf :

providers.tf

provider "libvirt" {
  uri = "qemu:///system"
}

Pour un provider cloud, les paramètres sont différents :

# Exemple AWS (non testé dans ce lab)
provider "aws" {
  region = "eu-west-3"
  # Les credentials viennent de ~/.aws/credentials ou des variables d'env
}

Credentials et sécurité

Ne jamais écrire de mot de passe, token ou clé API directement dans providers.tf. Utilisez des variables d’environnement, un fichier ~/.aws/credentials, Vault ou un autre gestionnaire de secrets.

terraform init : ce qui se passe

Lors de l’exécution de terraform init, Terraform :

1. Lit required_providers dans versions.tf
2. Interroge registry.terraform.io pour résoudre la version
3. Télécharge le binaire du provider dans .terraform/providers/
4. Crée ou met à jour .terraform.lock.hcl

$ terraform init

Initializing provider plugins...
- Finding dmacvicar/libvirt versions matching "~> 0.8"...
- Installing dmacvicar/libvirt v0.9.7...
- Installed dmacvicar/libvirt v0.9.7 (self-signed, key ID 0833E38C51E74D26)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

Le dossier .terraform/ est local à chaque poste. Il ne doit pas être commité (ajoutez .terraform/ à votre .gitignore).

Le fichier .terraform.lock.hcl

Ce fichier enregistre la version exacte résolue et les checksums du provider :

.terraform.lock.hcl

# Maintenu automatiquement par "terraform init". Ne pas modifier manuellement.

provider "registry.terraform.io/dmacvicar/libvirt" {
  version     = "0.9.7"
  constraints = "~> 0.8"
  hashes = [
    "h1:vdMblF3sJkstxm2zXE1z/0Hije42plcpynyDmqqjuD4=",
    "zh:0892a2581f460333a8c140cc53110a1675657200cbd2a49d9f4667bc238d0098",
    # ...
  ]
}

Il doit être commité dans le dépôt. Il garantit que tous les membres de l’équipe et tous les pipelines CI/CD utilisent exactement la même version du provider, quelle que soit la contrainte déclarée.

Pour mettre à jour le lock file après avoir changé la contrainte de version :

terraform init -upgrade

Pour régénérer les hashes pour d’autres plateformes (utile en CI) :

terraform providers lock -platform=linux_amd64 -platform=darwin_arm64

Résultat :

- Fetching dmacvicar/libvirt 0.9.7 for linux_amd64...
- Obtained dmacvicar/libvirt checksums for linux_amd64; All checksums for
  this platform were already tracked in the lock file

Success! Terraform has validated the lock file and found no need for changes.

Inspecter les providers actifs

La commande terraform providers affiche les providers requis par la configuration et par le state :

$ terraform providers

Providers required by configuration:
.
└── provider[registry.terraform.io/dmacvicar/libvirt] ~> 0.8


Providers required by state:

    provider[registry.terraform.io/dmacvicar/libvirt]

Après un apply, les deux sections sont présentes : configuration et state. Avant tout apply, seule la section “configuration” apparaît.

Plusieurs providers dans une configuration

Une configuration peut utiliser plusieurs providers simultanément :

versions.tf

terraform {
  required_providers {
    libvirt = {
      source  = "dmacvicar/libvirt"
      version = "~> 0.8"
    }
    local = {
      source  = "hashicorp/local"
      version = "~> 2.5"
    }
  }
}

Provider alias (plusieurs instances)

Pour utiliser le même provider avec des configurations différentes (deux régions AWS, deux hyperviseurs libvirt…), on utilise l’alias :

provider "libvirt" {
  alias = "srv1"
  uri   = "qemu+ssh://srv1.local/system"
}

provider "libvirt" {
  alias = "srv2"
  uri   = "qemu+ssh://srv2.local/system"
}

resource "libvirt_volume" "disk_srv1" {
  provider = libvirt.srv1
  name     = "disk-srv1.qcow2"
  pool     = "default"
}

Récapitulatif des fichiers providers

projet/
├── versions.tf    ← bloc terraform { required_providers {} }
├── providers.tf   ← bloc provider {} (config, credentials)
├── .terraform/    ← binaires téléchargés (dans .gitignore)
└── .terraform.lock.hcl  ← versions verrouillées (à commiter)

À retenir

1. Un provider est un plugin qui traduit HCL en appels API d’une plateforme
2. required_providers dans versions.tf déclare le provider et sa contrainte
3. ~> (pessimistic constraint) est le plus courant — il bloque les breaking changes
4. terraform init télécharge le provider et crée .terraform.lock.hcl
5. .terraform.lock.hcl doit être commité — c’est notre garantie de reproductibilité
6. .terraform/ ne doit pas être commité — il est régénéré par terraform init
7. terraform providers liste les providers actifs en configuration et en state

Prochaines étapes

Déclarer des ressources Créer des ressources Terraform avec le bloc resource {} et ses meta-arguments.

Votre première infrastructure Créer une VM KVM avec Terraform : le premier lab complet de A à Z.

×

📖 Voir la documentation →