Salt

Presenter Notes

Au programme du workshop

  • présentation de salt
  • explication de comment lire et faire des states
  • présentation des states les plus utile
  • installation pour ceux qui l'ont pas déjà fait (je parie que c'est tout le monde)
  • exercices

Presenter Notes

Salt

C'est quoi ?

  • un outil d'orchestration
  • un config manager
  • une architecture client serveur

Mais aussi:

  • permet de gérer des vms (salt-cloud)
  • et probablement d'autre trucs (prototyping pour faire du monitoring)

Presenter Notes

Type de deployement

  • en mode client-serveur (/!\ crypto maison)
  • en local ← on va probablement utiliser ça aujourd'hui
  • Nouveau: ansible-like, via ssh sans minion

Remarque: peut avoir plusieurs master en mode client-serveur

Presenter Notes

Questions sur c'est quoi salt ?

Presenter Notes

rapide intro à l'orchestration

Presenter Notes

L'orchestration en 5min

Simple:

salt <pattern ou nom de machine> <commande>

Exemples:

salt '*' test.ping

salt mon_precieux.com cmd.run "ls"

salt-call --local state.highstate

Commande à retenir: state.highstate synchronise les states.

Liste des modules disponible:

Vocabulaire (salt a plein de termes à la con): module == "commande d'orchestration"

Remarque: en vrai, un module c'est <module python>.<function dans le dis fichier>

Tous les modules disponible: http://docs.saltstack.com/ref/modules/all/index.html

Presenter Notes

States

Presenter Notes

Détails importants

  • les states sont écrits dans des fichier en ".sls"
  • on doit définir un fichier top.sls dans /srv/salt/top.sls (customisable)
  • exemple de top.sls:

    !yaml base: '*': # tout le monde - github - zabbix-agent - users

    'mon.server_1.com': - ii - logstash - clean_backups

  • chaque nom dans top.sls pointe vers soit:

    • un fichier du même nom en .sls (eg: github.sls)
    • un répertoire du même nom contenant un fichier init.sls (exemple: github/init.sls
  • rappel: une fois que les states sont ecrit, pour les "executer" utiliser le module state.highstate

Presenter Notes

Les states

Un state est un état dans lequel on veut que la machine soit. Exemple: je veux que ce package soit installé, je veux que cet user existe.

Généralement très proche d'une commande ou d'une série de commandes shell (mais pas exactement).

Structure (en yaml):

1 nom_du_state:
2   module_python.fonction_python:
3     - clef_1: argument_1
4     - clef_2: argument_2
5     - clef_3: argument_3
6     ...

Vous l'avez deviné, c'est exactement ça en python:

1 from module_python import fonction_python
2 
3 fonction_python(clef_1=argument_1, clef_2=argument_2, clef_3=argument_3, ...)

Presenter Notes

Exemple

 1 fred_user:
 2   user.present:
 3     - name: fred
 4     - fullname: Fred Jones
 5     - shell: /bin/zsh
 6     - home: /home/fred
 7     - uid: 4000
 8     - gid: 4000
 9     - groups:
10       - wheel
11       - storage
12       - games
13 
14 dependance:
15   pkg.installed:
16     - name: git

Rappel:

1 nom_du_state:
2   module_python.fonction_python:
3     - clef_1: argument_1
4     - clef_2: argument_2
5     - clef_3: argument_3
6     ...

Presenter Notes

Entering salt confusing syntaxe ! #F34R

Presenter Notes

useless name !

Rappel:

1 nom_du_state:
2   module_python.fonction_python:
3     - name: <name>
4     - clef_2: argument_2
5     - clef_3: argument_3
6     ...

Tous les states salt acceptent comme premier argument "name", c'est une convention. Donc ils ont décidé qu'on pouvait écrire ça comme ça:

1 <name>:
2   module_python.fonction_python:
3     - clef_2: argument_2
4     - clef_3: argument_3
5     ...

Aussi possible (si pas d'arguments):

1 <name>:
2   module_python.fonction_python

Presenter Notes

encore plus !

Rappel:

1 nom_du_state:
2   module_python.fonction_python:
3     - name: <name>
4     ...

Ils ont aussi décidé qu'on avait le droit d'écrire ça comme ça:

1 nom_du_state:
2   module_python:
3     - fonction_python
4     - name: <name>
5     ...

Utilise uniquement ici:

1 nom_du_state:
2   module_python_1:
3     - fonction_python_1
4   module_python_2:
5     - fonction_python_2

Car ceci est illégale en yaml:

1 nom_du_state:
2   module_python_1.fonction_python_1
3   module_python_2.fonction_python_2

Presenter Notes

jinaj2

Vous pouvez utiliser du jinja2 (un système de tempalting python similaire à celui de django) directement dans vos states.

Exemple:

1 {% for pkg in ['git', 'svn', 'hg'] %}
2 {{ pkg }}:
3   pkg.installed
4 {% endfor %}

Remarque: ne codez pas ça, y a un moyen bien plus simple de le faire.

Presenter Notes

Ordonner les states

Presenter Notes

Ordre d'execution des states

NOUVEAU: désormait les fichiers .sls sont executé séquentiellement, ce n'était pas le cas avant.

Il est possible de créé des dépendances d'excution entre state avec "require" et "require_in".

ATTENTION: syntaxe confusante:

1 service apache2 start:
2   cmd.run:
3     - require:
4       - pkg: apache-fpm-prefork

Ici "require" n'est PAS un argument pour l'appel de la fonction python.

"require_in" fait l'inverse de "require", il dit "je suis nécessaire pour ce state" ("require" dit "j'ai besoin de ce state").

Presenter Notes

Gestion des événements

Presenter Notes

Retour d'un state

Chaque state peut revenir dans 3 états différents:

  • erreur (rouge): je me suis torché
  • ok (vert): je suis déjà dans l'état désiré
  • j'ai du agir pour passer dans l'état désiré (bleu)

C'est le dernier qui est intéressant car il permet de triggerer un autre state grâce à "watch" et "watch_in".

Exemple: si on répertoire git a été mis à jours, je veux lancer un collectstatic (django).

 1 git://pouet.com/pouet.git:
 2   git.latest:
 3     - target: /home/moi/pouet
 4 
 5 python manage.py collectstatic --noinput:
 6   cmd.wait:
 7     - cwd: /home/moi/pouet
 8     - user: moi
 9     - watch:
10       - git: git://pouet.com/pouet.git

Remarque: ici non plus, "watch" et "watch_in" ne sont PAS des arguments pour la fonction.

Remarque: y a un mod_watch qui existe parfois dans certains states pour faire une action spécial si jamais ils sont appelé via un watch (par exemple "service.running").

Presenter Notes

Et voilà, il faut juste savoir ça !

Presenter Notes

Liste de states cool

Presenter Notes

User

 1 fred:
 2   user.present:
 3     - fullname: Fred Jones
 4     - shell: /bin/zsh
 5     - home: /home/fred
 6     - uid: 4000
 7     - gid: 4000
 8     - groups:
 9       - wheel
10       - storage
11       - games

Remarque: user.absent existe aussi

Exemple de doc: http://docs.saltstack.com/ref/states/all/salt.states.user.html#module-salt.states.user

Presenter Notes

pkg.installed

1 vim:
2   pkg.installed

Remarque: salt va automagiquement aller choisir votre gestionnaire de pkg (marche pour apt et yum en tout cas).

Astuce, vous avez le droit d'écrire:

1 mes_pkgs:
2   pkg.installed:
3     - names:
4       - vim
5       - emacs
6       - nano

Presenter Notes

file.managed

 1 /etc/http/conf/http.conf:
 2   file.managed:
 3     - source: salt://apache/http.conf
 4     - user: root
 5     - group: root
 6     - mode: 644
 7     - template: jinja
 8     - defaults:
 9         custom_var: "default value"
10         other_var: 123

Existe aussi: file.directory, file.symlink, file.exists et beaucoup d'autres.

Remarque: on peut aussi mettre une url combiné avec un hash du fichier.

Presenter Notes

git.latest

1 https://github.com/saltstack/salt.git:
2   git.latest:
3     - rev: develop
4     - target: /tmp/salt

Presenter Notes

cmd.run et cmd.wait

Super pratique !

1 service apache2 reload:
2   cmd.wait:
3     - watch:
4       - git: <url de mon super projet>
5 
6 python manage.py collectstatic:
7   cmd.run:
8     - unless: ls /path/vers/les/statics

Presenter Notes

cron.present

1 date > /tmp/crontest:
2   cron.present:
3     - user: root
4     - minute: 7
5     - hour: 2

Presenter Notes

Divers

  • au début on a parfois du mal à savoir quoi faire car c'est une autre façon de penser. Basiquement c'est généralement coder en state exactement ce qu'on aurait fait à la main PLUS ce qu'il faut faire pour une mis à jours (à coup de watch).

  • vous pouvez aussi écrire vos states en:

    • full python
    • dans un dsl python
    • en json
    • en yaml/mako
    • voir écrire votre propre renderer
    • mais yaml/jinja2 convient dans l'imense majorité des cas
  • vous pouvez écrire le truc appelé par vos states, c'est vraiment pas difficile

  • pareil pour les modules
  • hésitez pas à aller voir le code

  • y a BEACOUP plus que ce que je vous ai montré, vraiment (pillar, grains, include, gitfs, se parler entre minions etc ...)

En fait, quasiment tout est customisable dans salt, mais les defaults sont suffisant.

Presenter Notes

Exercice: ce que vous voulez

Propositions: déployer un projet django classique (genre carnet-rose) avec toute la stack déployer un projet django plus avancé: hacker agenda utiliser salt pour gérer la config de votre machine (user, dotfiles, pkgs, config de vos apps) vos idées

Remarque: apprennez direct à utiliser la documentation (demo).

Presenter Notes

Rappel

  • commencer par installer salt
  • configuer le master/minion si nécessaire
  • essayer de faire un test.ping
  • écrire votre /srv/salt/top.sls
  • faire votre premier state (commencez par foutre votre utilisateur ou installer des pkgs par exemple)

Presenter Notes