Introduction à l’architecture de Salt#

Vue d’ensemble#

Vue d’ensemble#

../../_images/overview.png

Topologies possibles#

  • masterless

  • master et minion sur la même machine

  • 1 master, N minions (topologie la plus courante)

  • 1 master, N syndics, M minions

  • X masters, N syndics, M minions

../../_images/topology.png

Acteurs de l’architecture#

  • master : serveur central

    • conserve les clefs de chiffrement de chaque minion

    • envoi des requêtes d’exécutions asynchrones à tous les minions

    • sert des fichiers aux minions (avec moteur de template)

    • peut conserver des informations en provenance des minions

  • minion : machine sur laquelle tourne l’agent salt-minion

    • normalement, est pilotée par un master (pas obligatoire)

    • le démon salt-minion s’occupe de traiter les demandes d’exécution

  • syndic : machine qui sert de master secondaire

    • c’est à la fois un master et un minion

    • reçoit ses ordres du master principal et les distribue aux minions sous sa responsabilité

Composants Salt#

  • gestion des clefs

  • exécution distante

  • gestion de configuration

  • automatisation (planification, réaction aux événements)

  • interrogation / stockage d’informations sur l’état des minions (informations statiques, semi-statiques, dynamiques)

Gestion des clefs de chiffrement#

  • chaque acteur dispose d’une clef unique de chiffrement

  • AES256 pour le chiffrement des échanges

  • RSA pour l’authentification (2048 ou 4096 bits)

  • le master reçoit les clefs des minions qui s’enregistrent auprès de lui et leur retourne sa propre clef publique

  • la clef d’un minion doit être individuellement acceptée sur le master pour pouvoir ensuite piloter le minion

    • et surtout pour que le minion puisse faire des requêtes auprès du master

Exécution distante (remote execution)#

  • execution modules : exécuter une fonction présente dans un des modules présent dans le package python salt.modules sur les minions, et renvoyer les résultats de ces exécutions via un returner

    • s’appuie sur la présence d’un agent salt-minion qui tourne sur les machines pilotées

  • targeting : mécanisme de sélection des minions qui sont ciblés par une exécution

  • grains : données dynamiques du minion utilisable pour paramétrer l’exécution d’une commande ou pour le targeting

  • outputters : permet de formater les réponses renvoyées par les minions lorsqu’ils exécutent des commandes

  • returner : permet de rediriger et de formater les réponses renvoyées par les minions lorsqu’ils exécutent des commandes ;

    • le returner par défaut formate les résultats en texte (colorisé) et les envoie au master ;

    • il existe des returners qui écrivent directement dans des bases de données, envoient le resultat sur d’autres bus de communication, etc.

Gestion de configuration centralisée#

  • state modules : permettent d’exprimer l’état dans lequel on veut placer un minion de manière déclarative

    • implémentés sous la forme de modules python dans le packages salt.states du minion,

    • un state est mis en œuvre en utilisant les modules d’exécution salt

  • renderers : permettent d’utiliser plusieurs formats de fichier pour la déclaration states ou de les générer

  • pillars : permettent d’envoyer sélectivement des données déclarées vers les minions, données qui ensuite sont réutilisées par les states

Autres composants#

  • serveur de fichier : le master peut générer et servir des fichiers quand un minion le demande (identifiés par URI salt://path/to/file)

  • peer communication : pour que les minions puissent « communiquer » entre eux

  • scheduler : pour planifier des exécutions

  • reactor system : pour que l’infrastructure puisse réagir à des événements

  • beacons : générer des événements lors d’un changement sur un minion

  • salt-api : serveur REST permettant de piloter le master à distance en appliquant des permissions

Topologies#

Technologie réseau (ZeroMQ)#

Salt repose sur ZeroMQ (ZMQ) une librairie réseau moderne :

../../_images/zmq_logo.png
  • légère (peu d”overhead)

  • asynchrone

  • robuste (passage à l’échelle, interruptions)

  • forte compatibilité (windows, unix, mac os…)

  • open source (LGPLv3)

  • architecture claire (simple à mettre en œuvre)

  • compatible avec tous les langages (c, python, cpp, go…)

Alternatives pour le bus de communication :

  • RAET (Reliable Asynchronous Event Transport) qui utilise UDP,

  • TCP transport : implémentation du protocole de transport en pur TCP.

Salt Master#

Démon salt-master :

  • attend l’enregistrement des minions pour les commander,

  • écoute par défaut sur les ports TCP :

    • 4505 : socket ZMQ de type PUB ; c’est celle qui sert à envoyer des requêtes d’exécution aux minions (qui souscrivent à cette socket),

    • 4506 : socket ZMQ de type REQ ; c’est celle qui sert aux minions à renvoyer les résultats d’une exécution, à charger un fichier de configuration, etc.

  • la commande salt communique avec le salt-master par la socket TCP 4506 sur l’interface locale (lo)

Salt Master - Diagramme#

../../_images/salt_master_minion_ports.png

Salt Minion#

  • agent tournant côté client (salt-minion)

  • utilise ZMQ pour communiquer avec master

  • seuls les minions dont la clef d’authentification a été acceptée côté master pourront interagir avec ce dernier

  • les payload sont signés et chiffrés lors de la communication avec le master

Salt Minion - masterless#

salt-minion seul

  • qui n’interagit pas avec un master

  • qui utilise des fichiers de description locaux

salt-call --local state.apply

Salt Syndic#

../../_images/salt-syndic.png

Salt Syndic#

Syndic (Syndicate) : démon salt-syndic qui relaie les commandes reçues d’un master of masters auprès du démon salt-master local

  • le master principal envoie une commande sur sa socket PUB

  • le syndic reçoit cette commande et la retransmet au master local

  • le master local envoie la commande sur sa socket PUB

  • les minions du réseau du syndic concernés exécutent la commande

  • les minions du réseau du syndic concernés renvoient le résultat au master local

  • le master local retourne ces résultats au syndic

  • le syndic renvoie les réponses au master principal

Machine accessible par ssh#

  • une machine sans minion peut être pilotée par salt-ssh

  • salt-ssh copie un environnement minimal en python pour « reproduire » son environnement

  • solution limitée