Pillar vs grains

Grains и pillar — два словаря данных, доступных в каждом SLS, и путаница между ними — одна из самых частых архитектурных ошибок в Salt. Разница не в синтаксисе, а в источнике истины и направлении потока данных. Grains собираются на миньоне и описывают то, что машина знает о себе: ОС, ядро, объём памяти, IP-адреса, роли из /etc/salt/grains. Pillar рендерится на мастере и описывает то, что администратор решил про эту машину: параметры, роли, секреты. Отсюда рабочее правило: 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: это ровно та дыра, о которой предупреждает документация Salt, потому что значение grain задаёт сам миньон. Обратная ошибка — тащить в pillar факты о машине (количество CPU, адреса интерфейсов), которые grains отдают бесплатно и всегда актуальными. Третья — забыть, какой словарь как обновляется: grains освежаются refresh_grains (или рестартом миньона), pillar — refresh_pillar; после смены кастомного grain, используемого в pillar top file, нужно обновить и то и другое, иначе pillar скомпилируется по старым значениям. Наконец, не дублируйте одно значение и в grain, и в pillar — источников истины станет два, и они разойдутся.

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

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