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

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

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. Это может вызвать изменение поведения, если одна и та же переменная определена на уровне playbook и на уровне роли с разными значениями и используется в import_tasks или import_role для определения роли или файла для импорта.

Доступ к переменным include_role и import_role

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

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

Существует важное различие в способе, которым include_role (динамический) предоставляет доступ к переменным роли, по сравнению с import_role (статический). import_role — это предобработчик, а defaults и vars оцениваются при разборе playbook, делая переменные доступными для задач и ролей, перечисленных в любой точке playbook. 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 как запрос не устанавливать пароль. Если ваш playbook начинает выдавать ошибки из-за этого, измените используемый алгоритм хеширования с этим фильтром.

Ускоренное устаревание: использование __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]))

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

Использование squash_actions для вызова модуля пакета, такого как «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

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

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

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

Следующие модули будут удалены в 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 был удалён и должен быть удалён из ваших playbook'ов
• Модуль 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 вместе. Теперь это работает правильно, но может потребоваться внести изменения в задачи.