Introduction à la terminologie et aux concepts de SaltStack

La partie gestion de la configuration de Salt est principalement implémentée à l'aide du systèmestate.

Le système d'état utilisestate modules, qui sont distincts des modules d'exécution décrits ci-dessus. Heureusement, les modules d’état et d’exécution ont tendance à se refléter assez étroitement. Le système d'état porte bien son nom, car il permet à un administrateur de décrire l'état dans lequel un système doit être placé. Comme pour les modules d'exécution, la plupart des modules d'état représentent des raccourcis de fonctionnalités et fournissent une syntaxe simple pour de nombreuses actions courantes. Cela aide à maintenir la lisibilité et supprime la nécessité d'inclure une logique complexe dans les fichiers de gestion de la configuration eux-mêmes.

Saltformulas sont des ensembles d'appels de module d'état, arrangés dans le but de produire un certain résultat. Ce sont les fichiers de gestion de la configuration qui décrivent l'apparence d'un système une fois la formule appliquée. Par défaut, ceux-ci sont écrits au format de sérialisation YAML, ce qui constitue un très bon compromis entre lisibilité élevée et convivialité.

L'administrateur de Salt peut appliquer des formules en mappant des serviteurs à des ensembles spécifiques de formules. Les formules peuvent également être appliquées de manière ad hoc si nécessaire. Les serviteurs exécuteront les modules d'état trouvés à l'intérieur afin de mettre leur système en conformité avec la politique fournie.

Une bonne collection de formules Salt créées par l'organisation et la communauté SaltStack peut être trouvée dansthis GitHub account.

Templating permet d'écrire les formules Salt et d'autres fichiers d'une manière plus flexible. Les modèles peuvent utiliser les informations disponibles sur les minions pour construire des versions personnalisées de formules ou de fichiers de configuration. Par défaut, Salt utilise le format de modèle Jinja, qui fournit une fonctionnalité de substitution et des constructions logiques simples pour la prise de décision.

Renderers sont les composants qui exécutent le modèle pour produire des fichiers d'état ou de configuration valides. Les rendus sont définis par le format de gabarit qui constitue le format d'entrée et le format de sérialisation des données qui seront produits en sortie. Compte tenu des valeurs par défaut décrites ci-dessus, le moteur de rendu par défaut traite les modèles Jinja afin de générer des fichiers YAML.

Saltgrains sont des informations, collectées et maintenues par un serviteur, concernant principalement son système hôte sous-jacent. Celles-ci sont généralement collectées par le démonsalt-minion et renvoyées au maître sur demande. Cette fonctionnalité peut être exploitée à différentes fins.

Par exemple, les données de grain peuvent être utilisées pour cibler un sous-ensemble spécifique de nœuds du pool de serveurs pour l'exécution à distance ou la gestion de la configuration. Si vous voulez voir la disponibilité de vos serveurs Ubuntu, les céréales vous permettent de ne cibler que ces machines.

Les grains peuvent également être utilisés comme arguments pour des modifications de configuration ou des commandes. Par exemple, vous pouvez utiliser grains pour obtenir l'adresse IPv4 associée à l'interfaceeth0 pour une modification d'un fichier de configuration ou comme argument d'une commande.

Les administrateurs peuvent également attribuer des grains à des serviteurs. Par exemple, il est assez courant d'utiliser des grains pour attribuer un "rôle" à un serveur. Cela peut ensuite être utilisé pour cibler un sous-ensemble de nœuds similaire à l'exemple de système d'exploitation ci-dessus.

Bien qu'il soit possible d'attribuer des grains à des serviteurs, la grande majorité des variables de configuration seront attribuées via le systèmepillars. Dans Salt, un pilier représente un magasin de valeurs-clés qu'un sbire peut utiliser pour récupérer des données attribuées arbitrairement. Cela fonctionne comme une structure de données de dictionnaire qui peut être imbriquée ou hiérarchisée à des fins d'organisation.

Les piliers offrent quelques avantages importants par rapport au système à grains pour attribuer des valeurs. Plus important encore, les données sur les piliers ne sont disponibles que pour les minions qui leur sont affectées. Les autres sbires n'auront pas accès aux valeurs stockées à l'intérieur. Cela le rend idéal pour stocker des données sensibles spécifiques à un nœud ou à un sous-ensemble de nœuds. Par exemple, les clés secrètes ou les chaînes de connexion à la base de données sont souvent fournies dans une configuration de pilier.

Les données Pillar sont souvent utilisées dans le contexte de gestion de la configuration pour injecter des données variables dans un modèle de configuration. Salt propose une sélection de formats de gabarit pour remplacer les parties variables d’un fichier de configuration par les éléments spécifiques au nœud qui l’appliquera. Les grains sont également souvent utilisés de cette manière pour référencer les données de l'hôte.

Saltmine est une zone sur le serveur maître où les résultats des commandes régulièrement exécutées sur les serviteurs peuvent être stockés. Le but de ce système est de collecter les résultats de commandes arbitraires exécutées sur des machines minions. Ce magasin global peut ensuite être interrogé par d'autres composants et sbires de votre infrastructure.

La mine de sel ne stocke que le résultat le plus récent pour chaque exécution de commande, ce qui signifie que cela ne vous aidera pas si vous avez besoin d'accéder à des données historiques. L'objectif principal de la mine est de fournir des informations actualisées à partir de machines minions en tant que complément flexible aux données de grain déjà disponibles. Les sbires peuvent interroger des données sur leurs homologues à l'aide du système minier. L’intervalle dans lequel le séide rafraîchit les données de la mine peut être configuré par séprime.

Le système Saltreactor fournit un mécanisme pour déclencher des actions en réponse aux événements générés. Dans Salt, les changements survenant dans l'ensemble de votre infrastructure amèneront les démonssalt-minion ousalt-master à générer des événements sur un bus de messages ZeroMQ. Le système de réacteur surveille ce bus et compare les événements à ses réacteurs configurés afin de répondre de manière appropriée.

L'objectif principal du système de réacteur est de fournir un système flexible permettant de créer des réponses situationnelles automatisées. Par exemple, si vous avez développé une stratégie de dimensionnement automatique, votre système créera automatiquement des nœuds pour répondre de manière dynamique à vos demandes en ressources. Chaque nouveau nœud déclencherait un événement. Un réacteur pourrait être configuré pour écouter ces événements et configurer le nouveau nœud, en l'intégrant dans l'infrastructure existante.

Saltrunners sont des modules qui s'exécutent sur le serveur maître au lieu des serviteurs. Certains coureurs sont des utilitaires à usage général utilisés pour vérifier l’état de diverses parties du système ou effectuer des opérations de maintenance. Certaines sont des applications puissantes permettant d'orchestrer votre infrastructure à plus grande échelle.

Saltreturners sont utilisés pour spécifier des emplacements alternatifs où les résultats d'une action exécutée sur un serviteur seront envoyés. Par défaut, les sbires renvoient leurs données au maître. Un renvoi permet à l'administrateur de rediriger les données de retour vers une autre destination. En règle générale, cela signifie que les résultats sont renvoyés à la destination spécifiée par le retourneurand vers le processus qui a lancé la commande minion.

Le plus souvent, les utilisateurs de retour transmettent les résultats à un système de base de données ou à un service de métrique ou de journalisation. Ceci fournit une méthode flexible pour obtenir des données arbitraires dans ces systèmes. Les retours peuvent également être utilisés pour collecter des données spécifiques à Salt, telles que des caches de travaux et des données d'événement.