Les grains Salt : faits système et grains personnalisés

Un parc n'est jamais homogène : distributions différentes, rôles variés. Les grains sont la réponse de Salt : des faits collectés côté minion qui décrivent chaque machine, exploitables pour cibler et brancher vos déploiements. Ce module apprend à déployer automatiquement selon le système d'exploitation et le rôle. Public visé : intermédiaires ayant pratiqué states et pillars.

Ce que vous allez apprendre

• Lire les grains système d'un minion.
• Définir des grains personnalisés (rôle, environnement).
• Cibler et brancher des states selon les grains.

Prérequis

• Savoir écrire des states et connaître le ciblage.

Les grains système

Au démarrage, chaque minion collecte des dizaines de faits : os, os_family, osrelease, cpuarch, mem_total, fqdn, adresses IP. Ces grains système sont disponibles partout, dans le ciblage comme dans les states. La fonction grains.item en lit une sélection :

salt 'web1' grains.item os os_family osrelease cpuarch

web1:
    ----------
    cpuarch:
        x86_64
    os:
        Debian
    os_family:
        Debian
    osrelease:
        13

grains.items affiche tout, grains.get os_family renvoie une seule valeur. Ces faits pilotent ensuite les décisions : grains['os_family'] dans un state permet de choisir le bon paquet ou le bon chemin selon la distribution.

Les grains personnalisés

Les grains système décrivent la machine, mais pas son rôle métier. On ajoute alors des grains personnalisés : role: web, environnement: prod. Ils se définissent dans le fichier /etc/salt/grains du minion, dans sa configuration, ou dynamiquement. Ce sont eux qui rendent un top file lisible et un ciblage stable.

# /etc/salt/grains sur le minion
role: web
environnement: prod

Après modification, un salt 'web1' saltutil.sync_grains ou un redémarrage du minion recharge les grains. On les relit comme les autres :

salt 'web1' grains.get role

web1:
    web

Les grains ne sont pas un coffre-fort

Les grains vivent dans des fichiers locaux du minion (/etc/salt/grains ou sa configuration) : toute personne ayant accès à la machine peut les modifier. Deux conséquences directes. D'abord, n'y stockez jamais de secret (mot de passe, clé, jeton) : ces données appartiennent aux pillars. Ensuite, ne ciblez pas un pillar sensible par grain dans le top file des pillars : un minion pourrait forger son grain (role et consorts) pour se faire servir des données qui ne le concernent pas. Ciblez ces pillars par identifiant ou nom de minion.

Cibler par grain

Le drapeau -G sélectionne les minions par grain. Un grain de rôle vise une fonction métier ; un grain système vise une famille de machines. Sur un parc où seul un serveur porte le rôle web :

salt -G 'role:web' test.ping

web1:
    True

Le même mécanisme avec un grain système rassemble toute une famille d'OS, ici trois machines Debian :

salt -G 'os_family:Debian' test.ping

proxy1:
    True
web1:
    True
db1:
    True

C'est ce ciblage qui remplace les exceptions machine par machine : vous décrivez une intention (« les serveurs web », « les hôtes Debian »), pas une liste.

Cas pratique : un serveur web selon l'OS

Assemblons les deux idées. Un state unique installe le bon serveur web selon la famille d'OS du minion, grâce à grains['os_family'] évalué en Jinja. Sur une machine Debian il posera apache2, sur une machine RedHat httpd, sans que vous ayez à écrire une exception.

{# le paquet du serveur web dépend de la famille d'OS du minion #}
{% set pkg = "apache2" if grains["os_family"] == "Debian" else "httpd" %}

serveur_web:
  pkg.installed:
    - name: {{ pkg }}
  service.running:
    - name: {{ pkg }}
    - enable: true
    - require:
      - pkg: serveur_web

À l'application sur une cible Debian, Salt résout pkg en apache2, installe le paquet et démarre le service :

salt db1 state.apply webserver

          ID: serveur_web
    Function: pkg.installed
        Name: apache2
      Result: True
     Changes:   ...
----------
          ID: serveur_web
    Function: service.running
        Name: apache2
      Result: True

Summary for db1
------------
Succeeded: 2 (changed=1)
Failed:    0

Prouver l'idempotence

Un state correct ne change rien s'il est rejoué sur un système déjà conforme. Le second passage le vérifie :

salt db1 state.apply webserver

        Name: apache2
     Comment: All specified packages are already installed
        Name: apache2
     Comment: The service apache2 is already running
Succeeded: 2
Failed:    0

changed=1 au premier passage, aucun changement au second : le state est idempotent. La preuve côté machine confirme le résultat :

salt db1 cmd.run 'systemctl is-active apache2'

db1:
    active

Grain de rôle ou pillar ?

Le rôle est un fait non secret qui sert au ciblage : c'est un bon grain. Un mot de passe est une donnée sensible : c'est un pillar. Ne mélangez pas les deux responsabilités.

Dépannage

Symptôme	Cause probable	Solution
Un grain personnalisé n'apparaît pas	Grains non rechargés	salt '<minion>' saltutil.sync_grains ou redémarrer le minion
-G 'role:web' ne cible personne	Grain absent ou mal orthographié	Vérifier /etc/salt/grains et grains.get role
grains['os_family'] lève une erreur en Jinja	Grain inexistant sur la cible	Utiliser grains.get('os_family', 'Debian') avec repli

Glissez pour voir

À retenir

1. Les grains sont des faits du minion, collectés à son démarrage.
2. Les grains système (os_family, osrelease) adaptent le déploiement à la machine.
3. Les grains personnalisés (role, environnement) rendent ciblage et top file lisibles.
4. Le drapeau -G cible les minions par grain, système ou personnalisé.
5. Fait non secret pour le ciblage : grain. Donnée sensible : pillar.

Prochaines étapes

Les pillars Servir des données par minion, y compris les secrets, depuis le master.

Jinja dans Salt Brancher un state sur les grains avec variables, conditions et boucles.

Les states Revoir SLS, top file et requisites, la base que les grains ciblent.

×

📖 Voir la documentation →