• Tuto 1
• 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
• Tuto Video 1

• Pense bête rapide

$ systemctl start salt-master
$ systemctl enable salt-master

• Editer le fichier /etc/salt/minion.d/master.conf et indiquer lui votre master :

master: salt-master

• On démarre et active au boot le service :

$ systemctl start salt-minion
$ systemctl enable salt-minion

• On voit apparaître portable.localdomain dans les liste des minions qui n'ont pas encore été acceptés :

salt-key -L a        
Accepted Keys:
Denied Keys:
Unaccepted Keys:
portable.localdomain

• On génère une fingerprint pour ce minion sur le minion :

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

• On donne cette figerprint à portable.localdomain :

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

• Puis on accepte la clé :

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.

• On vérifie les clés :

salt-key -L a
[sudo] Mot de passe de gigix : 
Accepted Keys:
portable.localdomain
Denied Keys:
Unaccepted Keys:
Rejected Keys:

• On vérifie le fonctionnement :

sudo salt 'portable.localdomain' test.ping
portable.localdomain:
    True

• Sécurisons le minion avec la fingerprint du master. On récupère sa fingerprint publique :

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

• On édite le fichier /etc/salt/minion.d/master.conf :

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'

• On restart le service :

systemctl restart salt-minion

• On teste à nouveau :

salt 'portable.localdomain' test.ping 
portable.localdomain:
    True

• La clé locale du minion:

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

• Les clés du master :

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

Les pillars sont chargés quand le minion démarre, ou on peu le faire manuellement :

salt '*' saltutil.refresh_pillar
salt '*' saltutil.refresh_grains

Tout resynchroniser :

salt '*' saltutil.sync_all

Client en standalone (serverless) :

salt-call --local grains.items

Exécution sur le master :

salt-run test.foo

Exécution vers un cloud provider (https://docs.saltstack.com/en/latest/topics/cloud/index.html) :

salt-cloud

Client vers serveur :

salt-call grains.items

Serveur vers clients via SSH (agentless) :

salt-ssh -i --roster-file=./roster 'node1' test.ping

Exemple de fichier roster (toutes les options du fichier roster) :

node1:
    host: 192.168.122.1
    user: root
    priv: /root/.ssh/id_rsa

Serveur vers clients via client salt :

salt '*' cmd.run 'ls -l /etc'
salt '*' test.ping

Autres :

salt '*' cmd.run 'echo "Hello: $FIRST_NAME"' saltenv='{FIRST_NAME: "Joe"}'

salt myminion grains.item pythonpath --out=pprint

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

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

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

States :

salt '*' sys.doc
salt '*' sys.doc cmd
salt '*' sys.doc cmd.run

Runner :

salt-run doc.runner

<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>

• Corrrecte :

httpd:
  pkg.installed: []

Ou

httpd:
  pkg:
    - installed

httpd:
  pkg.installed: []
  service.running: []

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

• Incorrecte :

httpd:
  pkg.installed
  service.running

• Exécuter toutes les SLS :

salt '*' state.apply 

• Exécuter la sls gigix :

salt '*' state.apply gigix

• Avec des paramètres et plusieurs sls :

salt '*' state.apply mysls1,mysls2 test=true saltenv=dev pillarenv=dev pillar='{"key": "val"}' exclude="[{'id': 'id_to_exclude'}, {'sls': 'sls_to_exclude'}]"

• Avec targetting par Pillar :

salt --pillar 'webserver_role:dev' state.apply

• Seulement un id d'une sls :

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

https://docs.saltstack.com/en/latest/ref/states/top.html#advanced-minion-targeting

• globbing sur le nom des minions :

salt 'web[1-5]' test.ping
salt 'web[1,3]' test.ping
salt '*.example.*' test.ping
salt 'web?.example.net' test.ping

base:
  'web[1,3]':
  - match: glob
  - webserver

• regexp sur le nom des minions

salt -E 'web1-(prod|devel)' test.ping

base:
  'web1-(prod|devel)':
  - match: pcre
  - webserver

• Liste de minion :

salt -L 'web1,web2,web3' test.ping

base:
  'web1,web2,web3':
  - match: list
  - webserver

• Grain :

salt -G 'os:Fedora' test.ping

'node_type:webserver':
  - match: grain
  - webserver

• Grain avec regexp :

salt 'P@os:(RedHat|Fedora|CentOS)' test.ping

'os:Fedo.*':
  - match: grain_pcre
  - webserver

• Pillar exacte :

'cheese:foo':
  - match: pillar_exact
  - webserver

• Pillar globing :

salt -I 'somekey:specialvalue' test.ping
salt -I 'foo:bar:baz*' test.ping

'cheese:foo:baz*':
  - match: pillar
  - webserver

• Pillar avec regexp :

salt 'J@pdata:^(foo|bar)$' test.ping

'cheese:(swiss|american)':
  - match: pillar_pcre
  - webserver

• Groupes (les nodesgroups sont à déclarer dans le fichier /etc/salt/master) :

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'

base:
  group1:
    - match: nodegroup
    - webserver

• Network :

salt -S 192.168.40.20 test.ping
salt -S 2001:db8::/64 test.ping

'172.16.0.0/12':
   - match: ipcidr
   - internal

• Multiples :

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

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

• Range cluster (non supporté de base) :

salt 'R@%test:APPS' test.ping

CLUSTER: host1..100.test.com
APPS:
  - frontend
  - backend
  - mysql

• data (avec le minion datastore) :

salt '*' state.disable mysql

Pour lister ceux qui ont été désactivés :

salt '*' state.list_disabled

salt '*' state.enable gigix

salt '*' state.show_highstate
salt '*' state.show_lowstate
salt '*' state.show_low_sls foo saltenv=dev
salt '*' state.show_sls core,edit.vim dev

Voir le contenu top sls des serveurs :

salt '*' state.show_top

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

salt '*' state.show_state_usage

• Récupérer un Pillar :

{{ salt['pillar.get']('foo:bar:baz', 'qux') }}

• Récupérer un Grain :

{{ salt['grains.get']('node_type', '') }}

• Grains :

salt '*' grains.items

• Pillar

salt '*' pillar.items

• Définir une variable :

{% set the_node_type = salt['grains.get']('node_type', '') %}

{% set name = {
    'RedHat': 'httpd',
    'Debian': 'apache2',
}.get(grains.os_family) %}

• Appeler un module :

{{ salt['module.function_name']('argument_1', 'argument_2') }}
{{ salt['cmd.run']('pgrep -f redis-server') }}

{% 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 %}

{% for user, uid in pillar.get('users', {}).items() %}
{{user}}:
  user.present:
    - uid: {{uid}}
{% endfor %}

La maccro est une sorte de fonction :

# 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) }}

Avec l'option failhard :

/etc/yum.repos.d/company.repo:
  file.managed:
    - source: salt://company/yumrepo.conf
    - user: root
    - group: root
    - mode: 644 
    - order: 1
    - failhard: True

L'ordonnancement est possible grâce à require ou require_in (sa dépendance inversée) :

httpd:
  pkg.installed: []
  service.running:
    - require:
      - pkg: httpd
      - sls: network

vim:
  pkg.installed:
    - require_in:
      - file: /etc/vimrc

/etc/vimrc:
  file.managed:
    - source: salt://edit/vimrc

On peu également faire appel à order :

apache:
  pkg.installed:
    - name: httpd
    - order: 1

Pour désigner le dernier : order: last ou order: -1.

• 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 :

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

# (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

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_watchalors celle-ci sera appellée. Tous les modules n'ont pas de fonction mod_watch et s'exécuteront donc comme un simple require :

ntpd:
  service.running:
    - watch:
      - file: /etc/ntp.conf
  file.managed:
    - name: /etc/ntp.conf
    - source: salt://ntp/files/ntp.conf

On peu également le faire avec listen /listen_in.

Contrairement à 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.

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

restart-apache2:
  service.running:
    - name: apache2

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

Il y a aussi prereq et prereq_in expliqué ici.

La gestion des erreurs est possible grâce à onfail ou onfail_in (sa dépendance inverse).

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

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:

/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

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

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

unless et onlyif lance des commandes shell.

Dans l'exemple ci-dessous, vim sera installé quand toutes les conditions seront fausses :

vim:
  pkg.installed:
    - unless:
      - rpm -q vim-enhanced
      - ls /usr/bin/vim

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

checkcmd permet de vérifier l'état attendu :

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

L'option 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).

my_retried_state:
  pkg.installed:
    - name: nano
    - retry:
        attempts: 5
        until: True
        interval: 60
        splay: 10

install_nano:
  pkg.installed:
    - name: nano
    - retry: True

wait_for_file:
  file.exists:
    - name: /path/to/file
    - retry:
        attempts: 15
        interval: 30

Fichier ssh/init.sls :

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

Fichier ssh/server.sls :

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

Fichier ssh/custom-server.sls :

include:
  - ssh.server

extend:
  /etc/ssh/banner:
    file:
      - source: salt://ssh/custom-banner

On peut également exclure un id ou un sls :

exclude:
  - sls: http
  - id: /etc/vimrc

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.

httpd:
  service.running:
    - enable: True
    - provider: service

emacs:
  pkg.installed:
    - provider:
      - cmd: customcmd

Tout est lancé en parallèle et prendra donc 10 secondes à la place de 15 :

sleep 10:
  cmd.run:
    - parallel: True

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

sleep 5:
  cmd.run:
    - parallel: True

Le fichier /etc/salt/minion doit contenir la ligne suivant pour êtreactivé : backup_mode: minion.

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

• Pour lister les backups :

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

• Pour restaurer un backup :

salt foo.bar.com file.restore_backup /tmp/foo.txt 1

• Pour supprimer un backup :

salt foo.bar.com file.delete_backup /tmp/foo.txt 0

• 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 :

salt '*' state.show_highstate
salt '*' state.show_highstate --out yaml
salt '*' state.show_sls edit.vim --out pprint

• 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:

salt '*' state.show_lowstate
salt '*' state.low '{name: vim, state: pkg, fun: installed}'

Les pillar sont à définir dans le fichier /srv/pillar/top.sls.

Exemples :

{{ saltenv }}:
  '*':
     - common_pillar

base:
  '*':
    - apache
dev:
  'os:Debian':
    - match: grain
    - vim
test:
  '* and not G@os: Debian':
    - match: compound
    - emacs

Fichier /srv/pillar/apache.sls :

apache:
  lookup:
    name: httpd
    config:
      tmpl: salt://apache/files/httpd.conf

Exemple pour y faire appel :

{{ salt['pillar.get']('apache:lookup:name') }}

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

Il prend le premier et s'il ne trouve pas il passe au suivant :

file_roots:
  base:
    - /srv/salt/prod
  qa:
    - /srv/salt/qa
    - /srv/salt/prod
  dev:
    - /srv/salt/dev
    - /srv/salt/qa
    - /srv/salt/prod

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

On appellera ces fichiers map.jinja.

{% 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')) %}

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

On chargera par exemple le fichier apache/map.jinja dans un fichier sls de la façon suivante :

{% from "apache/map.jinja" import apache with context %}

apache:
  pkg.installed:
    - name: {{ apache.server }}
  service.running:
    - name: {{ apache.service }}
    - enable: True

• Status des minions :

$ salt-run manage.status
down:
    - portable.localdomain
up:

• Minions down :

$ salt-run manage.down  
- portable.localdomain

• Minions up :

$ salt-run manage.up    
- portable.localdomain

• Version du client salstack des minions :

$ salt-run manage.versions            
Master:
    2017.7.3
Up to date:
    ----------
    portable.localdomain:
        2017.7.3

# /srv/salt/orch/cleanfoo.sls
cmd.run:
  salt.function:
    - tgt: '*'
    - arg:
      - rm -rf /tmp/foo

salt-run state.orchestrate orch.cleanfoo

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

salt-run state.orchestrate orch.webserver

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

salt-run state.orchestrate orch.web_setup

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

# /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 }}

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

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

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.

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

Pour forcer la maj de toutes les mines :

salt '*' mine.update

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 :

beacons:
  inotify:
    /etc/important_file: {}
    /opt: {}

Un autre exemple :

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

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 :

salt-run state.event pretty=true

Ce qui affichera :

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"
}

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

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

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

Sur le master, créer le fichier /srv/reactor/revert.sls :

revert-file:
  local.state.apply:
    - tgt: {{ data['data']['id'] }}
    - arg:
      - maintain_important_file

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 :

reactor:
  - salt/beacon/*/inotify//etc/important_file:
    - /srv/reactor/revert.sls

Exemple de reactor :

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

• Configuration du minion :

{{ opts['cachedir'] }}

• Pillar

{{ salt['pillar.get']('key', 'failover_value') }}
{{ salt['pillar.get']('stuff:more:deeper') }}

• Grains:

{{ salt['grains.get']('os') }}

• environnement salt (base par défaut) :

{{ saltenv }}

• nom du sls courant :

{{ sls }}

• Chemin du sls :

{{ slspath }}

Copie un fichier du master vers les minions :

salt-cp '*' [ options ] SOURCE [SOURCE2 SOURCE3 ...] DEST

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 :

# 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

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.

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 :

salt-run jobs.list_jobs

• Lancer un job :

On le stop avec Ctrl+c mais je job continue:

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:

• Savoir le status d'un jobs :

Le job n'a pas fini car il ne retourne rien :

sudo salt-run jobs.lookup_jid 20180304011226668249

Le job a terminé quand il retourne quelque chose :

salt-run jobs.lookup_jid 20180304011226668249
portable.localdomain:
    True

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é) :

peer:
  .*:
    - .*

Redémarrer votre master et tester :

salt '*' publish.publish '*' test.ping
portable.localdomain:
    ----------
    portable.localdomain:
        True

salt-call publish.publish '*' test.ping               
local:
    ----------
    portable.localdomain:
        True

Pour commenter dans un sls il suffit d'utiliser le #.

Pour commenter un block on peu passer en mode jinja avec {# et #} :

{# 
mon commentaire ligne1
mon commentaire ligne2
#} 

Editer le fichier de configuration /etc/salt/master.d/gitfs.conf :

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

roots correspond aux file_roots.

Chaque tag ou branche est accessible avec saltenv :

$ salt '*' state.apply saltenv=test
$ salt '*' state.apply saltenv=base

https://docs.saltstack.com/en/latest/ref/modules/index.html

https://docs.saltstack.com/en/latest/ref/states/writing.html

https://docs.saltstack.com/en/latest/topics/grains/#writing-grains

https://docs.saltstack.com/en/latest/ref/clients/

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

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__

• Option debug (-l debug) :

salt-call --local -l debug --file-root=$PWD state.apply test=True

• Tracer l'exécution de toutes les states :

salt-call --local --file-root=$PWD state.orchestrate test=True

• Voir tous les events :

salt-run state.event pretty=True