Руководство по переносу Ansible 2.7

В этом разделе обсуждаются изменения в поведении между Ansible 2.6 и Ansible 2.7.

Цель документа — помочь обновить ваши плейбуки, плагины и другие части вашей инфраструктуры Ansible, чтобы они работали с этой версией.

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

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

• Командная строка
• Совместимость с Python

• Плейбук

  • Исправление порядка приоритета ролей во время загрузки ролей
  • Экспонирование переменных include_role и import_role
  • Встроенные переменные в include_tasks/import_tasks
  • vars_prompt с неизвестными алгоритмами

• Устаревшие функции

  • Ускоренное устаревание: Использование __file__ в AnsibleModule
  • Использование цикла с модулем package через squash_actions

• Модули

  • Удаленные модули
  • Уведомления об устаревании
  • Заметные изменения в модулях
• Плагины
• Перенос пользовательских скриптов
• Сеть

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

Если вы указываете --tags или --skip-tags несколько раз в командной строке, Ansible объединит указанные метки вместе. В предыдущих версиях Ansible вы могли установить merge_multiple_cli_tags на False, если хотели сохранить только последнюю указанную --tags. Эта конфигурационная опция существовала для обеспечения обратной совместимости. Поведение перезаписи устарело в 2.3, а поведение по умолчанию было изменено в 2.4. Ansible 2.7 удаляет конфигурационную опцию; несколько --tags теперь всегда объединяются.

Если у вас есть скрипт оболочки, зависящий от установки merge_multiple_cli_tags на False, пожалуйста, обновите свой скрипт, чтобы он добавлял только --tags значение, которое вам нужно, прежде чем обновлять до Ansible 2.7.

Совместимость с Python

Ansible прекратил поддержку Python 2.6 на контроллере (хосте, где выполняется /usr/bin/ansible или /usr/bin/ansible-playbook). Модули, поставляемые с Ansible, все еще могут использоваться для управления хостами, на которых установлен только Python 2.6. Вам просто нужен хост с Python 2.7 или Python 3.5 или выше, чтобы управлять этими хостами.

Это влияет на возможность использования /usr/bin/ansible-pull для управления хостом с Python 2.6. ansible-pull выполняется на управляемом хосте, но это скрипт контроллера, а не модуль, поэтому ему потребуется обновленный Python. Активно развиваемые дистрибутивы Linux, поставляемые с Python 2.6, имеют средства для установки более новых версий Python (например, вы можете установить Python 2.7 через SCL на RHEL-6), но вам, возможно, также потребуется установить Python-связки для работы многих распространенных модулей (например, для RHEL-6, для обновленной установки Python необходимо установить selinux-связки и yum).

Решение о прекращении поддержки Python 2.6 на контроллере было принято, потому что многие зависимые библиотеки становятся недоступными там. В частности, python-cryptography больше не доступен для Python 2.6, а последняя версия pycrypto (альтернатива python-cryptography) имеет известные уязвимости безопасности, которые никогда не будут исправлены.

Плейбук

Исправление порядка приоритета ролей во время загрузки ролей

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

До Ansible 2.7, при загрузке роли переменные, определённые в файлах vars/main.yml и defaults/main.yml роли, были недоступны при разборе файла tasks/main.yml роли. Это препятствовало использованию этих переменных ролью при её разборе. Проблема проявлялась при использовании import_tasks или import_role с переменной, определённой в vars или defaults роли.

В Ansible 2.7, файлы vars и defaults роли теперь обрабатываются перед файлом tasks/main.yml. Это может привести к изменению поведения, если одна и та же переменная определена на уровне плейбука и уровня роли с разными значениями и используется в import_tasks или import_role для определения импортируемой роли или файла.

Экспонирование переменных include_role и import_role

В Ansible 2.7 был добавлен новый аргумент модуля public к модулю include_role, который определяет, будут ли переменные defaults и vars роли экспонированы за пределами роли, что позволит использовать эти переменные последующим задачам. Значение по умолчанию равно public: False, что соответствует текущему поведению.

import_role не поддерживает аргумент public и безусловно экспонирует переменные defaults и vars роли остальной части плейбука. Эта функциональность приближает import_role к ролям, перечисленным в заголовке roles плейбука.

Существует важное различие в том, как include_role (динамически) экспонирует переменные роли по сравнению с import_role (статически). import_role — это предобработчик, а defaults и vars оцениваются при разборе плейбука, делая переменные доступными для задач и ролей, перечисленных в любой точке плейбука. include_role — это условная задача, а defaults и vars оцениваются во время выполнения, делая переменные доступными для задач и ролей, перечисленных *после* задачи include_role.

Встроенные переменные в include_tasks/import_tasks

Начиная с Ansible 2.7, include_tasks и import_tasks больше не могут принимать встроенные переменные. Вместо этого задачи должны передавать переменные с помощью ключевого слова vars.

СТАРОЕ В Ansible 2.6 (и ранее) допустимый синтаксис для указания переменных был:

- include_tasks: include_me.yml variable=value

НОВОЕ В Ansible 2.7 задача должна быть изменена на использование ключевого слова vars.

- include_tasks: include_me.yml
  vars:
    variable: value

vars_prompt с неизвестными алгоритмами

vars_prompt теперь выводит ошибку, если алгоритм хеширования, указанный в encrypt, не поддерживается контроллером. Это повышает безопасность vars_prompt, так как ранее он возвращал None, если алгоритм был неизвестен. Некоторые модули, в частности модуль user, рассматривали пароль None как запрос не устанавливать пароль. Если ваш плейбук начинает выдавать ошибки из-за этого, измените используемый алгоритм хеширования с этим фильтром.

Устаревшие функции

Ускоренное устаревание: Использование __file__ в AnsibleModule

Мы устареваем использование переменной __file__ для ссылки на файл, содержащий текущий выполняемый код. Этот распространенный прием в Python для поиска пути к файловой системе не всегда работает (даже в обычном Python). Иногда модуль Python может быть импортирован из виртуального расположения (например, внутри файла zip). В таких случаях переменная __file__ будет ссылаться на виртуальное расположение, указывающее на место внутри файла zip. Это может привести к проблемам, если, например, код пытается использовать __file__ для поиска каталога, содержащего модуль Python, чтобы записать некоторую временную информацию.

До появления AnsiBallZ в Ansible 2.1 использование __file__ работало в AnsibleModule иногда, но любой модуль, который его использовал, давал сбой при включённой конвейеризации (потому что модуль передавался в стандартный ввод интерпретатора Python, поэтому __file__ не содержал пути к файлу). AnsiBallZ непреднамеренно сделал использование __file__ рабочим, всегда создавая временный файл для AnsibleModule.

Ansible 2.8 больше не будет создавать временный файл для AnsibleModule; вместо этого он будет читать файл из файла zip. Это изменение должно ускорить выполнение модулей, но это означает, что начиная с Ansible 2.8, ссылка на __file__ всегда будет давать сбой в AnsibleModule.

Если вы являетесь автором стороннего модуля, использующего __file__ с AnsibleModule, пожалуйста, обновите свой модуль(и) сейчас, пока использование __file__ устарело, но всё ещё доступно. Наиболее распространённое использование __file__ — это поиск каталога для записи временного файла. В Ansible 2.5 и выше вы можете использовать атрибут tmpdir экземпляра AnsibleModule вместо этого, как показано в этом коде из модуля apt:

-    tempdir = os.path.dirname(__file__)
-    package = os.path.join(tempdir, to_native(deb.rsplit('/', 1)[1]))
+    package = os.path.join(module.tmpdir, to_native(deb.rsplit('/', 1)[1]))

Использование цикла с модулем package через squash_actions

Использование squash_actions для вызова модуля package, такого как “yum”, только для вызова модуля один раз устарело и будет удалено в Ansible 2.11.

Вместо использования неявного сжатия, задачи должны вместо этого передавать список напрямую в параметр name, pkg или package модуля. Эта функциональность поддерживается в большинстве модулей с Ansible 2.3.

СТАРОЕ В Ansible 2.6 (и ранее) следующая задача вызывала модуль «yum» только 1 раз для установки нескольких пакетов

- name: Install packages
  yum:
    name: "{{ item }}"
    state: present
  with_items: "{{ packages }}"

НОВОЕ В Ansible 2.7 она должна быть изменена следующим образом:

- name: Install packages
  yum:
    name: "{{ packages }}"
    state: present

Модули

Основные изменения в популярных модулях подробно описаны здесь

• Параметр конфигурации DEFAULT_SYSLOG_FACILITY сообщает модулям Ansible использовать определенный объект syslog при регистрации информации на всех управляемых машинах. Из-за ошибки в более старых версиях Ansible это значение не влияло на машины, использующие journald с установленными Python-связями systemd. На этих машинах сообщения журнала Ansible отправлялись в /var/log/messages, даже если вы установили DEFAULT_SYSLOG_FACILITY. Ansible 2.7 исправляет эту ошибку, направляя все сообщения журнала Ansible в соответствии со значением, установленным для DEFAULT_SYSLOG_FACILITY. Если у вас настроено DEFAULT_SYSLOG_FACILITY, местоположение удаленных журналов на системах, использующих journald, может измениться.

Удаленные модули

Следующие модули больше не существуют:

Уведомления об устаревании

Следующие модули будут удалены в Ansible 2.11. Пожалуйста, обновите свои playbook-файлы соответственно.

• na_cdot_aggregate используйте na_ontap_aggregate вместо этого.
• na_cdot_license используйте na_ontap_license вместо этого.
• na_cdot_lun используйте na_ontap_lun вместо этого.
• na_cdot_qtree используйте na_ontap_qtree вместо этого.
• na_cdot_svm используйте na_ontap_svm вместо этого.
• na_cdot_user используйте na_ontap_user вместо этого.
• na_cdot_user_role используйте na_ontap_user_role вместо этого.
• na_cdot_volume используйте na_ontap_volume вместо этого.
• sf_account_manager используйте na_elementsw_account вместо этого.
• sf_check_connections используйте na_elementsw_check_connections вместо этого.
• sf_snapshot_schedule_manager используйте na_elementsw_snapshot_schedule вместо этого.
• sf_volume_access_group_manager используйте na_elementsw_access_group вместо этого.
• sf_volume_manager используйте na_elementsw_volume вместо этого.

Заметные изменения в модулях

• Режим проверки теперь поддерживается в модулях command и shell. Однако только при указании creates или removes. Если указано одно из этих значений, модуль проверит существование файла и сообщит правильный статус изменения; если они не включены, модуль пропустит этот этап, как это делалось ранее.
• Модуль win_chocolatey изначально требовал proxy_username и proxy_password, чтобы экранировать все двойные кавычки в значении. Это больше не требуется, а экранирование может привести к дополнительным проблемам.
• Модуль win_uri удалил устаревший параметр use_basic_parsing, так как в Ansible 2.5 этот параметр ничего не делал

• Модуль win_scheduled_task удалил следующие устаревшие параметры:

  • executable, используйте path в записи действий вместо этого
  • argument, используйте arguments в записи действий вместо этого
  • store_password, установите logon_type: password вместо этого
  • days_of_week, используйте monthlydow в записи триггеров вместо этого
  • frequency, используйте type, в записи триггеров вместо этого
  • time, используйте start_boundary в записи триггеров вместо этого
• Параметр модуля interface_name для na_ontap_net_vlan был удален и должен быть удален из ваших playbooks
• Модуль win_disk_image устарел возвращаемое значение mount_path, используйте mount_paths[0] вместо этого. Это будет удалено в Ansible 2.11.

• include_role и include_tasks теперь могут быть использованы непосредственно из ansible (adhoc) и ansible-console:

  #> ansible -m include_role -a 'name=myrole' all
  

• Модуль pip добавил зависимость от setuptools для поддержки требований к версиям. Это требование относится к интерпретатору Python, который выполняет модуль, а не к интерпретатору Python, который управляет модулем.
• До Ansible 2.7.10 модуль replace делал обратное тому, что было задумано, при совместном использовании параметров before и after. Теперь это работает правильно, но может потребоваться изменение задач.

Плагины

• Фильтр hash_password теперь выводит ошибку, если указанный алгоритм хеширования не поддерживается контроллером. Это повышает безопасность фильтра, так как ранее он возвращал None, если алгоритм был неизвестен. Некоторые модули, в частности модуль пользователя, рассматривали пароль None как запрос не устанавливать пароль. Если ваш playbook начинает выдавать ошибки из-за этого, измените используемый алгоритм хеширования с этим фильтром.

Перенос пользовательских скриптов

Нет заметных изменений.

Сети

Нет заметных изменений.