Conditions personnalisées Terraform : validation, precondition, postcondition et check

Comment refuser une taille d'instance trop petite avant le plan ? Comment vérifier qu'une instance a bien reçu une IP après sa création ? Comment surveiller la santé d'un service sans faire échouer l'apply ? Ces trois questions appellent trois dispositifs différents, et Terraform en a un quatrième par-dessus.

Terraform offre quatre niveaux de validation : la validation de variable, la precondition, la postcondition et le bloc check. Ils se ressemblent à l'écrit, mais un seul n'arrête pas l'opération. Savoir lequel mettre où, et lequel bloque, est le sous-objectif d'examen 2a, et c'est le trou le plus fréquent en préparation.

Tous les exemples de ce guide ont été exécutés sur Terraform v1.15.4 avant publication, résultats compris.

Ce que vous allez apprendre

• validation : refuser une entrée avant le plan, y compris en croisant deux variables
• precondition : refuser une hypothèse avant la création (et le piège de count = 0)
• postcondition : refuser un résultat après la création, avec self
• check : surveiller sans bloquer, et pourquoi il fait sortir plan -detailed-exitcode en 2
• Le tableau checks de show -json : le verdict des quatre en un appel machine

Prérequis

• Terraform 1.15 ou plus récent (installer Terraform). Les blocs check datent de 1.5, la validation croisée de 1.9.
• Variables et lifecycle maîtrisés (variables, lifecycle).

validation : refuser une entrée avant le plan

Dans un bloc variable, un bloc validation refuse une valeur d'entrée avant tout plan. Sa condition est un booléen, son error_message s'affiche quand elle est fausse. Depuis Terraform 1.9, la condition peut référencer une autre variable, ce qu'on appelle une validation croisée :

variable "replicas" {
  type = number
  validation {
    condition     = var.replicas <= var.replicas_max
    error_message = "replicas ne peut pas dépasser replicas_max."
  }
}

precondition : refuser une hypothèse avant la création

Dans un bloc lifecycle, une precondition vérifie une hypothèse au moment du plan, avant que la ressource soit créée :

resource "aws_instance" "web" {
  # ...
  lifecycle {
    precondition {
      condition     = var.instance_type != "t2.nano"
      error_message = "t2.nano est trop petit pour ce rôle."
    }
  }
}

Le piège de count = 0

Une precondition est évaluée par instance. Sur une ressource en count = 0, il n'y a aucune instance : la précondition n'est jamais évaluée, et le plan passe. Ne comptez pas sur une précondition pour garder un invariant quand le nombre d'instances peut tomber à zéro.

postcondition : refuser un résultat après la création

Toujours dans lifecycle, une postcondition vérifie le résultat après la création. Elle est la seule à disposer de self, l'objet créé :

    postcondition {
      condition     = self.private_ip != ""
      error_message = "L'instance n'a pas reçu d'IP privée."
    }

C'est la différence de fond avec la précondition : la précondition garde une entrée (connue au plan), la postcondition garde une sortie (connue après l'apply). Les deux bloquent l'opération quand leur condition est fausse.

check : surveiller sans bloquer

Un bloc check de niveau racine surveille un invariant. Contrairement aux trois précédents, un assert en échec n'arrête pas l'apply : il produit un avertissement, pas une erreur. C'est fait pour des vérifications de continuité de service qu'on ne veut pas bloquantes.

check "sante_http" {
  data "http" "home" {
    url = "https://${aws_instance.web.public_ip}/"
  }
  assert {
    condition     = data.http.home.status_code == 200
    error_message = "La home ne répond pas 200."
  }
}

Un check peut contenir un data source scopé, comme ici. Point à connaître : ce data source est relu à chaque plan, donc il apparaît toujours en action read dans le plan.

check et plan -detailed-exitcode

Un check avec un data source scopé fait sortir terraform plan -detailed-exitcode en 2 (« des changements »), même sur une configuration convergée, car le data source est relu à chaque plan. Une chaîne d'intégration continue qui décide sur ce code retour croira toujours qu'il reste des changements. Le plan JSON le confirme : la seule entrée non no-op de resource_changes est ce data source, en action read.

Lire le verdict des quatre : le tableau checks

terraform show -json expose un tableau checks de premier niveau. Chaque entrée porte un address.kind et un status :

address.kind	Dispositif	Bloque ?
var	validation de variable	oui
resource	precondition / postcondition	oui
output_value	precondition d'un output	oui
check	bloc check	non, avertit

Glissez pour voir

Un check en échec porte son message dans instances[].problems[].message. C'est la preuve machine des quatre niveaux, sans jamais lire une sortie humaine :

terraform show -json | jq '.checks[] | {kind: .address.kind, status}'

Le dernier piège : validate ne joue pas ces conditions

terraform validate contrôle la forme de la configuration, pas les valeurs. Il ne connaît pas les valeurs des variables, donc il rend valid: true sur une entrée que le plan refusera :

terraform validate -json          # valid: true, error_count: 0
terraform plan -var replicas=99   # Error: Invalid value for variable

validate est un contrôle de syntaxe et de références, utile en pré-commit ; il ne remplace jamais un plan pour valider les valeurs.

À retenir

• validation (variable) refuse une entrée avant le plan ; depuis 1.9 elle peut croiser deux variables.
• precondition garde une hypothèse avant création, mais n'est pas évaluée si count = 0.
• postcondition garde un résultat après création ; seule elle a self.
• Ces trois-là bloquent ; le bloc check avertit seulement.
• Un check avec data source scopé fait sortir plan -detailed-exitcode en 2 sur une config pourtant convergée.
• Le tableau checks de show -json donne le verdict des quatre ; validate ne joue aucune de ces conditions.

FAQ : questions fréquentes

Les questions ci-dessous portent sur ce qui bloque le plus souvent : quel niveau choisir, pourquoi une précondition ne se déclenche pas, et pourquoi un plan annonce des changements sur une configuration stable. Chaque réponse donne la commande de vérification correspondante.

Quelle différence entre precondition et postcondition ?

La precondition garde une hypothèse AVANT la création, évaluée au plan ; la postcondition garde un résultat APRÈS la création. La postcondition est la seule à disposer de self, l'objet créé. Les deux vivent dans lifecycle et bloquent l'opération.

Pourquoi ma precondition ne se déclenche pas ?

Parce que la ressource est probablement en count = 0 : une precondition est évaluée par instance, et sans instance elle n'est jamais jouée. Le plan passe alors sans erreur. Vérifiez que la ressource a au moins une instance quand vous comptez sur sa precondition.

Un bloc check bloque-t-il l'apply ?

Non. Le bloc check est le seul des quatre niveaux qui ne bloque pas : un assert en échec produit un avertissement, pas une erreur, et l'apply réussit quand même. Il sert à surveiller la continuité de service sans arrêter l'opération.

Pourquoi plan -detailed-exitcode rend 2 sur une config stable ?

Parce qu'un bloc check contient souvent un data source scopé, relu à chaque plan par construction. Ce read est vu comme un changement, donc plan -detailed-exitcode rend 2 même sans ajout ni modification. Une CI qui décide sur ce code croira toujours qu'il reste des changements.

terraform validate joue-t-il les validations ?

Non. terraform validate contrôle la forme et les références, pas les valeurs : il ne connaît pas les valeurs des variables. Il rend valid: true sur une entrée que le plan refusera. Utilisez validate en pré-commit, mais jamais à la place d'un plan pour valider les valeurs.

Une validation de variable peut-elle référencer une autre variable ?

Oui, depuis Terraform 1.9. Une validation croisée permet à la condition d'un bloc validation de référencer une autre variable, par exemple var.taille_lot <= var.taille_max. Avant 1.9, une validation ne pouvait référencer que sa propre variable.

Comment voir le résultat des quatre niveaux d'un coup ?

Avec le tableau checks de terraform show -json. Chaque entrée porte un address.kind (var, resource, output_value, check) et un status (pass ou fail). Un check en échec porte son message dans instances problems message. C'est la preuve machine des quatre niveaux.

Pour aller plus loin

• Le bloc lifecycle : ou vivent precondition et postcondition, avec les autres garde-fous de la ressource.
• Les outputs Terraform : la precondition d'un output, pour garantir une sortie de module.
• Tester un module Terraform : ce que terraform test prouve, la ou une condition ne suffit plus.
• Custom conditions : la reference officielle : les quatre niveaux et leurs messages.
• Format JSON du plan : le tableau checks, verdict machine des quatre niveaux.

×

📖 Voir la documentation →