Salt

Il s'agit d'un logiciel de gestion de configuration.

La gestion de configurations via un logiciel comme Salt ou Puppet présente un certain nombre d'avantages qui justifient pleinement l'adoption d'une telle organisation au sein d'un chaton Membre du collectif CHATONS :

• écrire une configuration une fois, la déployer partout (par exemple, créer les comptes kivonbien partout) ;
• système de templates de configuration : une configuration identique partout sauf pour certaines parties qui dépendront de variables propres aux machines ;
• si on utilise un gestionnaire de version pour les formules salt ¹⁾, il est possible de revenir en arrière très rapidement, de savoir qui blâmer, etc. ;
• il n'y a qu'un seul endroit où chercher pour trouver un élément de configuration.

Un agent doit être déployé sur chaque machine à contrôler (un minion dans le jargon salt), qui se connectera à un maître via les ports 4505 et 4506. Avantage d'un minion qui se connecte à un maître plutôt que l'inverse : il n'y a qu'un endroit où on devra modifier le pare-feu.

Parmi les gestionnaires de configuration, il y a Salt, Puppet, Ansible et plein d'autres encore.

Framasoft a choisi Salt parce que sa syntaxe est relativement simple (± du YAML, pour ceux qui connaissent), et que sa courbe d'apprentissage est rapide.

Salt permet aussi d'envoyer directement des commandes sur les serveurs distants. Cela peut être très utile pour tester une configuration rapidement sans modifier les formules ou pour mettre à jour tous les serveurs en une seule commande.

La doc officielle : http://repo.saltstack.com/.

On prend ici pour exemple la machine omerine avec comme maître souane.chatons.org.

Exécutez les commandes suivantes (attention si vous êtes en Wheezy ou Jessie, il faut remplacer stretch dans la définition du dépôt de Salt) :

if [ ! -f /etc/apt/sources.list.d/salt.list ]
then
    wget -O - https://repo.saltstack.com/apt/debian/9/amd64/latest/SALTSTACK-GPG-KEY.pub | sudo apt-key add -
    echo "deb http://repo.saltstack.com/apt/debian/9/amd64/latest stretch main" > /etc/apt/sources.list.d/salt.list
fi

apt-get update

if [[ $(dpkg -l | grep -c salt-minion) -eq 0 ]]
then 
    apt-get install salt-minion debconf-util -y

    service salt-minion stop
    echo $(hostname -s) > /etc/salt/minion_id
    echo -e "master: souane.chatons.org\nbackup_mode: minion\nhash_type: sha256" > /etc/salt/minion.d/custom.conf
    service salt-minion start
fi

Pour Ubuntu, on ira voir http://docs.saltstack.com/en/latest/topics/installation/ubuntu.html, puis on créera le fichier /etc/salt/minion.d/custom.conf dans lequel on mettra :

master: souane.chatons.org

Sur la machine qui sert de maître Salt (souane), exécutez salt-key -L qui vous donnera toutes les clés acceptées ou non des minions :

Accepted Keys:
Unaccepted Keys:
omerine
Rejected Keys:

Ensuite, toujours sur le maître, exécutez salt-key -a omerine :

The following keys are going to be accepted:
Unaccepted Keys:
omerine
Proceed? [n/Y] y
Key for minion omerine accepted.

Sur le maître, on vérifiera que tout fonctionne comme prévu avec salt omerine test.ping qui doit donner :

omerine:
    True

Si cela fonctionne comme prévu, on lance salt omerine state.highstate pour pousser l'ensemble des configurations sans attendre.

salt-run manage.status

salt \* -b1 -t600 pkg.upgrade
# Pour tous les serveurs sauf vaiana
salt -C 'not vaiana' -b1 -t600 pkg.upgrade

• \* ⇒ cible toutes les machines
• -b 1 ⇒ n'exécute la commande que sur une machine à la fois (ça vaut mieux, pour ne pas bourriner tous les CPU en même temps
• -t600 ⇒ laisse 600 secondes au minion pour répondre (certaines mises à jour peuvent prendre du temps)

Voir les paquets à mettre à jour sur tous les serveurs :

salt \*  pkg.list_upgrades false

salt minion cmd.run "echo toto"

• Il vaut mieux créer un dossier du nom de la thématique (ex: fail2ban, monitoring) plutôt qu'une recette directement (pas de fail2ban.sls par exemple). Ça marche aussi, mais un dossier permet par la suite d'étendre la configuration en rajoutant d'autres recettes dans d'autres fichiers.
• dedans, soit vous mettez tout dans init.sls si c'est relativement atomique, soit vous faites des includes :

include:
  - monitoring.munin
  - .shinken

La différence entre les deux écritures est qu'on spécifie le chemin complet vers la recette d'un côté et un chemin relatif de l'autre. Dans ce dernier cas, il faut que shinken.sls soit dans le même répertoire que la recette qui fait l'include. La première syntaxe permet d'appeler une recette d'un autre répertoire.
Le découpage en include permet d'avoir des recettes atomiques, qui ne se rapporte qu'à un seul logiciel/une seule thématique au sein d'une recette plus globale.

• Si vous souhaitez pousser des fichiers, regroupez-les dans un sous-répertoire files pour que les recettes et les fichiers ne se mélangent pas (ça fait perdre du temps de regarder lesquels sont des fichiers et lesquels sont des recettes).
• Préférez des fichiers templatisés plutôt que d'avoir des fichiers différents selon les cas. Pour déclarer qu'un fichier est templatisé et lui passer des variables :

/etc/fail2ban/jail.local:
  file.managed:
    - makedirs: True
    - source:
      - salt://fail2ban/files/jail.local
    - template: jinja
    - user: root
    - group: root
    - mode: 644
    - default:
      f2b: {{pillar['shinken-hosts'][grains['id']]['f2b']}}
      host: {{grains['id']}}

• Pour vérifier qu'un fichier existe sur le serveur distant :

truc: {% if salt['file.file_exists' ]('/var/log/mail.log') -%}True{% else -%}False{% endif %}

• Page d'accueil de la communauté Salt
• Tuto de démarrage officiel de Salt
• Liste des ''states'' de Salt (ce que vous pouvez faire avec Salt via les formules)
• Présentation HTML5 de Sky sur Salt