Salt SSH : administrer des serveurs Salt sans agent

Installer un minion n'est pas toujours possible : machine legacy, prestataire, équipement verrouillé. Salt SSH répond à ce cas : il exécute Salt par SSH, sans agent, à la manière d'Ansible. Ce module apprend à administrer des serveurs sans minion, et à connaître les limites de ce mode. Public visé : intermédiaires ayant pratiqué les states.

Ce que vous allez apprendre

• Comprendre le fonctionnement de Salt SSH.
• Déclarer des cibles dans un roster.
• Appliquer un state sans agent.
• Connaître les limites face au mode master/minion.

Prérequis

• Savoir écrire des states (module Les states) et un accès SSH aux cibles.

Comment fonctionne Salt SSH

Au lieu d'un minion permanent, salt-ssh se connecte en SSH, pousse un Salt minimal (thin) sur la cible, exécute la fonction demandée, récupère le résultat et nettoie. Aucun démon ne reste installé. L'outil vient dans un paquet séparé du master :

sudo apt-get install -y salt-ssh

Les cibles ne sont plus découvertes par acceptation de clé, mais déclarées dans un fichier roster (/etc/salt/roster). Chaque entrée donne l'adresse, l'utilisateur SSH, la clé privée à utiliser et l'élévation de privilèges :

/etc/salt/roster

proxy1:
  host: 192.168.10.43
  user: debian
  priv: /home/debian/.ssh/saltssh
  sudo: true

On pilote alors la cible avec la même logique qu'un minion, mais sans agent. Le drapeau -i accepte une clé d'hôte encore inconnue au premier contact :

sudo salt-ssh -i 'proxy1' test.ping

proxy1:
    True

Cas d'usage et limites

Salt SSH brille pour l'amorçage (bootstrapper un futur minion), les machines où l'on ne peut rien installer, ou un petit parc ponctuel. Mais il paie le prix de l'agentless : plus lent (connexion et push à chaque exécution), il perd le bus d'événements, le Reactor et le cache du mode master/minion.

Deux modes complémentaires

Salt SSH n'est pas un remplacement du master/minion, mais un complément : on l'emploie là où l'agent est impossible, et on garde le mode master/minion pour la réactivité et l'orchestration à grande échelle.

Travaux pratiques : appliquer un state sans agent

Un test.ping prouve la connexion ; le vrai intérêt est d'appliquer un state par SSH. La commande est identique au mode minion, seul le binaire change :

sudo salt-ssh -i 'proxy1' state.apply sshdemo

          ID: /etc/motd.d/salt-demo
    Function: file.managed
     Comment: File /etc/motd.d/salt-demo updated

Succeeded: 1 (changed=1)
Failed:    0

Le state s'applique exactement comme sur un minion, alors qu'aucun agent n'est installé sur la cible : Salt a poussé son thin le temps de l'exécution, appliqué le file.managed, puis nettoyé.

Mesurer le compromis

L'agentless a un coût : à chaque appel, Salt ouvre une connexion SSH et transfère son thin, là où un minion écoute en permanence. Le même test.ping, chronométré dans les deux modes, rend l'écart tangible :

time sudo salt-ssh -i 'proxy1' test.ping   # agentless
time sudo salt proxy1 test.ping            # master/minion

salt-ssh : real  0m5.018s
minion   : real  0m0.488s

Environ dix fois plus lent en agentless sur une simple commande. Sur un parc de centaines de machines exécutées en boucle, l'écart devient rédhibitoire, ce qui explique pourquoi Salt SSH reste un complément ciblé, pas le mode par défaut.

À retenir

1. Salt SSH exécute Salt par SSH, sans agent installé.
2. Les cibles se déclarent dans un roster, pas par acceptation de clés.
3. Idéal pour l'amorçage et les machines verrouillées.
4. Plus lent, il perd bus d'événements, Reactor et cache : un complément, pas un remplacement.

Prochaines étapes

Orchestration Coordonner un déploiement multi-machines depuis le master.

Formation Salt Revenir au parcours complet et poursuivre les modules suivants.

×

📖 Voir la documentation →