Grains

Grains — это система фактов о миньоне: операционная система, версия ядра, архитектура, объём памяти, IP-адреса, имя хоста и десятки других свойств, которые Salt собирает на каждой машине автоматически. Название отсылает к «крупицам» информации о системе. Grains пронизывают весь Salt: по ним таргетируют команды (salt -G 'os:Ubuntu' pkg.install nginx), на них строятся условия в Jinja-шаблонах и SLS-файлах, через них формулы адаптируются к разным дистрибутивам. Если states отвечают на вопрос «что должно быть на машине», то grains — на вопрос «что это за машина». Без понимания grains невозможно написать ни одну кроссплатформенную формулу.

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

Grains собираются самим миньоном при старте процесса и кэшируются — это статичные данные, а не живой мониторинг. Посмотреть всё, что миньон о себе знает: salt '*' grains.items (с мастера) или salt-call --local grains.items (локально на машине). Список одних имён без значений — grains.ls, конкретное значение — salt '*' grains.get os. Типовые grains: id (идентификатор миньона), os и os_family (например, Ubuntu и Debian), osrelease, kernel, cpuarch, num_cpus, mem_total, ipv4, fqdn, virtual (физика или гипервизор), saltversion. Вложенные значения адресуются через двоеточие: grains.get ip_interfaces:eth0. В Jinja grains доступны через словарь grains: {{ grains['os_family'] }} — так один SLS-файл выбирает правильное имя пакета для Debian и RHEL. Помимо автоматических, бывают кастомные grains — статичные (файл /etc/salt/grains, секция в конфиге миньона) и динамические (Python-модули в _grains/).

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

Grains — ваш инструмент всегда, когда поведение должно зависеть от свойств машины. Таргетинг: salt -G 'os_family:RedHat' cmd.run 'cat /etc/redhat-release'. Условная логика в формулах: имя пакета, путь к конфигу и имя сервиса выбираются по os_family. Привязка ролей: положить role: web в кастомный grain и адресовать группу как salt -G 'role:web' state.apply nginx. Инвентаризация: salt '*' grains.item os osrelease saltversion --out=json — готовый срез парка для отчёта. Граница применимости важна: grains описывают саму машину и заведомо несекретны — любые данные, которые назначаются централизованно или должны быть скрыты (пароли, токены, флаги окружений), живут в pillar, который раздаёт мастер.

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

Самая опасная ошибка — использовать grains для решений о безопасности: значения grains полностью контролирует миньон, и скомпрометированная машина может объявить себе role: db, чтобы получить чужой pillar при таргетинге по grain. Секреты таргетируйте по id или pillar. Вторая ошибка — ожидать от grains актуальности в реальном времени: это кэш со старта процесса; после изменения системы (новый диск, смена hostname) обновите их — salt '*' saltutil.refresh_grains. Третья — хардкод под конкретный os вместо os_family: формула, проверяющая только Ubuntu, молча ломается на Debian, хотя различий нет. Четвёртая — превращать grains в свалку конфигурации, которой место в pillar.

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

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

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

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

Полезные ресурсы