Providers, resources et data sources dans Terraform

Tout projet Terraform repose sur trois concepts : le provider (la connexion à une API), la resource (ce que Terraform crée), et la data source (ce que Terraform lit sans créer). Comprendre la distinction entre ces trois briques suffit pour lire et écrire n’importe quel projet Terraform.

Ce que vous allez apprendre

Ce qu’est un provider : le plugin qui connecte Terraform à une API (libvirt, AWS, GitHub…)
Déclarer une resource : la syntaxe resource "type" "nom" et ses attributs
Utiliser une data source : lire une ressource existante sans la créer
Référencer entre ressources : libvirt_volume.disk.path et la gestion des dépendances

Les providers : la connexion à une API

Un provider est un plugin qui permet à Terraform de communiquer avec une technologie particulière. Il traduit vos déclarations HCL en appels API.

Il en existe des centaines : libvirt, AWS, Azure, GCP, Kubernetes, GitHub, Cloudflare, Vault…

Déclarer un provider

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

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

Deux blocs distincts :

required_providers (dans terraform {}) : déclare la source du provider et sa contrainte de version. Obligatoire.
provider "nom" {} : configure le provider (URL, région, credentials…). Optionnel si les valeurs par défaut conviennent.

Le Terraform Registry

Les providers sont publiés sur le Terraform Registry. C’est là que Terraform les télécharge lors de terraform init.

Pour trouver le source d’un provider : namespace/nom. Exemples :

hashicorp/aws
dmacvicar/libvirt
hashicorp/kubernetes

Providers multiples

Un projet peut utiliser plusieurs providers simultanément :

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

Les resources : ce que Terraform crée

Une resource représente un objet d’infrastructure que Terraform gère : une VM, un réseau, un disque, un bucket, un enregistrement DNS…

Syntaxe d’une resource

resource "TYPE" "NOM_LOCAL" {
  attribut1 = valeur1
  attribut2 = valeur2
}

TYPE : identifie le provider et le type d’objet (ex: libvirt_domain, aws_instance, kubernetes_deployment).
NOM_LOCAL : nom interne au projet Terraform, utilisé pour référencer la resource ailleurs dans le code. Il n’apparaît pas dans l’infrastructure.

Exemple avec libvirt

resource "libvirt_volume" "disk_ubuntu" {
  name = "ubuntu-01.qcow2"
  pool = "default"
  target = {
    format = { type = "qcow2" }
  }
  create = {
    content = {
      url = "/home/bob/images/ubuntu-24.04-cloudimg.img"
    }
  }
}

resource "libvirt_domain" "vm_web" {
  name        = "web-01"
  type        = "kvm"
  memory      = 1024
  memory_unit = "MiB"
  vcpu        = 2

  devices = {
    disks = [
      {
        source = {
          file = { file = libvirt_volume.disk_ubuntu.path }
        }
        target = { dev = "vda", bus = "virtio" }
      }
    ]
    interfaces = [
      {
        model  = { type = "virtio" }
        source = { network = { network = "default" } }
      }
    ]
  }
}

Référencer une resource depuis une autre

Pour utiliser un attribut d’une resource dans une autre, la syntaxe est :

TYPE.NOM_LOCAL.ATTRIBUT

Dans l’exemple ci-dessus :

file = libvirt_volume.disk_ubuntu.path

Terraform comprend automatiquement la dépendance : il créera libvirt_volume.disk_ubuntu avant libvirt_domain.vm_web.

Les data sources : lire sans créer

Une data source permet de lire des informations sur une ressource qui existe déjà — sans la créer ni la gérer.

Cas d’usage typiques :

Récupérer l’ID d’un réseau existant pour y connecter une VM
Lire une AMI AWS par ses critères (plutôt que son ID qui change)
Consulter un secret dans Vault

Syntaxe d’une data source

data "TYPE" "NOM_LOCAL" {
  filtre = valeur
}

Exemple : lire un pool libvirt existant

data "libvirt_pool" "images" {
  name = "default"
}

resource "libvirt_volume" "disk" {
  name = "test.qcow2"
  pool = data.libvirt_pool.images.name
  # ...
}

La syntaxe pour référencer une data source :

data.TYPE.NOM_LOCAL.ATTRIBUT

Résumé visuel

Relation entre provider, resource et data source dans Terraform

Les attributs calculés

Certains attributs d’une resource ne sont connus qu’après création (adresse IP, ID généré, chemin de volume…). Dans le plan, ils s’affichent ainsi :

+ id   = (known after apply)
+ path = (known after apply)

On peut quand même les utiliser dans d’autres resources — Terraform résout les dépendances automatiquement.

À retenir

Un provider est un plugin qui connecte Terraform à une API. Il se déclare dans required_providers et se configure dans provider {}.
Une resource est un objet créé et géré par Terraform. Elle est référencée par TYPE.NOM.ATTRIBUT.
Une data source lit un objet existant sans le créer ni le modifier. Ses valeurs sont stockées dans le state, mais terraform destroy ne détruit pas l’objet distant. Référence : data.TYPE.NOM.ATTRIBUT.
Les dépendances entre resources sont résolues automatiquement dès qu’on référence un attribut d’une resource depuis une autre.

Prochaines étapes

Structure d'un projet Terraform Comment répartir providers, resources et data sources dans les bons fichiers.

Déclaratif vs impératif Pourquoi Terraform décrit un état final plutôt que des étapes à exécuter.

La CLI Terraform Les commandes du quotidien : init, fmt, validate, plan, apply, state.