Grains

Grains — это система фактов о миньоне, включающая операционную систему, версию ядра, архитектуру, объём памяти, IP-адреса, имя хоста и другие свойства. Salt собирает эти данные автоматически на каждой машине. Название отсылает к «крупицам» информации о системе. Grains используются для таргетинга команд, построения условий в 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'. Условная логика в формулах также основана на grains: имя пакета, путь к конфигу и имя сервиса выбираются по 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.

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

• Что такое grains
• Кастомные grains
• Grains в таргетинге
• Pillar vs grains
• Jinja в SLS