利用角色简化playbook

一、描述角色（roles）的结构

1、利用角色构造ansible playbook

1.角色定义

• Ansible的roles提供了一种方法，让用户能以通用的方式更加轻松地重复利用Ansible代码。我们可以在标准化目录结构中打包所有任务、变量、文件、模板，以及调配基础架构或部署应用所需的其他资源。只需通过复制相关的目录，将角色从一个项目复制到另一个项目。然后，只需从一个play调用该角色就能执行它。
• 简单来说roles是指一段写好的通用的playbook代码
• 编写完毕后，可以从playbook中向角色传递调整其行为的变量，设置所有站点相关的主机名、IP地址、用户名，或其他在本地需要的具体详细信息。roles的作者也可以确保在选择不在play中设置变量值时，为这些变量设定合理的默认值。

2.ansible角色具有下列优点：

• 角色可以分组内容，从而与他人轻松共享代码
• 可以编写角色来定义系统类型的基本要素：web服务器、数据库服务器、Git存储库，或满足其他用途
• 角色使得较大型项目更容易管理
• 角色可以由不同的管理员并行开发

3.获取角色的方法

• 通过Ansible Galaxy网站获取由社区提供支持的许多角色。
• 安装rhel-system-roles软件包，这个安装包里面包含了一些系统默认自带的roles

[root@master ~]#  yum -y install rhel-system-roles
[root@master project]# ll /usr/share/doc/rhel-system-roles/
total 4
drwxr-xr-x. 2 root root   42 Aug  1 23:12 certificate
drwxr-xr-x. 3 root root   55 Aug  1 23:12 collection
drwxr-xr-x. 2 root root   42 Aug  1 23:12 crypto_policies
drwxr-xr-x. 2 root root   77 Aug  1 23:12 ha_cluster
drwxr-xr-x. 2 root root   42 Aug  1 23:12 kdump
drwxr-xr-x. 2 root root   42 Aug  1 23:12 kernel_settings
drwxr-xr-x. 2 root root   42 Aug  1 23:12 logging

每个角色的文档目录均包含一个README.md文件。README.md文件含有角色的说明，以及角色用法信息。

README.md文件也会说明影响角色行为的角色变量。通常，README.md文件中含有一个playbook代码片段，用于演示常见配置场景的变量设置。

部分角色文档目录中含有示例playbook。首次使用某一角色时，请查看文档目录中的任何额外示例playbook。

RHEL系统角色的角色文档与Linux系统角色的文档相匹配。使用Web浏览器来访问位于Ansible Galaxy网站上的角色文档。

4.查看系统中有哪些角色可以使用

[root@master roles]# ansible-galaxy list
# /usr/share/ansible/roles
- linux-system-roles.certificate, (unknown version)
- linux-system-roles.crypto_policies, (unknown version)
- linux-system-roles.ha_cluster, (unknown version)
- linux-system-roles.kdump, (unknown version)
- linux-system-roles.kernel_settings, (unknown version)
- linux-system-roles.logging, (unknown version)
- linux-system-roles.metrics, (unknown version)
……略

5.查看帮助

[root@master roles]# cat /usr/share/doc/rhel-system-roles/timesync/README.md
timesync
========
[![Travis Build Status](https://travis-ci.org/linux-system-roles/timesync.svg?branch=master)](https://travis-ci.org/linux-system-roles/timesync)
……略

2、检查ansible角色结构

Ansible角色由子目录和文件的标准化结构定义。顶级目录定义角色本身的名称。文件整理到子目录中，子目录按照各个文件在角色中的用途进行命名，如tasks和handlers。files和templates子目录中包含由其他YAML文件中的任务引用的文件。

[root@master roles~]# tree my_role/
my_role/		:具体的角色项目名称，比如 nginx、tomcat、php（自由设置）
├── defaults		:用于为当前角色设定默认变量，此目录应当包含一个 main.yml 文件
│   └── main.yml	:main.yml,类似代码中的主函数，进行统一管理
├── files		:用来存放由 copy 模块或 script 模块等模块调用的文件
├── handlers		:用于定义此角色中触发条件时执行的动作，此目录应当包含一个
main.yml 文件		
│   └── main.yml
├── meta		:用于定义此角色的特殊设定及其依赖关系，此目录应当包含一个
main.yml 文件
│   └── main.yml
├── README.md		:说明文件
├── tasks		:用于定义当前角色的任务列表，此目录应当包含一个 main.yml 文件
│   └── main.yml
├── templates		:用来存放 jinjia2 模板，template 模块会自动在此目录中寻找jinjia2 模板文件
├── tests		:用于存放测试 role 本身功能的 playbook 和主机定义文件，在开发测试阶段比较常用,此目录应当包含一个 main.yml 文件和自身资源设定 invetory
│   ├── inventory
│   └── test.yml
└── vars		:用于定义此角色用到的变量，此目录应当包含一个 main.yml 文件

注意：除tests子目录外，其他的所有子目录下的YAML文件必须以main命名。

Ansible角色子目录

子目录	功能
defaults	此目录中的main.yml文件包含角色变量的默认值，使用角色时可以覆盖这些默认值。 这些变量的优先级较低，应该在play中更改和自定义。
files	此目录包含由角色任务引用的静态文件。
handlers	此目录中的main.yml文件包含角色的处理程序。
meta	此目录中的main.yml文件包含与角色相关的信息，如作者、许可证、平台和可选的角色依赖项。
tasks	此目录中的main.yml文件包含角色的任务。
templates	此目录包含由角色任务引用的Jinja2模板。
tests	此目录可以包含清单和名为test.yml的playbook，可用于测试角色。
vars	此目录中的main.yml文件定义角色的变量值。这些变量通常用于角色内部用途。 这些变量的优先级较高，在playbook中使用时不应更改。

注：并非每个角色都有这些所有的目录

3、定义变量和默认值

• 角色变量通过roles目录中的var/main.yml文件来定义，这些变量具有较高的优先级，无法被清单变量覆盖，而且，这些变量只能在当前角色中生效。
• 角色的默认变量通过roles目录中的defaultes/main.yml文件来定义，默认变量的优先级最低。
• 在vars/main.yml或defaults/main.yml中定义具体的变量，但不要在两个文件中定义相同的变量。有意要覆盖变量的值时，应使用默认变量。

注意事项：

• 角色中不应该包含特定于站点的数据以及任何机密，如密码或私钥。这是因为角色应该是通用的，可以重复利用并自由共享。特定于站点的详细信息不应硬编码到角色中。
• 机密应当通过其他途径提供给角色。play中设置的角色变量可以提供机密，或指向含有该机密的Ansible Vault加密文件。

4、在playbook中使用角色

示例：

[root@master tasks]# cat test.yml 
---
- hosts: httpd
  roles:
    - role: role1
    - role: role2

• 对于每个指定的角色，角色任务、角色处理程序、角色变量和角色依赖项将按照顺序导入到playbook中。角色中的任何模块或include_tasks/import_tasks任务都可引用角色中相关的文件、模板或任务文件，且无需相对或绝对路径名称。Ansible将分别在角色的files、templates或tasks子目录中寻找它们。
• 如果使用roles部分将角色导入到play中，这些角色会在用户为该play定义的任何任务之前运行。

[root@master tasks]# cat test.yml jj.yml
---
- hosts: httpd
  roles:
    - role: role1
    - role: role2
      var1: xx
      var2: xxx
//如果这样写，则在执行role2时，任何defaults和vars变量都会被覆盖。

---
- hosts: httpd
  roles:
    - role: role1
    - { role: role2，var1: xx, var2: xxx }       
//这种写法和上面那种写法意义相同，但是这种写法会难以阅读

注意事项：

内嵌设置的角色变量（角色参数）具有非常高的优先级。它们将覆盖大多数其他变量。务必要谨慎，不要重复使用内嵌设置在play中任何其他位置的任何角色变量的名称，因为角色变量的值将覆盖清单变量和任何play中的vars。

5、控制执行顺序

• 在角色添加到play中后，角色任务将添加到任务列表的开头。如果play中包含第二个角色，其任务列表添加到第一个角色之后。
• 角色处理程序添加到play中的方式与角色任务添加到play中相同。每个play定义一个处理程序列表。角色处理程序先添加到处理程序列表，然后将play中的对应的handlers部分添加至任务列表。
• 在某些情形中，可能需要在角色之前执行一些play任务。若要支持这样的情形，可以为play配置pre_tasks部分。列在此部分中的所有任务将在执行任何角色之前执行。如果这些任务中有任何一个通知了处理程序，则这些处理程序任务也在角色或普通任务之前执行。play也支持post_tasks关键字。这些任务在play的普通任务和它们通知的任何处理程序运行之后执行。
• 一个play中通常不会同时包含所有这些部分。

[root@master project]# cat playbook/test.yml 
---
- hosts: httpd
  pre_tasks:
    - debug:
        msg: 'pre-task'
      notify: my handler

  roles:
    - timesync
  tasks:
    - debug:
        msg: 'first task'
      notify: my handler
  post_tasks:
    - debug:
        msg: 'post-task'
      notify: my handler
  handlers:
    - name: my handler
      debug:
        msg: Running my handler

在上例中，每个部分中都执行debug任务来通知my handler处理程序。my handler任务执行了三次：

• 在执行了所有pre_tasks任务后
• 在执行了所有角色任务和tasks部分中的任务后
• 在执行了所有post_tasks后

除了将角色包含在play的roles部分中外，也可以使用普通任务将角色添加到play中。使用include_role模块可以动态包含角色，使用import_role模块则可静态导入角色。

以下playbook演示了如何通过include_role模块来利用任务包含角色。

- name: Execute a role as a task
  hosts: httpd
  tasks:
    - name: A normal task
      debug:
        msg: 'first task'
    - name: A task to include role2 here
      include_role: role2

注意： include_role模块是在Ansible 2.3中新增的，而import_role模块则是在Ansible 2.4中新增的。

6、控制执行程序流程

二、利用系统角色重用内容

1、红帽企业Linux系统角色

• 自RHEL7.4开始，操作系统随附了多个Ansible角色，作为rhel-system-roles软件包的一部分。
• 系统角色的目的是在多个版本之间标准化红帽企业Linux子系统的配置。使用系统角色来配置版本6.10及以上的任何红帽企业Linux主机。

Redhat系统角色简介

名称	状态	角色描述
rhel-system-roles.kdump	全面支持	配置kdump崩溃恢复服务
rhel-system-roles.network	全面支持	配置网络接口
rhel-system-roles.selinux	全面支持	配置和管理SELinux自定义，包括SELinux模式、文件和端口上下文、布尔值设置以及SELinux用户
rhel-system-roles.timesync	全面支持	使用网络时间协议或精确时间协议配置时间同步
rhel-system-roles.postfix	技术预览	使用Postfix服务将每个主机配置为邮件传输代理
rhel-system-roles.firewall	开发中	配置主机的防火墙
rhel-system-roles.tuned	开发中	配置tuned服务，以调优系统性能

2、简化配置管理

• 举个例子：RadHat7的建议时间同步服务为chronyd服务。但在RadHat6中，建议的服务为ntpd服务。在混合了RHEL6和7主机的环境中，管理员必须管理这两个服务的配置文件。但是如果借助RHEL系统角色，管理员不再需要维护这两个服务的配置文件。管理员可以使用rhel-system-roles.timesync角色来配置RHEL6和7主机的时间同步。一个包含角色变量的简化YAML文件可以为这两种类型的主机定义时间同步配置。

3、安装RHEL系统角色

RHEL系统角色由rhel-system-roles软件包提供，该软件包可从AppStream流获取。在Ansible控制节点上安装该软件包。

安装RHEL系统角色

yum -y install rhel-system-roles

安装后，RHEL系统角色位于/usr/share/ansible/roles目录中：

ls -l /usr/share/ansible/roles/

红帽企业Linux中的默认roles_path在路径中包含/usr/share/ansible/roles，因此在playbook引用这些角色时Ansible可以很轻松的找到它们。

注意
如果在当前Ansible配置文件中覆盖了roles_path，设置了环境变量ANSIBLE_ROLES_PATH，或者roles_path中更早列出的目录下存在另一个同名的角色，则Ansible可能无法找到系统角色。

4、时间同步角色示例

假设需要在服务器上配置NTP时间同步。我们可以自行编写自动化来执行每一个必要的任务。但是，RHEL系统角色中有一个可以执行此操作角色，那就是rhel-system-roles.timesync。

该角色的详细记录位于**/usr/share/doc/rhel-system-roles/timesync目录下的README.md**中。此文件说明了影响角色行为的所有变量，还包含演示了不同时间同步配置的三个playbook代码片段。

为了手动配置NTP服务器，该角色具有一个名为timesync_ntp_servers的变量。此变量取一个要使用的NTP服务器的列表作为值。列表中的每一项均由一个或多个属性构成。两个关键属性如下：

timesync_ntp_servers属性

属性	用途
hostname	要与其同步的NTP服务器的主机名。
iburst	一个布尔值，用于启用或禁用快速初始同步。在角色中默认为no，但通常应该将属性设为yes.

根据这一信息，以下示例play使用rhel-system-roles.timesync角色将受管主机配置为利用快速初始同步从三个NTP服务器获取时间。此外，还添加了一个任务，以使用timezone模块将主机的时区设为UTC。

//查看受管主机的时间
[root@master project]# ansible all -a 'date'
192.168.129.133 | CHANGED | rc=0 >>
1999年 08月 09日 星期一 12:00:39 CST

[root@master playbook]# ls
base  roles  test.yml                  //建议单独创建一个目录用于存放角色
[root@master roles]# cp -a /usr/share/ansible/roles/rhel-system-roles.timesync/ timesync
[root@master roles]# ls
timesync

//编写playbook
[root@master project]# cat playbook/test.yml 
---
- hosts: httpd
  vars:
    timesync_ntp_servers:
       - hostname: time1.aliyun.com
         inburst: yes

    timezone: UTC
  roles:
    - timesync
//执行完毕后输出的结果
[root@master project]# ansible-playbook playbook/test.yml 

PLAY [httpd] *****************************************************************************************

TASK [Gathering Facts] *******************************************************************************
ok: [192.168.129.133]
……略

[root@master project]# ansible all -a 'date'
192.168.129.133 | CHANGED | rc=0 >>
2021年 08月 04日 星期三 18:08:37 CST

5、SELINUX角色示例

• 系统自带的rhel-system-roles.selinux角色可以简化SELinux配置设置的管理。它通过利用SELinux相关的Ansible模块来实施。
• 此角色可以执行的任务包括：
  • 设置enforcing或permissive模式
  • 对文件系统层次结构的各部分运行restorecon
  • 设置SELinux布尔值
  • 永久设置SELinux文件上下文
  • 设置SELinux用户映射

6、调用SELinux角色

• 有时候，SELinux角色必须确保重新引导（重启）受管主机，以便能够完整应用其更改。但是，它本身从不会重新引导主机。如此一来，用户便可以控制重新引导的处理方式。

• 该角色将一个布尔值变量selinux_reboot_required设为True，如果需要重新引导，则失败。你可以使用block/rescure结构来从失败中恢复，具体操作为：如果该变量未设为true，则让play失败，如果值是true，则重新引导受管主机并重新运行该角色。

[root@master project]# cat playbook/test.yml 
---
- hosts: all
  vars:
    selinux_policy: targeted
    selinux_state: disabled
  tasks:
    - name: apply selinux
      block:
        - include_role:
            name: roles/selinux
      rescue:
        - name: Check for failure for other reasons than required reboot
          fail:
          when: not selinux_reboot_required

        - name: reboot
          reboot:

        - include_role:
            name: roles/selinux

8、配置SELinux角色

[root@master project]# cat playbook/test.yml 
---
- hosts: httpd
  vars:
    selinux_policy: targeted
    selinux_state: disabled
  roles:
    - selinux

//执行playbook
[root@master project]# ansible-playbook playbook/test.yml 

PLAY [httpd] *****************************************************************************************

TASK [Gathering Facts] *******************************************************************************
ok: [192.168.129.133]

TASK [selinux : Install SELinux python2 tools] *******************************************************
skipping: [192.168.129.133]
……略