大家好，我是蓝胖子，前面一节我简单的讲了讲Ansible的架构和编排任务的语法，可以发现，通过playbook方式编排任务时，能够将任务文档化，但是在面对比较复杂且不同业务的任务编排时，维护playbook就变得复杂，所以Ansible产生了role模式针对复杂的任务进行编排工作。今天我们就通过一个实际的案例来看看如何使用role模式。
语法以及实际案例
平时我们在进行日志收集的时候，往往会在每台机器上安装filebeat，并且由于每台机器运行服务的不同，那么收集日志的配置文件也是不一样的，如何快速高效的部署filebeat以及拥有不同的配置文件就是我们要思考的问题，当然不可能一台机器一台机器的修改配置文件。
接下来我将会以一个我自己写的filebeat相关的role举例，来分析role模式涉及的一些规范以及如何写一个好的任务编排, 案例中的filebeat的role模式拥有对filebeat的安装，更新配置的功能。
role其实是对之前使用playbook的文件目录进行了一些规范(比如必须有roles目录且和playbook入口文件在同一位置，roles目录下的各个特定role的目录也是固定命名的)。
代码已经上传github
https://github.com/HobbyBear/ansible-role-filebeat.git
整个项目的目录结构如下所示，filebeatop.yml到时候是我们执行ansible playbook命令的入口文件，我们可以使用这样的命令使用这个role , ansible-playbook -i hosts filebeatop.yml ，其中hosts目录就是存放inventory主机清单。
.
├── ReadMe.md
├── filebeatop.yml
├── group_vars
│ └── test.yml
├── hosts
│ ├── prod
│ └── test
└── roles
└── filebeat
├── handlers
│ └── main.yml
├── tasks
│ ├── install.yml
│ ├── main.yml
│ ├── rpm.yml
│ └── updatecfg.yml
└── templates
├── debug.conf
├── filebeatbox.yml
└── log.yml
filebeatop.yml 的内容如下,其中roles配置项可以配置多个role，不过案例中就只配置了一个filebeat的role，这个role的名称就是上述roles目录下的filebeat这个文件夹的名称。同时filebeatop.yml同时设置了变量version和logstashendpoint，不同的是version变量是role级别的。
- hosts: test
roles:
- role: filebeat
version : '7.14.2'
vars:
logstashendpoint: 192.168.0.2:5054
接着了解下roles目录的结构,filebeat 就代表一个role，其下有handlers，tasks，templates目录，它们存放的内容如下，
roles
└── filebeat
├── handlers
│ └── main.yml
├── tasks
│ ├── install.yml
│ ├── main.yml
│ ├── rpm.yml
│ └── updatecfg.yml
└── templates
├── debug.conf
├── filebeatbox.yml
└── log.yml
- tasks 里面存放具体的Ansible 的各种模块定义的任务，其入口文件是main.yml 它里面可以通过include 引入其他task。就比如这个案例中,我在main.yml 引入了其他配置文件定义的任务。main.yml 代码如下, 可以看到在引入其他配置文件定义的任务时，我还用tags为任务打上了标签，这个标签可以让我们后续根据特定的标签执行任务。
- include: install.yml
tags:
- install
- include: rpm.yml
tags:
- rpm
- include: updatecfg.yml
tags:
- updatecfg
- handlers 目录下存放任务的后续处理逻辑，它其实也是ansible的模块定义的各种任务，与tasks不同的是，它是专门放到tasks执行后执行的。例如在handlers的main.yml文件中，我定义了一个名为restart Filebeat service 的handler，handlers/main.yml代码如下
become 设置为yes，become_method 设置为sudo 代表在运行这个service的命令时是要以sudo权限运行的。
- name: restart Filebeat service
become: yes
become_method: sudo
service:
name: filebeat
enabled: yes
state: restarted
这个handler在tasks/updatecfg.yml中有被用到，如下，在更新完filebeat服务配置后，通过notify配置，定义所需的handler的名称，便可以在特定task执行完成后运行对应的handler。
- name: 更新服务配置
shell: "sudo systemctl daemon-reload"
notify:
- restart Filebeat service
- templates 目录存放的是某些需要用到的配置文件模板，在模板文件中可以使用{{ 变量名 }} 引用，变量的定义可以在前面filebeatop.yml文件中vars，或者roles配置中定义，也可以放到与hosts目录同级的group_vars 目录中定义，Ansible 关于变量的定义方式有很多种，这里就不展开了。 拿案例中的group_vars举例，其目录下的文件名是inventory主机清单中的机器组的名称，比如我这里有个test的机器组，所以我在group_vars有个test.yml文件，内容如下,定义了两个变量 log_path和log_type。
log_path: "- /home/webserver/logs/box-api/box-api.log\r\n - /home/webserver/logs/box-bsk/box-bsk.log\r\n - /home/webserver/logs/box-flow/box-flow.log"
log_type:
box
这两个变量被 templates目录下的log.yml文件所引用。log.yml文件内容如下(是一个典型的filebeat设置日志采集路径的配置)
- type: log
tail_files: true
paths:
{{ log_path}}
fields:
log_type: {{ log_type }}
如何使用这些模板文件呢，其实就是通过ansible的template模块，拿filebeat role中的updatecfg.yml定义的任务片段举例，将filebeat 相关的配置文件上传到主机上对应的目录。
- name: 传送配置文件
become: yes
become_method: sudo
template: src=log.yml dest=/home/webserver/local/filebeat-{{ version }}-linux-x86_64/log.yml owner=root group=root
- name: 传送配置文件
become: yes
become_method: sudo
template: src=filebeatbox.yml dest=/home/webserver/local/filebeat-{{ version }}-linux-x86_64/filebeatbox.yml owner=root group=root