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

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

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

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

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

• Версия Python
• Инвентаризация
  • Начальные playbook относительные group_vars и host_vars
• Устаревшие
  • Указание источников инвентаризации
  • Использование нескольких тегов
  • Другие замечания
• Модули
  • Удаленные модули
  • Уведомления об устаревании
  • Заметные изменения в модулях
• Плагины
  • Изменения в плагинах vars
  • Плагины инвентаризации
  • Плагины обратной связи
  • Плагин поиска шаблонов: Экранирование строк
• Тесты
  • Успешные/неудачные тесты
• Сети
  • Постоянное соединение
• Конфигурация

Версия Python

Ansible больше не будет поддерживать Python 2.4 или 2.5 на целевых хостах. В дальнейшем на целевых хостах потребуется Python 2.6+, как это уже есть на контроллере.

Инвентаризация

Инвентаризация была переработана для реализации через плагины и теперь позволяет использовать несколько источников. Это изменение в основном прозрачно для пользователей.

Исключением является inventory_dir, который теперь является переменной хоста; ранее он мог иметь только одно значение, поэтому он устанавливался глобально. Это означает, что вы больше не можете использовать его на ранних этапах задач для определения hosts: или аналогичных ключевых слов. Это также меняет поведение add_hosts и неявного localhost; поскольку они больше не автоматически наследуют глобальное значение, по умолчанию они устанавливаются в значение None. Дополнительную информацию можно найти в документации модуля.

inventory_file остается неизменным, поскольку он всегда был специфичен для хоста.

Была исправлена ошибка с путем/каталогом инвентаризации, который по умолчанию устанавливался в текущую рабочую директорию. Это приводило к тому, что group_vars и host_vars подбирались из текущей рабочей директории, а не только рядом с playbook или каталогом инвентаризации, когда список хостов (разделенных запятыми имен хостов) предоставлялся в качестве инвентаризации.

Начальные playbook относительные group_vars и host_vars

В версиях Ansible до 2.4 система инвентаризации сохраняла контекст начального playbook, который был выполнен. Это позволяло последовательно включаемым playbook из других каталогов наследовать group_vars и host_vars, расположенные относительно файла playbook верхнего уровня.

Из-за некоторых несоответствий в поведении эта функциональность не будет включена в новую систему инвентаризации, начиная с Ansible версии 2.4.

Аналогичную функциональность можно получить, используя vars_files, include_vars или group_vars и host_vars, расположенные относительно файла инвентаризации.

Устаревшие

Указание источников инвентаризации

Использование --inventory-file в командной строке устарело. Используйте --inventory или -i. Соответствующий ключ конфигурации ini, hostfile, и переменная среды, ANSIBLE_HOSTS, также устарели. Замените их ключом конфигурации inventory и переменной среды ANSIBLE_INVENTORY.

Использование нескольких тегов

Указание --tags (или --skip-tags) несколько раз в командной строке в настоящее время приводит к тому, что последнее значение перекрывает все предыдущие. Это поведение устарело. В будущем, если вы укажете –tags несколько раз, теги будут объединены. Отныне использование --tags несколько раз в одной командной строке выведет предупреждение об устаревании. Установка параметра merge_multiple_cli_tags в значение True в файле ansible.cfg позволит включить новое поведение.

В 2.4 значение по умолчанию изменено на объединение тегов. Вы можете включить старое поведение перезаписи с помощью параметра конфигурации.

В 2.5 несколько параметров --tags будут объединены без возможности вернуться к старому поведению.

Другие замечания

В этой версии нет существенных изменений.

Модули

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

• Модули win_shell и win_command теперь корректно сохраняют цитируемые аргументы в командной строке. Задачи, которые пытались обойти проблему, добавляя дополнительные кавычки/экранирование, могут потребовать переработки, чтобы удалить излишнее экранирование. Дополнительные сведения см. в проблеме 23019.

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

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

• Нет

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

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

• azure, используйте azure_rm_virtualmachine, который использует новую SDK Resource Manager.
• win_msi, используйте win_package вместо него

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

• У модуля win_get_url словарь win_get_url в результатах устарел, его содержимое теперь также доступно непосредственно в результирующем выводе, как и в других модулях. Этот словарь будет удален в Ansible 2.8.
• Модуль win_unzip больше не включает словарь win_unzip в своих результатах; содержимое теперь включено непосредственно в результирующий вывод, как и в других модулях.
• Значения возврата модуля win_package exit_code и restart_required устарели в пользу rc и reboot_required соответственно. Устаревшие значения возврата будут удалены в Ansible 2.6.

Плагины

Был представлен новый способ конфигурирования и документирования плагинов. Это не требует изменений в существующих настройках, но разработчики должны начать адаптацию к новой инфраструктуре сейчас. Более подробная информация будет доступна в документации для разработчиков для каждого типа плагинов.

Изменения в плагинах vars

Было много изменений в реализации плагинов vars, но пользователям и разработчикам не нужно ничего менять, чтобы сохранить работоспособность текущих настроек. Разработчики должны рассмотреть возможность изменения своих плагинов, чтобы воспользоваться новыми возможностями.

Самое заметное различие для пользователей заключается в том, что плагины vars теперь вызываются по требованию, а не во время построения инвентаризации. Это должно сделать их более эффективными для больших инвентаризаций, особенно при использовании подмножества хостов.

Плагины инвентаризации

Разработчики должны начать миграцию от жестко запрограммированной инвентаризации с динамическими скриптами инвентаризации к новым плагинам инвентаризации. Скрипты по-прежнему будут работать через плагин инвентаризации script, но усилия по развитию Ansible теперь будут сосредоточены на написании плагинов, а не на улучшении существующих скриптов.

Пользователи и разработчики должны изучить новые плагины, потому что они предназначены для устранения необходимости во многих обходных путях и решениях, встречающихся в динамических скриптах инвентаризации.

Плагины обратной связи

Пользователи:

• Плагины обратной связи теперь используют новую систему конфигурации. Пользователям не нужно ничего изменять, так как старая система по-прежнему работает, но вы можете увидеть уведомление об устаревании, если используемые плагины обратной связи не наследуют встроенные классы. Разработчикам необходимо обновить их, как указано ниже.

Разработчики:

• Если ваш обратный вызов не наследуется от CallbackBase (прямо или косвенно через другой обратный вызов), он по-прежнему будет работать, но будет выведено уведомление об устаревании. Чтобы избежать этого и гарантировать его работу в будущем, измените его так, чтобы он наследовался от callbackBase, чтобы он имел новые методы и свойства обработки параметров. Вы также можете реализовать новые методы и свойства обработки параметров, но это не гарантирует автоматическое наследование изменений, добавленных в будущем. Вы можете посмотреть подробности в CallbackBase и/или AnsiblePlugin.
• Любые обратные вызовы, наследующие от других обратных вызовов, могут потребовать обновления для включения тех же документированных параметров, что и у родительского обратного вызова, иначе параметры не будут доступны. Это отмечено в руководстве разработчика.

Плагин поиска шаблонов: Экранирование строк

До Ansible 2.4 обратные слеши в строках, переданных плагину поиска шаблонов, экранировались автоматически. В версии 2.4 пользователи отвечают за экранирование обратных слешей самостоятельно. Это изменение согласует плагин поиска шаблонов с модулем шаблона, чтобы правила экранирования обратных слешей были одинаковыми для обоих.

Если у вас есть поиск шаблона такого вида:

- debug:
    msg: '{{ lookup("template", "template.j2") }}'

СТАРЫЙ В Ansible 2.3 (и ранее) template.j2 выглядело так:

{{ "name surname" | regex_replace("^[^\s]+\s+(.*)", "\1") }}

НОВЫЙ В Ansible 2.4 это должно быть изменено на:

{{ "name surname" | regex_replace("^[^\\s]+\\s+(.*)", "\\1") }}

Тесты

Тесты пройдены/не пройдены

До версии Ansible 2.4 код возврата задачи rc переопределял код возврата failed. В версии 2.4 для расчета состояния задачи используются и rc, и failed. Из-за этого также были изменены плагины тестирования succeeded/failed`. Это означает, что переопределение завершения задачи с failed_when: no приведет к тому, что succeeded/failed вернут True/False. Например:

• command: /bin/false register: result failed_when: no

• debug:

  msg: ‘Это выводится в 2.3’

  when: result|failed

• debug:

  msg: ‘Это выводится в 2.4’

  when: result|succeeded

• debug:

  msg: ‘Это всегда выводится’

  when: result.rc != 0

Как видно из примера выше, в Ansible 2.3 succeeded/failed проверяли только значение rc.

Сеть

Было внесено несколько изменений в работу модулей сети.

Плейбуки должны по-прежнему использовать connection: local.

Постоянное соединение

Переменные конфигурации connection_retries и connect_interval, добавленные в Ansible 2.3, теперь устарели. Для Ansible 2.4 и более поздних версий используйте connection_retry_timeout.

Для управления таймаутами используйте command_timeout вместо предыдущей переменной верхнего уровня timeout в [default]

Дополнительную информацию см. в Руководстве по отладке сети Ansible.

Конфигурация

Система конфигурации претерпела значительные изменения. Пользователи, как правило, не должны столкнуться с проблемами, за исключением следующего:

• Все относительные пути определяются относительно самого файла ansible.cfg. Ранее они варьировались в зависимости от настройки. Новое поведение должно быть более предсказуемым.
• Доступен новый макрос {{CWD}}, который сделает пути относительными к 'текущей рабочей директории'. Это небезопасно, но некоторые пользователи действительно хотят полагаться на такое поведение.

Разработчики, работающие напрямую с предыдущим API, должны пересмотреть свое использование, так как некоторые методы (например, get_config) были сохранены для обратной совместимости, но будут предупреждать пользователей о том, что функция устарела.

Новая конфигурация спроектирована таким образом, чтобы свести к минимуму необходимость изменений кода в ядре для новых плагинов. Плагины просто должны документировать свои настройки, и система конфигурации будет использовать документацию для получения необходимых данных. Это по-прежнему находится в разработке; в настоящее время этим поддерживаются только плагины «callback» и «connection». Дополнительные сведения будут добавлены в конкретные руководства разработчиков плагинов.