saltstack [Linuxed]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== SaltStack ======

Equivalent de Puppet mais en python. La configuration, SaltState, est notée en yaml (ou un autre langage éventuellement), puis il est possible de la surchargée avec la couche Pillar.

L'architecture est classique:
  * Un master
  * Des minions

====== Installation ======

===== Installation du salt-master =====

L'installation du serveur se fait via le paquet salt-master:

  [root@salt-master] # yum install salt-master

L'installation est terminée.

Par défaut, le paquet salt-master active le service "salt-master".

Pour vérifier que c'est bien le cas: 

  [root@salt-master] # chkconfig --list salt-master

===== Configuration du pare-feu =====

Il faut autoriser les ports 4505 et 4506 en TCP pour que les clients puissent communiquer avec le salt-master. Ajouter les lignes suivantes dans /etc/sysconfig/iptables:

  # SALT
  -A INPUT -m state --state new -m tcp -p tcp --dport 4505 -j ACCEPT
  -A INPUT -m state --state new -m tcp -p tcp --dport 4506 -j ACCEPT

Puis relancer le service iptables:

  [root@salt-master] # service iptables restart
  
===== Signature des certificats clients =====

Pour vérifier les certificats des clients en attente de signature:

  [root@salt-master] # salt-key -L
  
Pour signer d'éventuels certificats:

  [root@salt-master] # salt-key -A
  
Tant que les clients salt ne seront pas installés, il ne risque pas d'y avoir de certificats en attente de signature. Tant que le certificat d'un client n'est pas signé, ce client ne peut pas récupérer sa configuration.
===== Installation d'un salt-minion =====

L'installation d'un client salt se fait par le paquet salt-minion:

  [root@salt-minion01] # yum install salt-minion
  
===== 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:


<file>
master: salt-master.in.virt.linuxed.net
</file>


<WRAP center round important 60%> L'adresse du salt-master doit être connue (DNS, ou /etc/hosts). </WRAP>

===== Activation du service =====

Pour démarrer le service après son installation:

  [root@salt-minion01] # service salt-minion start

Le service doit être actif au démarrage:

  [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]].