Hiera

Fiche express
Type	Backend de données hiérarchisées pour Puppet
Rôle	Séparer les données de la logique des manifests
Formats	YAML, JSON (eyaml pour les données chiffrées)
Voir aussi	Puppet · Augeas

Hiera est le système de recherche de données hiérarchisées utilisé par Puppet. Il sépare les données propres à chaque nœud ou groupe de nœuds (valeurs de paramètres de classes, listes de classes à inclure...) de la logique du code Puppet, en les stockant dans des fichiers plats (YAML par défaut) organisés selon une hiérarchie de recherche configurable.

Principe

Hiera interroge une série de sources (la « hiérarchie ») dans un ordre défini, de la plus spécifique (par nœud) à la plus générale (commune à tous), et retourne la première valeur trouvée pour une clé donnée — ou fusionne les valeurs de plusieurs niveaux selon le type de recherche demandé (priorité, fusion de tableaux, fusion de hash).

Configuration

Fichier hiera.yaml :

:backends:
  - yaml
:yaml:
  :datadir: /etc/puppet/hieradata
:hierarchy:
  - "node/%{::fqdn}"
  - common

• backends : format(s) de stockage des données (yaml, json...).
• yaml.datadir : répertoire racine des fichiers de données.
• hierarchy : ordre de recherche. Avec l'exemple ci-dessus :
  • "node/%{::fqdn}" → /etc/puppet/hieradata/node/<fqdn-du-client>.yaml
  • common → /etc/puppet/hieradata/common.yaml

Utilisation en ligne de commande

Pour interroger Hiera hors d'un run Puppet (pratique pour déboguer une hiérarchie) :

ln -s /etc/puppet/hiera.yaml /etc/hiera.yaml

$ hiera ntp::servers ::fqdn=exemple-client.exemple.com
$ hiera classes ::fqdn=exemple-client.exemple.com
["ntp", "apache", "postfix"]

$ hiera vmwaretools::working_dir osfamily=RedHat
$ hiera vmwaretools::version
$ hiera classes ::virtual=vmware

Assignation de classes

Historiquement, l'assignation de classes à des nœuds pouvait se faire directement dans site.pp :

node "kermit.example.com", "grover.example.com", "snuffie.example.com" {
  include ntp
  # ou : class { "ntp": }
}

L'approche recommandée avec Hiera consiste plutôt à déclarer les classes à inclure directement dans les données, via hiera_include dans site.pp :

hiera_include('classes')

puis, dans le fichier de données du nœud ou du groupe concerné :

classes:
  - ntp
  - apache
  - postfix

ntp::restrict: []
ntp::autoupdate: false
ntp::enable: true
ntp::servers:
  - 0.pool.ntp.org iburst
  - 1.pool.ntp.org iburst
  - 2.pool.ntp.org iburst
  - 3.pool.ntp.org iburst

(correction par rapport à la source : ntp::restrict: suivi d'un tiret seul sur la ligne suivante définit en YAML une liste contenant un élément nul, pas une liste vide ; la notation [] exprime sans ambiguïté une liste vide.)

Cette approche « les données pilotent le code » évite de modifier site.pp à chaque changement de périmètre et facilite la revue des différences entre environnements (diff sur des fichiers de données plutôt que sur du code Puppet).

Voir aussi

• Puppet — outil de gestion de configuration consommant les données Hiera
• Augeas — édition ciblée de fichiers de configuration, souvent invoqué depuis Puppet