Руководство по переносу Ansible-core 2.15

В этом разделе рассматриваются изменения в поведении между ansible-core 2.14 и ansible-core 2.15.

Он предназначен для помощи в обновлении ваших playbooks, плагинов и других частей вашей инфраструктуры Ansible, чтобы они работали с этой версией Ansible.

Мы рекомендуем прочитать эту страницу вместе с Журналом изменений Ansible-core 2.15, чтобы понять, какие обновления вам могут потребоваться.

Этот документ является частью коллекции по переносу. Полный список руководств по переносу можно найти по адресу руководствам по переносу.

Playbook
- Обработчики
Командная строка
Устаревшие
Модули
Плагины
Перенос пользовательских скриптов
Сети

Playbook

Условные операторы — из-за устранения проблемы безопасности CVE-2023-5764 в ansible-core 2.15.7, условные выражения с встроенными блоками шаблонов могут завершиться с сообщением «Conditional is marked as unsafe, and cannot be evaluated.», когда встроенный шаблон обращается к данным из недоверенных источников, таких как результаты модулей или переменные, помеченные !unsafe. Условные операторы с встроенными шаблонами могут быть источником вредоносной подстановки шаблонов при ссылке на недоверенные данные, и их почти всегда можно переписать без встроенных шаблонов. Условные операторы задач Playbook, такие как when и until , давно отображают предупреждения, отговаривающие от использования встроенных шаблонов в условных операторах; это предупреждение также распространено на условные операторы, не являющиеся задачами, такие как действие assert.
```
- name: task with a module result (always untrusted by Ansible)
  shell: echo "hi mom"
  register: untrusted_result

# don't do it this way...
# - name: insecure conditional with embedded template consulting untrusted data
#   assert:
#     that: '"hi mom" is in {{ untrusted_result.stdout }}'

- name: securely access untrusted values directly as Jinja variables instead
  assert:
    that: '"hi mom" is in untrusted_result.stdout'
```

Обработчики

Как документировано, если определено несколько обработчиков с одинаковым именем, последний добавленный в игру — тот, который выполняется при уведомлении. До ansible-core 2.15 это не так для обработчиков, динамически включённых в игру задачей include_role . Эта проблема решена в ansible-core 2.15, и пользователям, полагающимся на поведение ansible-core 2.14 и более ранних версий, может потребоваться соответствующим образом скорректировать свои playbooks.

В качестве примера изменения поведения рассмотрим следующее:

- include_role:
    name: foo
  vars:
    invocation: 1

- block:
   - include_role:
       name: foo
     vars:
       invocation: 2
  when: inventory_hostname == "bar"

- meta: flush_handlers

Примечание

Пример предполагает, что в роли foo есть задача, уведомляющая обработчик с именем foo_handler в роли foo.

Примечание

Тот факт, что разные переменные и/или их значения прикреплены к задачам include_role , включая одну и ту же роль, делает их различными ролями.

Примечание

Второе выполнение задачи include_role приводит к включению задач и обработчиков из роли независимо от результата условного оператора when. Условный оператор when прикреплён к block , охватывающему задачу include_role , и поэтому условный оператор when применяется ко всем задачам и обработчикам из роли после их включения в игру.

К моменту выполнения задачи flush_handlers все хосты уведомлены foo_handler при первом выполнении include_role. Кроме того, хост bar (из-за when , ограничивающего все остальные хосты) уведомил foo_handler снова во время второго выполнения include_role.

В ansible-core 2.15 последний обработчик с именем foo_handler , добавленный в игру, происходит со второго выполнения include_role , и поэтому к нему прикреплён when: inventory_hostname == "bar" , в результате чего обработчик фактически выполняется только на хосте bar и пропускается на всех остальных хостах. Следовательно, уведомления с хоста bar были дедублированы.

В ansible-core 2.14 и более ранних версиях foo_handler с первого выполнения запускается на всех хостах. Кроме того, foo_handler со второго выполнения запускается на хосте bar снова.

Командная строка

Код возврата ansible-galaxy search теперь равен 0 вместо 1, а вывод stdout пустой, когда результаты пусты, для соответствия другим командам ansible-galaxy .