Salt Stack est un logiciel d'automatisation de taches similaire à Puppet.
Puppet est très intéressant mais un peu complexe à mettre en place, Salt a de gros avantages tels que la simplicité et la souplesse.
Par contre cette simplicité a pour pendant une certaine confusion à la première mise en place.
Voici les concepts et la mise en place d'un config pour automatiser les post installation de distro sur un poste multiboot.

  1. State
  2. Salt utilise les "state" qui sont en fait des séquences déclaratives qui seront ensuite appliquées aux machines cibles.
    Par défaut Salt utilise un mode client/server mais peut aussi etre utilisé en stand alone.
    Le mode client/server s'installe de facon similaire à Puppet avec un echange de certificats entre le maitre et le client (appelé minion dans salt).
    Je ne rentre pas dans les détails qui sont documentés maintes fois mais oriente le billet sur la pratique un peu plus avancées.
    En pratique on défini le repertoire source des configuration qui doit contenir un fichier top.sls qui pourra être appelé via le state.highstate :
    • En mode master/minion
    • salt '*' state.highstate
    • En mode standalone
    • salt-call state.highstate

  3. Grains
  4. On peut ensuite interagir avec des variables définies dans le système (à la manière de facter sous puppet) grâce au grains.
    La encore on a beaucoup de souplesse pour créer ses propres grains, je définie une catégorie dans /etc/salt/minion :
    grains: type: work
    Ca me permettra ensuite de faire un profil "boulot" et un profil "home" simplement.
    On peut ensuite questionner ce "grain" :
    salt-call grains.item type
    Ou bien dans le fichier top.sls :
    base:
      'type:work':
        - match: grain
        - work

    Si le grain 'type' est work on va exécuter le state work, il faut donc que il existe un sous répertoire work dans lequel on a un fichier init.sls.
    Ce fichier init.sls sera équivalent au top.sls de la racine pour ce "state".
    On peut ensuite appelé ce state individuellement par :
    salt-call state.sls work

  5. Template/Pillar
  6. Afin d'apporter un peu d'intelligence au langage descriptif salt utilise un systeme de template appelé jinja2. Par exemple on definit un pillar pour les package à installer en fonction des os.
    On définit le pillar dans /etc/salf/minon :
    pillar_roots:
      base:
        - /vagrant/pillar
    Dans ce repertoire on définit un top.sls :
    base:
      '*':
        - pkgnames
    
    Puis dans /vagrant/pillar/pkgnames.sls :
    pkgdef:
      {% if grains['os_family'] == 'RedHat' %}
      apache: httpd
      {% elif grains['os_family'] == 'Debian' %}
      apache: apache2
      {% endif %}
    Ensuite dans le apache.sls (dans les salts /vagrant/salt/work dans mon cas):
    apache:
      pkg.installed:
        - name: {{ pillar['pkgdef']['apache'] }}
    De la même manière on peut tester les configurations pillar :
    salt-call pillar.get pkgdefws:firefox
    On va chercher la valeur firefox dans le groupe pillar pkgdefws (package definition workstation).

  7. Modules
  8. Afin de pouvoir gérer les states salt fournit un grand nombre de modules natifs simple d'accès.

    A noter que le templating est aussi accessible hors des pillar directement dans les states standards.

  9. Autres outils
  10. Accessiblité de la doc :
    La command salt-call sys.doc permet de voir la documentation sur tous les modules.
    On peut voir ensuite un module particulier :
    salt-call sys.doc user
    
    Cela ressemble un peu au fonction pydoc bien pratique.
  11. Masterless
  12. On peut tout utiliser en local en configurant Salt en mode sans maitre.
    Il faut mettre cela dans le /etc/salt/minion :
    file_client: local
    Puis lancer les commandes avec --local :
    solydxk-x64 ~ # salt-call --local user.info root
    local:
        ----------
        fullname:
            root
        gid:
            0
        groups:
            - root
        home:
            /root
    ....
    
    Pour declarer le repertoire source des sls :
    file_roots:
      base:
        - /srv/salt/local
        - /srv/salt/pillar
    
    Il faut mette un top.sls dans local, on peut mettre un toto.sls dans pillar pour faire des fichiers de conf.
    Puis on peut en local :
    salt-call --local state.highstate
    Salt est aussi orienté lancement de commande en ligne vers des groupes prédéfinis, on peut aussi gérer des authentifications externes afin de donner des permissions sur le lancement des différents "states". Voir cette page.

Conclusion :
Salt semble vraiment simple à utiliser et puissant après un minimum d'habitude.
La syntax Yaml est cependant un peu trop succinte et peut preter à confusion, il font donc bien découper ses fichiers selon les fonctions.
Le gros point fort est la simplicité de faire des choses avancées, le grand nombre de modules natifs existants et pour ceux qui aiment sa nature pythonienne.