Linux Ansible自动化运维 roles(角色) 详解

一、角色的定义

角色（roles）是ansible自1.2版本开始引入的新特性，用于层次性，结构化地组织playbook。roles能够根据层次型结构自动装载变量文件、tasks以及handlers等。要使用roles只需要在playbook中使用include指令即可。简单的说，roles就是通过分别将变量、文件、任务、模块及处理器放置于单独的目录中、并可以便捷地include他们的一种机制。角色一般用于基于主机构建服务的场景中、但也可以是用于构建守护进程等场景中。

二、角色示例

为了让你更直观的认识角色的标准结构，我提前创建了一个示例角色，示例角色的目录结构如下：
在testredhat目录下文件的结构：

如你所见，我创建的示例角色的角色名为testredhat，testredhat目录就代表了这个角色，此目录中包含了defaults 、files 、handlers 、meta 、tasks 、templates 、vars等子目录，而且在defaults 、handlers 、meta 、tasks 、vars等目录中，还都有一个名为"main.yml"的文件，那么这样的目录结构代表了什么含义呢？我们一起来了解一下，在角色中，上述目录结构的作用如下：

注：此处先进行大致介绍，以便你有一个大概的印象，之后会有对应的示例，所以，如果有疑问请先保留。

目录	作用
tasks目录	角色需要执行的主任务文件放置在此目录中，默认的主任务文件名为main.yml，当调用角色时，默认会执行main.yml文件中的任务，你也可以将其他需要执行的任务文件通过include的方式包含在tasks/main.yml文件中。
handlers目录	当角色需要调用handlers时，默认会在此目录中的main.yml文件中查找对应的handler
defaults目录	角色会使用到的变量可以写入到此目录中的main.yml文件中，通常，defaults/main.yml文件中的变量都用于设置默认值，以便在你没有设置对应变量值时，变量有默认的值可以使用，定义在defaults/main.yml文件中的变量的优先级是最低的。
vars目录	角色会使用到的变量可以写入到此目录中的main.yml文件中，看到这里你肯定会有疑问，vars/main.yml文件和defaults/main.yml文件的区别在哪里呢？区别就是，defaults/main.yml文件中的变量的优先级是最低的，而vars/main.yml文件中的变量的优先级非常高，如果你只是想提供一个默认的配置，那么你可以把对应的变量定义在defaults/main.yml中，如果你想要确保别人在调用角色时，使用的值就是你指定的值，则可以将变量定义在vars/main.yml中，因为定义在vars/main.yml文件中的变量的优先级非常高，所以其值比较难以覆盖。
meta目录	如果你想要赋予这个角色一些元数据，则可以将元数据写入到meta/main.yml文件中，这些元数据用于描述角色的相关属性，比如 作者信息、角色主要作用等等，你也可以在meta/main.yml文件中定义这个角色依赖于哪些其他角色，或者改变角色的默认调用设定，在之后会有一些实际的示例，此处不用纠结。
templates目录	角色相关的模板文件可以放置在此目录中，当使用角色相关的模板时，如果没有指定路径，会默认从此目录中查找对应名称的模板文件。
files目录	角色可能会用到的一些其他文件可以放置在此目录中，比如，当你定义nginx角色时，需要配置https，那么相关的证书文件即可放置在此目录中。

当然，上述目录并不全是必须的，也就是说，如果你的角色并没有相关的模板文件，那么角色目录中并不用包含templates目录，同理，其他目录也一样，一般情况下，都至少会有一个tasks目录。

看完上述描述，你可能还是有一些小疑惑，不如我们来动手写一个简单的角色，这样就比较容易理解了。

注：当前用于测试的ansible版本为2.9.0，以下所有示例基于此版本进行。

为了熟悉角色的使用，我们一起来纯手动的编写一个用于测试的角色吧，这个角色的名字就叫"testredhat"。

首先，我们创建一个名为"testredhat"的目录，这个目录就代表了"testredhat"角色，执行如下命令即可：

# mkdir testredhat

 
 
 

 
 
 

  
1
 

角色目录创建完毕，我决定先赋予testredhat角色一个简单的功能，即输出"hello role"这句话，没错，通过debug模块可以输出信息，那么我们需要编写一个debug任务，之前提到过，调用角色时，角色会默认执行tasks/main.yml中的任务，那么我们就把debug任务写在tasks/main.yml文件中吧，首先，在testrole目录中创建tasks子目录，在tasks子目录中创建一个名为main.yml的文件。

# mkdir tasks
# touch tasks/main.yml

 
 
 

 
 
 

  
1
  
2
 

在tasks/main.yml文件中写入如下内容

- debug:
    msg: "hello role!"

 
 
 

 
 
 

  
1
  
2
 

如你所见，直接将我们需要执行的任务写在tasks/main.yml文件中即可。

我们并不需要创建handlers、defaults等目录，因为目前我们编写的角色非常简单，用不到这些目录结构。

我们的第一个测试角色编写完毕了~，就是这么简单，角色编写完毕后，就需要调用对应的角色了，那么怎样才能调用角色呢？其实也很简单，我们只需要在testredhat的同级目录中编写一个简单的剧本即可，此例中，调用角色的剧本文件名为test.yml，它与testredhat目录处于同级目录中，如下：

# ls
testredhat  test.yml

 
 
 

 
 
 

  
1
  
2
 

我们需要使用test.yml文件来调用testrole角色，test.yml文件的内容如下：

[root@server4 ~]# cat test.yml 
- hosts: testB
  roles:
  - testredhat

 
 
 

 
 
 

  
1
  
2
  
3
  
4
  
5
 

如上例所示，调用对应的角色时，需要使用roles关键字进行调用，使用"- hosts"指定目标主机，上例表示，在目标主机testB上执行testredhat角色对应的任务，但是由于testredhat并没有什么其他操作，只是输出了一句话，所以并不会对目标主机有什么实际动作。

那么我们执行test.yml，看看这个测试角色能不能正常被调用，执行后结果如下：

如我们所愿，角色被正常调用了，"hello role!"输出了，没错，我们已经学会使用角色了。

看到此处，你会不会觉得我把简单的问题复杂化了，如果你只是单纯的调用一个debug任务输出一句话，那么是有点复杂化了，但是如果你的配置过程慢慢变得丰富，文件越来越多，结构越来越复杂，那么使用角色会是更好的选择，它能让你的文件结构符合统一的标准，让任何一个懂得这个标准的人快速的阅读你的代码，并且为以后的扩展留出很大的空间，而且，通过刚才的调用过程，你应该已经明白了，我可以将testredhat目录移至到任何ansible主机中进行调用，testredhat目录中包含了这个角色所需的所有文件，它是一个独立的的结构，说到独立，它在逻辑上也是独立的，因为这个角色的配置过程与目标主机是分开的，虽然我们调用角色时，需要编写一个playbook指定对应的目标主机，但是我们并没有修改角色目录中的任何文件，这正好解决了本文开头提出的问题。

刚才在调用角色时，我刻意的将test.yml文件写在了testrole目录的同级目录中，也就是说，调用testrole角色时，test.yml会从同级目录中查找与testrole角色同名的目录，其实，不仅仅是同级目录，还有一些其他的目录，在调用角色时，test.yml也会去查找，这些目录就是：

• 同级目录中的roles目录中。
• 当前系统用户的家目录中的.ansible/roles目录，即 ~/.ansible/roles目录中。

也就是说，只要testrole目录处于上述三个目录中的任何一个目录中，都可以使用上述方法正常的调用。

你也可修改ansible的配置文件，设置自己的角色搜索目录，编辑/etc/ansible/ansible.cfg配置文件，设置roles_path选项，此项默认是注释掉的，将注释符去掉，当你想要设置多个路径时，多个路径之间用冒号隔开，示例如下

roles_path    = /etc/ansible/roles:/opt:/testdir

 
 
 

 
 
 

  
1
 

即使你的角色目录不处于上述目录中的任何一个，也可以使用绝对路径的方式，调用对应的角色，示例如下：