Pillar

Pillar — подсистема Salt для передачи данных с мастера на миньоны: параметров конфигурации, переменных окружений, паролей и ключей. Главное отличие от файлового сервера и grains — модель доступа: pillar рендерится на мастере и раздаётся адресно, каждый миньон получает только тот срез данных, который назначен ему в pillar top file, и физически не может увидеть чужие значения. Именно поэтому 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