Mémo rapide de débrief de ce qu'est Salt dans son usage de base…https://docs.saltproject.io/en/master/topics/tutorials/walkthrough.html
une fois maitrisé il pourra être envisagé de voir les fonctionnements avancés (configuration, langage de rendu,…)
Salt est un orchestrateur d'infrastructure hétérogène de machine (Windows/Linux/Mac). Il permet une gestion rapide et uniforme des configurations pour installer ou déployer un modèle de machine au travers de ce qu'on appelle “Salt States”.
Salt est basé sur le modèle client/serveur. Les clients appelés “minion” sont connectés via un agent (salt-minion) au serveur (salt-master). L'installation standard du serveur installe l'agent salt-minion ce qui permet de faire des tests directement sur lui meme en l'absence de machines clientes. Afin de garder une connexion permanente entre serveur et minions, on doit s'assurer que les services salt-master et salt-minion soient démarrés à chaque redémarrage des machines.
Il peut avoir plusieurs masters qui jouent le role de failover ou d'équilibreur de charge. Un master suffit pour environ 200 minions.
Le serveur utilise 2 ports de communication (4505 et 4506). Il est peut etre nécessaire de régler les parefeux.
A noter que les minions peuvent fonctionner sans master (masterless) à des fins de tests local avant déploiement.
Les minions sont connus par le master par un ID (paramétré dans /etc/salt/minion_id pour les linux). Cet ID est en général le nom DNS de la machine, mais peut etre modifié.
Les connexions entre minion et master se font grace à des échanges de clés (salt-key).
La commande de base est:
salt 'ID_minion' fonction_ou_module
example:
salt 'monServeur' test.version
on peut remplacer monServeur par * qui lancera la fonction test.version sur tous les minions connectés au master.
Les fonctions sont appelées “execution module”. Toutes les fonctions et aides associées sont accessibles par
salt '*' sys.doc
ATTENTION c'est très long à afficher!!! Il est préférable de consulter l'aide des fonctions en ligne: https://docs.saltproject.io/en/master/ref/modules/all/index.html#all-salt-modules
Afin de débuguer on peut faire des manipulations directement sur le minion avec la commande salt-call (pour tester un state). La commande “salt” fait la meme chose mais depuis le master.
Les states permettent de d'orchestrer les actions à mener sur les minions en utilisant si besoin les informations spécifiques dans les pillars. Les states peuvent cibler les minions en les filtrant avec les grains.
Salt se base sur python. Les fichiers en langage YAML sont convertis en python avant d'être exploité par salt.
JINJA –> YAML –>Python
Les grains sont des éléments stockés sur les minions. Ils caractérisent des paramètres du minion tel que le CPU, os, la quantité de mémoire, les versions du noyeau, etc..
Les pillars quant à eux sont stockés uniquement sur le master et contiennent des donnés sensibles ou parmètres spécifiques utilisés par les States tel que les mots de passe, les paramètres de configuration d'une application,etc… Les données des pilllars échangées entre minion et le master sont transmises de façon sécurisées et chiffrées avec la clé (mentionné plus haut) du minion concerné.
examples d'un pillar (user.sls)
users:
user1:
fullname: Robert Hernandez
uid: 5000
gid: 5000
shell: /bin/bash
home: /home/user1
groups:
- wheel
- admin
password: $6$SALTsalt$UiZikbV3VeeBPsg8./Q5DAfq9aj7CVZMDU6ffBiBLgUEpxv7LMXKbcZ9JSZnYDrZQftdG319XkbLVMvWcF/Vr/
enforce_password: True
key.pub: True
user2:
fullname: Joe Smith
uid: 5031
gid: 5031
shell: /bin/bash
home: /home/user2
password: $6$SALTsalt$UiZikbV3VeeBPsg8./Q5DAfq9aj7CVZMDU6ffBiBLgUEpxv7LMXKbcZ9JSZnYDrZQftdG319XkbLVMvWcF/Vr/
groups:
- admin
key.pub: True
Les states, la base de salt, permettent d'automatiser les taches à éxécuter sur les minions. On déclare dans un state ce qui doit etre fait tel que installer un logiciel, paramétrer un service, copier un fichier de configuration, etc… Les paramètres spécifiques pour un minion donné sont récupérés sur les pillars grace au langage JINJA.
Example d'un state (users.sls) qui utilisent les informations du pillar user.sls avec le langage JINJA pour récupérer les informations nécessaires à son exécution.
{% for user, args in pillar['users'].iteritems() %}
{{ user }}:
group.present:
- gid: {{ args['gid'] }}
user.present:
- home: {{ args['home'] }}
- shell: {{ args['shell'] }}
- uid: {{ args['uid'] }}
- gid: {{ args['gid'] }}
{% if 'password' in args %}
- password: {{ args['password'] }}
{% if 'enforce_password' in args %}
- enforce_password: {{ args['enforce_password'] }}
{% endif %}
{% endif %}
- fullname: {{ args['fullname'] }}
{% if 'groups' in args %}
- groups: {{ args['groups'] }}
{% endif %}
- require:
- group: {{ user }}
{% if 'key.pub' in args and args['key.pub'] == True %}
{{ user }}_key.pub:
ssh_auth:
- present
- user: {{ user }}
- source: salt://users/{{ user }}/keys/key.pub
{% endif %}
{% endfor %}
Ce state est appélé par le top file (top.sls)
base:
"*":
- users
on lance l'éxécution d'un state avec
salt '*' state.apply monstate.sls
si on ne fourni pas de state en paramètre c'est top.sls qui est exécuté. Ici le top.sls ne lance que users.sls sur tous les minions.
avant tout: https://docs.saltproject.io/salt/user-guide/en/latest/topics/state-system.html
L'arborescence des pillars et states sont identiques et leur racine est déclaré dans le fichier de configuration du master. Par défaut:
Les 2 arborescences contiennent un top file (top.sls) et les fichiers déclaratifs ont l'extension SLS. Ces fichiers sont en YAML. Les fichiers states peuvent en plus utiliser le langage JINJA pour récupérer les données dans les sls pillars.
Note sur Salt-SSH : afin de gérer le matériel ne permettant pas l'installation de salt-minion (comme les switches) on peut passer par du pure SSH avec salt master mais qui utilise les states et pillars.
Les states permettent l'installation des logiciels ou copie des fichiers de configuration vers les minions. Il est donc nécessaire que le master puisse transférer des fichiers vers les minions. Pour cela le master intègre un service de partage et transfère de fichier dont la racine est la meme que celle de l'arborescence des states.