Пиллары разные нужны
Пиллары это защищенное (безопасное) хранилище данных внутри Salt'а. Поэтому, в первую очередь, они используются для разграничения доступа к критичным данным (сертификаты, логины, пароли).
Кроме дефолтных пилларов у Salt'а есть также модуль ext_pillar, который предоставляет интерфейс подключения к внешним источникам данных и генерирует пиллары из этих источников в один общий словарь.
Например, можно брать данные из mysql, postgres, redis, mongo, git, да хоть из вывода скрипта / команды cmd_json, cmd_yaml.
Полный список модулей опубликован на официальном сайте SaltStack.
Если у вас нестандартная ситуация и имеющиеся модули не устраивают, можно написать свой и положить его в /usr/lib/python3/dist-packages/salt/pillar/, после чего необходимо перезапустить мастер.
Пример такого модуля:
#/etc/salt/master/conf.d/pillar.confext_pillar: - dummy: dummy
#/usr/lib/python3/dist-packages/salt/pillar/dummy.pydef ext_pillar(minion_id, pillar, *args, **kwargs): dummy = {'dummy': 'what u want mann?'} return dummy
Из всех доступных модулей pillarstack оказался для нашей команды наиболее интересным и актуальным. Сейчас расскажем почему.
Знакомство с PillarStack
Stack или pillarstack это простой и гибкий YAML пиллар, который умеет читать пиллары из пилларов, согласно официальной документации на сайте.
Он позволяет использовать внутри пилларов пиллары, прочитанные ранее. Это значит, что мы можем использовать пиллар из предыдущего конфига. И это мегаудобно! Покажем, как это работает:
Допустим, у нас конфигурация из трёх конфигов:#/etc/salt/conf.d/pillarstack.confext_pillar: - stack: - /srv/pillar/stack1.cfg - /srv/pillar/stack2.cfg - /srv/pillar/stack3.cfg#/srv/pillar/stack1.cfg# с каждой строкой stack начинает "накапливать" пиллары,# и уже после 2й строки его можно использовать в yml файлах, но не в конфигеcore.ymlcommon/*.ymlosarchs/{{ __grains__['osarch'] }}.ymloscodenames/{{ __grains__['oscodename'] }}.ymlhosts/{{ 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
Каждый конфиг можно представить как слой. В каждом таком слое мы можем использовать данные из предыдущих слоев.
При настройке пилларов доступны следующие переменные:
- grains таргетирование конфигов по grains
- opts таргетирование конфигов по опциям в конфиге
- pillar пиллары, которые сформировались до начала обработки текущего 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
В yml файлах можно использовать:
- __opts__: опции конфига
- __grains__: грейны миньона
- pillar: пиллары из других ext_pillar или из дефолтных пилларов (те, что в top.sls)
- stack: накопленный стек пилларов, включая текущий конфиг.
Если вы только собираетесь перейти на pillarstack, то ниже пара моментов, на которые стоит обратить внимание:
1. Рекурсивное включение работает только в pillar. Stack не включает каталоги, только файлы.
# pillar# top.slsbase: '*': - dir1.* # прочитает /dir1/dir2/dir3/*# stack нужно указывать каждый каталог# stack.cfg/dir1/*/dir1/dir2/*/dir1/dir2/dir3/*
2. Дефолтное поведение при слиянии списков:
- pillar списки перезаписываются
- stack используется стратегия merge-last (списки складываются).
Стратегии слияния пилларов позволяют очень гибко настроить пиллары.
Подробное описание с примерами есть в документации.
Если вкратце описать каждую из стратегий:
- merge-last (используется по умолчанию): рекурсивное слияние, приоритет у последнего словаря/списка
- merge-first: рекурсивное слияние, приоритет у первого словаря/списка
- remove: удаление указанных элементов
- overwrite: переопределение словаря / списка.
Пояснение: в каждом слиянии участвует два словаря/списка назовем их первый и последний
Стратегия указывается как первый элемент словаря / списка, к которому ее надо применить.
Главное не увлекаться чрезмерным использованием стратегий, так как это усложнит конфигурацию. Возможно, в таком случае стоит пересмотреть организацию пилларов.
Заключение
Пиллары позволяют ограничить доступ к чувствительным данным. Данных становится всё больше, сценарии их применения становятся всё изощреннее, поэтому важно использовать удобный инструмент для их организации. На данный момент для нашей команды это pillarstack, в будущем мы планируем развернуть vault.
Нам кажется, удивительно, почему pillarstack до сих пор не вытеснил дефолтный пиллар, ведь он гораздо удобнее и гибче, а стратегии очень выручают, когда надо точечно изменить поведение переменной stack. А вы что думаете? Используете ли pillarstack в своей работе?
