====== SaltStack ======
  * {{:tuto:linux:install-saltstack.pdf|Tuto 1}}
  * [[https://blog.talpor.com/2014/07/saltstack-beginners-tutorial/|Tuto 2]]
  * Tuto 3 :
    * https://docs.saltstack.com/en/latest/
    * https://docs.saltstack.com/en/getstarted/overview.html
    * https://docs.saltstack.com/en/getstarted/fundamentals/index.html
  * [[https://www.youtube.com/watch?v=8yDML4CbXH0|Tuto Video 1]]

  * [[https://github.com/saltstack/salt/wiki/Cheat-Sheet|Pense bête rapide]]
===== Configurer le master =====
<code>
$ systemctl start salt-master
$ systemctl enable salt-master
</code>

===== Configurer le minion =====
  * Editer le fichier ''/etc/salt/minion.d/master.conf'' et indiquer lui votre master :
<code>
master: salt-master
</code>

  * On démarre et active au boot le service :
<code>
$ systemctl start salt-minion
$ systemctl enable salt-minion
</code>

  * On voit apparaître portable.localdomain dans les liste des minions qui n'ont pas encore été acceptés :
<code>
salt-key -L a        
Accepted Keys:
Denied Keys:
Unaccepted Keys:
portable.localdomain
</code>

  * On génère une fingerprint pour ce minion sur le minion :
<code>
salt-call key.finger --local
local:
    14:e6:21:3b:0c:f9:0a:96:ea:5a:69:bb:2e:82:b4:c7:18:3c:4f:09:40:d2:46:8f:f9:09:e9:81:87:15:1a:0f
</code>

  * On donne cette figerprint à portable.localdomain :
<code>
salt-key -f portable.localdomain
Unaccepted Keys:
portable.localdomain:  14:e6:21:3b:0c:f9:0a:96:ea:5a:69:bb:2e:82:b4:c7:18:3c:4f:09:40:d2:46:8f:f9:09:e9:81:87:15:1a:0f
</code>

  * Puis on accepte la clé :
<code>
salt-key -a portable.localdomain
The following keys are going to be accepted:
Unaccepted Keys:
portable.localdomain
Proceed? [n/Y] 
Key for minion portable.localdomain accepted.
</code>

  * On vérifie les clés :
<code>
salt-key -L a
[sudo] Mot de passe de gigix : 
Accepted Keys:
portable.localdomain
Denied Keys:
Unaccepted Keys:
Rejected Keys:
</code>

  * On vérifie le fonctionnement :
<code>
sudo salt 'portable.localdomain' test.ping
portable.localdomain:
    True
</code>

  * Sécurisons le minion avec la fingerprint du master. On récupère sa fingerprint publique :
<code>
salt-key -f master.pub
Local Keys:
master.pub:  1b:5e:6d:ae:20:65:dd:f1:62:0b:9b:85:eb:3a:38:8d:ec:d6:cf:98:06:3d:ca:65:fb:a7:dd:c6:86:15:bb:96
</code>

  * On édite le fichier ''/etc/salt/minion.d/master.conf'' :
<code>
master: localhost
master_finger: '1b:5e:6d:ae:20:65:dd:f1:62:0b:9b:85:eb:3a:38:8d:ec:d6:cf:98:06:3d:ca:65:fb:a7:dd:c6:86:15:bb:96'
</code>

  * On restart le service :
<code>
systemctl restart salt-minion
</code>

  * On teste à nouveau :
<code>
salt 'portable.localdomain' test.ping 
portable.localdomain:
    True
</code>

===== Afficher les clés =====
  * La clé locale du minion:
<code>
salt-call key.finger --local
local:
    14:e6:21:3b:0c:f9:0a:96:ea:5a:69:bb:2e:82:b4:c7:18:3c:4f:09:40:d2:46:8f:f9:09:e9:81:87:15:1a:0f
</code>

  * Les clés du master :
<code>
salt-key -F                                           
Local Keys:
master.pem:  83:9f:f3:37:c6:6c:f8:55:5e:84:c7:60:4d:10:59:ce:a2:81:23:47:1a:bf:df:c1:6f:f1:3f:85:48:ee:8a:b0
master.pub:  1b:5e:6d:ae:20:65:dd:f1:62:0b:9b:85:eb:3a:38:8d:ec:d6:cf:98:06:3d:ca:65:fb:a7:dd:c6:86:15:bb:96
Accepted Keys:
portable.localdomain:  14:e6:21:3b:0c:f9:0a:96:ea:5a:69:bb:2e:82:b4:c7:18:3c:4f:09:40:d2:46:8f:f9:09:e9:81:87:15:1a:0f
</code>
===== Rafraichir les Pillar / Grains / .. =====
Les pillars sont chargés quand le minion démarre, ou on peu le faire manuellement :
<code>
salt '*' saltutil.refresh_pillar
salt '*' saltutil.refresh_grains
</code>

Tout resynchroniser :
<code>
salt '*' saltutil.sync_all
</code>

===== Exemples =====
**Client en standalone (serverless) :**
<code>
salt-call --local grains.items
</code>

**Exécution sur le master** :
<code>
salt-run test.foo
</code>

**Exécution vers un cloud provider** (https://docs.saltstack.com/en/latest/topics/cloud/index.html) :
<code>
salt-cloud
</code>

**Client vers serveur :**
<code>
salt-call grains.items
</code>

**Serveur vers clients via SSH (agentless) :**
<code>
salt-ssh -i --roster-file=./roster 'node1' test.ping
</code>

Exemple de fichier roster ([[https://docs.saltstack.com/en/latest/topics/ssh/roster.html|toutes les options du fichier roster]]) :
<code>
node1:
    host: 192.168.122.1
    user: root
    priv: /root/.ssh/id_rsa
</code>

**Serveur vers clients via client salt :**
<code>
salt '*' cmd.run 'ls -l /etc'
salt '*' test.ping
</code>

**Autres :**
<code>
salt '*' cmd.run 'echo "Hello: $FIRST_NAME"' saltenv='{FIRST_NAME: "Joe"}'
</code>

<code>
salt myminion grains.item pythonpath --out=pprint
</code>

<code>
salt '*' cp.get_file salt://vimrc /etc/vimrc
salt '*' cp.get_file "salt://{{grains.os}}/vimrc" /etc/vimrc template=jinja
</code>

<code>
salt '*' -b 10 test.ping
salt -G 'os:RedHat' --batch-size 25% apache.signal restart
</code>

<code>
base:
  'not webserv* and G@os:Debian or E@web-dc1-srv.* and ( ms-1 or G@id:ms-3 ) or J|@foo|bar|^foo:bar$':
    - match: compound
    - webserver
</code>

===== Documentation =====
States :
<code>
salt '*' sys.doc
salt '*' sys.doc cmd
salt '*' sys.doc cmd.run
</code>

Runner :
<code>
salt-run doc.runner
</code>

===== Structure d'un SLS =====
<code yaml>
<Include Declaration>:
  - <Module Reference>
  - <Module Reference>

<Extend Declaration>:
  <ID Declaration>:
    [<overrides>]


# standard declaration

<ID Declaration>:
  <State Module>:
    - <Function>
    - <Function Arg>
    - <Function Arg>
    - <Function Arg>
    - <Name>: <name>
    - <Requisite Declaration>:
      - <Requisite Reference>
      - <Requisite Reference>


# inline function and names

<ID Declaration>:
  <State Module>.<Function>:
    - <Function Arg>
    - <Function Arg>
    - <Function Arg>
    - <Names>:
      - <name>
      - <name>
      - <name>
    - <Requisite Declaration>:
      - <Requisite Reference>
      - <Requisite Reference>


# multiple states for single id

<ID Declaration>:
  <State Module>:
    - <Function>
    - <Function Arg>
    - <Name>: <name>
    - <Requisite Declaration>:
      - <Requisite Reference>
  <State Module>:
    - <Function>
    - <Function Arg>
    - <Names>:
      - <name>
      - <name>
    - <Requisite Declaration>:
      - <Requisite Reference>
</code>

  * Corrrecte :
<code yaml>
httpd:
  pkg.installed: []
</code>

Ou 

<code yaml>
httpd:
  pkg:
    - installed
</code>

<code yaml>
httpd:
  pkg.installed: []
  service.running: []
</code>

<code yaml>
ius:
  pkgrepo.managed:
    - humanname: IUS Community Packages for Enterprise Linux 6 - $basearch
    - gpgcheck: 1
    - baseurl: http://mirror.rackspace.com/ius/stable/CentOS/6/$basearch
    - gpgkey: http://dl.iuscommunity.org/pub/ius/IUS-COMMUNITY-GPG-KEY
    - names:
        - ius
        - ius-devel:
            - baseurl: http://mirror.rackspace.com/ius/development/CentOS/6/$basearch
</code>

  * Incorrecte :
<code yaml>
httpd:
  pkg.installed
  service.running
</code>

===== Exécution des sls =====
  * Exécuter toutes les SLS :
<code>
salt '*' state.apply 
</code>

  * Exécuter la sls gigix :
<code>
salt '*' state.apply gigix
</code>

  * Avec des paramètres et plusieurs sls :
<code>
salt '*' state.apply mysls1,mysls2 test=true saltenv=dev pillarenv=dev pillar='{"key": "val"}' exclude="[{'id': 'id_to_exclude'}, {'sls': 'sls_to_exclude'}]"
</code>

  * Avec targetting par Pillar :
<code>
salt --pillar 'webserver_role:dev' state.apply
</code>

  * Seulement un id d'une sls :
<code>
salt-call --local --file-root=$PWD state.sls_id this_state_will_return_changes test
local:
----------
          ID: this_state_will_return_changes
    Function: test.succeed_with_changes
      Result: True
     Comment: Success!
     Started: 00:38:08.528352
    Duration: 0.287 ms
     Changes:   
              ----------
              testing:
                  ----------
                  new:
                      Something pretended to change
                  old:
                      Unchanged

Summary for local
------------
Succeeded: 1 (changed=1)
Failed:    0
------------
Total states run:     1
Total run time:   0.287 ms
</code>

===== Targeting =====
https://docs.saltstack.com/en/latest/ref/states/top.html#advanced-minion-targeting
  * globbing sur le nom des minions :
<code>
salt 'web[1-5]' test.ping
salt 'web[1,3]' test.ping
salt '*.example.*' test.ping
salt 'web?.example.net' test.ping
</code>

<code yaml>
base:
  'web[1,3]':
  - match: glob
  - webserver
</code>

  * regexp sur le nom des minions
<code>
salt -E 'web1-(prod|devel)' test.ping
</code>

<code yaml>
base:
  'web1-(prod|devel)':
  - match: pcre
  - webserver
</code>

  * Liste de minion :
<code>
salt -L 'web1,web2,web3' test.ping
</code>

<code yaml>
base:
  'web1,web2,web3':
  - match: list
  - webserver
</code>

  * Grain :
<code>
salt -G 'os:Fedora' test.ping
</code>

<code yaml>
'node_type:webserver':
  - match: grain
  - webserver
</code>

  * Grain avec regexp :
<code>
salt 'P@os:(RedHat|Fedora|CentOS)' test.ping
</code>

<code yaml>
'os:Fedo.*':
  - match: grain_pcre
  - webserver
</code>

  * Pillar exacte :
<code yaml>
'cheese:foo':
  - match: pillar_exact
  - webserver
</code>

  * Pillar globing :
<code>
salt -I 'somekey:specialvalue' test.ping
salt -I 'foo:bar:baz*' test.ping
</code>

<code yaml>
'cheese:foo:baz*':
  - match: pillar
  - webserver
</code>

  * Pillar avec regexp :
<code>
salt 'J@pdata:^(foo|bar)$' test.ping
</code>

<code yaml>
'cheese:(swiss|american)':
  - match: pillar_pcre
  - webserver
</code>

  * Groupes (les nodesgroups sont à déclarer dans le fichier ''/etc/salt/master'') :
<code>
nodegroups:
  group1: 'L@foo.domain.com,bar.domain.com,baz.domain.com and bl*.domain.com'
  group2: 'G@os:Debian and foo.domain.com'
  group3: 'G@os:Debian and N@group1'
</code>

<code yaml>
base:
  group1:
    - match: nodegroup
    - webserver
</code>

  * Network :
<code>
salt -S 192.168.40.20 test.ping
salt -S 2001:db8::/64 test.ping
</code>

<code yaml>
'172.16.0.0/12':
   - match: ipcidr
   - internal
</code>

  * Multiples :
<code>
salt -C 'G@os:Debian and webser* or E@db.*' test.ping
salt -C '* and not G@kernel:Darwin' test.ping
salt -C '( ms-1 or G@id:ms-3 ) and G@id:ms-3' test.ping
</code>

<code yaml>
base:
  'webserv* and G@os:Debian or E@web-dc1-srv.*':
    - match: compound
    - webserver
</code>

  * Range cluster (non supporté de base) :
<code>
salt 'R@%test:APPS' test.ping
</code>

<code yaml>
CLUSTER: host1..100.test.com
APPS:
  - frontend
  - backend
  - mysql
</code>

  * data ([[https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.data.html#module-salt.modules.data|avec le minion datastore]]) :
===== Désactiver un sls =====
<code>
salt '*' state.disable mysql
</code>

Pour lister ceux qui ont été désactivés :
<code>
salt '*' state.list_disabled
</code>

===== Réactiver un sls =====
<code>
salt '*' state.enable gigix
</code>

===== Voir les sls =====
<code>
salt '*' state.show_highstate
salt '*' state.show_lowstate
salt '*' state.show_low_sls foo saltenv=dev
salt '*' state.show_sls core,edit.vim dev
</code>


Voir le contenu top sls des serveurs :
<code>
salt '*' state.show_top
</code>
===== Voir les sls en cours d'exécution =====
<code>
salt '*' state.running
local:
    - The function "state.apply" is running as PID 13972 and was started at 2018, Mar 03 13:14:07.242163 with jid 20180303131407242163
</code>

===== Voir les statistiques d'exécution des sls =====
<code>
salt '*' state.show_state_usage
</code>

===== Récupérer une variable =====
  * Récupérer un Pillar :
<code>
{{ salt['pillar.get']('foo:bar:baz', 'qux') }}
</code>

  * Récupérer un Grain :
<code>
{{ salt['grains.get']('node_type', '') }}
</code>

===== Lister Pillar / Grains =====
  * Grains :
<code>
salt '*' grains.items
</code>

  * Pillar
<code>
salt '*' pillar.items
</code>

===== Définir une variable =====
  * Définir une variable :
<code>
{% set the_node_type = salt['grains.get']('node_type', '') %}
</code>


<code>
{% set name = {
    'RedHat': 'httpd',
    'Debian': 'apache2',
}.get(grains.os_family) %}
</code>
===== Executer un module =====
  * Appeler un module :
<code yaml>
{{ salt['module.function_name']('argument_1', 'argument_2') }}
{{ salt['cmd.run']('pgrep -f redis-server') }}
</code>

===== Conditions =====
<code yaml>
{% set ethhb = salt['pillar.get']('eth-hb', 'bond1') %}
{% if grains['ip4_interfaces'][ethhb][0].startswith('192.168.1.') %}
  host.present:
    - ip: {{ grains['ip4_interfaces'][ethhb][0] }}
    - names:
      - {{ grains['host'] }}-hb
{% else %}
    cmd.run:
      - name: "echo '{{ ethhb }} is not properly configured !'; exit 1"
{% endif %}
</code>

===== Boucles =====
<code yaml>
{% for user, uid in pillar.get('users', {}).items() %}
{{user}}:
  user.present:
    - uid: {{uid}}
{% endfor %}
</code>

===== Macro =====
La maccro est une sorte de fonction :
<code yaml>
# macro message
{% macro message(name, comment, changes=False, result=False, failhard=True) -%} 
pacemaker-{{ sls }}-{{ name }}: 
  test.configurable_test_state:
    - name: pacemaker-{{ sls }}-{{ name }}
    - changes: {{ changes }}
    - result: {{ result }}
    - comment: {{ comment }}
    - failhard: {{ failhard }}
{%- endmacro %}

{{ message('error-test', 'mon erreur !!!', failhard=False) }}
</code>
===== Quitter lors d'une erreur =====
Avec l'option **failhard** :
<code yaml>
/etc/yum.repos.d/company.repo:
  file.managed:
    - source: salt://company/yumrepo.conf
    - user: root
    - group: root
    - mode: 644 
    - order: 1
    - failhard: True
</code>

===== Ordonnancement =====
L'ordonnancement est possible grâce à **require** ou **require_in** (sa dépendance inversée) :
<code yaml>
httpd:
  pkg.installed: []
  service.running:
    - require:
      - pkg: httpd
      - sls: network
</code>

<code yaml>
vim:
  pkg.installed:
    - require_in:
      - file: /etc/vimrc

/etc/vimrc:
  file.managed:
    - source: salt://edit/vimrc
</code>

On peu également faire appel à ''order'' :
<code yaml>
apache:
  pkg.installed:
    - name: httpd
    - order: 1
</code>

Pour désigner le dernier : ''order: last'' ou ''order: -1''.
===== Exécution sur changement =====
  * https://docs.saltstack.com/en/latest/ref/states/requisites.html

L'exécution sur changement est possible grâce à **onchanges** ou **onchanges_in** (sa dépendance inversée).
S'exécute seulement si le résultat de l'exécution cible est un succès et si la cible a des changements :
<code yaml>
Deploy server package:
  file.managed:
    - name: /usr/local/share/myapp.tar.xz
    - source: salt://myapp.tar.xz

Extract server package:
  archive.extracted:
    - name: /usr/local/share/myapp
    - source: /usr/local/share/myapp.tar.xz
    - archive_format: tar
    - onchanges:
      - file: Deploy server package
</code>

<code yaml>
# (Archive arguments omitted for simplicity)

# Match by ID declaration
Extract server package:
  archive.extracted:
    - onchanges:
      - file: Deploy server package

# Match by name parameter
Extract server package:
  archive.extracted:
    - onchanges:
      - file: /usr/local/share/myapp.tar.xz
</code>


Cela se fait également avec **watch** et **watch_in**. **watch** agit comme **require**, mais ajoute un comportement supplémentaire (mod_watch). C'est à dire que si le module à une fonction //mod_watch//alors celle-ci sera appellée. Tous les modules n'ont pas de fonction //mod_watch// et s'exécuteront donc comme un simple **require** :
<code yaml>
ntpd:
  service.running:
    - watch:
      - file: /etc/ntp.conf
  file.managed:
    - name: /etc/ntp.conf
    - source: salt://ntp/files/ntp.conf
</code>

On peu également le faire avec [[https://docs.saltstack.com/en/latest/ref/states/requisites.html#listen-listen-in|listen /listen_in]].

Contrairement à [[https://docs.saltstack.com/en/latest/ref/states/requisites.html#watch|watch et watch_in]], listen et listen_in ne modifieront pas l'ordre des états et peuvent être utilisés pour s'assurer que vos états sont exécutés dans l'ordre dans lequel ils sont définis.

<code yaml>
restart-apache2:
  service.running:
    - name: apache2
    - listen:
      - file: /etc/apache2/apache2.conf

configure-apache2:
  file.managed:
    - name: /etc/apache2/apache2.conf
    - source: salt://apache2/apache2.conf
</code>

<code yaml>
restart-apache2:
  service.running:
    - name: apache2

configure-apache2:
  file.managed:
    - name: /etc/apache2/apache2.conf
    - source: salt://apache2/apache2.conf
    - listen_in:
      - service: apache2
</code>

Il y a aussi **prereq** et **prereq_in** expliqué [[https://docs.saltstack.com/en/latest/ref/states/requisites.html#prereq|ici]].

===== Gestion des erreurs =====
La gestion des erreurs est possible grâce à **onfail** ou **onfail_in** (sa dépendance inverse).
<code yaml>
primary_mount:
  mount.mounted:
    - name: /mnt/share
    - device: 10.0.0.45:/share
    - fstype: nfs

backup_mount:
  mount.mounted:
    - name: /mnt/share
    - device: 192.168.40.34:/share
    - fstype: nfs
    - onfail:
      - mount: primary_mount
</code>

===== Héritage d'arguments =====
L'héritage est possible grâce à **use** ou **use_in** (sa dépendance inverse).

Dans cet exemple ''/etc/bar.conf'' va prendre les même arguments que ''/etc/foo.conf'' sauf pour la ''source'' qu'il aura redéfini:
<code yaml>
/etc/foo.conf:
  file.managed:
    - source: salt://foo.conf
    - template: jinja
    - mkdirs: True
    - user: apache
    - group: apache
    - mode: 755

/etc/bar.conf
  file.managed:
    - source: salt://bar.conf
    - use:
      - file: /etc/foo.conf
</code>

===== Exécuter en tant que =====
L'exécution **en tant que** est possible grâce à **runas** ou **runas_in** (sa dépendance inverse).

<code yaml>
django:
  pip.installed:
    - name: django >= 1.6, <= 1.7
    - runas: daniel
    - require:
      - pkg: python-pip

run_script:
  cmd.run:
    - name: Powershell -NonInteractive -ExecutionPolicy Bypass -File C:\\Temp\\script.ps1
    - runas: frank
    - runas_password: supersecret
</code>

===== unless / onlyif =====
**unless** et **onlyif** lance des commandes shell.

Dans l'exemple ci-dessous, vim sera installé quand **toutes les conditions seront fausses** :
<code yaml>
vim:
  pkg.installed:
    - unless:
      - rpm -q vim-enhanced
      - ls /usr/bin/vim
</code>

**onlyif** est l'inverse qui signifie quand **toutes les conditions serons vraies**.

===== checkcmd =====
**checkcmd** permet de vérifier l'état attendu :
<code yaml>
comment-repo:
  file.replace:
    - name: /etc/yum.repos.d/fedora.repo
    - pattern: ^enabled=0
    - repl: enabled=1
    - check_cmd:
      - ! grep 'enabled=0' /etc/yum.repos.d/fedora.repo
</code>

===== retry =====
L'option [[https://docs.saltstack.com/en/latest/ref/states/requisites.html#retrying-states|retry]] lui permet d'être exécuté plusieurs fois jusqu'à ce qu'un résultat souhaité soit obtenu ou que le nombre maximum de tentatives ait été atteint.

Le paramètre **attemps** contrôle le nombre maximum de fois que l'état sera exécuté. S'il n'est pas spécifié ou si une valeur non valide est spécifiée, la valeur par défaut sera 2.

Le paramètre **until** définit le résultat requis pour arrêter de réessayer l'état. Si non spécifié ou si une valeur non valide est spécifiée alors la valeur par défaut sera True.

Le paramètre **interval** définit la durée, en secondes, pendant laquelle le système attendra entre les tentatives. Si elle n'est pas spécifiée ou si une valeur non valide est spécifiée, la valeur par défaut sera 30.

Le paramètre **splay** permet d'étendre l'intervalle. Si elle n'est pas spécifiée ou si une valeur non valide est spécifiée, la valeur par défaut est 0 (c'est-à-dire qu'il n'y aura pas d'intervalle).

<code yaml>
my_retried_state:
  pkg.installed:
    - name: nano
    - retry:
        attempts: 5
        until: True
        interval: 60
        splay: 10
</code>

<code yaml>
install_nano:
  pkg.installed:
    - name: nano
    - retry: True
</code>

<code yaml>
wait_for_file:
  file.exists:
    - name: /path/to/file
    - retry:
        attempts: 15
        interval: 30
</code>

===== include / exclude =====
Fichier ''ssh/init.sls'' :
<code yaml>
openssh-client:
  pkg.installed

/etc/ssh/ssh_config:
  file.managed:
    - user: root
    - group: root
    - mode: 644
    - source: salt://ssh/ssh_config
    - require:
      - pkg: openssh-client
</code>

Fichier ''ssh/server.sls'' :
<code yaml>
include:
  - ssh

openssh-server:
  pkg.installed

sshd:
  service.running:
    - require:
      - pkg: openssh-client
      - pkg: openssh-server
      - file: /etc/ssh/banner
      - file: /etc/ssh/sshd_config

/etc/ssh/sshd_config:
  file.managed:
    - user: root
    - group: root
    - mode: 644
    - source: salt://ssh/sshd_config
    - require:
      - pkg: openssh-server

/etc/ssh/banner:
  file:
    - managed
    - user: root
    - group: root
    - mode: 644
    - source: salt://ssh/banner
    - require:
      - pkg: openssh-server
</code>

Fichier ''ssh/custom-server.sls'' :
<code yaml>
include:
  - ssh.server

extend:
  /etc/ssh/banner:
    file:
      - source: salt://ssh/custom-banner
</code>

On peut également exclure un id ou un sls :
<code yaml>
exclude:
  - sls: http
  - id: /etc/vimrc
</code>

===== provider =====
Il est de changer le comportement en spécifiant un provider. Par exemple systemd est le provider par défaut pour les services. Si on souhaite passer par init, on utilisera le provider service.
<code yml>
httpd:
  service.running:
    - enable: True
    - provider: service
</code>

<code yml>
emacs:
  pkg.installed:
    - provider:
      - cmd: customcmd
</code>
===== parallel =====
Tout est lancé en parallèle et prendra donc 10 secondes à la place de 15 :  
<code yaml>
sleep 10:
  cmd.run:
    - parallel: True

nginx:
  service.running:
    - parallel: True
    - require:
      - cmd: sleep 10

sleep 5:
  cmd.run:
    - parallel: True
</code>
===== backup des changement des fichiers =====
Le fichier ''/etc/salt/minion'' doit contenir la ligne suivant pour êtreactivé : ''backup_mode: minion''.

<code>
/etc/ssh/sshd_config:
  file.managed:
    - source: salt://ssh/sshd_config
    - backup: minion
</code>

  * Pour lister les backups :
<code>
salt foo.bar.com file.list_backups /tmp/foo.txt
foo.bar.com:
    ----------
    0:
        ----------
        Backup Time:
            Sat Jul 27 2013 17:48:41.738027
        Location:
            /var/cache/salt/minion/file_backup/tmp/foo.txt_Sat_Jul_27_17:48:41_738027_2013
        Size:
            13
    1:
        ----------
        Backup Time:
            Sat Jul 27 2013 17:48:28.369804
        Location:
            /var/cache/salt/minion/file_backup/tmp/foo.txt_Sat_Jul_27_17:48:28_369804_2013
        Size:
            35
</code>

  * Pour restaurer un backup :
<code>
salt foo.bar.com file.restore_backup /tmp/foo.txt 1
</code>

  * Pour supprimer un backup :
<code>
salt foo.bar.com file.delete_backup /tmp/foo.txt 0
</code>

===== high / low state =====
  * High :
Lors de la définition de formules salt dans YAML, les données représentées sont appelées High Data par le compilateur. Lorsque les données sont initialement chargées dans le compilateur, il s'agit d'un seul grand dictionnaire python, ce dictionnaire peut être vu en exécutant :
<code>
salt '*' state.show_highstate
salt '*' state.show_highstate --out yaml
salt '*' state.show_sls edit.vim --out pprint
</code>

  * Low :
Cette structure "High Data" est ensuite compilée jusqu'au "Low Data". Les données basses correspondent à ce qui est nécessaire pour créer des exécutions individuelles dans le système de gestion de la configuration de Salt. Les données faibles sont une liste ordonnée d'appels d'état unique à exécuter. Les données faibles sont une liste ordonnée d'appels à état unique à exécuter. Une fois que les données sont compilées, l'ordre d'évaluation peut être vu. Les lowstates peuvent être visualisées en exécutant:
<code>
salt '*' state.show_lowstate
salt '*' state.low '{name: vim, state: pkg, fun: installed}'
</code>

===== Définir un Pillar =====
Les pillar sont à définir dans le fichier ''/srv/pillar/top.sls''.

Exemples :
<code yaml>
{{ saltenv }}:
  '*':
     - common_pillar
</code>

<code yaml>
base:
  '*':
    - apache
dev:
  'os:Debian':
    - match: grain
    - vim
test:
  '* and not G@os: Debian':
    - match: compound
    - emacs
</code>

Fichier ''/srv/pillar/apache.sls'' :
<code yaml>
apache:
  lookup:
    name: httpd
    config:
      tmpl: salt://apache/files/httpd.conf
</code>

Exemple pour y faire appel :
<code yaml>
{{ salt['pillar.get']('apache:lookup:name') }}
</code>
===== Gestion des états de retour =====
<code yaml>
always-passes-with-any-kwarg:
  test.nop:
    - name: foo
    - something: else
    - foo: bar

always-passes:
  test.succeed_without_changes:
    - name: foo

always-fails:
  test.fail_without_changes:
    - name: foo

always-changes-and-succeeds:
  test.succeed_with_changes:
    - name: foo

always-changes-and-fails:
  test.fail_with_changes:
    - name: foo

my-custom-combo:
  test.configurable_test_state:
    - name: foo
    - changes: True
    - result: False
    - comment: bar.baz

is-pillar-foo-present-and-bar-is-int:
  test.check_pillar:
    - present:
        - foo
    - integer:
        - bar

this_state_will_return_changes:
  test.succeed_with_changes

this_state_will_NOT_return_changes:
  test.succeed_without_changes

this_state_is_watching_another_state:
  test.succeed_without_changes:
    - comment: 'This is a custom comment'
    - watch:
      - test: this_state_will_return_changes
      - test: this_state_will_NOT_return_changes

this_state_is_also_watching_another_state:
  test.succeed_without_changes:
    - watch:
      - test: this_state_will_NOT_return_changes
</code>

===== Gestion des environnements de configuration =====
Il prend le premier et s'il ne trouve pas il passe au suivant :
<code>
file_roots:
  base:
    - /srv/salt/prod
  qa:
    - /srv/salt/qa
    - /srv/salt/prod
  dev:
    - /srv/salt/dev
    - /srv/salt/qa
    - /srv/salt/prod
</code>

===== Jinja =====
https://docs.saltstack.com/en/latest/topics/jinja/index.html

==== map jinja ====
On appellera ces fichiers **map.jinja**.

<code yaml>
{% set apache = salt['grains.filter_by']({
    'Debian': {
        'server': 'apache2',
        'service': 'apache2',
        'conf': '/etc/apache2/apache.conf',
    },
    'RedHat': {
        'server': 'httpd',
        'service': 'httpd',
        'conf': '/etc/httpd/httpd.conf',
    },
}, merge=salt['pillar.get']('apache:lookup')) %}
</code>

<code yaml>
{% set htop = salt['grains.filter_by']({
    'Suse': {
        'pattern': salt['grains.filter_by']({
            '12.3': 'htop',
            'default': 'htop',
        }, grain='osrelease'),
    },
    'default': {
        'pattern': 'htop'
    },
}, grain='os') %}
</code>

On chargera par exemple le fichier ''apache/map.jinja'' dans un fichier sls de la façon suivante :
<code yaml>
{% from "apache/map.jinja" import apache with context %}

apache:
  pkg.installed:
    - name: {{ apache.server }}
  service.running:
    - name: {{ apache.service }}
    - enable: True
</code>
===== runner =====
<note warning>
**salt-run** est toujours lancé à partir du master !
</note>

==== manage ====
  * Status des minions :
<xtermrtf>
$ salt-run manage.status
down:
    - portable.localdomain
up:
</xtermrtf>

  * Minions down :
<xtermrtf>
$ salt-run manage.down  
- portable.localdomain
</xtermrtf>

  * Minions up :
<xtermrtf>
$ salt-run manage.up    
- portable.localdomain
</xtermrtf>

  * Version du client salstack des minions :
<xtermrtf>
$ salt-run manage.versions            
Master:
    2017.7.3
Up to date:
    ----------
    portable.localdomain:
        2017.7.3
</xtermrtf>
==== orchestrate ====
<code yaml>
# /srv/salt/orch/cleanfoo.sls
cmd.run:
  salt.function:
    - tgt: '*'
    - arg:
      - rm -rf /tmp/foo
</code>

<code>
salt-run state.orchestrate orch.cleanfoo
</code>

<code yaml>
# /srv/salt/orch/webserver.sls
install_nginx:
  salt.state:
    - tgt: 'web*'
    - sls:
      - nginx
</code>

<code>
salt-run state.orchestrate orch.webserver
</code>

<code yaml>
# /srv/salt/orch/web_setup.sls
webserver_setup:
  salt.state:
    - tgt: 'web*'
    - highstate: True
</code>

<code>
salt-run state.orchestrate orch.web_setup
</code>

<code yaml>
# /srv/salt/orch/deploy.sls
create_instance:
  salt.runner:
    - name: cloud.profile
    - prof: cloud-centos
    - provider: cloud
    - instances:
      - server1
    - opts:
        minion:
          master: master1
</code>

<code yaml>
# /srv/salt/orch/deploy.sls
{% set servers = salt['pillar.get']('servers', 'test') %}
{% set master = salt['pillar.get']('master', 'salt') %}
create_instance:
  salt.runner:
    - name: cloud.profile
    - prof: cloud-centos
    - provider: cloud
    - instances:
      - {{ servers }}
    - opts:
        minion:
          master: {{ master }}
</code>

<code>
salt-run state.orchestrate orch.deploy pillar='{"servers": "newsystem1", "master": "mymaster"}'
</code>


<code yaml>
bootstrap_servers:
  salt.function:
    - name: cmd.run
    - tgt: 10.0.0.0/24
    - tgt_type: ipcidr
    - arg:
      - bootstrap

storage_setup:
  salt.state:
    - tgt: 'role:storage'
    - tgt_type: grain
    - sls: ceph
    - require:
      - salt: webserver_setup

webserver_setup:
  salt.state:
    - tgt: 'web*'
    - highstate: True
</code>

===== mine =====
https://docs.saltstack.com/en/latest/topics/mine/index.html

Une mine est identique à un **grains** mais moins statique. En effet celui-ci va être actualisé toutes les **60** minutes par défaut contrairement à un **grains** qui lui est actualisé seulement au démarrage du minion.

On peut changer dans la configuration du minion ''/etc/salt/minion'' la variable **mine_interval** pour modifier le temps de collecte.

La mine se déclare comme un **pillar** avec la fonction **mine_functions**.

<code yaml>
mine_functions:
  test.ping: []
  network.ip_addrs:
    interface: eth0
    cidr: '10.0.0.0/8'
</code>

Pour forcer la maj de toutes les mines :
<code>
salt '*' mine.update
</code>

===== beacons =====
https://docs.saltstack.com/en/latest/topics/beacons/index.html

Les beacons permettent de placer des //hook// sur des événements sur les minions.

Pour créer un beacons, créer le fichier ''/etc/salt/minion.d/beacons.conf'' :
<code yaml>
beacons:
  inotify:
    /etc/important_file: {}
    /opt: {}
</code>

Un autre exemple :
<code yaml>
beacons:
  inotify:
    /etc/important_file: {}
    /opt: {}
    interval: 5
    disable_during_state_run: True
  load:
    1m:
      - 0.0
      - 2.0
    5m:
      - 0.0
      - 1.5
    15m:
      - 0.1
      - 1.0
    interval: 10
</code>

Par exemple si on modifie le fichier ''/etc/important_file'', cela va créer un event que l'on peu surveiller de cette façon sur le master :
<code>
salt-run state.event pretty=true
</code>

Ce qui affichera :
<code>
salt/beacon/larry/inotify//etc/important_file       {
 "_stamp": "2015-09-09T15:59:37.972753",
 "data": {
     "change": "IN_IGNORED",
     "id": "larry",
     "path": "/etc/important_file"
 },
 "tag": "salt/beacon/larry/inotify//etc/important_file"
}
</code>

Un [#reactor] est la réponse du master à fournir à un minion lors d'un event sur un beacons.

===== reactor =====
https://docs.saltstack.com/en/latest/topics/reactor/index.html

<note>
Les reactor sont à configurer sur le master !
</note>

Le reactor est la réponse à fournir aux [[#beacons]].

Sur le master, créer le fichier ''/srv/reactor/revert.sls'' :
<code yaml>
revert-file:
  local.state.apply:
    - tgt: {{ data['data']['id'] }}
    - arg:
      - maintain_important_file
</code>

Il faut maintenant indiquer au reactor d'exécuter le fichier revert sls, pour cela on édite le fichier ''/etc/salt/master.d/reactor.conf'' :
<code yaml>
reactor:
  - salt/beacon/*/inotify//etc/important_file:
    - /srv/reactor/revert.sls
</code>

Exemple de reactor :
<code yaml>
reactor:                            # Master config section "reactor"

  - 'salt/minion/*/start':          # Match tag "salt/minion/*/start"
    - /srv/reactor/start.sls        # Things to do when a minion starts
    - /srv/reactor/monitor.sls      # Other things to do

  - 'salt/cloud/*/destroyed':       # Globs can be used to match tags
    - /srv/reactor/destroy/*.sls    # Globs can be used to match file names

  - 'myco/custom/event/tag':        # React to custom event tags
    - salt://reactor/mycustom.sls   # Reactor files can come from the salt fileserver
</code>

===== Variables utiles =====
  * Configuration du minion :
<code yaml>
{{ opts['cachedir'] }}
</code>

  * Pillar
<code yaml>
{{ salt['pillar.get']('key', 'failover_value') }}
{{ salt['pillar.get']('stuff:more:deeper') }}
</code>

  * Grains:
<code yaml>
{{ salt['grains.get']('os') }}
</code>

  * environnement salt (base par défaut) :
<code yaml>
{{ saltenv }}
</code>

  * nom du sls courant :
<code yaml>
{{ sls }}
</code>

<note>
La variable sls contient la valeur de référence sls et n'est disponible que dans le fichier SLS réel (pas dans les fichiers référencés dans ce SLS). La valeur de référence sls est la valeur utilisée pour inclure les sls dans les fichiers top.sls ou via l'option include.
</note>

  * Chemin du sls :
<code yaml>
{{ slspath }}
</code>

===== Copie de fichier =====
Copie un fichier du master vers les minions :
<code>
salt-cp '*' [ options ] SOURCE [SOURCE2 SOURCE3 ...] DEST
</code>

===== syndic =====
https://docs.saltstack.com/en/latest/topics/topology/syndic.html

salt-syndic permet de compartimenter les minions avec plusieurs masters. Chacun des master gèrent un groupe de minions.

Exemple :
<code>
# salt-key -L
Accepted Keys:
my_syndic
Denied Keys:
Unaccepted Keys:
Rejected Keys:

# salt '*' test.ping
minion_1:
    True
minion_2:
    True
minion_4:
    True
minion_3:
    True
</code>

===== proxy =====
https://docs.saltstack.com/en/latest/topics/proxyminion/index.html

salt-proxy permet de gérer des équipements où on ne peut pas installer de minion comme un switch réseau par exemple.

===== jobs =====
https://docs.saltstack.com/en/latest/topics/jobs/
https://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.jobs.html

  * Affiche les derniers jobs :
<code>
salt-run jobs.list_jobs
</code>

  * Lancer un job :
On le stop avec Ctrl+c mais je job continue:
<code>
sudo salt '*' test.sleep 100                      
^C
Exiting gracefully on Ctrl-c
This job's jid is: 20180304011226668249
The minions may not have all finished running and any remaining minions will return upon completion. To look up the return data for this job later, run the following command:

salt-run jobs.lookup_jid 20180304011226668249:
</code>

  * Savoir le status d'un jobs :
Le job n'a pas fini car il ne retourne rien :
<code>
sudo salt-run jobs.lookup_jid 20180304011226668249

</code>

Le job a terminé quand il retourne quelque chose :
<code>
salt-run jobs.lookup_jid 20180304011226668249
portable.localdomain:
    True
</code>

===== publish =====
https://docs.saltstack.com/en/latest/ref/peer.html
https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.publish.html

Permet à un minion d'exécuter une commande sur un autre.

Créer le fichier ''/etc/salt/master.d/peer.conf'' pour autoriser les master entre eux (cet exemple n'est pas sécurisé et est déconseillé) :
<code yaml>
peer:
  .*:
    - .*
</code>

Redémarrer votre master et tester :
<code>
salt '*' publish.publish '*' test.ping
portable.localdomain:
    ----------
    portable.localdomain:
        True

salt-call publish.publish '*' test.ping               
local:
    ----------
    portable.localdomain:
        True
</code>
===== Commentaires =====
Pour commenter dans un sls il suffit d'utiliser le ''#''.

Pour commenter un block on peu passer en mode jinja avec ''{#'' et ''#}'' :
<code jinja>
{# 
mon commentaire ligne1
mon commentaire ligne2
#} 
</code>

===== Gestion des environnements avec gitfs =====
Editer le fichier de configuration ''/etc/salt/master.d/gitfs.conf'' :
<code>
top_file_merging_strategy: same
state_top_saltenv: base

fileserver_backend:
  #- roots
  - git

gitfs_provider: pygit2

gitfs_remotes:
  - https://github.com/gigi206/salt-test.git
</code>

**roots** correspond aux **file_roots**.

Chaque tag ou branche est accessible avec saltenv :
<xtermrtf>
$ salt '*' state.apply saltenv=test
$ salt '*' state.apply saltenv=base
</xtermrtf>

<note>
La branche **master** correspond au saltenv **base** !
</note>

===== Créer son propre module =====
https://docs.saltstack.com/en/latest/ref/modules/index.html

===== Créer son propre state =====
https://docs.saltstack.com/en/latest/ref/states/writing.html

===== Créer son propre grain =====
https://docs.saltstack.com/en/latest/topics/grains/#writing-grains
===== Client salt en python =====
https://docs.saltstack.com/en/latest/ref/clients/

===== Renderer en python =====
https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.py.html

===== Vars selon context =====
<code>
auth:
    - __path__ (path to your module dir)

modules:
    - __pillar__
    - __salt__
    - __opts__
    - __context__ ({'systemd.sd_booted': True})
    - __grains__

runners:
    - __pillar__
    - __salt__
    - __opts__
    - __grains__

returners:
    - __salt__
    - __opts__
    - __pillar__
    - __grains__

pillars:
    - __salt__ (modules)
    - __opts__
    - __pillar__
    - __grains__

# nothing
tops:
    - ['__builtins__', '__file__', 'subprocess', 'yaml', '__name__', '__package__', '__doc__']

outputters:
    - __opts__
    - __pillar__
    - __grains__

states:
    - __pillar__
    - __low__ (lowstate structure?)
    - __env__
    - __running__
    - __lowstate__
    - __salt__
    - __opts__
    - __grains__

log_handlers:
    - __path__

renderers:
    - __salt__ - Execution functions (i.e. __salt__['test.echo']('foo'))
    - __grains__ - Grains (i.e. __grains__['os'])
    - __pillar__ - Pillar data (i.e. __pillar__['foo'])
    - __opts__ - Minion configuration options
    - __env__ - The effective salt fileserver environment (i.e. base). Also referred to as a "saltenv". __env__ should not be modified in a pure python SLS file. To use a different environment, the environment should be set when executing the state. This can be done in a couple different ways:
        Using the saltenv argument on the salt CLI (i.e. salt '*' state.sls foo.bar.baz saltenv=env_name).
        By adding a saltenv argument to an individual state within the SLS file. In other words, adding a line like this to the state's data structure: {'saltenv': 'env_name'}
    - __sls__ - The SLS path of the file. For example, if the root of the base environment is /srv/salt, and the SLS file is /srv/salt/foo/bar/baz.sls, then __sls__ in that file will be foo.bar.baz.

grains:
    - __salt__
    - __opts__
    - __pillar__
    - __grains__
</code>
===== Debug =====
  * Option debug (**-l debug**) :
<code yaml>
salt-call --local -l debug --file-root=$PWD state.apply test=True
</code>

  * Tracer l'exécution de toutes les states :
<code yaml>
salt-call --local --file-root=$PWD state.orchestrate test=True
</code>

  * Voir tous les events :
<code>
salt-run state.event pretty=True
</code>