Bonnes pratiques Salt : GitFS, environnements et tests

Tant que vos states vivent dans /srv/salt sur le master, rien ne trace qui a changé quoi, et un fichier édité à la main part directement en production. Ce module industrialise ce socle : les states servis depuis Git avec GitFS, chaque branche devenant un environnement Salt, et des contrôles automatiques (salt-lint, state.show_sls) avant toute application. Public visé : intermédiaires et avancés prêts à passer du lab à une exploitation sérieuse.

Ce que vous allez apprendre

• Servir les states depuis Git avec GitFS.
• Faire d'une branche Git un environnement Salt.
• Linter vos states avec salt-lint.
• Vérifier le rendu d'un SLS avant de l'appliquer.

Prérequis

• Avoir pratiqué states et pillars, et connaître Git.

Le dépôt, avant tout

Un projet Salt sain repose sur une séparation simple : l'arbre des states (/srv/salt) et celui des pillars (/srv/pillar), chacun avec son top file. On regroupe les states par service, avec une hiérarchie qui se lit comme une table des matières : un lecteur devine le contenu de mysql/server.sls avant de l'ouvrir.

• Répertoiresrv/salt/

  • top.sls
  • Répertoiremysql/

    • init.sls
    • conf.sls
  • Répertoirenginx/

    • init.sls
    • conf.sls

Trois règles structurent ces fichiers, chacune détaillée dans un module dédié : l'installation va dans init.sls et la configuration dans un conf.sls séparé (voir Les states) ; les valeurs qui changent selon la distribution vivent dans un map.jinja ; et les secrets restent en pillar chiffré, jamais en grain ni en state versionné.

Tout cela ne vaut cependant que si le dépôt est la source de vérité. C'est précisément ce que GitFS impose.

GitFS : servir les states depuis Git

GitFS fait du master un client Git : au lieu de lire des fichiers posés à la main dans /srv/salt, il récupère les states depuis un dépôt. Le changement de nature est important. Modifier la production ne consiste plus à éditer un fichier sur le master, mais à pousser un commit. Vous héritez gratuitement de l'historique, de la relecture en merge request et du rollback de Git.

La configuration tient en quelques lignes côté master :

/etc/salt/master.d/gitfs.conf

fileserver_backend:
  - gitfs
  - roots

gitfs_provider: gitpython
gitfs_base: main
gitfs_remotes:
  - file:///srv/gitfs/salt.git

gitfs_base désigne la branche qui alimente l'environnement base, ici main. Le backend roots est conservé en second : le master continue de servir /srv/salt si un fichier n'est pas trouvé dans Git, ce qui permet une migration progressive. Après modification, redémarrez le master, puis forcez une synchronisation :

sudo salt-run fileserver.update

Le dépôt doit appartenir à l'utilisateur du master

Le salt-master tourne sous l'utilisateur salt, pas sous root. Si le dépôt appartient à un autre compte, Git refuse de l'ouvrir avec fatal: detected dubious ownership in repository et GitFS reste vide sans que rien ne le signale côté client. Donnez le dépôt au master :

sudo chown -R salt:salt /srv/gitfs/salt.git

Le top file de Git supplante celui de /srv/salt

Conséquence directe et coûteuse à découvrir : dès que le dépôt Git contient un top.sls, c'est lui qui fait autorité, même si /srv/salt/top.sls existe encore. Les states déclarés uniquement dans le top file local ne sont plus appliqués, sans le moindre message d'erreur. Migrez le top file en premier, et vérifiez ce qu'un minion reçoit réellement :

sudo salt web1 state.show_top

Une branche, un environnement

C'est la propriété la plus utile de GitFS : chaque branche du dépôt devient un environnement Salt. Une branche dev crée un environnement dev, sans aucune configuration supplémentaire. Le master les liste :

sudo salt-run fileserver.envs

- base
- dev

Le même state, appliqué depuis deux environnements différents, sert alors le contenu de la branche correspondante. Ici, un state motd qui pose une bannière, appliqué depuis l'environnement base (branche main) :

sudo salt web1 state.apply motd saltenv=base
sudo salt web1 cmd.run 'cat /etc/motd.d/banniere'

web1:
    Configuration servie depuis Git (environnement base).

Puis exactement la même commande, depuis l'environnement dev :

sudo salt web1 state.apply motd saltenv=dev
sudo salt web1 cmd.run 'cat /etc/motd.d/banniere'

web1:
    Configuration servie depuis Git (environnement dev).

Le state n'a pas changé de nom, seule la branche qui le sert diffère. Vous tenez là un cycle de promotion naturel : on développe sur dev, on teste avec saltenv=dev, puis on fusionne dans main pour que la production (l'environnement base) reçoive le changement. La promotion devient une merge request, avec sa relecture et sa trace.

La revue de code s'applique enfin à l'infrastructure

Sans GitFS, un vim sur le master suffit à changer la production. Avec GitFS, il faut pousser une branche, la faire relire, puis la fusionner. La discipline devient structurelle au lieu de reposer sur la bonne volonté de chacun.

Tester avant d'appliquer

Un state fautif ne se voit pas au commit, il se voit en production. Trois contrôles, faciles à mettre en CI, l'évitent.

salt-lint : attraper les fautes de style et les pièges

salt-lint analyse les fichiers SLS et signale les écarts aux bonnes pratiques. Il attrape notamment le piège classique du mode non quoté, que YAML interpréterait comme un entier décimal au lieu d'une valeur octale :

salt-lint mauvais.sls

[207] File modes should always be encapsulated in quotation marks
mauvais.sls:7
    - mode: 0644

[210] Numbers that start with '0' should always be encapsulated in quotation marks
mauvais.sls:7
    - mode: 0644

Une fois le mode corrigé en "0644", l'outil ne renvoie rien et sort avec un code 0, ce qui rend le pipeline vert. C'est exactement le comportement attendu d'un linter en CI : silencieux quand tout va bien, bloquant sinon.

state.show_sls : le SLS se rend-il vraiment

Un SLS peut être syntaxiquement propre et échouer au rendu : un pillar absent, une variable Jinja indéfinie, une boucle qui produit du YAML invalide. state.show_sls rend le state sans l'appliquer et montre le résultat compilé :

sudo salt web1 state.show_sls motd saltenv=base

web1:
    ----------
    /etc/motd.d/banniere:
        ----------
        __env__:
            base
        __sls__:
            motd
        file:
            ...

Deux informations précieuses ici. Le state se rend (donc il compilera à l'application), et le champ __env__ confirme quel environnement l'a servi, ce qui lève tout doute quand plusieurs branches coexistent.

test=True : la simulation avant l'application

Le dernier filet reste le mode simulation. test=True exécute le highstate sans rien modifier et affiche ce qui changerait. C'est le réflexe à prendre avant chaque application sensible :

sudo salt 'web*' state.apply test=True

Ces trois contrôles se chaînent naturellement dans un pipeline : salt-lint sur les fichiers modifiés, state.show_sls pour vérifier le rendu, puis test=True sur un environnement de recette avant la fusion vers main.

Dépannage

Symptôme	Cause probable	Solution
fatal: detected dubious ownership in repository	Le dépôt n'appartient pas à l'utilisateur du master	chown -R salt:salt sur le dépôt, puis salt-run fileserver.update
fileserver.envs ne montre que base	GitFS n'a pas encore récupéré les branches	Forcer salt-run fileserver.update et vérifier les logs du master
GitFS reste vide sans erreur côté client	Le backend roots masque le problème	Interroger salt-run fileserver.file_list backend=gitfs
salt-lint introuvable	Installé hors de l'environnement Python courant	L'installer dans un venv dédié (Debian bloque les installs système)
Un changement ne remonte pas aux minions	Cache du fileserver	salt-run fileserver.update puis réappliquer

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. GitFS fait du master un client Git : la production ne se modifie plus à la main, elle se pousse en commit.
2. Chaque branche Git devient un environnement Salt, ciblé par saltenv=. La promotion devient une merge request.
3. Le dépôt doit appartenir à l'utilisateur salt, sinon GitFS reste silencieusement vide.
4. salt-lint attrape les pièges classiques (mode non quoté) et bloque la CI avec un code de sortie non nul.
5. state.show_sls prouve que le SLS se rend et révèle l'environnement qui l'a servi (__env__).
6. test=True reste le dernier filet : simuler avant d'appliquer.

×

📖 Voir la documentation →