Salt. О славном pillar'е замолвите слово

В одной из наших прошлых статей Just add some Salt мы рассказывали, как мигрировали 700+ серверов на Salt. Мы поделились нашим опытом оптимизации Salt: как его применить и настроить без лишних усилий. Тогда мы только затронули тему пилларов, а сегодня хотели бы остановиться на ней подробнее.

Пиллары разные нужны

Пиллары — это защищенное (безопасное) хранилище данных внутри 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.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

Из всех доступных модулей pillarstack оказался для нашей команды наиболее интересным и актуальным. Сейчас расскажем почему.

Знакомство с PillarStack

Stack или pillarstack — это «простой и гибкий YAML пиллар, который умеет читать пиллары из пилларов», согласно официальной документации на сайте.

Он позволяет использовать внутри пилларов пиллары, прочитанные ранее. Это значит, что мы можем использовать пиллар из предыдущего конфига. И это мегаудобно! Покажем, как это работает:

Допустим, у нас конфигурация из трёх конфигов:
#/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

Каждый конфиг можно представить как слой. В каждом таком слое мы можем использовать данные из предыдущих слоев.

При настройке пилларов доступны следующие переменные:

• 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.sls
base:
  '*':
    - 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 в своей работе?