Pillar vs grains

Grains и pillar — это два словаря данных, доступных в каждом SLS. Часто возникает путаница между ними, что становится одной из самых распространённых архитектурных ошибок в Salt. Разница между ними не в синтаксисе, а в источнике истины и направлении потока данных. Grains собираются на миньоне и описывают то, что машина знает о себе: ОС, ядро, объём памяти, IP-адреса и роли из /etc/salt/grains. Pillar рендерится на мастере и описывает то, что администратор решил про эту машину: параметры, роли и секреты. Следовательно, правило безопасности гласит: миньон полностью контролирует свои grains, поэтому им нельзя доверять ничего секретного и ничего, что раздаёт права.

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

Grains вычисляются при старте миньона, включая статические значения из конфига и /etc/salt/grains, и кэшируются. Обновить их можно через saltutil.refresh_grains или рестарт миньона, а посмотреть — через salt '*' grains.items. Мастер узнаёт значения grains от самого миньона и не может их проверить. Pillar же движется в обратную сторону: мастер рендерит SLS из pillar_roots под конкретного миньона по top.sls и отправляет результат. После правок нужен saltutil.refresh_pillar. Механизмы пересекаются в двух местах. Во-первых, оба словаря доступны в Jinja: {{ grains['os_family'] }} и {{ salt['pillar.get']('nginx:port') }} могут использоваться в одном шаблоне. Во-вторых, рендеринг pillar на мастере имеет доступ к grains миньона — типовой паттерн, когда pillar-файл выбирает значения по grains['os_family'], отдавая Debian и RedHat разные имена пакетов.

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

Выбор почти всегда однозначен. Grains используются для ветвления логики по свойствам платформы (имя пакета, путь к конфигу, init-система), таргетинга несекретных операций (salt -G 'os:Ubuntu' pkg.upgrade) и инвентаризации парка. Pillar применяется для любых секретов, номеров версий и портов, списков пользователей, различий dev/stage/prod — всего, что должно задаваться централизованно и проверяемо. Серая зона — роли серверов: их можно объявить кастомным grain на миньоне или назначить через pillar по minion id. Grain-роль удобна для таргетинга из CLI, но помните: скомпрометированный хост может сам себе выставить role: db и получить всё, что таргетируется на эту роль. Поэтому раздача секретов должна опираться на pillar и minion id, а grains-роли оставьте для выбора логики установки и отчётности.

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

Главная ошибка — привязка секретов или прав доступа к grains, что создает уязвимость, поскольку значение grain задаёт сам миньон. Обратная ошибка — транспортировка в pillar фактов о машине (количество CPU, адреса интерфейсов), которые grains отдают бесплатно и всегда актуальными. Третья ошибка — забыть, какой словарь как обновляется: grains освежаются через refresh_grains (или рестартом миньона), а pillar — через refresh_pillar. После смены кастомного grain, используемого в pillar top file, нужно обновить и то, и другое, иначе pillar скомпилируется по старым значениям. Наконец, не дублируйте одно значение и в grain, и в pillar — источников истины станет два, и они разойдутся.

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

• Pillar
• Grains
• Кастомные grains
• Grains в таргетинге
• Секреты в pillar