Кастомные grains

Тема дорожной карты · SaltStack

Автоматические grains описывают то, что машина знает о себе сама: ОС, ядро, железо. Кастомные grains позволяют добавить к этому паспорту ваши собственные атрибуты — роль сервера (role: web), датацентр, стойку, команду-владельца, номер окружения. После этого по ним можно таргетировать (salt -G 'role:web' state.apply nginx), строить условия в Jinja и раскладывать states через top file. Есть два класса кастомных grains: статичные — просто значения, записанные на миньоне, и динамические — Python-код, вычисляющий значения при каждом обновлении grains. Выбор между ними — это выбор между «назначили руками» и «определяется автоматически».

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

Статичные grains задаются двумя способами. Первый — файл /etc/salt/grains на миньоне, обычный YAML: role: web, datacenter: msk-1; списки тоже допустимы. Второй — секция grains: прямо в конфиге миньона /etc/salt/minion — результат тот же, но данные смешиваются с настройками процесса, поэтому отдельный файл считается более чистым вариантом. Ставить значения можно и удалённо: salt 'web-01' grains.setval role web запишет grain в /etc/salt/grains без захода на машину. Динамические grains — это Python-модули в каталоге _grains/ внутри file_roots на мастере (то есть salt://_grains/): каждая функция модуля возвращает словарь, который вливается в общий набор grains. Раскатываются они командой salt '*' saltutil.sync_grains (или saltutil.sync_all), после которой миньоны скачивают код и пересчитывают grains. Так делают grains вида «есть ли GPU», «какой SSD-контроллер», «внутренний инвентарный номер из DMI» — всё, что можно вычислить кодом на самой машине.

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

Статичный grain — когда атрибут назначается человеком и меняется редко: роль, окружение, датацентр. Он живёт на машине и переживает переустановку мастера. Динамический — когда значение выводимо из самой системы: наличие устройства, версия внутреннего агента, признак «машина в облаке X». Практический критерий выбора между grain и pillar: если атрибут описывает машину и по нему нужно таргетировать — grain; если это конфигурационные данные или секреты, которые машина не должна определять сама, — pillar. Роли часто держат именно в grains ради удобного таргетинга, но помните ограничение доверия: миньон может выставить себе любую роль, поэтому раздача секретов должна опираться на pillar с таргетингом по id, а не на самопровозглашённый grain.

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

Главная ошибка — секреты или security-критичные признаки в кастомных grains: значение контролирует миньон, компрометация машины означает возможность «примерить» чужую роль. Вторая — забыть saltutil.sync_grains после правки модуля в _grains/ и недоумевать, почему значения старые; после синхронизации иногда нужен ещё saltutil.refresh_grains. Третья — дорогой код в динамическом grain: функции выполняются при каждом пересчёте grains, и обращение к внешнему API на 10 секунд затормозит старт миньона. Четвёртая — дублировать один атрибут в /etc/salt/grains и в конфиге миньона, а потом искать, откуда берётся «не то» значение.

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

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

Проверить знания (2)

Загрузка вопросов…