Ansible处理程序通知vs注册 [英] Ansible Handler notify vs register

问题描述

因此，在阅读Ansible文档之后，我发现Handlers仅在任务报告更改时才被触发，例如:

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

这两种方法之间有什么区别吗?我什么时候应该使用它们? 对我来说，register似乎在这里有更多功能，除非我遗漏了某些东西...

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...

推荐答案

有一些区别，具体情况要视情况而定.

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

仅在实际执行了处理程序的情况下，它们才会在输出中可见.如果没有收到通知，Ansibles输出中将不会有任何已跳过的任务.无论是否跳过，更改执行或不执行，任务始终具有输出. (除了通过标签/跳过标签将其排除)

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)

可以从任何角色调用处理程序.如果您具有相互依赖的更复杂的角色，这将很方便.假设您有一个角色来管理iptables，但是您定义的规则实际上取决于其他角色(例如数据库角色，redis角色等).每个角色都可以将其规则添加到配置文件中，最后您通知iptables更改后重新加载iptables的角色.

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.

默认情况下，处理程序在剧本的末尾执行.任务将在定义后立即执行.这样，您可以配置所有应用程序，最后将为每个处理程序触发所有已更改应用程序的服务重启.但是，这可能很危险.如果通知处理程序后您的剧本失败，则实际上不会调用该处理程序.如果再次运行该剧本，则触发任务可能不再具有更改状态，因此不会通知处理程序.这导致Ansible实际上不是幂等的.从Ansible 1.9.1开始，您可以使用--force-handler选项调用Ansible，也可以在ansible.cfg中定义force_handlers = True，以在剧本失败后甚至触发所有通知的处理程序. (参阅文档)

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)

如果您需要在特定点触发处理程序(例如，您将系统配置为使用内部DNS，现在想通过此DNS解析主机)，则可以通过定义以下任务来刷新所有处理程序:/p>

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

无论被通知多少次，处理程序都只会被调用一次.想象一下，您有一个依赖于多个配置文件的服务(例如，bind/named:rev，zone，root.db，rndc.key，named.conf)，并且如果这些文件中的任何一个更改了，您都想重新启动named.使用处理程序，您只需从管理这些文件的每个任务中发出通知.否则，您需要注册5个无用的var，然后在重新启动任务中全部检查它们.

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.

我个人更喜欢处理程序.与处理register相比，它看上去干净得多.在Ansible 1.9.1之前，每个寄存器触发的任务都更安全.

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

这篇关于Ansible处理程序通知vs注册的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！