如果将所有的play都写在一个playbook中,很容易导致这个playbook文件变得臃肿庞大,且不易读。因此,可以将多个不同任务分别写在不同的playbook中,然后使用include将其包含进去即可。而role则是整合playbook的方式。无论是include还是role,其目的都是分割大playbook以及复用某些细化的play甚至是task。
roles说明
roles意为角色,主要用于封装playbook实现复用性。在ansible中,roles通过文件的组织结构来展现。
首先需要有一个roles目录。同时,在roles目录所在目录中,还要有一个playbook文件,此处为nginx.yml,nginx.yml文件是ansible-playbook需要执行的文件,在此文件中定义了角色,当执行到角色时,将会到roles中对应的角色目录中寻找相关文件。
roles目录中的子目录是即是各个role。例如,此处只有一个名为halo的role,在role目录中,有几个固定名称的目录(如果没有则忽略)。在这些目录中,还要有一些固定名称的文件,除了固定名称的文件,其他的文件可以随意命名。以下是各个目录的含义:
- tasks目录:存放task列表。若role要生效,此目录必须要有一个主task文件main.yml,在main.yml中可以使用include包含同目录(即tasks)中的其他文件。
- handlers目录:存放handlers的目录,若要生效,则文件必须名为main.yml文件。
- files目录:在task中执行copy或script模块时,如果使用的是相对路径,则会到此目录中寻找对应的文件。
- templates目录:在task中执行template模块时,如果使用的是相对路径,则会到此目录中寻找对应的模块文件。
- vars目录:定义专属于该role的变量,如果要有var文件,则必须为main.yml文件。
- defaults目录:定义角色默认变量,角色默认变量的优先级最低,会被任意其他层次的同名变量覆盖。如果要有var文件,则必须为main.yml文件。
- meta目录:用于定义角色依赖,如果要有角色依赖关系,则文件必须为main.yml。
所以,相对完整的role的文件组织结构如下图。
1 | ├── roles |
实例
使用role的方式来安装halo,相对来说,结构会比较清晰明了。还是使用ansible去自动部署halo博客系统。功能很简单,就是在一台机器上面自动部署java+halo+nginx服务。目录如下:
1 | ├── roles |
主要分为3个role,由site.yml引入,内容如下:
1 | # cat site.yml |
pre_tasks
为运行play之前的操作,post_tasks
为运行完play之后的操作。主要是看nginx这个role的内容:
1 | [root@localhost nginx]# cat tasks/main.yml |
meta/main.yml
为role的依赖关系,要先运行这里面的内容才会运行自己的nginx这个role。
java这个role很简单,只需要安装jdk即可。
1 | [root@localhost java]# cat tasks/main.yml |
而halo的内容如下:
1 | [root@localhost halo]# cat tasks/main.yml |
运行结果如下:
1 | [root@localhost halo]# ansible-playbook site.yml |
附ansible halo压缩包的下载地址:halo.tar.gz