[Системное администрирование] Salt. О славном pillar'е замолвите слово
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В одной из наших прошлых статей 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 в своей работе?
===========
Источник:
habr.com
===========
Похожие новости:
- [Системное администрирование, Виртуализация, Облачные вычисления, Облачные сервисы] Вебинар «Как построить современную сетевую инфраструктуру» 17 декабря от Mail.ru Group
- [Системное администрирование, Серверное администрирование, DevOps, Kubernetes] Kubernetes 1.20 — и что же слома.../починили на этот раз?
- [Системное администрирование, IT-инфраструктура, DevOps] DevOps-дайджест от «Рексофт»
- [Системное администрирование] Не работает поиск в Windows 10
- [Системное администрирование, Сетевые технологии, Сетевое оборудование] MikroTik Скрипт: Уведомление о успешном входе на устройство или простой парсер журнала MikroTik
- [Open source, Системное администрирование, Разработка под Linux] RedHat прекратит поддержку CentOS в 2021 году
- [Системное администрирование, DevOps] Очередная встреча сообщества MonHouse состоится завтра, 09.12.2020, в 19:00
- [Информационная безопасность, Системное администрирование, Сетевые технологии, Облачные сервисы, Сетевое оборудование] Избавляемся от головной боли или зачем нужна система хранения USB-ключей в условиях пандемии
- [Системное администрирование, IT-инфраструктура, Серверное администрирование, DevOps] Prometheus и VictoriaMetrics: отказоустойчивая инфраструктура для хранения метрик (перевод)
- [Системное администрирование, Серверное администрирование, DevOps, Kubernetes] Docker is deprecated — и как теперь быть?
Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_saltstack, #_pillar, #_salt, #_pillarstack, #_blog_kompanii_timeweb (
Блог компании Timeweb
), #_sistemnoe_administrirovanie (
Системное администрирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:19
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
В одной из наших прошлых статей 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 Каждый конфиг можно представить как слой. В каждом таком слое мы можем использовать данные из предыдущих слоев. При настройке пилларов доступны следующие переменные:
# Допустим, у нас пиллары только в 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 файлах можно использовать:
Если вы только собираетесь перейти на pillarstack, то ниже пара моментов, на которые стоит обратить внимание: 1. Рекурсивное включение работает только в pillar. Stack не включает каталоги, только файлы. # pillar
# top.sls base: '*': - dir1.* # прочитает /dir1/dir2/dir3/* # stack нужно указывать каждый каталог # stack.cfg /dir1/* /dir1/dir2/* /dir1/dir2/dir3/* 2. Дефолтное поведение при слиянии списков:
Стратегии слияния пилларов позволяют очень гибко настроить пиллары. Подробное описание с примерами есть в документации. Если вкратце описать каждую из стратегий:
Пояснение: в каждом слиянии участвует два словаря/списка назовем их первый и последний Стратегия указывается как первый элемент словаря / списка, к которому ее надо применить. Главное — не увлекаться чрезмерным использованием стратегий, так как это усложнит конфигурацию. Возможно, в таком случае стоит пересмотреть организацию пилларов. Заключение Пиллары позволяют ограничить доступ к чувствительным данным. Данных становится всё больше, сценарии их применения становятся всё изощреннее, поэтому важно использовать удобный инструмент для их организации. На данный момент для нашей команды это pillarstack, в будущем мы планируем развернуть vault. Нам кажется, удивительно, почему pillarstack до сих пор не вытеснил дефолтный пиллар, ведь он гораздо удобнее и гибче, а стратегии очень выручают, когда надо точечно изменить поведение переменной stack. А вы что думаете? Используете ли pillarstack в своей работе? =========== Источник: habr.com =========== Похожие новости:
Блог компании Timeweb ), #_sistemnoe_administrirovanie ( Системное администрирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:19
Часовой пояс: UTC + 5