Ansible 利用角色简化playbook

1. 描述角色结构

1.1 ansible角色

Ansible角色提供了一种方法，让用户能以通用的方式更加轻松地重复利用Ansible代码。我们可以在标准化目录结构中打包所有任务、变量、文件、模板，以及调配基础架构或部署应用所需的其他资源。只需通过复制相关的目录，将角色从一个项目复制到另一个项目。然后，只需从一个play调用该角色就能执行它。

借助编写良好的角色，可以从playbook中向角色传递调整其行为的变量，设置所有站点相关的主机名、IP地址、用户名，或其他在本地需要的具体详细信息。例如，部署数据库服务器的角色可能已编写为支持多个变量，这些变量用于设置主机名、数据库管理员用户和密码，以及需要为安装进行自定义的其他参数。角色的作者也可以确保在选择不在play中设置变量值时，为这些变量设定合理的默认值。

1.2 ansible角色优点

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

1.3 获取ansible角色

除了自行编写、使用、重用和共享角色外，还可以从其他来源获取角色。一些角色已包含在rhel-system-roles软件包中，用户也可以从Ansible Galaxy网站获取由社区提供支持的许多角色。

1.4 Ansible角色目录结构

site.yml
webservers.yml
fooservers.yml
roles/
    common/
        tasks/					    	
        handlers/						
        files/							
        templates/					
        vars/				       
        defaults/                     
        meta/                      

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中使用时不应更改。

httpd-role.yml 
roles/
└── httpd 
     ├── files
     │    └── main.yml 
     ├── tasks
     │    ├── groupadd.yml 
     │    ├── install.yml 
     │    ├── main.yml 
     │    ├── restart.yml 
     │    └── useradd.yml 
     └── vars 
          └── main.yml 

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

1.5 定义变量和默认值

角色变量通过在角色目录层次结构中创建含有键值对的vars/main.yml文件来定义。角色变量在yml文件中引用：{{ VAR_NAME }}，这些变量具有较高的优先级，无法被清单变量覆盖。这些变量旨在供角色的内部功能使用。

默认变量是为play设置默认变量，通过default/main.yml文件定义，优先级最低，这些变量能让角色准确自定义或控制，正确配置相应任务。

不能改变的使用默认变量，能变化的使用角色变量

注意：
角色不应该包含特定于站点的数据。它们绝对不应包含任何机密，如密码或私钥。这是因为角色应该是通用的，可以重复利用并自由共享。特定于站点的详细信息不应硬编码到角色中。

机密应当通过其他途径提供给角色。这是用户可能要在调用角色时设置角色变量的一个原因。play中设置的角色变量可以提供机密，或指向含有该机密的Ansible Vault加密文件。

1.6 在playbook中使用角色

---
- hosts: localhost
    roles: 
      - role1
      - role2

对于每个指定的角色，角色任务、角色处理程序、角色变量和角色依赖项将按照顺序导入到playbook中。角色中的任何copy、script、template或include_tasks/import_tasks任务都可引用角色中相关的文件、模板或任务文件，且无需相对或绝对路径名称。Ansible将分别在角色的files、templates或tasks子目录中寻找它们。

如果使用roles部分将角色导入到play中，这些角色会在用户为该play定义的任何任务之前运行。

---
-hosts: localhost
roles: 
  - role: role1
  - role: role2
    var1: val1
    var2: val2

注意：
内嵌设置的角色变量（角色参数）具有非常高的优先级。它们将覆盖大多数其他变量。

务必要谨慎，不要重复使用内嵌设置在play中任何其他位置的任何角色变量的名称，因为角色变量的值将覆盖清单变量和任何play中的vars。

1.7 控制执行顺序

对于playbook中的每个play，任务按照任务列表中的顺序来执行。执行完所有任务后，将执行任务通知的处理程序。

在角色添加到play中后，角色任务将添加到任务列表的开头。如果play中包含第二个角色，其任务列表添加到第一个角色之后。

角色处理程序添加到play中的方式与角色任务添加到play中相同。每个play定义一个处理程序列表。角色处理程序先添加到处理程序列表，后跟play的handlers部分中定义的任何处理程序。

在某些情形中，可能需要在角色之前执行一些play任务。若要支持这样的情形，可以为play配置pre_tasks部分。列在此部分中的所有任务将在执行任何角色之前执行。如果这些任务中有任何一个通知了处理程序，则这些处理程序任务也在角色或普通任务之前执行。

此外，play也支持post_tasks关键字。这些任务在play的普通任务和它们通知的任何处理程序运行之后执行。

以下play演示了一个带有pre_tasks、roles、tasks、post_tasks和handlers的示例。一个play中通常不会同时包含所有这些部分。

- name: Play to illustrate order of execution
  hosts: remote.example.com
  pre_tasks:
    - debug:
      msg: 'pre-task'
      notify: my handler
  roles:
    - role1
  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后

执行顺序：

2. 利用系统角色重用内容

2.1 红帽企业Linux系统角色

自RHEL7.4开始，操作系统随附了多个Ansible角色，作为rhel-system-roles软件包的一部分。在RHEL8中，该软件包可以从AppStream中获取。以下是每个角色的简要描述：

名称	状态	角色描述
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.2 简化配置管理

借助RHEL系统角色，管理员不再需要维护这两个服务的配置文件。管理员可以使用rhel-system-roles.timesync角色来配置RHEL6和7主机的时间同步。一个包含角色变量的简化YAML文件可以为这两种类型的主机定义时间同步配置。

2.3 安装RHEL系统角色

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

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

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

2.4 时间同步角色示例

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

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

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

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

//修改受管主机时间
[root@localhost ~]# date -s '2001-12-18 00:00:00'
Tue Dec 18 00:00:00 CST 2001

[root@ansible playbook]# cat test.yml 
---
- hosts: http
  vars: 
    timesync_ntp_servers: 
      - hostname: time1.aliyun.com
        inburst: yes
    timezone: CST
  roles: 
    - timesync

[root@ansible playbook]# ansible-playbook test.yml 

PLAY [http] ********************************************************************

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

TASK [timesync : Check if only NTP is needed] **********************************
ok: [192.168.172.142]
......

//受管主机时间同步完成
[root@localhost ~]# date
Thu Aug  5 05:55:06 CST 2021

2.5 SELINUX角色示例

rhel-system-roles.selinux角色可以简化SELinux配置设置的管理。它通过利用SELinux相关的Ansible模块来实施。与自行编写任务相比，使用此角色的优势是它能让用户摆脱编写这些任务的职责。取而代之，用户将为角色提供变量以对其进行配置，且角色中维护的代码将确保应用用户需要的SELinux配置。

此角色可以执行的任务包括：

• 设置enforcing或permissive模式
• 对文件系统层次结构的各部分运行restorecon
• 设置SELinux布尔值
• 永久设置SELinux文件上下文
• 设置SELinux用户映射

2.5.1 调用SELinux角色

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

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

[root@ansible playbook]# cat test.yml 
---
- hosts: http
  vars: 
    selinux_state: enforcing
  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: Restart managed host
          reboot: 

        - include_role: 
            name: roles/selinux

[root@ansible playbook]# ansible-playbook test.yml 

PLAY [http] ********************************************************************

TASK [Gathering Facts] *********************************************************
ok: [192.168.172.142]
......
PLAY RECAP *********************************************************************
192.168.172.142            : ok=13   changed=4    unreachable=0    failed=0    skipped=18   rescued=1    ignored=0   

3. 角色结构创建

3.1 目录结构

默认情况下，Ansible在Ansible Playbook所在目录的roles子目录中查找角色。这样，用户可以利用playbook和其他支持文件存储角色。

如果Ansible无法在该位置找到角色，它会按照顺序在Ansible配置设置roles_path所指定的目录中查找。此变量包含要搜索的目录的冒号分隔列表。此变量的默认值为：

~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles```

这允许用户将角色安装到由多个项目共享的系统上。例如，用户可能将自己的角色安装在自己的主目录下的~/.ansible/roles子目录中，而系统可能将所有用户的角色安装在/usr/share/ansible/roles目录中。

每个角色具有自己的目录，采用标准化的目录结构。例如，以下目录结构包含了定义motd角色的文件。

[root@localhost ~]# tree roles/
roles/
└── motd
    ├── defaults
    │   └── main.yml
    ├── files
    ├── handlers
    ├── meta
    │   └── main.yml
    ├── tasks
    │   └── main.yml
    └── templates
        └── motd.j2

README.md提供人类可读的基本角色描述、有关如何使用该角色的文档和示例，以及其发挥作用所需要满足的任何非Ansible要求。
meta子目录包含一个main.yml文件，该文件指定有关模块的作者、许可证、兼容性和依赖项的信息。
files子目录包含固定内容的文件，而templates子目录则包含使用时可由角色部署的模板。
其他子目录中可以包含main.yml文件，它们定义默认的变量值、处理程序、任务、角色元数据或变量，具体取决于所处的子目录。

如果某一子目录存在但为空，如本例中的handlers，它将被忽略。

3.2 创建角色框架

可以使用标准Linux命令创建新角色所需的所有子目录和文件。此外，也可以通过命令行实用程序来自动执行新角色创建过程。
ansible-galaxy命令行工具可用于管理Ansible角色，包括新角色的创建。用户可以运行ansible-galaxy init来创建新角色的目录结构。指定角色的名称作为命令的参数，该命令在当前工作目录中为新角色创建子目录。

[root@ansible playbook]# cd roles/
[root@ansible roles]# ansible-galaxy init httpd
- Role httpd was created successfully
[root@ansible roles]# ls
httpd  selinux  timesync

[root@ansible roles]# tree httpd/
httpd
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

8 directories, 8 files

3.3 定义角色内容

创建目录结构后，用户必须编写角色的内容。ROLENAME/tasks/main.yml任务文件是一个不错的起点，它是由角色运行的主要任务列表。

下列tasks/main.yml文件管理受管主机上的/usr/local/httpd/conf/httpd.conf文件。它使用template模块将名为httpd.conf.j2的模板部署到受管主机上。因为template模块是在角色任务而非playbook任务内配置的，所以从角色的templates子目录检索httpd.conf.j2模板。

  template:
    src: 'httpd.conf.j2'
    dest: '/usr/local/httpd/conf/httpd.conf'

下列命令显示httpd角色的httpd.conf.j2模板的部分内容。它引用了变量。

ServerName {{ SERVER_NAME }}

将SERVER_NAME变量设置为localhost:80,将写入到该角色所应用的受管主机上的httpd.conf文件中。

SERVER_NAME: localhost:80

3.4 角色内容开发的推荐做法

角色允许以模块化方式编写playbook。为了最大限度地提高新开发角色的效率，请考虑在角色开发中采用以下推荐做法：

• 在角色自己的版本控制存储库中维护每个角色。Ansible很适合使用基于git的存储库。
• 角色存储库中不应存储敏感信息，如密码或SSH密钥。敏感值应以变量的形式进行参数化，其默认值应不敏感。使用角色的playbook负责通过Ansible Vault变量文件、环境变量或其他ansible-playbook选项定义敏感变量。
• 使用ansible-galaxy init启动角色，然后删除不需要的任何目录和文件。
• 创建并维护README.md和meta/main.yml文件，以记录用户的角色的用途、作者和用法。
• 让角色侧重于特定的用途或功能。可以编写多个角色，而不是让一个角色承担许多任务。
• 经常重用和重构角色。避免为边缘配置创建新的角色。如果现有角色能够完成大部分的所需配置，请重构现有角色以集成新的配置方案。使用集成和回归测试技术来确保角色提供所需的新功能，并且不对现有的playbook造成问题。

3.5 在playbook中使用角色

要访问角色，可在play的roles:部分引用它.

---
- hosts: all
  roles:
    - role: httpd      

3.6 通过变量更改角色的行为

编写良好的角色利用默认变量来改变角色行为，使之与相关的配置场景相符。这有助于让角色变得更为通用，可在各种不同的上下文中重复利用。

如果通过以下方式定义了相同的变量，则角色的defaults目录中定义的变量的值将被覆盖：

• 在清单文件中定义，作为主机变量或组变量
• 在playbook项目的group_vars或host_vars目录下的YAML文件中定义
• 作为变量嵌套在play的vars关键字中定义
• 在play的roles关键字中包含该角色时作为变量定义