Différences

Ci-dessous, les différences entre deux révisions de la page.

--- saltstack [2013/08/20 20:25] – modification externe 127.0.0.1
+++ saltstack [Date inconnue] (Version actuelle) – modification externe (Date inconnue) 127.0.0.1
@@ Ligne 53: / Ligne 53: @@
 ===== Configuration de l'adresse du salt-master =====
 L'adresse du salt-master peut être précisée dans le fichier /etc/salt/minion. Exemple avec la ligne suivante:
-  master: salt-master.in.virt.linuxed.net
+<file>
-<WRAP center round important 60%>
+master: salt-master.in.virt.linuxed.net
-L'adresse du salt-master doit être connue (DNS, ou /etc/hosts).
+</file>
-</WRAP>
+<WRAP center round important 60%> L'adresse du salt-master doit être connue (DNS, ou /etc/hosts). </WRAP>
 ===== Activation du service =====
@@ Ligne 71: / Ligne 74: @@
   [root@salt-minion01] # chkconfig salt-minion on
+====== Vérification ======
+Pour vérifier que les noeuds répondent:
+  [root@salt-master] # salt '*' test.ping
+Pour provoquer les mises à jour côté client:
+  [root@salt-master] # salt '*' state.highstate
+Le déclenchement de l'état highstate sur les clients ciblés (ici * = tous) va permettre à chaque client de vérifier leur configuration associée (en consultant le top.sls, voir exemples).
+====== Premiers tests ======
+===== Gestion du motd =====
+Exemple de gestion du fichier /etc/motd.
+Un fichier, appelé SaltState (ou sls) décrit le fait que nous voulons gérer ce fichier, ces permissions et son contenu (équivalent d’une classe puppet). Contenu du fichier /srv/salt/motd/init.sls:
+<code>
+/etc/motd:
+  file.managed:
+    - source: salt://motd/motd
+    - mode: 644
+    - user: root
+    - group: root
+</code>
+Ce qui indique qu’on veut gèrer le fichier /etc/motd, et que son contenu (source) se trouve dans salt, dans le fichier motd/motd, soit en réalité sur le serveur /srv/salt/motd/motd. Par défaut ce fichier est au format texte non interprété. Il est possible d’utiliser un moteur template (type jinja). Contenu du fichier source /srv/salt/motd/motd:
+<code>
+================================
+ATTENTION
+Machine gérée par Salt
+================================
+</code>
+Pour associer notre module motd à des clients, il faut passer par le fichier /srv/salt/top.sls (équivalent du nodes.pp, ou du ENC). Contenu du fichier /srv/salt/top.sls:
+<code>
+base:
+  '*':
+    - motd
+</code>
+Il est aussi possible de déployer, pour tester par exemple, un module sans l'associer dans le fichier top.sls:
+<code>
+salt 'machine.fqdn' state.sls motd
+</code>
+===== Gestion du motd avec pillar =====
+Exemple de gestion du fichier /etc/motd en permettant une variabilisation par pillar.
+Contenu du fichier /srv/salt/motd/init.sls:
+<code>
+/etc/motd:
+  file.managed:
+    - source: {{ pillar["motd"] }}
+    - template: jinja
+    - mode: 644
+    - user: root
+    - group: root
+</code>
+Deux points importants:
+    * La source passe par la couche pillar, pour permettre plus de souplesse
+    * Le template sera de type jinja (moteur de template pour python)
+Contenu du fichier /srv/pillar/motd.sls:
+<code>
+{% if grains["id"].endswith('in.virt.linuxed.net') %}
+  motd: salt://motd/virt_motd
+{% else %}
+  motd: salt://motd/motd
+{% endif %}
+</code>
+Donc sans modifier notre fichier sls, nous pouvons faire varier le template à utiliser pour le fichier motd (ici en fonction du hostname).
+Le fichier top.sls permet d'assigner les modules/classes pillar à nos clients. Contenu du fichier /srv/pillar/top.sls:
+<code>
+base:
+  '*':
+    - data
+    - motd
+</code>
+Contenu du fichier template /srv/salt/motd/virt_motd:
+<code>
+================================
+ATTENTION
+Machine Virtuelle gérée par Salt
+Info: {{ pillar["info"] }}
+OS: {{ grains["os"] }}
+================================
+</code>
+La couche pillar permet de récupérer sur le serveur salt-master des info pour le client. La couche grains, récupère des info locale à la machine (équivalent facter).
+Pour vérifier les info données via pillar à un client:
+<code>
+[root@salt-master] # salt 'hostname.fqdn' pillar.items
+</code>
+Pour vérifier les info locales (grains) d'un client, ce qui est possible directement sur le serveur salt-master (équivalent storeconfig/puppetDB):
+<code>
+[root@salt-master] # salt 'hostname.fqdn' grains.items
+</code>
+Comparaison [[:puppetvssalt|PuppetVsSalt]].