Skip to content

Les modules de Saltstack #1

salt-bluebanner-Dans cet article, je vais essayer de vous détailler au mieux certain composants de Salt afin de comprendre tout le potentiel qu’offre cette application de gestion de configuration.
Ces modules sont nombreux et variés ce qui permet globalement toutes les interactions possibles avec votre infrastructure (Cloud, Virtualisation, Réseau …).

Voici la liste des modules que je vais aborder rapidement :

Execution module
State module
Output module
Returner
Scheduler
Salt SSH

Il existe d’autres modules que je ne pourrais pas détailler dans cet article, tel que Reactor, Salt-Cloud, les Renderers, Salt-Runner …
Vous trouverez la liste de tous les modules sur la doc officiel.

I – Execution module

Ce module, comme son nom l’indique, permet d’exécuter des commandes depuis le master vers un ou plusieurs minions. S’il s’agit d’une commande système on utilise cmd.run, cependant l’avantage de Salt c’est qu’il  intègre une longue liste de modules qui permettent de se détacher des commandes Linux classiques pour utiliser des commandes plus simple, par exemple pour installer un paquet, on peut utiliser deux manières :

salt minion1 cmd.run 'apt-get -y install vim'
salt minion pkg.install vim

On remarque que la deuxième commande, qui utilise le module pkg est bien plus pratique une fois assimilé.
La liste complète des modules d’exécution est disponible ici.
Il existe des modules pour tout et n’importe quoi, de l’administration de base MySQL à la gestion de la configuration réseau. C’est un moyen rapide d’effectuer des tâches sur un ou plusieurs serveurs simultanément.

Un dernier exemple, redémarrer le service Nginx sur tous les serveurs Web :

salt 'webserv*' service.restart nginx

II – State module

Le module de State, permet de définir une configuration qu’on souhaiterait déployer sur un ou plusieurs minions. Pour cela, Salt utilise une syntaxe relativement simple en YAML qu’on peut dynamiser avec du Jinja (template). Salt utilise le dossier /srv/salt pour gérer les fichiers de states. C’est à vous de créer votre architecture de fichier afin de s’y retrouver dans les différentes states. On applique ensuite les states voulus au minions voulus grâce au fichier /srv/salt/top.sls.

Dans un exemple tout simple, nous allons voir comment déployer Nginx sur plusieurs serveurs. On commence donc par le fichier /srv/salt/nginx.sls :

nginx:
  pkg:
    - installed
  service.running:
    - watch:
      - file: /etc/nginx/nginx.conf
      - file: /etc/nginx/sites-available/default

Dans cette configuration, on donne deux ordres à Salt, tout d’abord d’installer le paquet « nginx » puis, que le service sois démarré. La dernière instruction (watch) permet de redémarrer le service en cas de modification de ses deux fichiers.

On peut également utiliser les states pour déployer un fichier depuis le serveur local, exemple si on veut déployer  /srv/salt/files/nginx-site-default, on ajoute cela à notre state nginx.sls :

/etc/nginx/sites-available/default:
  file.managed:
    - source: salt://files/nginx-site-default
    - user: root
    - group: root
    - mode: 640

Maintenant que notre state est « complète », on va devoir l’attribuer à tous nos serveurs web, cela se fait dans le fichier /srv/salt/top.sls :

base:
  'webserv*'
    - nginx

A partir de cet instant, notre configuration est prête à être déployée, que ce soit pour un ou un millier de minions. Pour appliquer l’état décrit dans le fichier top.sls, on utilise la commande state.highstate.

salt '*' state.highstate

III – Ouput Module

Ce module, qui n’en est pas réellement un, permet simplement de modifier l’output d’une commande Salt à la volée. Par exemple, lorsqu’on lance des commandes sur de multiples serveurs, l’output peut être long et difficile à déboguer, pour cela on peut utiliser l’argument –output. Voici quelques exemples :

salt '*' service.status nginx --output=json
{
    "minion1": false
}
{
    "minion2": false
}
{
    "minion3": true
}
salt '*' service.status nginx --output=yaml
minion1: false
minion2: false
minion3: true

La modification de l’output permet de traiter plus facilement les résultats dans un script, pour récupérer des variables par exemple.

IV – Returner Module

Le module Returner est très intéressant car il permet d’envoyer l’output d’une commande Salt (qu’elle qu’elle soit) dans un endroit externe. Cela peut être un e-mail, une base SQL, du noSQL, Hipchat …  Pour avoir la liste complète des Returners, c’est dans la doc officielle.

Nous allons voir comment logguer nos retours de Salt dans une base REDIS. Pour cela, nous allons créer le fichier /etc/salt/master.d/redis.conf qui va contenir les informations de notre serveur :

redis.db: '0'
redis.host: 'redis.server.com'
redis.port: 6379

À partir de cet instant, si notre serveur est démarré, on peut logguer ce que Salt nous renvoie en rajoutant l’argument –return comme ceci :

salt '*' status.loadavg --return=redis

Il est donc possible, grâce à ce module, de récolter des métriques et de les logguer dans une base de données afin de réaliser de la supervision mais nous verrons cela dans un autre article.

V – Scheduler Module

Un autre module important de Salt, le Scheduler. Comme son nom l’indique, il sert à programmer des actions sur nos minions afin qu’elles soient lancées périodiquement (comme un cron).

La fonction de « Schedule » se programme dans le Pillar d’un minion (genre de coffre-fort de données). Pour créer une tâche programmée qui va récolter des infos sur le load des minion, nous allons créer le fichier /srv/pillar/load_schedule.sls  :

job1:
  schedule.present:
    - function: status.loadavg
    - seconds: 120
    - return: redis
  schedule.enabled

Vous remarquerez que le paramètre « return: redis » permet de retourner l’output de ma commande status.loadavg dans mon Returner Redis.

Maintenant il ne faut pas oublier d’attribuer ce « Pillar » à nos minions (dans /srv/pillar/top.sls) :

base :
  '*'
    - load_schedule

Une fois que cela est fait, il y a plus qu’à mettre à jour le Pillar de nos minions avec cette commande :

salt '*' saltutil.refresh_pillar

Vos minions devraient donc commencer à remonter les moyennes de Load dans votre serveur Redis toutes les 2 minutes.

VI – Salt SSH

Salt-SSH est une fonction intéressante de Salt, il permet d’utiliser SSH plutôt que ZeroMQ et donc de ne pas avoir d’agent Salt (salt-minion). Pour pouvoir utiliser Salt-SSH, il faudra installer le paquet salt-ssh.

Les minions ne sont donc plus managés par salt-key, il faut donc utiliser un fichier dit « Roster » (/etc/salt/roster) ou l’on indique comment joindre nos minions :

minion1:
  host: 192.168.42.1 
  user: admin         
  passwd: myverylongpassword  
  sudo: True

On peut également déployer la clé SSH généré par Salt grâce à cette commande :

ssh-copy-id -i /etc/salt/pki/master/ssh/salt-ssh.rsa.pub [email protected]

Une fois la clé envoyée, on devrait pouvoir contacter notre minion SSH :

salt-ssh minion1 test.ping

Vous remarquerez que dans ce cas, on utilise salt-ssh plutôt que salt.

Pour ma part, je préfère utiliser Salt à travers ZeroMQ ce qui permet d’avoir de meilleures performances (c’est le choix initial des développeurs de Salt). La documentation de Salt-SSH se trouve ici.

VII – Conclusion

Dans cet article, je vous ai présenté les modules de Salt que j’utilise principalement. Il en existe cependant beaucoup d’autres, qui font de Saltstack un outil très complet et précis.
Je vous présenterez d’autres modules de manière plus détaillée dans d’autres articles car ils méritent qu’on se penche sur leurs cas.

Moi essayant de comprendre tous les modules Salt :

Published inCLI ToolsDevOpsLinuxSaltstackTutoriel

Be First to Comment

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Proudly hosted with Open-sources Softwares.