Ansible Handler通知vs寄存器(Ansible Handler notify vs register)

Ansible Handler通知vs寄存器(Ansible Handler notify vs register)

因此，在阅读Ansible文档后，我发现只有在任务报告更改时才会触发Handlers ，例如：

some tasks ... notify: nginx_restart # our handler - name: nginx_restart

VS

some tasks ... register: nginx_restart # do this after nginx_restart changes when: nginx_restart|changed

这两种方法有什么区别吗？ 我应该什么时候使用他们每个人？ 对我而言， register似乎在这里有更多的功能，除非我错过了一些东西......

So after reading Ansible docs, I found out that Handlers are only fired when tasks report changes, so for example:

some tasks ... notify: nginx_restart # our handler - name: nginx_restart

vs

some tasks ... register: nginx_restart # do this after nginx_restart changes when: nginx_restart|changed

Is there any difference between these 2 methods? When should I use each of them? For me, register seems to have more functionality here, unless I am missing something...

最满意答案

有一些差异，哪一个更好取决于情况。

处理程序只有在实际执行时才会在输出中可见。 没有通知，Ansibles输出中不会有跳过的任务 。 任务总是有输出，无论是否跳过执行。 （除了通过tags / skip-tags排除它们外）

处理程序可以从任何角色调用。 如果你有更复杂的角色彼此依赖，这将变得方便。 假设你有一个管理iptables的角色，但是你定义的规则实际上取决于其他角色（例如数据库角色，redis角色等）。每个角色都可以将他们的规则添加到配置文件中，并在最后通知iptables如果更改，可以重新加载iptables。

处理程序默认在剧本结束时执行。 任务将在其定义的地方立即执行。 通过这种方式，您可以配置所有应用程序，并且最终将为每个处理程序触发所有已更改应用程序的服务重新启动。 但这可能很危险。 如果在处理程序通知后您的playbook失败，处理程序实际上不会被调用。 如果再次运行剧本，则触发任务可能不再具有更改的状态，因此不会通知处理程序。 这导致Ansible实际上不是幂等的。 从Ansible 1.9.1开始，您可以使用--force-handler选项调用Ansible，或者在ansible.cfg定义force_handlers = True ，以便在剧本失败后触发所有通知的处理程序。 （ 请参阅文档 ）

如果您需要在特定点处理您的处理程序（例如，您将系统配置为使用内部DNS并且现在想通过此DNS解析主机），则可以通过定义如下任务来刷新所有处理程序：

- meta: flush_handlers

无论事件通知了多少次，处理程序只会被调用一次。 假设你有一个服务依赖于多个配置文件（例如bind / named：rev，zone，root.db，rndc.key，named.conf），并且如果这些文件中的任何一个发生了变化，你想重新启动named。 使用处理程序，您只需从每个管理这些文件的任务中通知。 否则，你需要注册5个无用的变量，然后在你的重启任务中检查它们。

我个人更喜欢处理程序。 它看起来比处理register更清洁。 在Ansible 1.9.1之前，每个注册触发的任务更安全。

There are some differences and which is better depends on the situation.

Handlers will only be visible in the output if they have actually been executed. Not notified, there will be no skipped tasks in Ansibles output. Tasks always have output no matter if skipped, executed with change or without. (except they are excluded via tags/skip-tags)

Handlers can be called from any role. This gets handy if you have more complex roles which depend on each other. Let's say you have a role to manage iptables but which rules you define is actually depending on other roles (e.g. database role, redis role etc...) Each role can add their rules to a config file and at the end you notify the iptables role to reload iptables if changed.

Handlers by default get executed at the end of the playbook. Tasks will get executed immediately where they are defined. This way you could configure all your applications and at the end the service restart for all changed apps will be triggered per handler. This can be dangerous though. In case your playbook fails after a handler has been notified, the handler will actually not be called. If you run the playbook again, the triggering task may not have a changed state any longer, therefore not notifying the handler. This results in Ansible actually not being idempotent. Since Ansible 1.9.1 you can call Ansible with the --force-handler option or define force_handlers = True in your ansible.cfg to even fire all notified handlers after the playbook failed. (See docs)

If you need your handlers to be fired at a specific point (for example you configured your system to use an internal DNS and now want to resolve a host through this DNS) you can flush all handlers by defining a task like:

- meta: flush_handlers

A handler would be called only once no matter how many times it was notified. Imagine you have a service that depends on multiple config files (for example bind/named: rev, zone, root.db, rndc.key, named.conf) and you want to restart named if any of these files changed. With handlers you simply would notify from every single task that managed those files. Otherwise you need to register 5 useless vars, and then check them all in your restart task.

Personally I prefer handlers. It appears much cleaner than dealing with register. Tasks triggered per register was safer before Ansible 1.9.1.