Итак, после чтения Ansible docs я обнаружил, что Handlers запускаются только при изменении отчетов о задачах, например:
some tasks ...
notify: nginx_restart
# our handler
- name: nginx_restart
против
some tasks ...
register: nginx_restart
# do this after nginx_restart changes
when: nginx_restart|changed
Есть ли разница между этими двумя методами? Когда следует использовать каждый из них?
Для меня register, похоже, имеет больше функциональности, если только я что-то не хватает...
Есть некоторые отличия, и это лучше зависит от ситуации.
Обработчики будут отображаться только на выходе, если они действительно были выполнены. Не сообщается, что в выпуске Ansibles не будет пропущенных задач. Задачи всегда имеют выход независимо от того, пропущены, выполнены с изменением или без. (за исключением того, что они исключаются через теги/теги пропуска)
Обработчики могут вызываться из любой роли. Это становится удобно, если у вас более сложные роли, которые зависят друг от друга. Скажем, у вас есть роль в управлении iptables, но какие правила вы определяете, в действительности зависит от других ролей (например, роль базы данных, роль redis и т.д.). Каждая роль может добавлять свои правила в файл конфигурации, а в конце вы уведомляете iptables роль для перезагрузки iptables при изменении.
Обработчики по умолчанию получают выполнение в конце учебника. Задачи будут выполняться немедленно, когда они определены. Таким образом, вы можете настроить все свои приложения, и в конце перезапуск службы для всех измененных приложений будет запущен для каждого обработчика. Это может быть опасно. В случае сбоя вашей плей-книжки после уведомления обработчика обработчик фактически не будет вызван. Если вы снова запустите playbook, задача запуска может не иметь измененного состояния, поэтому не будет уведомлять обработчик. Это приводит к тому, что Ansible фактически не является идемпотентным. Начиная с Ansible 1.9.1 вы можете вызвать Ansible с опцией --force-handler или определить force_handlers = True в ansible.cfg, чтобы даже запустить все обработчики уведомлений после выхода из игры. (См. документы)
Если вам нужно, чтобы ваши обработчики были запущены в определенном месте (например, вы настроили вашу систему на использование внутреннего DNS и теперь хотите разрешить хост через этот DNS), вы можете очистить все обработчики, определив задачу как:
- meta: flush_handlers
Обработчик будет вызываться только один раз независимо от того, сколько раз он был уведомлен. Представьте, что у вас есть служба, которая зависит от нескольких файлов конфигурации (например, bind/named: rev, zone, root.db, rndc.key, named.conf), и вы хотите перезапустить named, если какой-либо из этих файлов изменился. С обработчиками вы просто уведомляете каждую задачу, которая управляла этими файлами. В противном случае вам нужно зарегистрировать 5 бесполезных варов, а затем проверить их все в своей задаче перезагрузки.
Лично я предпочитаю обработчики. Он выглядит намного чище, чем иметь дело с register. Задачи, инициированные для каждого регистра, были безопаснее перед Ansible 1.9.1.
На странице Ansible Variables вы можете увидеть, как работает register.
Другим важным применением переменных является выполнение команды и использование результата этой команды для сохранения результата в переменной.
Зарегистрированные переменные - это как факты:
Эффективно зарегистрированные переменные точно так же, как факты.
Это сильно отличается от notify, который запускает обработчики. Он не сохраняет и не сохраняет переменные или факты.
с ignore_errors: True вы можете избежать отказавшего обработчика от остановки других обработчиков, определенных после продолжения работы