Ansible 处理程序通知与注册 [英] 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

对比

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 解析主机)，您可以通过定义如下任务来刷新所有处理程序:

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 个无用的变量，然后在你的重启任务中检查它们.

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 处理程序通知与注册的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！