C'est quoi ?
Mais aussi:
Remarque: peut avoir plusieurs master en mode client-serveur
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
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:
rappel: une fois que les states sont ecrit, pour les "executer" utiliser le module state.highstate
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, ...)
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 ...
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
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
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.
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").
Chaque state peut revenir dans 3 états différents:
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").
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
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
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.
1 https://github.com/saltstack/salt.git:
2 git.latest:
3 - rev: develop
4 - target: /tmp/salt
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
1 date > /tmp/crontest:
2 cron.present:
3 - user: root
4 - minute: 7
5 - hour: 2
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:
vous pouvez écrire le truc appelé par vos states, c'est vraiment pas difficile
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.
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).
| Table of Contents | t |
|---|---|
| Exposé | ESC |
| Full screen slides | e |
| Presenter View | p |
| Source Files | s |
| Slide Numbers | n |
| Toggle screen blanking | b |
| Show/hide slide context | c |
| Notes | 2 |
| Help | h |