Salt est un outil de gestion de configuration qui a la particularité de fonctionner avec des agents. Il existe un serveur, le master (salt-master) qui contient les fichiers de configuration à déployer et les clients (salt-minion) sur lesquels les configurations sont appliquées.
Les fichiers de configuration de Salt sont relativement simple :
Par défaut, le master écoute sur toutes les interfaces et sur les ports 4505 et 4506. On peut forcer l’écoute sur une interface réseau unique :
interface: 192.168.1.10
Les minions tentent, par défaut, de joindre l’IP qui est résolue depuis le DNS salt. Si celui-ci ne résoud pas, nous avons la possibilité de préciser l’IP dans le fichier de conf.
master: 192.168.0.10
Après modification de ces fichiers, un redémarrage des services spécifiques est nécessaire.
Les communications entre le master et les minions sont chiffrées par des clés AES. Un fois que la configuration du minion est en place (IP du master définie et joignable sur les ports Salt), il est nécessaire de valider sa clé avant de pouvoir lui envoyer des commandes. La commandes salt-key -L, sur le master, permet de lister les clés. Elle affichera les clés acceptées et celles en attente. L’option -A de la commande salt-key permet de valider toutes les clés en attente, alors que l’option -a permet de ne valider que celle qui est précisée en argument.
Les modules salt s’utilisent de la manière suivante (la dernière commande permettant de lancer sur module sur tous les minions) :
salt module
salt '*' module
Pour vérifier que les minions sont bien joignables nous pour utiliser le module test.ping de Salt:
salt minion1 test.ping
Pour installer des paquets ou redémarrer des services, nous pouvons utiliser les commandes suivantes :
salt minion1 pkg.install nginx
salt minion1 service.restart nginx
Il existe également un module très utile qui permet d’exécuter des commandes système :
salt minion1 cmd.run 'ls -l /root/'
Enfin, pour connaître les fonctions disponibles sur un minion, nous pouvons utiliser le module sys.doc.
Sur le master, il est possible de définir où se situent les fichers de base de salt (pillar, states, …). Pour celà, il suffit de rajouter le bloc suivant dans le fichier master :
file_roots:
base:
- /srv/salt/local/
- /srv/salt/formula/
pillar_roots:
base:
- /srv/pillar
Il est également possible de créer des groupes de minions pour faciliter les déploiements (toujours dans le fichier /etc/salt/master) :
miniongroups:
web: 'L@minion1,minion2'
bdd: 'L@minion2,minion3'
Le “L@” signifie que le groupe est constitué d’une liste de hostnames.
Pour utiliser ces groupes, il suffit de remplacer le nom d’un minion par -N suivi du nom de groupe :
salt -N bdd test.ping
Les states sont des fichiers au format YAML qui portent des extensions SLS. Ils permettent de décrire l’état dans lequel un serveur doit être. Les formulas sont des ensembles de states. Pour appliquer un state sur un minion, il faut lancer la commande suivante :
salt -N web state.sls nginx
salt -N web state.sls nginx.vhosts
Dans cet exemple Salt va appliquer des formulas qu’il va trouver à ces endroits : /srv/salt/formula/nginx.sls et /srv/salt/formula/nginx/vhosts.sls.
Il existe un nom de formula particulier : init.sls. Lorsqu’une formula porte ce nom, elle hérite du nom du dossier dans lequel elle se trouve.
En reprenant l’exemple ci-dessus, le premier state pourrait appeler le fichier suivant : /srv/salt/formula/nginx/init.sls.
Il s’agit de fichiers contenant des informations spécifiques à un ou plusieurs minions (variables) et qui sont stockés sur le master. Le but est de pouvoir ainsi les déployer de manière combinée avec une formula.
Comme pour les states, les pillars sont des fichier YAML qui portent des extensions SLS. Il y a un top file pour les pillar : top.sls. Leur arborescence par défaut est /srv/pillar, elle peut être modifié (cf Configuration avancée), mais de doit pas être placée dans un sous-dossier des states.
Le contenu du fichier top.sls est de type :
base:
'*':
- data
De cette manière, tous les minions sont associés au fichier /src/pillar/data.sls. En reprenant le groupe créer dans le paragraphe Configuration avancée, nous pouvous associer aux groupes créés des pillars spécifiques :
web:
- match: miniongroup
- web
bdd:
- match: miniongroup
- bdd
Il y aura donc un fichier /srv/pillar/web.sls pour les machines du groupe web et /srv/pillar/bdd.sls pour les machines du groupe bdd.
On peut également ajouter une section pour matcher un host précis :
minion3:
- match: compound
- bdd_master
Le host minion3 appliquera également le fichier /srv/pillar/bdd_master.sls.
Enfin, un paramètre order peut être ajouté pour préciser l’ordre de priorité des fichiers. Lorsqu’un pillar est modifié sur le master, avant que la nouvelle valeur puisse être utilisée, il faut exécuter la commande :
salt '*' saltutil.refresh_pillar
Pour vérifier la valeur d’une variable sur un minion ou un groupe de minions, on peut utiliser la commande suivante :
salt -N web pillar.get nginx.port #Syntaxe à vérifier
Ils contiennent des informations spécifiques à un ou plusieurs minions. Ils sont obtenus ou générés depuis le ou les minions. Ils ressemblent par certains aspects aux gathering_facts d’Ansible mais sont en réalité différents (les valeurs sont modifiables, la liste de valeur n’est pas statique, …). Pour consulter la valeur d’une variable, nous pouvons utiliser la commande suivante :
salt -N web grains.get [clé]
Pour modifier la valeur d’une variable grain, nous pouvons utiliser la commande suivante :
salt -N web grains.setval [clé] [valeur]
Cela peut être utile lorsque, par exemple, on joue un state ou une formula uniquement lorsqu’une variable est définie sur True. On force la variable avant de lancer le salt -N web state.sls nginx.ssl