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

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

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

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

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

• Командная строка
• Совместимость с Python
• Плейбук
  • Исправление порядка приоритета ролей во время загрузки ролей
  • Экспозиция переменных include_role и import_role
  • Встроенные переменные include_tasks/import_tasks
  • vars_prompt с неизвестными алгоритмами
• Устаревшие
  • Ускоренное устаревание: Удаление параметра модуля params в ldap_attr и ldap_entry
  • Ускоренное устаревание: Использование __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 к модулю include_role был добавлен новый аргумент public, определяющий, будут ли переменные 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 для пароля как запрос не устанавливать пароль. Если ваш плейбук начинает выводить ошибки по этой причине, измените используемый алгоритм хеширования с помощью этого фильтра.

Устаревшие

Ускоренное устаревание: Удаление параметра модуля params в ldap_attr и ldap_entry

Параметр модуля params в ldap_attr и ldap_entry устарел по сокращенному циклу (будет удален в Ansible 2.10) из-за обхода обычной обработки параметров Ansible. В частности, если параметр bind_pw задан со значением params, значение параметра может быть помещено в файл журнала или выведено на стандартный вывод.

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

Модули

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

• Настройка 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 вместо этого.

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

• Проблема безопасности Установка bind_pw с параметром params для модулей ldap_entry и ldap_attr запрещена. Если bind_pw устанавливалось с params, значение могло попасть в журнал или отобразиться в стандартном выводе. Установите bind_pw напрямую, используя параметры модулей вместо этого.
• Режим проверки (check mode) теперь поддерживается в модулях 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 вместе. Теперь это работает правильно, но может потребоваться внести изменения в задачи.

Плагины

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

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

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

Сети

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