Déclarer des ressources Terraform : bloc resource et cycle de vie

Le bloc resource est la brique de base de Terraform : il déclare un objet à créer et à maintenir. Le déclarer est simple. Ce qui compte vraiment, et ce que l'examen interroge, c'est de savoir lire, avant d'appliquer, ce que Terraform va faire à cette ressource : la créer, la mettre à jour en place, la remplacer, ou la détruire.

Ce guide part de la base, la syntaxe et l'adressage, puis montre comment les références ordonnent les ressources, et enfin comment lire les quatre opérations du cycle de vie dans le plan au format JSON. Les exemples ont été vérifiés sur Terraform v1.15.4 avec local, random et terraform_data, sans cloud.

Ce que vous allez apprendre

• La syntaxe d'un bloc resource : type, nom, arguments
• Pourquoi le couple type + nom est l'adresse dans le state
• Comment une référence ordonne les ressources, sans depends_on
• Les quatre opérations du cycle de vie, et leur signature dans le plan
• terraform_data, la ressource intégrée sans provider
• Lire le plan et le state de façon structurée (-json)

Prérequis

• Providers et premiers pas (providers, resources et data sources)
• Terraform 1.15.x, la série stable courante

Qu'est-ce qu'un bloc resource ?

Un bloc resource déclare un objet que Terraform crée, met à jour et détruit. Sa syntaxe tient en trois parties :

resource "local_file" "rapport" {
  filename = "rapport.txt"
  content  = "bonjour"
}

• local_file est le type, fourni par un provider (ici local). Une exception : terraform_data est un type intégré, il n'appartient à aucun provider.
• rapport est le nom local.
• Le corps contient les arguments de l'objet.

On référence la ressource par local_file.rapport, et ses attributs par local_file.rapport.<attribut>.

L'adresse est la clé du state

Le couple type + nom n'est pas qu'un alias de code : c'est l'adresse de la ressource dans le fichier d'état. La documentation le dit : « Terraform uses the resource type and name as the resource's address in your workspace's state file. »

La conséquence est concrète et surprend souvent : renommer une ressource détruit l'objet et le recrée, parce que Terraform voit l'ancienne adresse disparaître et une nouvelle apparaître. Pour renommer sans détruire, il faut un bloc moved, traité dans le lab de migration for_each.

Les références ordonnent les ressources

Quand une ressource référence un attribut d'une autre, Terraform en déduit l'ordre. C'est la dépendance implicite, et elle suffit dans l'immense majorité des cas :

resource "random_pet" "hote" {
  length = 2
}

resource "local_file" "fiche" {
  filename = "fiche-${random_pet.hote.id}.txt"
  content  = "hote=${random_pet.hote.id}\n"
}

local_file.fiche référence random_pet.hote.id : Terraform crée l'hôte, puis la fiche. Aucun depends_on n'est nécessaire, et en ajouter un ici serait redondant. Le meta-argument depends_on ne sert qu'aux dépendances de comportement qu'aucune référence ne peut exprimer : voir depends_on en Terraform.

Les quatre opérations du cycle de vie

Voici le cœur du sujet, et ce que l'examen interroge. Terraform ne fait que quatre choses à une ressource, et chacune a une signature dans le plan JSON.

Opération	actions dans le plan
Créer	["create"]
Mettre à jour en place	["update"]
Remplacer (détruire puis créer)	["delete", "create"]
Détruire	["delete"]

Glissez pour voir

Une cinquième valeur, ["no-op"], signale qu'il n'y a rien à faire. Tout le sujet consiste à distinguer une mise à jour en place d'un remplacement : l'une modifie l'objet, l'autre le recrée.

Le montage de démonstration

Ce petit montage suffit à provoquer les deux opérations qui comptent, une mise à jour en place et un remplacement, sans aucun provider distant :

variable "niveau" {
  type    = string
  default = "beta"
}

variable "cycle" {
  type    = number
  default = 1
}

resource "random_pet" "serie" {
  length  = 2
  keepers = { cycle = var.cycle }
}

resource "terraform_data" "jeton" {
  input            = var.niveau
  triggers_replace = random_pet.serie.id
}

terraform_data est une ressource intégrée qui offre le cycle de vie complet sans aucun provider : son argument input se met à jour en place, et triggers_replace force un remplacement quand la valeur suivie change.

Lire une mise à jour en place

Changez le niveau. L'argument input change, mais rien n'impose de recréer :

terraform apply -auto-approve
terraform plan -var 'niveau=stable' -out=tfplan
terraform show -json tfplan | jq -c '.resource_changes[] | select(.address=="terraform_data.jeton") | .change.actions'

["update"]

["update"] : l'objet est modifié, pas recréé. C'est le cas le moins coûteux.

Lire un remplacement

Changez le cycle. Les keepers en dépendent, donc random_pet.serie est remplacé, son id change, et le triggers_replace du jeton déclenche à son tour un remplacement :

terraform plan -var 'cycle=2' -out=tfplan
terraform show -json tfplan | jq -c '.resource_changes[] | select(.address=="terraform_data.jeton") | .change.actions'

["delete", "create"]

["delete", "create"] : détruit puis recréé. Ce n'est pas anodin, l'objet est neuf. Pour inverser cet ordre et supprimer la fenêtre où l'objet n'existe plus, c'est create_before_destroy, traité dans le bloc lifecycle Terraform.

Toujours lire le plan avant d'appliquer

La différence entre ["update"] et ["delete", "create"] est la différence entre une modification indolore et la recréation d'un objet. Sur une base de données ou un volume, elle change tout. Le plan JSON la donne avant l'apply, là où la sortie humaine peut se lire trop vite.

Inspecter le plan et le state de façon fiable

terraform state list et terraform state show produisent une sortie humaine, pratique à lire mais non contractuelle. Pour un script ou un contrôle, seules les formes structurées sont stables :

terraform show -json | jq '.values.root_module.resources[] | {address, mode}'
terraform plan -detailed-exitcode          # 0 = aucun changement, 2 = des changements
terraform output -json

terraform plan -detailed-exitcode rend 0 quand la configuration est stable, 2 quand des changements restent à appliquer : c'est le test d'idempotence de tout workflow en automation.

Provisioners : en dernier recours

Un bloc provisioner exécute une commande locale ou distante lors de la création ou de la destruction. La documentation officielle le déconseille : « We recommend using configuration management tools or other means to perform actions on the local or remote machine instead of using the provisioner block. » Réservez-le aux cas qu'aucune ressource de provider ne couvre.

Dépannage

Ces symptômes se lisent tous dans le plan, avant l'apply. Le tableau associe chaque signature d'action à ce qu'elle signifie réellement.

Symptôme	Cause	Solution
Une ressource est remplacée alors qu'on attendait une mise à jour	Un attribut modifié ne peut pas être changé en place	Normal si l'API distante l'impose ; le plan montre ["delete", "create"]
Une ressource est détruite puis recréée après un simple renommage	Le nom fait partie de l'adresse dans le state	Utiliser un bloc moved pour renommer sans détruire
Invalid single-argument block definition	Un bloc mono-ligne à deux arguments	Écrire le bloc en multi-lignes, un argument par ligne
Resource already exists	L'objet existe hors de Terraform	L'importer avec un bloc import {}
Un depends_on ajouté ne change rien	Il double une référence déjà présente	Le supprimer : la référence ordonne déjà

Glissez pour voir

À retenir

1. Un bloc resource a un type (du provider, sauf terraform_data) et un nom local.
2. Le couple type + nom est l'adresse dans le state : renommer détruit et recrée, sauf bloc moved.
3. Une référence ordonne les ressources ; depends_on n'est qu'un dernier recours.
4. Terraform ne fait que quatre opérations, chacune avec sa signature : ["create"], ["update"], ["delete", "create"], ["delete"].
5. Distinguer mise à jour en place et remplacement est le point clé, et le plan JSON le donne avant l'apply.
6. terraform_data offre le cycle de vie complet sans provider.
7. Les formes -json et plan -detailed-exitcode sont les seules stables pour un contrôle.

FAQ : questions fréquentes

Les questions ci-dessous reprennent les points qui reviennent le plus souvent : l'adresse comme clé du state, le choix entre référence et depends_on, et la lecture des opérations dans le plan.

Quelle est la syntaxe d'un bloc resource Terraform ?

Un bloc resource porte un type fourni par un provider, un nom local, et des arguments. On le référence par type.nom, et ses attributs par type.nom.attribut. Le type terraform_data est la seule exception : il est intégré et n'appartient à aucun provider.

Pourquoi renommer une ressource la détruit-elle et la recrée-t-elle ?

Parce que le couple type + nom est l'adresse de la ressource dans le state. En renommant, Terraform voit l'ancienne adresse disparaître et une nouvelle apparaître : il détruit puis recrée. Le bloc moved permet de renommer sans détruire.

Faut-il un depends_on quand une ressource en référence une autre ?

Non. Quand une ressource référence un attribut d'une autre, Terraform en déduit l'ordre : c'est la dépendance implicite, suffisante dans la grande majorité des cas. Ajouter depends_on par-dessus est redondant et rend le plan plus conservateur.

Quelles sont les quatre opérations du cycle de vie d'une ressource ?

Créer, mettre à jour en place, remplacer (détruire puis créer), et détruire. Chacune a une signature dans le plan JSON : create, update, delete puis create, et delete. Une cinquième valeur, no-op, signale qu'il n'y a rien à faire.

Comment savoir si une ressource sera mise à jour en place ou remplacée ?

En lisant le tableau resource_changes[].actions du plan au format JSON, avant d'appliquer. La valeur update signale une mise à jour en place, delete puis create un remplacement. La sortie humaine peut se lire trop vite, le JSON tranche.

À quoi sert la ressource terraform_data ?

Elle offre le cycle de vie complet sans aucun provider. Son argument input se met à jour en place quand il change, triggers_replace force un remplacement quand la valeur suivie change, et son attribut calculé output rend la valeur. Elle sert aussi de relais pour replace_triggered_by.

Comment inspecter le state de façon fiable dans un script ?

Avec les formes structurées : terraform show -json pour le state et le plan, terraform output -json pour les sorties, terraform plan -detailed-exitcode pour l'idempotence. Les sorties de state list et state show sont humaines et non contractuelles.

Pour aller plus loin

• Les expressions Terraform : Explique comment une ressource se référence et comment les types se convertissent.
• depends_on : les dépendances explicites : Ajoute une dépendance quand aucune référence ne l'exprime.
• Le bloc lifecycle : Détaille les sept règles qui pilotent création, remplacement et destruction.

×

📖 Voir la documentation →