Variables et valeurs nommées HCL

Les valeurs nommées rendent un fichier HCL réutilisable. Sans elles, vous répétez des chaînes en dur, des noms de projet, des listes de paquets ou des options de build partout. Avec elles, vous paramétrez une seule fois puis vous réutilisez proprement la valeur dans tout le fichier.

Le point important est le suivant : HCL fournit la syntaxe des expressions et des références, mais la nature exacte des valeurs nommées disponibles dépend de l’outil. Terraform et Packer ont beaucoup en commun, sans être identiques.

Les deux familles à connaître en premier

Dans la plupart des usages, commencez par distinguer deux familles :

les variables d’entrée, accessibles via var.nom ;
les valeurs locales, accessibles via local.nom.

Les premières servent à recevoir une valeur venant de l’extérieur. Les secondes servent à calculer ou centraliser une valeur dérivée dans le code.

Variables d’entrée

Une variable d’entrée déclare un paramètre configurable.

Exemple Terraform :

variable "environment" {
  type    = string
  default = "dev"
}

Exemple Packer :

variable "image_tag" {
  type    = string
  default = "3.20"
}

Dans les deux cas, l’accès se fait ensuite avec var.environment ou var.image_tag.

Valeurs locales

Une valeur locale sert à éviter la répétition et à donner un nom à un calcul.

Exemple Terraform :

locals {
  vm_name = "${var.environment}-web"
}

Exemple Packer :

locals {
  full_image = "${var.base_image}:${var.image_tag}"
}

Dans les deux cas, la référence devient local.vm_name ou local.full_image.

Ce qui dépend de l’outil

La syntaxe var. et local. est familière dans plusieurs outils, mais les autres valeurs nommées varient.

Dans Terraform

Vous rencontrerez aussi souvent :

les attributs de ressources ;
les data sources ;
les outputs de modules.

Autrement dit, les expressions Terraform peuvent référencer beaucoup plus d’objets liés à l’infrastructure décrite.

Dans Packer

Les cas les plus courants tournent surtout autour de :

var. pour les paramètres du build ;
local. pour les calculs intermédiaires ;
les blocs source et build qui consomment ces valeurs.

Le schéma est différent, car Packer décrit un workflow de construction d’image et non une infrastructure cible à maintenir dans le temps.

Typage et validation

Les variables d’entrée acceptent en général un type explicite, souvent le même vocabulaire HCL dans Terraform et Packer :

variable "labels" {
  type = map(string)
}

Le détail des types est traité dans Types et collections HCL. L’idée clé ici est plus simple : une valeur nommée devient beaucoup plus sûre quand son type est clairement déclaré.

Valeur d’entrée ou calcul local ?

Voici la règle pratique la plus utile :

si la valeur doit changer selon l’environnement, le pipeline ou l’utilisateur, faites-en une variable d’entrée ;
si la valeur est dérivée d’autres valeurs et n’a pas vocation à être fournie de l’extérieur, faites-en un local.

Exemple :

variable "project" {
  type = string
}

variable "environment" {
  type = string
}

locals {
  full_name = "${var.project}-${var.environment}"
}

project et environment viennent de l’extérieur. full_name est un calcul interne.

À retenir

var. sert aux entrées configurables.
local. sert aux calculs et aux valeurs dérivées.
Le langage HCL fournit la syntaxe, mais les autres familles de valeurs nommées dépendent de Terraform ou de Packer.
Mieux vaut typer une valeur d’entrée clairement que laisser l’intention implicite.

Prochaines étapes

Types et collections HCL Pour choisir correctement string, map, object, list ou tuple

Fonctions HCL Pour transformer ces valeurs sans dupliquer des expressions partout

Variables Terraform Le prolongement concret si vous travaillez surtout dans Terraform

Variables et fonctions Packer Le bon prolongement si vous paramétrez surtout des templates Packer