Formation SaltStack : states, pillars et orchestration

Salt (anciennement SaltStack, aujourd'hui porté par le Salt Project) est un outil de gestion de configuration et d'orchestration open source. Il décrit l'état voulu de vos serveurs en YAML + Jinja, l'applique de façon idempotente, et pilote des milliers de nœuds en quasi temps réel grâce à son bus d'événements. Cette formation le prend de zéro, du premier ping à une plateforme complète orchestrée, avec des labs reproductibles sur de simples VM Linux (Debian 13), quel que soit votre hyperviseur ou votre cloud. Public visé : administrateurs systèmes et DevOps, débutants acceptés, à l'aise avec la ligne de commande Linux.

SaltStack, c'est quoi

L'image la plus juste est celle d'une tour de contrôle. Vous n'allez plus sur chaque serveur taper des commandes : vous écrivez une fiche d'état (« ce paquet installé, ce service démarré, ce fichier avec ce contenu »), et la tour se charge de la faire respecter sur les machines concernées, qu'il y en ait trois ou trois mille. C'est la gestion de configuration, et Salt y ajoute l'orchestration : coordonner qui fait quoi, et dans quel ordre.

Sa particularité tient en une phrase : Salt écoute en permanence. Un minion qui redémarre, un disque qui se remplit, un service qui tombe produisent un événement, et Salt sait réagir sans que personne ne lance rien. C'est ce qui le sépare des outils qui se contentent d'appliquer une configuration quand un humain le demande.

SaltStack et Salt désignent la même chose : « SaltStack » était le nom de l'entreprise et du produit, le projet open source s'appelle aujourd'hui Salt, porté par le Salt Project. Vous croiserez les deux noms indifféremment.

Ce que vous allez apprendre

Installer un master et des minions, et lancer votre premier test.ping.
Cibler finement les minions (globbing, grains, matchers) et exécuter des commandes distantes.
Écrire des states déclaratifs et idempotents avec top file, requisites, pillars, grains et Jinja.
Orchestrer un déploiement multi-machines (web + base de données).
Sécuriser les secrets (GPG renderer, Vault) et exploiter Salt en production.

Comment fonctionne Salt, et pourquoi l'apprendre

Salt repose sur une architecture master/minion : un master central envoie des ordres, des minions installés sur chaque serveur les exécutent et renvoient leurs résultats. La communication passe par un bus de messages ZeroMQ rapide, ce qui explique la réputation de Salt sur les grands parcs et l'orchestration temps réel. Salt sait aussi fonctionner sans agent via Salt SSH, à la manière d'Ansible.

Deux notions structurent tout le reste. Les grains sont les faits statiques d'un minion (système d'exploitation, CPU, rôle), collectés côté minion. Les pillars sont des données confidentielles servies par le master, ciblées par minion : c'est là que vivent mots de passe, clés et variables d'environnement. Combinés à Jinja, ils rendent les states génériques et réutilisables.

Un mot que vous croiserez partout : le highstate. C'est l'action d'appliquer d'un coup tous les states qu'une machine doit porter, tels que le top file les lui attribue. C'est la commande que vous taperez le plus souvent, et le moment où Salt compare l'état réel à l'état voulu pour ne corriger que les écarts.

Apprendre Salt reste pertinent en 2026 : la version stable est la série 3008, le packaging onedir est désormais le standard, et de nombreuses organisations exploitent un socle Salt pour la configuration, la conformité et la réaction automatique aux événements via le Reactor.

Le parcours en un coup d'œil

La formation compte 15 modules répartis en 4 volets progressifs, jusqu'à un projet final qui relie Terraform, cloud-init et Salt. Le mieux est de les suivre dans l'ordre : chaque volet s'appuie sur le précédent. Un projet fil rouge court en parallèle sur un petit parc de trois machines (web, base de données, reverse proxy) : au fil des modules vous installez un serveur Nginx déclaratif, servez sa configuration par pillars et grains, puis coordonnez le déploiement web + PostgreSQL avec l'orchestration.

Pour suivre votre avancée leçon par leçon, la page Mon parcours affiche le programme complet avec suivi de progression : les leçons se cochent au fur et à mesure, et vous retrouvez d'un coup d'œil où vous en êtes dans les quatre volets.

Volet 1 · Fondamentaux

Poser l'architecture master/minion, piloter le parc à distance, puis décrire son état de façon déclarative et idempotente.

1. Découvrir Salt Architecture master/minion/SSH, installation, premier ping et commande distante.

2. Les commandes distantes Cibler les minions, grains, matchers, batch et gestion des retours.

3. Les states SLS, highstate, top file, requisites et ordering déclaratif idempotent.

4. Les modules Salt pkg, service, file, user, cron et git pour déployer une application idempotente.

Volet 2 · Données et gabarits

Rendre les states génériques : les faits du minion, les données servies par le master, et les gabarits Jinja qui les combinent.

5. Les grains Faits système et grains personnalisés pour déployer selon la cible.

6. Les pillars Configuration et données sensibles par minion, servies par le master.

7. Jinja Variables, conditions, boucles et macros pour générer une config depuis grains et pillars.

8. Gestion des fichiers file.managed, file.recurse, templates Jinja et rechargement sur changement.

Volet 3 · Orchestrer et réagir

Coordonner un déploiement multi-machines, administrer sans agent, et faire réagir l'infrastructure aux événements.

9. Orchestration Runner, orchestrate et déploiement coordonné multi-machines (base avant web).

10. Salt SSH Administrer des serveurs sans agent par SSH, roster, cas d'usage et limites.

11. Le bus d'événements Beacons et Reactor : un service surveillé qui se relève seul après une panne.

Volet 4 · Industrialiser

Passer du lab à l'exploitation : secrets chiffrés, states servis depuis Git, environnements et tests automatisés.

12. Gestion des secrets Chiffrer les pillars avec le renderer GPG, et savoir quand passer à Vault.

13. Bonnes pratiques GitFS, une branche par environnement, et les tests salt-lint avant d'appliquer.

14. Salt en production Durcir le bus, cadrer les droits avec publisher_acl et eauth, exposer salt-api à la CI.

15. Projet final : une VM née conforme Terraform, cloud-init et autosign : une machine s'enrôle et se configure seule en moins d'une minute.

Salt face à Ansible, Chef et Puppet

Les quatre outils résolvent le même problème avec des philosophies différentes. Ansible est agentless et pilote par SSH en YAML : prise en main rapide. Chef décrit la configuration en Ruby (agent-based). Puppet utilise un DSL déclaratif agent-serveur. Salt combine les deux mondes : un mode master/minion très rapide pour l'orchestration temps réel, et un mode Salt SSH sans agent quand installer un minion n'est pas possible.

Le point fort de Salt tient à son bus d'événements : les minions publient des événements que le Reactor peut transformer en actions automatiques, ce qui permet des architectures réactives difficiles à reproduire ailleurs. Si vous débutez la gestion de configuration, comparez avec la formation Ansible, la formation Chef et le panorama des outils pour choisir en connaissance de cause.

Mon retour d'expérience, pour ceux qui veulent comprendre

Ce qui suit engage un point de vue, libre à vous de le discuter. Il ne sort pas de la documentation : il vient du lab qui sous-tend ces 15 modules, un master et trois minions, où j'ai cassé des services exprès pour voir ce que Salt en faisait, et où j'ai perdu assez d'heures sur des pannes muettes pour vouloir vous les épargner.

Salt a-t-il encore un avenir en 2026

C'est la première question honnête à poser, et l'éluder décrédibiliserait toute la formation. Salt appartient à VMware, racheté par Broadcom fin 2023, ce qui a légitimement inquiété. Ma lecture : le Salt Project reste open source sous Apache 2.0, la communauté publie toujours (série 3008 en 2026, packaging onedir standardisé), et rien n'indique un abandon à court terme.

Je ne vends pas Salt comme le futur par défaut de la gestion de configuration : sur ce terrain, Ansible domine largement le marché et les offres d'emploi. Salt est un choix de niche assumé : on l'adopte pour son bus d'événements et son orchestration temps réel, pas parce que c'est le plus populaire. Si votre seul besoin est de configurer quelques serveurs, Ansible ira plus vite à apprendre. Si vous voulez une infrastructure réactive qui se corrige seule, Salt a des arguments que peu d'outils égalent.

Ce que cette formation défend

Le second passage est non négociable. Un state qui n'est pas rejoué et vérifié idempotent n'est pas terminé. Chaque module de ce parcours le prouve sur un lab réel, jamais sur du pseudo-code.
Les secrets ne vivent jamais dans un grain ni dans un state. Les grains sont modifiables par n'importe qui sur le minion ; les vrais secrets passent par les pillars, et les données sensibles par un renderer chiffré.
cmd.run est un aveu d'échec temporaire. À chaque fois que vous l'écrivez, cherchez d'abord le module dédié (pkg, service, file, user). S'il n'y a pas d'alternative, gardez-le avec unless ou onlyif, jamais nu.
On simule avant d'appliquer. test=True coûte deux secondes et évite de casser un service en production. Ce réflexe vaut pour tous les outils, Salt le rend simple.
Le master est un actif critique, pas un utilitaire. Il détient les pillars, donc tous les secrets du parc, et peut exécuter n'importe quoi partout. Ses ports 4505/4506 se restreignent au réseau d'administration, et publisher_acl cadre qui a le droit d'exécuter quoi. Ce n'est pas une option de fin de projet, c'est la condition pour le mettre en production.

Ce que je vous déconseille

Croire qu'un module désactivé est un module bloqué. J'ai posé disable_modules: [cmd] sur un minion sensible, persuadé d'avoir interdit l'exécution de commandes arbitraires. Le module a continué de répondre. La même directive bloque pourtant bien disk. Un durcissement non vérifié n'est pas un durcissement, c'est une croyance : testez la restriction que vous venez de poser, systématiquement.
Lancer depuis du Jinja une commande qui modifie le système. Le gabarit est rendu avant l'exécution du state : votre commande partira même en test=True, et l'idempotence saute sans que rien ne l'annonce. Jinja calcule, il n'agit pas.
Cibler un pillar sensible par grain. Un grain est déclaré par le minion, donc forgeable par quiconque a un shell dessus. Cibler un secret par grain revient à le livrer à qui sait mentir sur son identité. Ciblez par nom de minion.
Oublier que le master ne tourne pas en root. Le service s'exécute sous l'utilisateur salt, et cette seule ligne m'a coûté plusieurs heures : le trousseau GPG cherché au mauvais endroit, un dépôt GitFS silencieusement vide (Git refuse un dépôt appartenant à un autre utilisateur), une authentification PAM impossible faute d'accès à /etc/shadow. Aucune de ces trois pannes ne dit son vrai nom dans les journaux.
Empiler deux sources de vérité pour le top file. Dès que GitFS est actif, son top.sls supplante celui de /srv/salt/. Deux fichiers, un seul gagne, et ce n'est jamais celui que vous êtes en train d'éditer. Choisissez une source, et une seule.

Versions et compatibilité

La formation cible la série stable 3008 (nom de code Argon), celle que vous installerez en 2026. Le packaging onedir est désormais le standard : Salt embarque son propre Python, ce qui supprime les conflits avec le Python système et simplifie l'installation sur toutes les distributions. Les labs tournent sur Debian 13, mais les states restent multi-distributions grâce aux grains (os_family) et à map.jinja, précisément ce que le parcours apprend à exploiter.

Un point d'attention concret : certaines commodités récentes n'existent pas sur les anciennes versions. Le masquage des valeurs de pillar en sortie CLI, par exemple, n'est apparu qu'en 3008 ; sur un master en 3006 LTS, ces mêmes commandes affichent les secrets en clair. Vérifiez toujours la version de votre master avec salt --version avant de vous fier à un comportement documenté ici.

À qui s'adresse ce parcours

Ce parcours vise les administrateurs systèmes et DevOps qui veulent piloter un parc de serveurs autrement qu'à la main, débutants en gestion de configuration acceptés, à l'aise avec la ligne de commande Linux. Il prépare concrètement à industrialiser la configuration d'une flotte, à orchestrer des déploiements multi-machines, et à bâtir des automatismes réactifs avec le Reactor. Si vous administrez déjà avec des scripts shell éparpillés, c'est le saut qualitatif que Salt vous fait franchir.

À retenir

Salt décrit l'état voulu en YAML + Jinja et l'applique de façon idempotente.
L'architecture master/minion privilégie la vitesse et l'orchestration temps réel ; Salt SSH offre un mode sans agent.
Les grains (faits du minion) et les pillars (données ciblées du master) rendent les states génériques et sécurisés.
Le bus d'événements et le Reactor distinguent Salt : des infrastructures réactives pilotées par les événements.
Le parcours va du premier ping à une plateforme complète orchestrée, avec des labs reproductibles sur de simples VM Linux.

FAQ : questions fréquentes sur Salt

SaltStack et Salt, quelle différence ?

Aucune : c'est le même outil. SaltStack était le nom de l'entreprise et du produit commercial, racheté par VMware en 2020. Le projet open source s'appelle aujourd'hui Salt, porté par le Salt Project. Les deux noms désignent la même technologie.

À quoi sert SaltStack concrètement ?

SaltStack sert à configurer et piloter un parc de serveurs depuis un point central : installer des paquets, déployer des fichiers de configuration, démarrer des services, et orchestrer un déploiement multi-machines dans le bon ordre, le tout de façon idempotente et reproductible.

Qu'est-ce que SaltStack (Salt) ?

Salt (anciennement SaltStack) est un outil open source de gestion de configuration et d'orchestration. Il décrit l'état voulu des serveurs en YAML rendu par Jinja, l'applique de façon idempotente, et pilote un parc via une architecture master/minion ou sans agent avec Salt SSH.

Quelle différence entre Salt et Ansible ?

Ansible est agentless et pilote par SSH : prise en main immédiate mais exécution plus lente à grande échelle. Salt privilégie un mode master/minion très rapide, avec un bus d'événements pour réagir automatiquement, tout en offrant aussi un mode sans agent (Salt SSH). Les deux décrivent l'état en YAML.

Grains ou pillars : quelle est la différence dans Salt ?

Les grains sont des faits collectés côté minion (OS, CPU, rôle) : modifiables localement, non sûrs pour des secrets, utiles au ciblage. Les pillars sont servis par le master et ciblés par minion : isolés et destinés aux secrets. Règle : fait non secret pour cibler = grain, donnée sensible = pillar.

Salt a-t-il encore un avenir après le rachat par Broadcom ?

Oui. Salt appartient à VMware, racheté par Broadcom fin 2023, mais le Salt Project reste open source sous licence Apache 2.0, avec une communauté active et des releases régulières (série 3008 en 2026). Apprendre Salt reste pertinent, en gardant à l'esprit que son écosystème est plus niche qu'Ansible.

Faut-il un master Salt ou peut-on l'utiliser sans agent ?

Les deux sont possibles. Le mode master/minion installe un agent permanent sur chaque serveur : rapide et réactif à grande échelle. Salt SSH exécute Salt par SSH sans agent, pratique pour l'amorçage ou les machines verrouillées, mais plus lent. On combine souvent les deux selon les machines.