.. -*- coding: utf-8 -*- :orphan: ======================================= Introduction à l'architecture de Salt ======================================= Vue d'ensemble ============== Vue d'ensemble -------------- .. image:: media/overview.png :align: center .. source d'inspiration : http://www.youtube.com/watch?v=2w2nGJwcM0c 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* .. image:: media/topology.png :align: center 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 : .. image:: media/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. .. _RAET: https://github.com/saltstack/raet 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 ----------------------- .. image:: media/salt_master_minion_ports.png :align: center 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 .. code:: console salt-call --local state.apply Salt Syndic ----------- .. image:: media/salt-syndic.png :align: center 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*