Pillar

Pillar — подсистема Salt для передачи данных с мастера на миньоны: параметров конфигурации, переменных окружений, паролей и ключей. Отличие от файлового сервера и grains заключается в модели доступа: pillar рендерится на мастере и раздаётся адресно, каждый миньон получает только свой срез данных, физически не видя чужие значения. Поэтому pillar считается штатным местом для секретов и данных, которые нельзя показывать всем машинам инфраструктуры. Второй важный момент: pillar — это данные, а states — логика. Хорошо написанный SLS-файл не содержит паролей и номеров портов в теле, он читает их из pillar через pillar.get, и одна и та же формула обслуживает dev, stage и prod без правки кода.

Как это работает

Дерево pillar находится на мастере в каталогах из опции pillar_roots (по умолчанию /srv/pillar) и состоит из обычных SLS-файлов: YAML плюс Jinja. Файл top.sls в корне сопоставляет миньоны и pillar-файлы. Когда миньон запрашивает данные, мастер рендерит назначенные ему SLS, собирает результат в один словарь и отправляет по шифрованному каналу. Рендеринг происходит на мастере, поэтому Jinja в pillar может обращаться к grains миньона, но не к его файловой системе. Миньон держит полученный словарь в памяти; полный словарь можно посмотреть командой salt '*' pillar.items, а отдельный ключ — salt '*' pillar.get nginx:worker_processes. Правки в файлах на мастере не прилетают на миньоны сами: нужно либо выполнить salt '*' saltutil.refresh_pillar, либо дождаться ближайшего state.apply, который компилирует свежий pillar перед запуском состояний.

Когда применять

Выносите в pillar всё, что меняется от машины к машине или от окружения к окружению: версии пакетов, адреса бэкендов, списки пользователей, TLS-сертификаты, учётные данные. Если значение хочется захардкодить в SLS с комментарием «на проде поменять» — оно должно быть в pillar. Для секретов это единственный корректный механизм в Salt: файлы из file_roots доступны каждому принятому миньону через salt://, а pillar-данные — только адресату. Когда источником данных должна быть не файл на мастере, а внешняя система (Vault, база, git-репозиторий), модель доступа сохраняется через external pillar. Не стоит тащить в pillar большие бинарные блобы и данные, которые описывают саму машину, — для этого уже есть grains.

Типичные ошибки

Самая частая ошибка — забыть про saltutil.refresh_pillar и полчаса отлаживать «не применяющееся» значение, которое просто не доехало до миньона. Вторая — держать секреты в pillar открытым текстом в git-репозитории: pillar защищает данные при передаче на миньоны, но не в истории коммитов, поэтому секретные значения шифруют GPG-renderer'ом или выносят во внешний pillar. Третья — обращаться к ключам напрямую ({{ pillar['a']['b'] }}): при отсутствии ключа рендер падает, тогда как salt['pillar.get']('a:b', default) переживает недостающие данные. Наконец, ошибка YAML в одном pillar-файле ломает компиляцию всего pillar для затронутых миньонов — проверяйте изменения на стенде.

Связанные понятия

• Что такое pillar
• Pillar top file
• Секреты в pillar
• Pillar vs grains
• Внешние pillar