Différences

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

--- saltstack [2013/08/22 07:18] – [Gestion du motd] madko
+++ 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 86: / Ligne 89: @@
 ===== 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:
-  /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:
-    file.managed:
-      - source: salt://motd/motd
-      - mode: 644
-      - user: root
-      - group: root
-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
+/etc/motd:
-  Machine gérée par Salt
+  file.managed:
-  ================================
+    - source: salt://motd/motd
+    - mode: 644
+    - user: root
+    - group: root
+</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:
-  base:
+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:
-    '*':
-      - 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:
-  /etc/motd:
-    file.managed:
+<code>
-      - source: {{ pillar["motd"] }}
+/etc/motd:
-      - template: jinja
+  file.managed:
-      - mode: 644
+    - source: {{ pillar["motd"] }}
-      - user: root
+    - template: jinja
-      - group: root
+    - 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.pls:
-  {% if grains["id"].endswith('in.virt.linuxed.net') %}
+    * La source passe par la couche pillar, pour permettre plus de souplesse
-    motd: salt://motd/virt_motd
+    * Le template sera de type jinja (moteur de template pour python)
-  {% else %}
-    motd: salt://motd/motd
-  {% endif %}
+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.pls permet d'assigner les modules/classes à nos clients. Contenu du fichier /srv/pillar/top.pls:
-  base:
+Le fichier top.sls permet d'assigner les modules/classes pillar à nos clients. Contenu du fichier /srv/pillar/top.sls:
-    '*':
-      - data
-      - motd
+<code>
+base:
+  '*':
+    - data
+    - motd
+</code>
-<WRAP center round important 60%>
-Le rôle de top.pls reste à vérifier...
-</WRAP>
 Contenu du fichier template /srv/salt/motd/virt_motd:
-  ================================
-  ATTENTION
+<code>
-  Machine Virtuelle gérée par Salt
+================================
-  Info: {{ pillar["info"] }}
+ATTENTION
-  OS: {{ grains["os"] }}
+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:
-  [root@salt-master] # salt 'hostname.fqdn' pillar.items
+<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):
-  [root@salt-master] # salt 'hostname.fqdn' grains.items
-Comparaison [[PuppetVsSalt]].
+<code>
+[root@salt-master] # salt 'hostname.fqdn' grains.items
+</code>
+Comparaison [[:puppetvssalt|PuppetVsSalt]].