Découvrir Salt : architecture, installation et premier ping

Salt est un outil de gestion de configuration et d'orchestration open source. Ce guide vous fait installer une architecture master/minion complète, accepter les clés des serveurs à administrer, puis prouver que tout communique avec un premier test.ping. À la fin, vous pilotez plusieurs serveurs depuis une console centrale et lancez votre première commande distante. Public visé : administrateurs systèmes débutants avec Salt, à l'aise avec la ligne de commande Linux et l'accès sudo.

Ce que vous allez apprendre

• Distinguer les rôles master, minion et le mode Salt SSH.
• Installer Salt via le dépôt signé officiel, sans curl | sh.
• Déclarer le master aux minions et accepter leurs clés avec salt-key.
• Vérifier la communication avec test.ping et lancer une commande distante.
• Repérer les premiers réflexes de sécurité et de dépannage.

Prérequis

Avant de commencer, réunissez les éléments suivants :

• Plusieurs machines Linux : une pour le master, une ou plusieurs pour les minions. Cet exemple utilise Debian 13, mais Salt fonctionne sur la plupart des distributions.
• Un accès sudo sur chaque machine.
• Une résolution de nom ou une adresse IP stable pour joindre le master depuis les minions.

Si vous découvrez la gestion de configuration en général, la page panorama des outils situe Salt face à Ansible, Chef et Puppet avant de plonger dans l'outil.

L'architecture de Salt en trois rôles

Avant d'installer quoi que ce soit, il faut comprendre qui parle à qui. Salt repose sur un modèle master/minion doublé d'un mode sans agent. Ces trois rôles couvrent la quasi-totalité des usages.

Le master est le point de contrôle. Il stocke la configuration (states et pillars, abordés dans les guides suivants), reçoit vos ordres et les distribue. Il ne fait rien sur les serveurs lui-même : il commande.

Le minion est un agent léger installé sur chaque serveur à administrer. Il s'abonne au master, exécute les commandes reçues et renvoie ses résultats. Les échanges transitent par un bus de messages ZeroMQ, très rapide, ce qui explique la réputation de Salt sur les grands parcs et l'orchestration en quasi temps réel.

Le mode Salt SSH est la troisième voie : le master se connecte en SSH et exécute Salt à la volée, sans agent installé, à la manière d'Ansible. Il dépanne les machines où l'on ne peut rien installer. Retenez pour l'instant qu'il existe ; un guide dédié y reviendra.

La confiance repose sur des clés

Un minion ne devient joignable qu'après que vous ayez accepté sa clé sur le master. C'est le point de sécurité central de la mise en route : personne ne pilote un serveur sans validation explicite de son identité cryptographique.

Installer Salt depuis le dépôt signé

Salt fournit une page d'installation qui propose un script bootstrap-salt.sh en pipe-to-shell. On l'évite volontairement : on ajoute le dépôt signé officiel, ce qui garantit la vérification GPG des paquets et une chaîne d'installation auditable et reproductible. La version stable au moment de l'écriture est Salt 3008, en packaging onedir (un binaire autonome qui embarque ses dépendances Python).

Les commandes qui suivent s'appliquent à Debian et Ubuntu. Le dépôt est hébergé sur l'infrastructure Broadcom, qui édite désormais Salt.

1. Installer les prérequis puis ajouter la clé du dépôt dans le trousseau APT :

   sudo apt-get update
   sudo apt-get install -y gnupg curl ca-certificates
   sudo install -d -m 0755 /etc/apt/keyrings
   curl -fsSL https://packages.broadcom.com/artifactory/api/security/keypair/SaltProjectKey/public \
     | sudo gpg --dearmor -o /etc/apt/keyrings/salt-archive-keyring.pgp

   La commande télécharge la clé publique et la convertit avec gpg --dearmor : rien n'est exécuté, on écrit seulement un fichier de trousseau.

2. Déclarer le dépôt officiel, qui référence cette clé :

   curl -fsSL https://github.com/saltstack/salt-install-guide/releases/latest/download/salt.sources \
     | sudo tee /etc/apt/sources.list.d/salt.sources
   sudo apt-get update

   La sortie de apt-get update doit lister une ligne provenant de packages.broadcom.com sans avertissement de signature.

3. Installer le rôle master sur la machine de contrôle :

   sudo apt-get install -y salt-master
   sudo systemctl enable --now salt-master

4. Installer le rôle minion sur chaque serveur à administrer :

   sudo apt-get install -y salt-minion

Vérifiez la version installée de chaque côté : master et minions doivent partager la même série majeure.

salt-master --version

salt-master 3008.2 (Argon)

Pourquoi éviter le pipe-to-shell

curl ... | sh exécute du code arbitraire téléchargé, sans que vous puissiez le relire ni vérifier sa signature. Le dépôt signé délègue la confiance à la clé GPG de l'éditeur et à APT, qui refuse un paquet non signé. C'est la même exigence que pour n'importe quel paquet système.

Déclarer le master aux minions

Un minion fraîchement installé ne sait pas où joindre son master. On le lui indique dans un fichier de configuration dédié, puis on démarre le service. Créer un fichier dans minion.d/ plutôt que d'éditer le fichier principal garde la configuration modulaire et facile à versionner.

1. Pointer le minion vers le master (remplacez l'adresse par celle de votre master) :

   sudo install -d -m 0755 /etc/salt/minion.d
   echo "master: 192.168.1.10" | sudo tee /etc/salt/minion.d/master.conf

2. Démarrer le minion, qui va alors présenter sa clé au master :

   sudo systemctl enable --now salt-minion

Par défaut, l'identifiant du minion est son nom d'hôte. Dans cet exemple, les minions s'appellent web1, db1 et proxy1, des noms parlants qui préfigurent leurs rôles. Vous pouvez forcer un identifiant en écrivant le nom voulu dans /etc/salt/minion_id.

Accepter les clés des minions

C'est l'étape de sécurité qui autorise chaque minion. Sur le master, listez les clés en attente, vérifiez qu'elles correspondent bien à vos serveurs, puis acceptez-les.

1. Lister toutes les clés, acceptées comme en attente :

   sudo salt-key --list all

   Accepted Keys:
   Denied Keys:
   Unaccepted Keys:
   db1
   proxy1
   web1
   Rejected Keys:

2. Accepter les minions une fois leur identité confirmée :

   sudo salt-key --accept-all --yes

   Key for minion db1 accepted.
   Key for minion proxy1 accepted.
   Key for minion web1 accepted.

En production, vérifiez l'empreinte

--accept-all va vite en lab, mais en production on accepte nommément chaque minion après avoir comparé son empreinte (salt-key --finger <id>) avec celle affichée sur le minion (salt-call key.finger --local). Cela évite d'accepter une machine usurpant l'identité d'un serveur légitime.

Vérifier la communication avec test.ping

Le moment de vérité. test.ping n'est pas un ping réseau ICMP : c'est un aller-retour applicatif qui prouve que le master atteint le minion et que le minion sait répondre via le bus Salt. La cible '*' vise tous les minions acceptés.

sudo salt '*' test.ping

db1:
    True
web1:
    True
proxy1:
    True

Chaque True confirme un minion opérationnel. Vous pouvez aussi lister les minions joignables d'un coup avec le runner manage.up, pratique pour un état des lieux rapide :

sudo salt-run manage.up

- db1
- proxy1
- web1

Le premier ping juste après l'acceptation

Si un test.ping lancé immédiatement après l'acceptation renvoie « Minion did not return », ce n'est pas une erreur : le minion se ré-authentifie avec sa clé fraîchement acceptée. Rejouez la commande quelques secondes plus tard, la réponse arrive.

Lancer votre première commande distante

Salt expose des centaines de modules d'exécution. Le plus direct pour démarrer est cmd.run, qui exécute une commande shell sur les minions ciblés et rapatrie la sortie. Récupérons par exemple la version du noyau sur tout le parc :

sudo salt '*' cmd.run 'uname -r'

db1:
    6.12.94+deb13-cloud-amd64
web1:
    6.12.94+deb13-cloud-amd64
proxy1:
    6.12.94+deb13-cloud-amd64

En une commande, vous obtenez une information homogène sur l'ensemble des serveurs. Le même mécanisme sert à interroger la distribution, l'espace disque ou n'importe quelle commande. Salt possède aussi des modules structurés plus fiables que cmd.run : par exemple grains.item lit des faits déjà collectés par le minion, sans lancer de shell.

sudo salt '*' grains.item os osrelease cpuarch

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

Ces grains deviendront centraux dès le prochain guide pour cibler les minions au lieu de tous les viser.

Sécurité dès le premier jour

Trois réflexes valent d'être posés dès la mise en route, avant même d'écrire le moindre state.

Le master concentre le pouvoir : il peut exécuter des commandes sur tout le parc. Traitez-le comme un serveur sensible, avec un accès réseau restreint et un accès administrateur limité. Un master compromis, c'est le parc entier compromis.

L'acceptation des clés est votre porte d'entrée. Ne l'automatisez pas aveuglément en production : chaque clé acceptée est un serveur qui exécutera vos ordres. Vérifiez les empreintes quand l'enjeu le justifie.

Enfin, aucun secret en clair dans les commandes ou la configuration. Les mots de passe et clés ont leur place dans les pillars chiffrés, sujet d'un guide dédié plus loin dans le parcours.

Dépannage

Les blocages les plus fréquents à la mise en route et leur résolution :

Symptôme	Cause probable	Solution
Aucune clé dans salt-key --list all	Le minion ne joint pas le master	Vérifier master: dans /etc/salt/minion.d/, la résolution de nom et le pare-feu (port 4505/4506)
test.ping : « Minion did not return » juste après l'acceptation	Ré-authentification en cours	Rejouer la commande après quelques secondes
gpg: command not found à l'ajout de la clé	Paquet gnupg absent	sudo apt-get install -y gnupg puis reprendre
Le minion apparaît dans « Unaccepted Keys » sans jamais passer accepté	Clé jamais validée	sudo salt-key -a <id> pour l'accepter nommément
Versions master et minion différentes	Dépôts non alignés	Réinstaller depuis le même dépôt signé des deux côtés

Glissez pour voir

Pour aller plus loin, le module salt-call --local permet de déboguer un minion isolément, sans passer par le master : utile pour distinguer un problème de communication d'un problème de configuration locale.

À retenir

1. Salt est master/minion : le master commande, les minions exécutent et renvoient leurs résultats via un bus ZeroMQ. Le mode Salt SSH ajoute une voie sans agent.
2. On installe depuis le dépôt signé officiel, jamais par curl | sh : la confiance passe par la clé GPG et APT.
3. Chaque minion déclare son master dans /etc/salt/minion.d/, puis présente une clé à valider.
4. salt-key accepte les minions ; en production, on vérifie l'empreinte avant d'accepter.
5. test.ping prouve la communication ; cmd.run et grains.item lancent vos premières commandes distantes.

Prochaines étapes

Les commandes distantes Cibler finement les minions avec globbing, grains, matchers et batch.

Le parcours Salt complet Situer ce guide dans la formation, du premier ping à l'orchestration.

Panorama des outils de gestion de configuration Comparer Salt à Ansible, Chef, Puppet et Rudder.

×

📖 Voir la documentation →