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

Исходный 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 будут объединены, без возможности возврата к старому поведению.

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

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

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

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

• Ни одного

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

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

• azure, используйте azure_rm_virtualmachine, который использует новый SDK для управления ресурсами.
• 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: 'This is printed on 2.3'
  when: result|failed

- debug:
    msg: 'This is printed on 2.4'
  when: result|succeeded

- debug:
    msg: 'This is always printed'
  when: result.rc != 0

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

Персистентное подключение

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

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

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