TP 26 : Gérer les versions et .terraform.lock.hcl

TP 26 : Gérer les versions et .terraform.lock.hcl

Objectifs

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

• contraindre la version de Terraform avec required_version ;
• contraindre les versions de providers avec des opérateurs adaptés (~>, >=, =) ;
• lire et interpréter .terraform.lock.hcl (hashes, plateformes) ;
• mettre à jour les providers avec terraform init -upgrade ;
• rendre le lock file portable sur plusieurs OS avec terraform providers lock.

Prérequis

• Terraform >= 1.5.
• Accès réseau au registre Terraform.

Contexte

Sur les projets d’InfraBank, un provider mis à jour silencieusement sur un poste a introduit une divergence de comportement entre développeurs. Le lock file existe précisément pour garantir que toute l’équipe et la CI utilisent les mêmes versions de providers.

Étape 1 : Contraindre la version de Terraform

versions.tf

terraform {
  required_version = ">= 1.5, < 2.0"
}

required_version empêche un apply avec une version de Terraform incompatible. Les opérateurs se combinent : ici, toute 1.x à partir de 1.5, mais pas la 2.0.

Étape 2 : Contraindre les providers

terraform {
  required_providers {
    random = {
      source  = "hashicorp/random"
      version = "~> 3.5"
    }
    null = {
      source  = "hashicorp/null"
      version = "~> 3.2"
    }
  }
}

Rappel des opérateurs :

• = 3.5.1 : version exacte.
• >= 3.5 : au moins 3.5.
• ~> 3.5 : « pessimiste », équivaut à >= 3.5, < 4.0 (autorise les correctifs et mineures, bloque la majeure suivante).
• ~> 3.5.1 : équivaut à >= 3.5.1, < 3.6.0.

Pour des ressources de production, ~> sur la mineure est un bon compromis entre stabilité et correctifs.

Étape 3 : Générer le lock file

terraform init
cat .terraform.lock.hcl

Vous obtenez, pour chaque provider, un bloc de ce type :

provider "registry.terraform.io/hashicorp/random" {
  version     = "3.5.1"
  constraints = "~> 3.5"
  hashes = [
    "h1:...",
    "zh:...",
    ...
  ]
}

Analyse :

• version : la version exacte réellement sélectionnée.
• constraints : la contrainte issue du code.
• hashes : empreintes des paquets provider. Elles garantissent l’intégrité : si un paquet téléchargé ne correspond pas à un hash, init échoue.
  • zh: = hash du zip officiel (par plateforme).
  • h1: = hash indépendant de la plateforme (schéma h1).

Le lock file doit être versionné dans Git : c’est lui qui fige les versions pour toute l’équipe.

Étape 4 : Observer le rôle du lock file

Modifiez la contrainte pour autoriser une version plus récente, sans mettre à jour le lock :

random = {
  source  = "hashicorp/random"
  version = "~> 3.6"
}

terraform init

Tant que la version verrouillée satisfait la nouvelle contrainte, Terraform la conserve. Le lock file prime : il ne bouge pas de lui-même.

Étape 5 : Mettre à jour avec init -upgrade

Pour prendre les dernières versions autorisées par les contraintes :

terraform init -upgrade
cat .terraform.lock.hcl | grep -A1 'version'

-upgrade recalcule les versions dans la limite des contraintes et réécrit le lock file. Vérifiez le diff en revue de code : c’est là qu’on décide sciemment de monter de version.

git diff .terraform.lock.hcl

Étape 6 : Rendre le lock file portable (multi-plateforme)

Par défaut, init n’enregistre les hashes que pour la plateforme courante. En équipe hétérogène (Linux, macOS, CI), ajoutez les plateformes cibles :

terraform providers lock \
  -platform=linux_amd64 \
  -platform=darwin_arm64 \
  -platform=darwin_amd64 \
  -platform=windows_amd64

Le lock file contient désormais les hashes de toutes ces plateformes : un collègue sur macOS ARM et la CI sous Linux valident le même fichier sans erreur d’intégrité.

Vérification

• .terraform.lock.hcl existe et est prêt à être committé.
• terraform init sans -upgrade conserve les versions verrouillées.
• terraform init -upgrade fait bien évoluer le lock file dans la limite des contraintes.
• Le lock contient les hashes des plateformes ciblées.

Nettoyage

rm -rf .terraform