Jinja-шаблоны
Тема дорожной карты · SaltStack
Jinja — шаблонизатор на Python, встроенный в Salt как механизм по умолчанию для рендеринга SLS-файлов и конфигов. Рендерер по умолчанию — связка jinja|yaml: сначала файл проходит через Jinja и превращается в обычный текст, затем результат парсится как YAML и становится структурой состояний. Именно Jinja делает статичные декларации параметризуемыми: один и тот же SLS-файл может ставить httpd на RedHat-семействе и apache2 на Debian, подставляя значения из grains и pillar. Синтаксис минимальный: {{ выражение }} — подстановка значения, {% инструкция %} — логика (условия, циклы, присваивания), {# комментарий #} — комментарий, который не попадёт в результат. Тот же движок используется в Ansible, поэтому навык почти без изменений переносится между инструментами.
Как это работает
Ключевой факт: SLS-файлы рендерятся на миньоне, а не на мастере. Миньон скачивает файл с файлового сервера мастера, прогоняет его через Jinja локально и только потом исполняет полученные состояния. Поэтому внутри шаблона доступны данные конкретного миньона: словарь grains (например, {{ grains['os'] }} или {{ grains['os_family'] }}), словарь pillar, объект salt — прокси ко всем execution-модулям ({{ salt['network.ip_addrs']() }}), а также opts (конфигурация миньона) и saltenv. Рендеринг происходит целиком до исполнения: любой вызов salt['cmd.run'](...) внутри Jinja выполнится в момент рендеринга, а не в порядке следования состояний. Проверить результат можно без применения: salt-call --local slsutil.renderer /srv/salt/web/init.sls покажет отрендеренный текст, а salt '*' state.show_sls web — итоговую структуру данных после прохода Jinja и YAML.
Когда применять
Jinja уместна там, где данные различаются, а логика одна: имена пакетов и пути конфигов, зависящие от grains['os_family']; подстановка портов и секретов из pillar через salt['pillar.get']('key', 'default'); генерация однотипных состояний циклом по списку. Второй большой сценарий — шаблоны конфигурационных файлов, раздаваемых через file.managed с template: jinja. Если же в SLS появляется многоэтажная логика — вложенные условия в несколько уровней, разбор строк, вычисления — это сигнал вынести её наружу: OS-специфичные значения — в map.jinja, сложные вычисления — в кастомный execution-модуль на Python. Шаблон должен читаться как конфигурация, а не как программа.
Типичные ошибки
Самая частая — забыть, что Jinja отрабатывает до YAML: шаблон генерирует текст с кривыми отступами, и падает уже YAML-парсер с малопонятной ошибкой; спасает предварительный прогон через slsutil.renderer. Вторая — ожидание, что вызов модуля в {{ }} выполнится «в нужный момент» между состояниями: весь Jinja вычисляется одним проходом до старта highstate. Третья — обращение {{ pillar['key'] }} к отсутствующему ключу роняет рендеринг всего файла; безопаснее salt['pillar.get']('key', 'default'). Наконец, тяжёлые вызовы execution-модулей в шаблонах замедляют каждый запуск состояний — рендеринг оплачивается при любом state.apply.
Связанные понятия
Полезные ресурсы
Проверить знания (2)
Загрузка вопросов…