Что такое pillar

Pillar — это защищённое хранилище «ключ–значение», в котором мастер держит данные для миньонов: конфигурационные параметры, различия между окружениями, учётные данные. Технически pillar выглядит как второе дерево SLS-файлов рядом со states, но работает по противоположной модели доступа. Файлы состояний и всё содержимое file_roots доступны любому принятому миньону, а pillar компилируется на мастере индивидуально под каждого миньона: машина получает ровно тот словарь, который назначен ей в top.sls дерева pillar, и не имеет способа запросить чужие ключи. Эта адресность — сама суть pillar. Она позволяет писать универсальные состояния («поставить nginx, порт взять из pillar») и при этом раздавать секреты только тем хостам, которым они действительно нужны.

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

Каталоги дерева задаются опцией pillar_roots в конфигурации мастера, по умолчанию это /srv/pillar. Внутри — обычные SLS: YAML, при необходимости с Jinja. Когда миньон запрашивает pillar (при старте, по команде или перед прогоном состояний), мастер берёт top.sls, определяет список SLS-файлов для этого миньона, рендерит их и сливает результат в единый словарь. Рендеринг выполняется процессом мастера, поэтому в Jinja доступны grains конкретного миньона — можно, например, подставлять разные значения по grains['os_family']. Готовый словарь уезжает миньону по шифрованному ZeroMQ-каналу и хранится у него в памяти. Дальше данные читают отовсюду: из командной строки — salt '*' pillar.items и salt '*' pillar.get users:deploy, из SLS-файла — {{ salt['pillar.get']('nginx:port', 80) }}, где двоеточие обозначает путь по вложенным ключам, а второй аргумент — значение по умолчанию.

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

Pillar нужен, как только одна и та же формула должна вести себя по-разному на разных машинах. Типовые случаи: пароли БД и API-токены (выдаются только целевым хостам), список SSH-пользователей по ролям серверов, размеры пулов и лимиты, различающиеся между stage и prod, адреса «соседей» кластера. Альтернативы проигрывают по конкретным причинам: хардкод в SLS требует править код при каждом изменении данных; grains не подходят для чувствительного и управляющего — их значения контролирует сам миньон; файлы в file_roots видны всем машинам без разбора. Если данных немного и они не секретны, начать можно с одного common.sls, подключённого всем через '*', и постепенно выделять специфичные файлы по ролям.

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

Частый сюрприз — «pillar не обновился»: миньон держит копию в памяти, и после правки файлов на мастере нужен saltutil.refresh_pillar (или очередной state.apply). Вторая ошибка — прямое обращение pillar['a']['b'] в Jinja: отсутствие ключа валит рендер SLS с малопонятной ошибкой, а pillar.get с default этого лишён. Третья — вера в то, что сам факт нахождения данных в pillar делает их защищёнными: на диске мастера и в git они лежат открытым текстом, для секретов нужен GPG-renderer или внешний источник. И не выводите pillar в логи CI — pillar.items печатает и секреты тоже.

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

• Pillar
• Pillar top file
• Pillar vs grains
• Секреты в pillar
• SLS-файлы и YAML