Руководство по переносу Ansible-core 2.14
В этом разделе рассматриваются изменения в поведении между версией ansible-core 2.13 и версией ansible-core 2.14.
Цель этого руководства – помочь в обновлении ваших плейбуков, плагинов и других частей вашей инфраструктуры Ansible, чтобы они работали с этой версией Ansible.
Рекомендуется прочитать эту страницу вместе с Журналом изменений Ansible-core 2.14, чтобы понять, какие обновления вам могут потребоваться.
Этот документ является частью коллекции руководств по переносу. Полный список руководств по переносу можно найти по адресу руководствам по переносу.
Плейбук
-
Условные выражения – из-за устранения уязвимости CVE-2023-5764 в ansible-core 2.14.12, условные выражения с вложенными блоками шаблонов могут завершаться сообщением «
Conditional is marked as unsafe, and cannot be evaluated.» при обращении вложенного шаблона к данным из ненадежных источников, таких как результаты модулей или переменные, помеченные!unsafe. Условные выражения с вложенными шаблонами могут быть источником вредоносного внедрения шаблонов при ссылке на ненадежные данные, и почти всегда могут быть переписаны без вложенных шаблонов. Ключевые слова условных выражений задач плейбука, такие как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.14 выражение
{{ defined_variable or undefined_variable }}не завершается ошибкой наundefined_variable, если первая частьorвычисляется доTrue, поскольку для вычисления второй части это не требуется. Один конкретный случай изменения поведения, на который следует обратить внимание, – это задача ниже, которая использует тестundefined. До версии 2.14 это приводило к ошибке, пытающейся получить доступ к неопределенному значению в словаре. В версии 2.14 утверждение проходит, поскольку словарь оценивается как неопределенный через одно из своих неопределенных значений:
- assert:
that:
- some_defined_dict_with_undefined_values is undefined
vars:
dict_value: 1
some_defined_dict_with_undefined_values:
key1: value1
key2: '{{ dict_value }}'
key3: '{{ undefined_dict_value }}'
Командная строка
- Python 3.9 на узле контроллера является обязательным требованием для этой версии.
- При запуске проверяются кодировка файловой системы и язык локализации, чтобы убедиться, что они UTF-8. В противном случае процесс завершается с ошибкой, сообщающей об ошибочной кодировке. Если вы ранее использовали локаль
CилиPOSIX, вы можете использоватьC.UTF-8. Если вы ранее использовали такую локаль, какen_US.ISO-8859-1, вы можете использоватьen_US.UTF-8. Для простоты проще всего экспортировать соответствующую локаль, используя переменную окруженияLC_ALL. Альтернативой изменению системной локали является запуск Python в режиме UTF-8; см. документацию Python для получения дополнительной информации.
Устаревшие элементы
Нет заметных изменений
Модули
Нет заметных изменений
Удаленные модули
Следующие модули больше не существуют:
- Нет заметных изменений
Уведомления об устаревании
Нет заметных изменений
Заметные изменения в модулях
Нет заметных изменений
Плагины
Нет заметных изменений
Перенос пользовательских скриптов
Нет заметных изменений
Сеть
Нет заметных изменений
© 2012–2018 Michael DeHaan
© 2018–2024 Red Hat, Inc.
Licensed under the GNU General Public License version 3.
https://docs.ansible.com/ansible/latest/porting_guides/porting_guide_core_2.14.html