SaltStack

Wiki.SaltStack History

Hide minor edits - Show changes to output

Changed lines 36-43 from:
Synchroniser les grains depuis le master: saltutil.sync_grains
to:
Synchroniser les grains depuis le master et rafraichir le pillar (WorkFlow):[@

salt '*'
saltutil.sync_grains

salt '*' saltutil.refresh_pillar

salt '*' state.highstate #-l debug@]

Added lines 29-31:

# Cas concrets
salt '*' state.highstate -l debug
Changed line 1 from:
Yoloow, Salt, the puppet killer, IMHO
to:
Yoloow, SaltStack
Changed lines 1-2 from:
Yoloow, Chef, the puppet killer, IMHO
to:
Yoloow, Salt, the puppet killer, IMHO

Liens:
* http://jensrantil.github.io/salt-vs-ansible.html
* http://www.tmartin.io/articles/2014/salt-improving-jinja-usage/

Changed lines 12-14 from:
to:
* module: C'est une action à lancer. C'est different des states.

Changed line 18 from:
** Accès à Pillar avec cas par défault: @@{{ salt['pillar.get']('pkgs:apache', 'httpd') }}@@
to:
** Accès à Pillar avec cas par défault: @@{{ salt['pillar.get']('pkgs:apache', 'httpd') }} #BestPractice@@
Added lines 22-64:

Pour débugger:[@
salt-master -l debug
salt-minion -l debug

killall -SIGUSR1 salt-master
killall -SIGUSR1 salt-minion

# Performance debug:
killall -SIGUSR2 salt-master@]

Synchroniser les grains depuis le master: saltutil.sync_grains

!! Jinjaaaaa
Pour faire une itération:[@# Data
users:
    bob:
        uid: 8001
        fullname: "Bob"
        password: '...'
    audrey:
        uid: 8002
        fullname: "Audrey"
        password: '...'

# Best practice
{% for user, userinfo in salt['pillar.get']('users', {}).iteritems() %}
[...]
{% endfor %}

# OldStyle
{% if pillar['users'] is defined %}
{% for user, userinfo in pillar['users'].iteritems() %}
[...]
{% endfor %}
{% endif %}
@]

!! Avis
C'est cool, les minions fonctionnent directement via la recherche dns salt.mon.domaine.com. Installation d'un seul packet, ça fonctionne et ça utilise les DNS.
En premiere impression, j'ai l'impression que la partie states est plus destiné a faire de la mise en place de configuration (un peu à la puppet) ou pour faire des taches complexes et/ou repetitives. La partie module permet une approche plus dynamique du parc, et permettant de manière quasi instantanée de remonter un grand nombre d'informations, ou alors pour éxécuter des commandes shell ou appliquer un state. Mouais?

Une presentation qui explique bien: http://fr.slideshare.net/SaltStack/an-overvisaltstack-presentation-clean
January 12, 2015, at 05:10 PM EST by 127.0.0.1 - Page moved to Wiki.SaltStack from Wiki.Chef
Added lines 1-15:
Yoloow, Chef, the puppet killer, IMHO

!! Petit démarrage
On identifie ces grandes entités:
* states: C'est des états dans lequel un objet doit être
* grains: C'est une information coté minion
* pillar: C'est une information coté master

Pour communiquer, de l'un à l'autre:
* state:
** Accès à Pillar: @@{{ pillar['pkgs']['apache'] }}@@
** Accès à Pillar avec cas par défault: @@{{ salt['pillar.get']('pkgs:apache', 'httpd') }}@@
* pillar
** Accès à Pillar: @@{% for user, uid in pillar.get('users', {}).items() %}@@
** Accès à un grain: @@  {% if grains['os_family'] == 'RedHat' %}@@
Page last modified on January 15, 2015, at 02:02 AM EST