Différents piliers sont nécessaires
Les piliers sont un magasin de données sécurisé (sécurisé) à l'intérieur de Salt. Par conséquent, tout d'abord, ils sont utilisés pour délimiter l'accès aux données critiques (certificats, identifiants, mots de passe).
En plus des piliers par défaut, Salt a également le module ext_pillar , qui fournit une interface pour se connecter à des sources de données externes et génère des piliers à partir de ces sources dans un dictionnaire commun.
Par exemple, vous pouvez prendre des données de mysql, postgres, redis, mongo, git ou même de la sortie d'un script / commande - cmd_json , cmd_yaml .
Une liste complète des modules est publiée sur le site officiel de SaltStack .
Si vous avez une situation non standard et que les modules disponibles ne vous conviennent pas, vous pouvez écrire le vôtre et le mettre dans / usr / lib / python3 / dist-packages / salt / pillar / , après quoi vous devez redémarrer l'assistant.
Un exemple d'un tel module:
#/etc/salt/master/conf.d/pillar.conf
ext_pillar:
- dummy: dummy
#/usr/lib/python3/dist-packages/salt/pillar/dummy.py
def ext_pillar(minion_id, pillar, *args, **kwargs):
dummy = {'dummy': 'what u want mann?'}
return dummy
De tous les modules disponibles, pillarstack s'est avéré être le plus intéressant et le plus pertinent pour notre équipe. Maintenant, disons pourquoi.
Introduction à PillarStack
Stack ou pillarstack est "un pilier YAML simple et flexible qui peut lire les piliers à partir des piliers", selon la documentation officielle sur le site .
Il vous permet d'utiliser les piliers lus précédemment à l'intérieur des piliers. Cela signifie que nous pouvons utiliser le pilier de la configuration précédente. Et c'est méga-pratique! Voyons comment cela fonctionne:
, :
#/etc/salt/conf.d/pillarstack.conf
ext_pillar:
- stack:
- /srv/pillar/stack1.cfg
- /srv/pillar/stack2.cfg
- /srv/pillar/stack3.cfg
#/srv/pillar/stack1.cfg
# stack "" ,
# 2 yml ,
core.yml
common/*.yml
osarchs/{{ __grains__['osarch'] }}.yml
oscodenames/{{ __grains__['oscodename'] }}.yml
hosts/{{ minion_id }}/roles.yml
#/srv/pillar/stack2.cfg
# stack stack1.cfg
# , , roles
# stack yml
{% for role in stack.roles %}
roles/{{ role }}/*.yml
{% endfor %}
#/srv/pillar/stack3.cfg
# stack "" stack1.cfg stack2.cfg
#
creds/{{ stack.db.host }}/*.yml
Chaque configuration peut être représentée sous forme de calque. Dans chacune de ces couches, nous pouvons utiliser les données des couches précédentes.
Les variables suivantes sont disponibles lors de la configuration des piliers:
- grains - ciblage des configurations par grains
- opts - ciblage des configurations par des options dans config
- pillar - piliers qui ont été formés avant le traitement du courant ext_pillar: stack
# , stack
# stack grains pillar
# stack.cfg , pillar
ext_pillar:
- stack:
grains:cpuarch:
x86_64:
- /srv/pillar/stack1.cfg
- /srv/pillar/stack2.cfg
pillar:environment:
dev: /srv/pillar/dev/stack.cfg
prod: /srv/pillar/prod/stack.cfg
# stack: grains, pillar
# pillar stack1.cfg, stack2.cfg
# 'environment', stack.cfg
ext_pillar:
- stack:
grains:custom:grain:
value:
- /srv/pillar/stack1.cfg
- /srv/pillar/stack2.cfg
- stack:
pillar:environment:
dev: /srv/pillar/dev/stack.cfg
prod: /srv/pillar/prod/stack.cfg
Dans les fichiers yml, vous pouvez utiliser:
- __opts__: options de configuration
- __grains__: grains de minion
- pillar: piliers d'autres piliers ext_pillar ou par défaut (ceux de top.sls)
- stack: pile de piliers accumulée, y compris la configuration actuelle.
Si vous allez simplement passer à pillarstack, voici quelques points qui méritent d'être pris en compte:
1. L'inclusion récursive ne fonctionne que dans pillar. La pile n'inclut pas les répertoires, uniquement les fichiers.
# pillar
# top.sls
base:
'*':
- dir1.* # /dir1/dir2/dir3/*
# stack
# stack.cfg
/dir1/*
/dir1/dir2/*
/dir1/dir2/dir3/*
2. Comportement par défaut lors de la fusion de listes:
- pilier - les listes sont écrasées
- stack - la stratégie de fusion-dernier est utilisée (les listes sont ajoutées).
Les stratégies de fusion de piliers permettent une personnalisation très flexible des piliers.
Une description détaillée avec des exemples se trouve dans la documentation.
Pour décrire brièvement chacune des stratégies:
- merge-last (par défaut): fusion récursive, le dernier dictionnaire / liste a priorité
- merge-first: fusion récursive, la priorité est donnée au premier dictionnaire / liste
- remove: supprime les éléments spécifiés
- écraser: remplacement de dictionnaire / liste.
Explication: dans chaque fusion, deux dictionnaires / listes sont impliqués, appelons-les le premier et le dernier. La
stratégie est indiquée comme le premier élément du dictionnaire / liste auquel elle doit être appliquée.
L'essentiel est de ne pas se laisser emporter par une utilisation excessive des stratégies, car cela compliquera la configuration. Peut-être, dans ce cas, vaut-il la peine de reconsidérer l'organisation des piliers.
Conclusion
Les piliers vous permettent de restreindre l'accès aux données sensibles. Avec de plus en plus de données et des scénarios de plus en plus sophistiqués pour son utilisation, il est important d'utiliser un outil pratique pour l'organiser. Pour le moment pour notre équipe, il s'agit de pillarstack, à l'avenir, nous prévoyons de déployer Vault.
Il nous semble surprenant que pillarstack n'ait pas encore supplanté le pilier par défaut, car il est beaucoup plus pratique et flexible, et les stratégies sont très utiles lorsqu'il est nécessaire de changer le comportement de la variable de stack point par point. Qu'est-ce que tu penses? Utilisez-vous pillarstack dans votre travail?