Избегание ограничителей шаблонов jinja в операторах when

Вопрос или проблема

В настоящее время я переношу свои Ansible playbook с версии 2.1 на 2.7. Ansible теперь выводит предупреждение, если я использую разделители шаблонов jinja, такие как {{ .. }} в условии when.

[WARNING]: when statements should not include jinja2 templating delimiters such as {{ }} or {% %}

У меня не возникло проблем с изменением простых условных выражений, но я хочу узнать, как исправить это:

- shell: pg_lsclusters -h | awk '{print $2 " " $6}'
  register: postgresql_lsclusters
  changed_when: false
  check_mode: no

- fail: 
    msg="test"
  when: postgresql_lsclusters.stdout.find("{{ postgresql_cluster }} {{ postgresql_data_dir }}/{{ postgresql_version }}/{{ postgresql_cluster }}") == -1

Я попытался заменить выражение when следующим образом, но без успеха:

when: postgresql_lsclusters.stdout.find(postgresql_cluster ~ ' ' ~ postgresql_data_dir ~ "https://serverfault.com/" ~ postgresql_version ~ "https://serverfault.com/" ~ postgresql_cluster") == -1`

Что-то вроде этого?

- name: Поиск кластера PG
  vars:
    big_pg_var: "{{ postgresql_cluster }} {{ postgresql_data_dir }}/{{ postgresql_version }}/{{ postgresql_cluster }}"
  fail:
    msg="test"
  when: postgresql_lsclusters.stdout.find(big_pg_var) == -1

Ответ или решение

Избегание использования делимитеров Jinja в условных операторах Ansible

При переносе ваших плейбуков Ansible с версии 2.1 на 2.7 вы столкнулись с предупреждением о том, что условия в блоке when не должны содержать делимитеры Jinja, такие как {{ }} или {% %}. Это изменение в Ansible направлено на улучшение читабельности кода и уменьшение вероятности ошибок при интерпретации шаблонов. Чтобы решить эту проблему, предлагаю рассмотреть несколько подходов.

Основа проблемы

Данная ошибка возникает, когда вы пытаетесь использовать переменные в выражении условия when, используя синтаксис Jinja. Например:

when: postgresql_lsclusters.stdout.find("{{ postgresql_cluster }} {{ postgresql_data_dir }}/{{ postgresql_version }}/{{ postgresql_cluster }}") == -1

Такой подход больше не рекомендуется, и Ansible выдает предупреждение. Текущий синтаксис намного проще и безопаснее, и его использование помогает избежать потенциальных проблем при интерпретации переменных.

Правильный подход

Одним из наиболее простых способов устранения указанной проблемы — это использовать дополнительные переменные, определенные в блоке vars или vars_file. Пример вашего кода с использованием дополнительных переменных выглядит следующим образом:

- name: PG cluster find
  vars:
    big_pg_var: "{{ postgresql_cluster }} {{ postgresql_data_dir }}/{{ postgresql_version }}/{{ postgresql_cluster }}"
  fail:
    msg: "test"
  when: postgresql_lsclusters.stdout.find(big_pg_var) == -1

Здесь вы определяете переменную big_pg_var, которая объединяет все необходимые элементы в одну строку. Это позволяет использовать переменную в условии без необходимости в дополнительных делимитерах.

Альтернативный способ

Если вы хотите избежать использования Jinja в условии when вообще, вы можете использовать встроенные функции Ansible для проверки наличия строки. Например:

- set_fact:
    big_pg_var: "{{ postgresql_cluster }} {{ postgresql_data_dir }}/{{ postgresql_version }}/{{ postgresql_cluster }}"

- fail:
    msg: "test"
  when: big_pg_var not in postgresql_lsclusters.stdout

В этом примере мы используем альтернативный подход, при котором вместо поиска индекса поздравляем проверку – содержится ли нужное значение в выходных данных stdout. Это позволяет избежать использования делимитеров Jinja в блоке when, что соответствет новым требованиям Ansible.

Заключение

Соблюдение новых стандартов написания условных операторов в Ansible делает ваши плейбуки более чистыми и легкими для чтения. Избегая использования делимитеров Jinja в блоках when, вы не только соответствуете актуальным требованиям Ansible, но и улучшаете поддерживаемость кода в долгосрочной перспективе. Надеюсь, приведенные методы помогут вам успешно адаптировать ваши плейбуки к новым стандартам.

Оцените материал
Добавить комментарий

Капча загружается...