Ansible之路——第九章：Ansible Playbook

 

Playbooks 是Ansible 管理配置、部署应用和编排的语言，可以使用Playbooks 来描述你想在远程主机执行的策略或者执行的一组步骤过程等。

如果说Ansible 模块是工作中的工具的话，那么playbooks 就是方案。

Playbooks 采用YAML 语法结构。

 

9.1 Playbooks 组成

• Target section：定义将要执行playbook 的远程主机组
• Variable section：定义playbook 运行时需要使用的变量
• Task section：定义将要在远程主机上执行的任务列表
• Handler section：定义task 执行完成以后需要调用的任务

9.1.1主机和用户

在playbook 中的每一个play 都可以选择在哪些机器和以什么用户身份完成，hosts 一行可以是一个主机组或者主机也可以是多个，中间以冒号分隔,可以参考前面讲的通配模式；

remote_user表示执行的用户账号，表示以什么用户来登录远程机器并执行任务。

---
  -hosts: webservers
    remote_user: root

 

9.1.2每一个任务都可以定义一个用户

---
  - hosts: webservers
    remote_user: root
    tasks:
      - name: test connection
        ping:
        remote_user: yourname

　

9.1.3在play 中支持sudo

---
  - hosts: webservers
    remote_user: yourname
    sudo: yes

　　

9.1.4在一个任务中支持sudo

---
  - hosts: webservers
    remote_user: yourname
    tasks:
      - service: name=nginx state=started
        sudo: yes

 

9.1.5 登陆后sudo 到其他用户执行

---
  - hosts: webservers
    remote_user: yourname
    sudo: yes
    sudo_user: postgres

 

9.2 任务列表

每个任务建议定义一个可读性较强的名字即name，在执行playbook 时会输出，tasks 的声明格式，建议使用”module:options”的格式。

下面以service 模块为例来定义一个任务，service: key=value 参数，请参看模块的详细介绍

tasks:
  - name: make sure apache is running
    service: name=httpd state=running

 

command 和shell 模块关注命令或者脚本执行后返回值，如果命令成功执行返回值不是0 的情况下，可以使用以下方法

tasks:
  - name: run this command and ignore the result
    shell: /usr/bin/somecommand || /bin/true

或者

tasks:
  - name: run this command and ignore the result
    shell: /usr/bin/somecommand
    ignore_errors: True

注：ignore_errors这里的值只要小写后为true或者yes就可以，所以即使是TRue这种也是正确的。

 

如果在任务中参数过长可以回车使用空格缩进：

---
  - hosts: server
    tasks:
      - name: Copy ansible inventory file to client
        copy: src=/etc/ansible/hosts dest=/tmp/hosts
              owner=root group=root mode=0644

 

9.3 变量的使用

1)      如何创建一个有效的变量名

变量名应该由字母、数组和下划线组成，以字母开头

2)      在inventory 中定义变量

3)      在playbook 中定义变量

4)      在角色和文件中包含变量

5)      如何使用变量：Jinja2

Jinja2 是一个被广泛使用的全功能的Python 模板引擎，它有完整的unicode 支持

注释：Ansible 允许在模板中使用循环和条件判断，但是在playbook 只使用纯粹的YAML 语法

6)      Jinja2 过滤器

变量可以通过过滤器修改。过滤器与变量用管道符号（ | ）分割，并且也可以用圆括号传递可选参数。多个过滤器可以链式调用，前一个过滤器的输出会被作为后一个过滤器的输入。

如{{ list | join(', ') }}，会把一个列表用逗号连接起来。

下面列举一些在Ansible 使用较多的Filters：

• 格式化数据：

{{ ansible_devices | join('| ') }}

• 过滤器和条件一起使用：

 

9.4 register

register 关键字的作用是将命令执行的结果保存为变量，结果会因为模块不同而不同，在运行ansible-playbook 时增加-v 参数可以看到results 可能的值；注册变量就如同通过setup 模块获取facts 一样。

 

执行结果：

 

9.5 过滤器

场景1：将获取到的变量的值的所有字母都变成大写。如：

 

 

 

如上例所示，testvar变量的值中包含3个小写字母，在使用debug模块输出这个变量的时候，我们使用了一个管道符，将testvar变量传给了一个名为“upper”的东西，“upper”就是一个过滤器，执行playbook的时候将变量中的小写字母变成了大写。

过滤器是一种能够帮助我们处理数据的工具。其实，ansible中的过滤器功能来自于jinja2模板引擎，我们可以借助jinja2的过滤器功能在ansible中对数据进行各种处理。

当我们想要通过过滤器处理数据的时候，只需要将数据通过管道符传递给对应的过滤器即可。过滤器有很多，有些是jinja2内置的，有些是ansible特有的。除此之外，jinja2还支持自定义过滤器。

 

跟字符串操作相关的过滤器，示例：

  

跟数字操作相关的过滤器，示例：

 

跟列表操作相关的过滤器，示例：

 

变量未定义相关操作的过滤器，示例：

 

上述的default过滤器，不仅能在变量未定义的时候返回指定的值，还能够让模块的参数变得“可有可无”。

 

关于“可有可无”，通过以下示例来说明其含义。

场景2，创建几个文件，只有个别文件需要指定权限，可以定义如下：

 

这里只有第一个文件需要指定权限，其余的都是使用系统默认的权限进行创建。在实际工作中，可能需要创建几十个这样的文件，有些需要指定权限，有些不需要，因此一般都会使用条件判断和循环语句来完成，如下：

 

这样的playbook确实可以很好的解决问题，但是一共循环了两遍，因为需要对文件的是否有mode属性进行判断，并根据判断结果调整参数设定。

更好的方法有：

这里并没有对文件是否有mode权限进行判断，而是直接调用了file模块的mode参数，将mode的值设置为了{{item.mode | default(omit)}}。这样表示的含义就是如果item有mode属性，就把file模块的mode参数设置为item的mode属性值，如果item没有mode属性，file模块就省略mode参数。‘omit’的字面意思就是省略，也就是“可有可无”。

 

9.6 pre_tasks and post_tasks

• pre_tasks: 设置playbook运行之前的tasks，一般用于准备条件或者变量自定义。
• post_tasks: 设置playbook运行之后的tasks

Playbook中各种task的执行顺序： 

pre_task  >  role  >  tasks  >  post_task

 

如果考虑到handler，则执行顺序为：

pre_task  >  pre_handler  >  role task  >  task  >  role handler  >  task handler  >  post task  >  post handler

 

如果你想立即执行所有的 handler 命令，在1.2及以后的版本，你可以这样做：

 

9.7 notify 与 handler

notify指定handler的执行机制：“notify”这个action可用于在每个play的最后被触发，在notify中列出的操作称为handler，仅在所有的变化发生完成后一次性地执行指定操作。在notify中列出的操作称为handle，也即notify中调用handler中定义的操作。

handler：用于当关注的资源发生变化时采取一定的操作。handler是task列表，这些task与前述的task并没有本质上的不同。

另外，handlers 会按照声明（notify）的顺序执行。

例如：修改ironic配置文件后需要重启相应的ironic服务。

 

9.8 tags

tags：对任务进行“打标签”操作。当任务存在标签后，我们就可以在执行playbook的时候，借助标签，指定执行哪些任务，或者不执行哪些任务。

例如：

 

9.8.1 查看所有tag

ansible-playbook <playbook_yaml> --list-tags

 

9.8.2 指定tag执行任务：

可以指定某个tag：

ansible-playbook test.yml -t/--tags "tag1"

可以指定多个tag（以逗号分隔，可以加空格）：

ansible-playbook test.yml -t "tag1, tag2”

 

9.8.3 指定tag跳过任务

可以使用--skip-tags来跳过某些tag：

可以指定某个tag：

ansible-playbook test.yml --skip-tags "tag1"

可以指定多个tag（以逗号分隔，可以加空格）：

ansible-playbook test.yml --skip-tags "tag1, tag2”

 

9.9 条件判断：when

when相当于shell脚本里的if 判断，when语句就是用来实现这个功能的，它是一个jinja2的语法，但是不需要双大括号，用法很简单。

 

 

 

运算比较符有：==、!=、>、<、>=、<=、and、or、not、()、in等

 

9.9.1 判断目录或文件是否存在：exists

 

#exists关键字，注意检查的是ansible主机。is not exists表示不存在，也可以用not testpath is exists

 

9.9.2 判断变量

• defined:判断变量是否已经定义，已经定义则为真
• undefined:判断变量是否已经定义，未定义则返回真
• none:判断变量是否已经定义，如果变量值已经定义，但是变量值为空，则返回真

 

9.9.3 判断执行结果

• success或succeeded: 通过任务的返回信息判断任务的执行状态，任务执行成功则返回真
• failure或failed: 通过任务的返回信息判断任务的执行状态，任务执行失败则返回真
• change或changed: 通过任务的返回信息判断任务的执行状态，任务执行状态为changed则返回真
• skip或skipped: 通过任务的返回信息判断任务的执行状态，当任务没有满足条件，而被跳过执行时，则返回真

 

9.9.4 判断路径

• file: 判断路径是否是一个文件，如果路径是一个文件则为真。
• directory: 判断路径是否是一个目录，如果路径是一个目录则为真
• link: 判断路径是否是一个软连接，如果路径是一个软连接则为真
• mount: 判断路径是否是一个挂载点，如果路径是一个挂载点则为真
• exists: 判断路径是否存在，如果路径存在则为真

注意：某些版本之前可能需要加上“is_”前缀

 

9.9.5 判断整除

• even: 判断数值是否是偶数，偶数则为真
• odd: 判断数值是否是奇数，奇数则为真
• divisibleby(num): 判断是否可以整除指定的数值，如果除以指定的值以后余数为0，则返回真

 

9.5.6 版本号比较

 version: 可以用于对比两个版本号的大小，或者与指定的版本号进行对比，语法version（'版本号'，'比较操作符'）。2.5版本此test从version_compare 更名为version。

 

9.5.7 列表比较

• subset: 判断一个list是不是另一个list的子集，是则为真
• siperset: 判断一个list是不是另一个list的父集，是则为真

注：2.5版本之前是issubset和issuperset

 

9.5.8 字符串与数字判断

• string: 判断对象是否是一个字符串，是则为真
• number: 判断对象是否是一个数字，是则为真

 

9.5.9 failed_when 

先看个例子：

 

有些时候，我们需要通过返回的字符串来判断是否failed。例如：

 

也就是说，我们只有在返回结果中出现字符串‘FAILED’,我们才认为我们的task 失败了（因为command 命令即使执行成功，返回值才是我们要判断失败与否的关键）。

 

9.5.10 changed_when

与failed_when类似。示例：

 

在使用command /shell 模块的时候ansible playbook 会按照自己的判断来决定是否changed了。

有时候我们仅仅是ls 了一下， ansible-playbook 也会认为是changed了，可能这并不是我们想要的，这个时候我们就要用例子中方法来修改task的状态了：

 

9.10 循环

9.10.1 标准循环

为了保持简洁，重复的任务可以用以下简写的方式：

 

如果你在变量文件中或者 ‘vars’ 区域定义了一组YAML列表，你也可以这样做：

with_items: "{{somelist}}"

 

以上写法与下面是完全等同的：

 

使用 ‘with_items’ 用于迭代的条目类型不仅仅支持简单的字符串列表。如果你有一个哈希列表，那么你可以用以下方式来引用子项：

 

注：如果同时使用 when 和 with items （或其它循环声明）, when声明会为每个条目单独执行。

 

9.10.2嵌套循环

循环也可以嵌套：

 

执行一下：

 

和以上介绍的with items一样，你也可以使用预定义变量：

 

9.10.3 对哈希表使用循环

哈希表：用于存储Key-Value键值对的集合。

使用with_dict 来循环哈希表中的元素：

 

9.10.4 对文件列表使用循环

with_fileglob 可以以非递归的方式来模式匹配单个目录中的文件

 

注：当在role中对 with_fileglob 使用相对路径时, Ansible会把路径映射到`roles/<rolename>/files`目录。

 

9.10.5 对并行数据集使用循环（不常见）

假设你通过某种方式加载了以下变量数据：

---
alpha: [ 'a', 'b', 'c', 'd' ]
numbers:  [ 1, 2, 3, 4 ]

如果你想得到’(a, 1)’和’(b, 2)’之类的集合.可以使用with_together：

 

不足的数据则为空：

 

注：这种使用方式不常见。

 

9.10.6 对子元素使用循环

假设你想对一组用户做一些动作，比如创建这些用户，并且允许它们使用一组SSH key来登录。

如何实现? 先假设你有按以下方式定义的数据，可以通过”vars_files”或”group_vars/all”文件加载：

 

那么可以这样实现：

 

根据mysql hosts以及预先给定的privs subkey列表，我们也可以在嵌套的subkey中迭代列表：

 

9.10.7 对整数序列使用循环

with_sequence 可以以升序数字顺序生成一组序列。你可以指定起始值、终止值，以及一个可选的步长值。

指定参数时也可以使用key=value这种键值对的方式。如果采用这种方式，format是一个可打印的字符串。

字值可以被指定为10进制，16进制(0x3f8)或者八进制(0600)。负数则不受支持。请看以下示例：

 

9.10.8 随机选择

random_choice功能可以用来随机获取一些值。它并不是负载均衡器(已经有相关的模块了)。它有时可以用作一个简化版的负载均衡器，比如作为条件判断：

 

提供的字符串中的其中一个会被随机选中。

 

9.10.9 Do-Until循环

有时你想重试一个任务直到达到某个条件。比如：

 

上面的例子递归运行shell模块，直到模块结果中的stdout输出中包含”all systems go”字符串，或者该任务按照10秒的延迟重试超过5次。retries和delay的默认值分别是3和5。

该任务返回最后一个任务返回的结果。单次重试的结果可以使用-vv选项来查看。被注册的变量会有一个新的属性attempts，值为该任务重试的次数。

 

9.10.10 查找第一个匹配的文件（不常见）

这其实不是一个循环,但和循环很相似，如果你想引用一个文件，而该文件是从一组文件中根据给定条件匹配出来的。这组文件中部分文件名由变量拼接而成。

针对该场景你可以这样做：

 

该功能还有一个更完整的版本，可以配置搜索路径.请看以下示例：

 

9.10.11 迭代程序的执行结果（不常见）

有时你想执行一个程序，而且按行循环该程序的输出。Ansible提供了一个优雅的方式来实现这一点。但请记住，该功能始终在本地机器上执行，而不是远程机器。

例如，find一堆文件出来，copy走。

 

如果你想远程执行命令，那么以上方法则不行。但你可以这样写：

 

9.10.12 使用索引循环列表（不常见）

如果你想循环一个列表，同时得到一个数字索引来标明你当前处于列表什么位置，那么你可以这样做：

 

9.10.13 循环配置文件（不常见）

ini插件可以使用正则表达式来获取一组键值对。因此，我们可以遍历该集合。以下是我们使用的ini文件：

  

以下是使用 with_ini 的例子：

 

以下是返回的值：

 

9.10.14 扁平化列表（不常见）

在罕见的情况下，你可能有几组列表，列表中会嵌套列表。而你只是想迭代所有列表中的每个元素，比如有一个非常疯狂的假定的数据结构：

 

你可以看到列表中的包到处都是。那么如果想安装两个列表中的所有包呢？

 

9.10.15 循环中使用注册器

当对处于循环中的某个数据结构使用 register 来注册变量时，结果包含一个 results 属性，这是从模块中得到的所有响应的一个列表。

以下是在 with_items 中使用 register 的示例：

 

返回的数据结构如下，与非循环结构中使用 register 的返回结果是不同的，非循环结构的返回结果类似下面：

 

而循环结构的返回结果如：

 

随后的任务可以用以下方式来循环注册变量，用来检查结果值：

 

9.11 包含

在编程的时候，我们一般都会将重复性的代码提取出来，作为一个逻辑单元，这个逻辑单元通常被称为“函数”或者“方法”。如果需要修改这段逻辑，只需要修改函数本身即可。而且这样还使得程序的可读性更强。

Ansible中也有类似的功能，这种功能被称为包含，通过包含，我们可以在一个playbook中包含另一个文件，以便实现我们想要的效果。

Ansible有两种包含的操作模式：动态和静态。Ansible 2.4引入了include和import的概念。

• 如果您使用import*包含Task（import_playbook，import_tasks等），它将是静态的。
• 如果您使用include*包含Task（include_tasks，include_role等），它将是动态的。

使用include包含Task（用于task文件和Playbook级包括）仍然可用，但现在被认为已被弃用，建议使用 include_tasks和 import_tasks。

 

9.11.1 include_tasks和import_tasks之间的差异

区别一：

• include_tasks：是动态的，在运行时展开。即在执行play之前才会加载自己变量。when只应用一次， 被include的文件名可以使用变量。
• import_tasks：是静态的，在加载时展开。即在playbooks解析阶段将父task变量和子task变量全部读取并加载。因为是加载时展开的，文件名的变量不能是动态设定的。 when在被import的文件里的每个task，都会重新检查一次。

例：

b.yml

 

y.yml:

 

运行：

 

因为 mode被改变之后, include_tasks不会重新evaluate mode, import_tasks会根据变化后的mode值重新evaluate每个task的条件。

 

区别二：

• include_tasks方法调用的文件名称可以加变量
• import_tasks方法调用的文件名称不可以有变量

对于include_tasks，导入文件时可以指定变量：

 

当使用import_tasks方法时，执行报错。ansible也给出了错误原因，当使用static include时，是不能使用变量的：

 

9.11.2 include_tasks和import_tasks的优缺点

使用include*语句的主要优点是循环。当循环与include*一起使用时，包含的任务或角色将为循环中的每个项目执行一次。

与import*语句相比，使用include*有一些限制：

• 仅存在于动态包含内的标签不会显示在-list-tags输出中。
• 仅存在于动态包含内的任务不会显示在-list-tasks输出中。
• 您不能使用notify来触发来自动态包含内部的处理程序名称。
• 您不能使用--start-at-task开始执行动态包含内的任务。

与include*相比，使用import*也可能有一些限制：

• 如上所述，循环不能用于导入。
• 当使用目标文件或角色名称的变量时，不能使用来自库存源（主机/组变量等）的变量。

总而言之，没有使用with的包含，就使用import，使用了with，那就用include。

 

9.11.3 import_playbook

如果想引入整个playbook，则需要使用include_playbook模块来代替include。在ansible2.8版本之后，include功能就被删除掉了。

要求：

• 包含一个带有要执行的play列表的文件。
• 带有play列表的文件必须被包含在顶层
• 不能在play中执行该操作。

例如：

main.yml

 

otherplays.yaml

 

otherplays.yaml中导入stuff.yaml，由于不是在顶层导入，而是在play中导入，所以执行会失败。

 

9.11.4 include_vars

include_vars模块可以包含JSON或YAML文件中的定义变量，覆盖已定义的主机变量和playbook变量。如：

 

9.11.5 include_role 与 import_role

后续再讲。

 

9.12 Roles

上述已经讲过tasks和handlers，那么如何组织playbook才是最好的方式呢？

roles！

 

roles是基于一个已知的文件结构，去自动加载某些vars_file，tasks以及handlers。基于roles对内容进行分组，使得我们可以容易地与其他用户分享roles。

一个项目的结构如下:

 

一个 playbook 如下：

 

这个 playbook 为一个角色x指定了如下的行为：

• 如果 roles/x/tasks/main.yml 存在, 其中列出的 tasks 将被添加到 play 中
• 如果 roles/x/handlers/main.yml 存在, 其中列出的 handlers 将被添加到 play 中
• 如果 roles/x/vars/main.yml 存在, 其中列出的 variables 将被添加到 play 中
• 如果 roles/x/meta/main.yml 存在, 其中列出的 “角色依赖” 将被添加到 roles 列表中 (1.3 and later)
• 所有 copy tasks 可以引用 roles/x/files/ 中的文件，不需要指明文件的路径。
• 所有 script tasks 可以引用 roles/x/files/ 中的脚本，不需要指明文件的路径。
• 所有 template tasks 可以引用 roles/x/templates/ 中的文件，不需要指明文件的路径。
• 所有 include tasks 可以引用 roles/x/tasks/ 中的文件，不需要指明文件的路径。

 

如果 roles 目录下有文件不存在，这些文件将被忽略。比如 roles 目录下面缺少了 vars/ 目录，这也没关系。

如果你在 playbook 中同时使用 roles 和 tasks，vars_files 或者 handlers，roles 将优先执行。如果想在roles前执行一些task，可以这样：

 

而且，如果你愿意，也可以使用参数化的 roles，这种方式通过添加变量来实现，比如：

 

当一些事情不需要频繁去做时，你也可以为 roles 设置触发条件，像这样：

 

它的工作方式是：将条件子句应用到 role 中的每一个 task 上。

 

最后，你可能希望给 roles 分配指定的 tags。比如：

 

9.12.1 roles各目录含义

• 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文件中。与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目录：角色可能会用到的一些其他文件可以放置在此目录中。

注：上述目录并不全是必须的，如果你的角色中没有用到对应这些目录的模块，那么对应的目录就不需要包含。一般情况下，至少要有一个tasks目录。

 

9.12.2 角色默认变量

角色默认变量允许你为 included roles 或者 dependent roles 设置默认变量。要创建默认变量，只需在 roles 目录下添加 defaults/main.yml 文件。这些变量在所有可用变量中拥有最低优先级，可能被其他地方定义的变量(包括 inventory 中的变量)所覆盖。

 

9.12.3 role查找

我们可以把单个role的目录写在与入口playbook同级的目录下，也可以放在同级的roles目录下，还可以通过/etc/ansible/ansible.cfg中的roles_path（默认为家目录的.ansible/roles目录）指定。

role查找优先级：同级roles目录 > /etc/ansible/ansible.cfg中的roles_path（默认为家目录的.ansible/roles目录） > 同级目录下

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

 

这种写法其实不算正规，标准语法应该这样：

 

在roles关键字中使用role关键字指定角色对应的绝对路径，可以直接调用角色。即使不使用绝对路径，也可以使用同样的语法指定角色名。如：

 

9.12.4 role变量传递

我们可以在调用role的时候传递对应的变量。如：

 

默认变量也可以定义在defaults/main.yml中，不过优先级是最低的。role使用的变量的优先级为：vars/main.yml > 调用role时传递的vars > defaults/main.yml。

还可以写成：

 

另外，角色中的变量是全局可访问的。例如：

 

在调用webserver这个角色时传递的变量testvar的值，是可以传递给web这个角色的。在两个角色里面对这个变量进行debug，都可以得到这个值：

 

也可以为role设置触发条件，如：

 

最后，还可以给role分配指定的tags。如：

 

9.12.5 重复调用

默认情况下，我们无法多次调用同一个角色。也就是说，如下的playbook只会调用一次webserver角色：

 

执行该playbook，可以发现，webserver中的debug模块只输出了一次：

 

如果想要多次调用同一个角色，有两种方法。如下：

• 方法一：设置角色的allow_duplicates属性，让其支持重复调用
• 方法二：调用角色时，传入的参数值不同

方法一需要为角色设置allow_duplicates属性，该属性需要设置在meta/main.yml中，如：

 

方法二，当调用角色时需要传入参数，如果传入参数的值不同，也可以连续调用多次。如：

 

9.12.6 role handler

如果想在角色中使用一些handlers以便进行触发，则可以直接将对应的handlers任务写入到handlers/main.yml文件中，示例：

 

9.12.7 角色依赖

角色依赖 使你可以自动地将其他 roles 拉取到现在使用的 role 中。角色依赖保存在 roles 目录下的 meta/main.yml 文件中。这个文件应包含一列 roles 和 为之指定的参数。

示例：

 

“角色依赖” 可以通过绝对路径指定，如同顶级角色的设置：

 

“角色依赖” 也可以通过源码控制仓库或者 tar 文件指定，使用逗号分隔：路径、一个可选的版本（tag, commit, branch 等等）、一个可选友好角色名（尝试从源码仓库名或者归档文件名中派生出角色名）：

 

“角色依赖” 总是在 role （包含”角色依赖”的role）之前执行，并且是递归地执行。默认情况下，作为 “角色依赖” 被添加的 role 只能被添加一次，如果另一个 role 将一个相同的角色列为 “角色依赖” 的对象，它不会被重复执行。但这种默认的行为可被修改，通过添加 allow_duplicates: yes 到 meta/main.yml 文件中。

比如，一个 role 名为 ‘car’，它可以添加名为 ‘wheel’ 的 role 到它的 “角色依赖” 中：

 

wheel 角色的 meta/main.yml 文件包含如下内容：

 

 

最终的执行顺序是这样的：

tire(n=1)

brake(n=1)

wheel(n=1)

tire(n=2)

brake(n=2)

wheel(n=2)

...

car

 

9.12.8 在 Roles 中嵌入模块

如果您编写一个定制模块，则可能希望将其作为角色的一部分进行分发。

在角色的tasks和handlers结构旁边，添加一个名为‘library’的目录，然后将定制模块直接包含在其中。

 

在一个role中定义的模块，可供其他role使用：

 

9.12.9 include_role与import_role

在后来版本（ansible>=2.4）中，ansible引入了 import_role（静态）和include_role（动态）方法。

---
# playbooks/test.yaml
- hosts: node1
  tasks:
    - include_role:
        name: role_A
      vars:
        name: maurice
        age: 100
    - import_role:
        name: role_B

 

比较于 roles 语句，import_role 和 include_role 的优点如下：

• 可以在task之间穿插导入某些role，这点是「roles」没有的特性。
• 更加灵活，可以使用「when」语句等判断是否导入。

关于include_role（动态）和import_role（静态）的区别，可以参考之前的include_tasks和import_tasks。

 

也正是因为 include_task 是动态导入，当我们给 include_role 导入的role打tag时，实际并不会执行该role的task。

举个例子，当我们使用include导入role_A，使用import导入role_B时：

---
# playbooks/test.yaml
- hosts: node1
  tasks:
    - include_role:
        name: role_A
      tags: maurice
    - import_role:
        name: role_B
      tags: maurice

 

role_A内容如下：

---
# tasks file for role_A

- debug:
    msg: "age"

- debug:
    msg: "maurice"

 

执行结果显示，role_A虽然被引用，但里面的task并没有执行：

  

（End）