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é les states et le ciblage.

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. La syntaxe {% ... %} est le gabarit Jinja, détaillé au module 7 ; retenez ici seulement qu'elle lit un grain pour décider. 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

Plutôt que d'installer réellement un second serveur web sur une machine du parc, simulons le rendu avec test=True : Salt résout le grain, montre ce qu'il ferait, sans rien modifier. C'est le réflexe à prendre avant toute application.

sudo salt web1 state.apply webserver test=True

          ID: serveur_web
    Function: pkg.installed
        Name: apache2
      Result: None
     Comment: The following packages would be installed/updated: apache2
----------
          ID: serveur_web
    Function: service.running
        Name: apache2
      Result: None
     Comment: Service apache2 not present; if created in this state run, it would have been started

Le Result: None et le conditionnel « would be installed » confirment que le grain os_family de web1 (Debian) a bien été résolu en apache2 : sur une machine RedHat, le même state aurait affiché httpd. Rien n'est installé, la cible reste intacte. C'est ce branchement par grain qui remplace les exceptions machine par machine.

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

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À 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.

×

📖 Voir la documentation →