TP 28 : Ajouter des validations et des contrôles

TP 28 : Ajouter des validations et des contrôles

Objectifs

À l’issue de ce TP, vous serez capable de :

• valider une variable en entrée avec un bloc validation ;
• garantir une hypothèse avant création avec precondition ;
• garantir un résultat après création avec postcondition ;
• surveiller un invariant sans bloquer l’apply avec un bloc check ;
• choisir le bon mécanisme selon le moment du cycle de vie.

Prérequis

• Terraform >= 1.5 (les blocs check sont disponibles depuis la 1.5 ; precondition/postcondition depuis la 1.2).
• Le provider random suffit pour la partie sans coût ; AWS pour l’exemple data source.

Contexte

Les configurations d’InfraBank ont provoqué des incidents « stupides » : une taille de sous-réseau incohérente, un environnement mal saisi, une AMI inexistante. Objectif : faire échouer tôt et clairement, plutôt que tard et confusément.

Étape 1 : Validation d’une variable

Le bloc validation s’exécute dès la saisie des variables, avant tout plan.

variables.tf

variable "environment" {
  type        = string
  description = "Environnement cible."

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "environment doit valoir dev, staging ou prod."
  }
}

variable "instance_count" {
  type = number

  validation {
    condition     = var.instance_count >= 1 && var.instance_count <= 10
    error_message = "instance_count doit être compris entre 1 et 10."
  }
}

variable "cidr_block" {
  type = string

  validation {
    condition     = can(cidrhost(var.cidr_block, 0))
    error_message = "cidr_block doit être un CIDR valide (ex. 10.0.0.0/16)."
  }
}

La fonction can(...) capture les erreurs d’une expression et renvoie un booléen : idéale pour valider un format.

terraform plan -var='environment=qa' -var='instance_count=1' -var='cidr_block=10.0.0.0/16'
# Erreur claire : environment doit valoir dev, staging ou prod.

Étape 2 : precondition (hypothèse avant création)

Une precondition vérifie une hypothèse avant de créer/mettre à jour une ressource. Exemple : refuser une AMI qui n’est pas en état available.

main.tf

data "aws_ami" "app" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-*-x86_64"]
  }
}

resource "aws_instance" "app" {
  ami           = data.aws_ami.app.id
  instance_type = "t3.micro"

  lifecycle {
    precondition {
      condition     = data.aws_ami.app.state == "available"
      error_message = "L'AMI sélectionnée n'est pas disponible."
    }
  }
}

La precondition échoue avant toute tentative de création si l’hypothèse n’est pas tenue.

Étape 3 : postcondition (garantie sur le résultat)

Une postcondition valide une propriété après création, sur les attributs calculés. Exemple : s’assurer que l’instance a bien reçu une IP privée dans le CIDR attendu.

resource "aws_instance" "app" {
  ami           = data.aws_ami.app.id
  instance_type = "t3.micro"

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

Dans une postcondition, self désigne la ressource elle-même. Si la condition est fausse après apply, Terraform signale l’erreur et marque l’apply en échec.

Étape 4 : bloc check (surveillance non bloquante)

Un bloc check exprime un invariant de niveau configuration, indépendant d’une ressource. Contrairement aux pre/postconditions, un check en échec n’interrompt pas l’apply : il émet un avertissement. Idéal pour un contrôle de santé ou une bonne pratique non critique.

checks.tf

check "cidr_assez_grand" {
  assert {
    condition     = pow(2, 32 - tonumber(split("/", var.cidr_block)[1])) >= 256
    error_message = "Le CIDR fournit moins de 256 adresses : prévoir plus large."
  }
}

On peut aussi combiner un check avec une data source dédiée (par exemple interroger un endpoint de santé) : le check valide alors l’état réel sans casser le déploiement.

Étape 5 : Choisir le bon mécanisme

Mécanisme	Moment	Effet en échec	Usage type
validation	saisie des variables	bloque (erreur)	format/plage d’une entrée
precondition	avant création d’une ressource	bloque (erreur)	hypothèse requise
postcondition	après création d’une ressource	bloque (erreur)	garantie sur le résultat
check	après le plan / l’apply	avertit (n’interrompt pas)	invariant, santé, bonne pratique

Étape 6 : Éprouver les contrôles

# Variable invalide -> échec immédiat
terraform plan -var='environment=qa' -var='instance_count=1' -var='cidr_block=10.0.0.0/16'

# CIDR trop petit -> avertissement du bloc check, pas de blocage
terraform plan -var='environment=dev' -var='instance_count=1' -var='cidr_block=10.0.0.0/25'

Vérification

• Une variable hors domaine produit une erreur explicite avant le plan.
• Une hypothèse non tenue (AMI indisponible) stoppe la création.
• Un check en échec produit un avertissement sans interrompre l’apply.

Nettoyage

terraform destroy -auto-approve