聊聊Ansible Playbook中的Handler
Ansible是一个系列文章，我会尽量以通俗易懂、诙谐幽默的总结方式给大家呈现这些枯燥的知识点，让学习变的有趣一些。
Ansible系列博文直达链接：Ansible入门系列
前言
在之前的这篇《初窥Ansible playbook》文章中，有说到这个handler，细心的朋友可能就对这个handler很好奇，这到底是个什么东西呢？在Ansible中，我们又是如何使用这个handler呢？在使用的过程中又有哪些事项需要特别注意的呢？这篇文章我就来对这个handler进行详细的总结，让大家在日后的工作中能够明明白白、放放心心的使用handler。
什么是handler
通过这么多年的编程经验，我们知道基本上每个主流的编程框架、语言都有Event机制，Ansible作为自动化运维界最亮的仔，它也不例外，这里要说的handler就是Playbook中的Event。将handler概念映射成Event，这样大家应该就能恍然大悟了。但是在Ansible中，它的handler还有一些特别的地方。
在Playbook中Handlers里面的每一个handler都是对模块的一次调用。而handler与任务不同，任务会默认的按照我们定义的顺序执行，handler则不一样，它需要在任务中被明确调用，才有可能被调用。注意这里的有可能，也就是说也有可能你明确调用了，但是handler也不一定能够被触发调用，这又是为什么呢？且听我慢慢说来！
前面有说到过，任务表中的任务都是有状态的，也就是任务执行后的结果：changed或者ok。在Ansible中，只有在任务的执行状态为changed时，才会执行该任务调用的handler。这也是handler与普通的Event机制不同的地方。
handler应用场景
一个东西存在就必定有它存在的场景，那我们在什么情况下使用handler呢？下面我就来说一个特别现实的场景。
在我们的生产环境中是通过Nginx来做负载均衡的，有的时候我们修改了Nginx的配置文件，然后就需要从Ansible管理主机分发到被管理的Nginx主机上，拷贝成功后，要执行nginx -s reload命令。在这个操作中有一个前提是必须要配置文件拷贝成功后才能执行nginx -s reload命令。像这样的应用场景，重启Nginx就可以设计成一个handler。
一个handler最多只执行一次，并且在所有的任务都执行完成之后再执行；如果有多个任务调用同一个handler，那么也只执行一次，这个也是同普通的Event机制的一个不同点。下面通过一个简单的例子来进行说明：
---
- hosts: server1
tasks:
- name: CopyFile1
copy:
src: /home/jelly/file1.log
dest: /home/test1/file1.log
notify:
- handler1
- name: CopyFile2
copy:
src: /home/jelly/file2.log
dest: /home/test1/file2.log
notify:
- handler1
handlers:
- name: handler1
debug: msg="Call handler1"
一开始，在被管理主机上是没有文件的，我们执行上面的YAML脚本，会输出以下日志内容：
[jelly@localhost yaml]$ ansible-playbook handlerDemo1.yaml
PLAY [server1] ***************************************
TASK [Gathering Facts] *******************************
ok: [192.168.1.3]
TASK [CopyFile1] *************************************
changed: [192.168.1.3]
TASK [CopyFile2] *************************************
changed: [192.168.1.3]
RUNNING HANDLER [handler1] ***************************
ok: [192.168.1.3] => {
"msg": "Call handler1"
}
PLAY RECAP *******************************************
192.168.1.3 : ok=4 changed=2 unreachable=0 failed=0
可以看到，handler1只被执行了一次。第一次执行后，文件已经被分发过去了，当我们再次执行这个YAML脚本时，changed状态应该为0，此时handler1就不会被执行。输出日志就是这个样子：
[jelly@localhost yaml]$ ansible-playbook handlerDemo1.yaml
PLAY [server1] ***************************************
TASK [Gathering Facts] *******************************
ok: [192.168.1.3]
TASK [CopyFile1] *************************************
ok: [192.168.1.3]
TASK [CopyFile2] *************************************
ok: [192.168.1.3]
PLAY RECAP *******************************************
192.168.1.3 : ok=3 changed=0 unreachable=0 failed=0
handler执行顺序
除了上面说到的触发场景和执行次数需要我们特殊关注外，还有这里要说的执行顺序，handler的执行顺序也是一个“奇葩”点。
handler是按照定义的顺序执行的，而不是按照在任务中的调用顺序执行的。
上面的话有点绕口，下面我通过一个例子来说明。
---
- hosts: server1
tasks:
- name: CopyFile1
copy:
src: /home/jelly/file1.log
dest: /home/test1/file1.log
notify:
- handler3
- name: CopyFile2
copy:
src: /home/jelly/file2.log
dest: /home/test1/file2.log
notify:
- handler2
- name: CopyFile3
copy:
src: /home/jelly/file3.log
dest: /home/test1/file3.log
notify:
- handler1
handlers:
- name: handler1
debug: msg="Call handler1"
- name: handler2
debug: msg="Call handler2"
- name: handler3
debug: msg="Call handler3"
从上面的YAML脚本可以看到，我们调用handler的顺序是3->2->1，而在handlers中定义的顺序是1->2->3，最终handler的执行顺序是1->2->3，同定义顺序保持一致的。执行输出日志如下：
[jelly@localhost yaml]$ ansible-playbook handlerDemo3.yaml
PLAY [server1] ***************************************
TASK [Gathering Facts] *******************************
ok: [192.168.1.3]
TASK [CopyFile1] *************************************
changed: [192.168.1.3]
TASK [CopyFile2] *************************************
changed: [192.168.1.3]
TASK [CopyFile3] *************************************
changed: [192.168.1.3]
RUNNING HANDLER [handler1] ***************************
ok: [192.168.1.3] => {
"msg": "Call handler1"
}
RUNNING HANDLER [handler2] ***************************
ok: [192.168.1.3] => {
"msg": "Call handler2"
}
RUNNING HANDLER [handler3] ***************************
ok: [192.168.1.3] => {
"msg": "Call handler3"
}
PLAY RECAP *******************************************
192.168.1.3 : ok=7 changed=3 unreachable=0 failed=0
触发场景、执行次数和执行顺序这三个“奇葩”点，大家可得牢牢记住喽！！！
总结
断断续续把这个知识点总结完了，关于Ansible handler这个知识点，别看它看起来很简单，就那么点东西，但是在实际的工作中作用却是非常大的，以后大家在读别人的YAML脚本的时候，就能看到更多handler的应用场景了。还是那句话，小工具，大作为！
果冻想，认真玩技术的地方。
2019年10月6日，于内蒙古呼和浩特。
