Блог

Я искал объяснение в документах SaltStack о том, что означает «с контекстом». Но есть только примеры использования контекста.

Что такое «контекст»?

Что он здесь делает? И почему это Debian игнорируется в map.jinja файле? (например map.log_dir , кажется, что он «прыгает вниз» на уровень)

 # config.sls
{% from "bind/map.jinja" import map with context %}

include:
  - bind

{{ map.log_dir }}:
  file.directory:
    - user: root
    - group: {{ salt['pillar.get']('bind:config:group', map.group) }}
    - mode: 775
    - require:
      - pkg: bind

# map.jinja
{% set map = salt['grains.filter_by']({
    'Debian': {
        'pkgs': ['bind9', 'bind9utils', 'dnssec-tools'],
        'service': 'bind9',
        'config_source_dir': 'bind/files/debian',
        'zones_source_dir': 'zones',
        'config': '/etc/bind/named.conf',
        'local_config': '/etc/bind/named.conf.local',
        'key_config': '/etc/bind/named.conf.key',
        'options_config': '/etc/bind/named.conf.options',
        'default_config': '/etc/default/bind9',
        'default_zones_config': '/etc/bind/named.conf.default-zones',
        'named_directory': '/var/cache/bind/zones',
        'log_dir': '/var/log/bind9',
        'user': 'root',
        'group': 'bind',
        'mode': '644'
    },
    'RedHat': {
        'pkgs': ['bind'],
        'service': 'named',
        'config_source_dir': 'bind/files/redhat',
        'zones_source_dir': 'zones',
        'config': '/etc/named.conf',
        'local_config': '/etc/named.conf.local',
        'default_config': '/etc/sysconfig/named',
        'named_directory': '/var/named/data',
        'log_dir': '/var/log/named',
        'user': 'root',
        'group': 'named',
        'mode': '640'
    },
 

Поскольку эта страница является лучшим результатом поиска для «импорта jinja с контекстом» (а в другом ответе на самом деле не сказано, что он делает), и я продолжаю возвращаться на эту страницу каждые пару месяцев, когда мне нужно возиться с солью, но забываю, что with context делает:

Когда вы import foo работаете в jinja, обычно макросы, в которых вы определили, foo не имеют доступа к переменным в файле, из которого вы его импортируете. В качестве оптимизации Jinja затем кэширует это, если вы снова импортируете файл позже. Если вместо этого вы это сделаете import foo with context , то макросы в foo могут обращаться к переменным в файле, из которого они импортируются. Компромисс заключается в том, что Jinja больше не кэширует foo , поэтому вы платите за время рендеринга.

Когда вы это делаете include , ваши переменные передаются в другой файл. Затем вы отображаете содержимое другого файла и вставляете его. Если вы это сделаете include foo without context , вы не передадите переменные текущего файла. Это полезно, потому что Jinja оптимизирует это, кэшируя содержимое foo , ускоряя ваш рендеринг.

with context является частью шаблонизатора jinja.

Вы можете прочитать больше об этом в документах jinja docs:

• поведение контекста импорта
• контекстный API

Что касается отсутствующих данных debian — это ваша полная карта.jinja? фрагмент не }, default='Debian') %} соответствует зернам.filter_by