利用角色简化playbook
描述角色结构
利用角色构造ansible playbook
随着开发更多的playbook，我们可能会发现有很多机会重复利用以前缩写的playbook中的代码。或许，一个用于为某一应用配置MySQL数据库的play可以改变用途，通过利用不同的主机名、密码和用户来为另一个应用配置MySQL数据库。
但在现实中，这个play可能比较冗长且复杂，有许多包含或导入的文件，以及用于管理各种情况的任务和处理程序。将所有这些代码复制到另一playbook中可能比较困难
Ansible角色提供了一种方法，让用户能以通用的方式更加轻松地重复利用Ansible代码。我们可以在标准化目录结构中打包所有任务、变量、文件、模板，以及调配基础架构或部署应用所需的其他资源。只需通过复制相关的目录，将角色从一个项目复制到另一个项目。然后，只需从一个play调用该角色就能执行它
借助编写良好的角色，可以从playbook中向角色传递调整其行为的变量，设置所有站点相关的主机名、IP地址、用户名，或其他在本地需要的具体详细信息。例如，部署数据库服务器的角色可能已编写为支持多个变量，这些变量用于设置主机名、数据库管理员用户和密码，以及需要为安装进行自定义的其他参数。角色的作者也可以确保在选择不在play中设置变量值时，为这些变量设定合理的默认值
Ansible角色具有下列优点：
- 角色可以分组内容，从而与他人轻松共享代码
- 可以编写角色来定义系统类型的基本要素：Web服务器、数据库服务器、Git存储库，或满足其他用途
- 角色使得较大型项目更容易管理
- 角色可以由不同的管理员并行开发
除了自行编写、使用、重用和共享角色外，还可以从其他来源获取角色。一些角色已包含在rhel-system-roles软件包中，用户也可以从Ansible Galaxy网站获取由社区提供支持的许多角色。
检查ansible角色结构
Ansible角色由子目录和文件的标准化结构定义。顶级目录定义角色本身的名称。文件整理到子目录中，子目录按照各个文件在角色中的用途进行命名，如tasks和handlers。files和templates子目录中包含由其他YAML文件中的任务引用的文件
site.yml
webservers.yml
fooservers.yml
roles/
common/
tasks/
handlers/
files/
templates/
vars/
defaults/
meta/
webservers/
tasks/
defaults/
meta/
以下tree命令显示了user.example角色的目录结构
[root@localhost roles]# tree user.example/
user.example/
├── defaults //默认值，可以修改的变量
│ └── main.yml
├── files //调用的静态文件（安装包等）
├── handlers
│ └── main.yml //处理程序定义
├── meta
│ └── main.yml //角色相关信息
├── README.md
├── tasks
│ └── main.yml //角色任务定义
├── templates //角色引用的模板定义
├── tests
│ ├── inventory
│ └── test.yml //角色里的测试（查看运行是否正常，给用户演示如何使用）
└── vars
└── main.yml //定义角色的变量值
vars/main.yml定义变量
defaults/main.yml 定义刻意需要覆盖的变量
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中使用时不应更改。 |
注意：并非每个角色都拥有所有这些目录
定义变量和默认值
角色变量通过在角色目录层次结构中创建含有键值对的vars/main.yml文件来定义。与其他变量一样，这些角色变量在角色YAML文件中引用：{{VAR_NAME}}。这些变量具有较高的优先级，无法被清单变量覆盖。这些变量旨在供角色的内部功能使用
默认变量允许为可在play中使用的变量设置默认值，以配置角色或自定义其行为。它们通过在角色目录层次结构中创建含有键值对的defaults/main.yml文件来定义。默认变量具有任何可用变量中最低的优先级。它们很容易被包括清单变量在内的任何其他变量覆盖。这些变量旨在让用户在编写使用该角色的play时可以准确地自定义或控制它将要执行的操作。它们可用于向角色提供所需的信息，以正确地配置或部署某些对象
在vars/main.yml或defaults/main.yml中定义具体的变量，但不要在两者中都定义。有意要覆盖变量的值时，应使用默认变量。
注意：
角色不应该包含特定于站点的数据。它们绝对不应包含任何机密，如密码或私钥
这是因为角色应该是通用的，可以重复利用并自由共享。特定于站点的详细信息不应硬编码到角色中
机密应当通过其他途径提供给角色。这是用户可能要在调用角色时设置角色变量的一个原因。play中设置的角色变量可以提供机密，或指向含有该机密的Ansible Vault加密文件
在playbook中使用ansible角色
在playbook中使用角色非常简单。下例演示了调用Ansible角色的一种方式
---
- hosts: 某主机
roles:
- role1
- role2
对于每个指定的角色，角色任务、角色处理程序、角色变量和角色依赖项将按照顺序导入到playbook中。角色中的任何copy、script、template或include_tasks/import_tasks任务都可引用角色中相关的文件、模板或任务文件，且无需相对或绝对路径名称。Ansible将分别在角色的files、templates或tasks子目录中寻找它们。
如果使用roles部分将角色导入到play中，这些角色会在用户为该play定义的任何任务之前运行。
以下示例设置role2的两个角色变量var1和var2的值。使用role2时，任何defaults和vars变量都会被覆盖
---
- hosts: 某主机
roles:
- role: role1
- role: role2
var1: val1
var2: val2
以下是在此情形中用户可能看到的另一种等效的YAML语法：
---
- hosts: 某主机
roles:
- role: role1
- { role: role2, var1: val1, var2: val2 }
尽管这种写法更精简，但在某些情况下它更加难以阅读
重要
正如前面的示例中所示，内嵌设置的角色变量（角色参数）具有非常高的优先级。它们将覆盖大多数其他变量。
务必要谨慎，不要重复使用内嵌设置在play中任何其他位置的任何角色变量的名称，因为角色变量的值将覆盖清单变量和任何play中的vars。
控制执行顺序
对于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: (1)
msg: 'pre-task'
notify: my handler (2)
roles:
- role1 (3)
tasks:
- debug: (4)
msg: 'first task'
notify: my handler (5)
post_tasks:
- debug: (6)
msg: 'post-task'
notify: my handler (7)
handlers:
- name: my handler (该项执行了3次)
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: remote.example.com
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中新增的
利用系统角色重用内容
红帽企业Linux系统角色
RHEL系统角色
| 名称 | 状态 | 角色描述 |
|---|---|---|
| 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服务，以调优系统性能 |
系统角色的目的是在多个版本之间标准化红帽企业Linux子系统的配置。使用系统角色来配置版本6.10及以上的任何红帽企业Linux主机
安装rhel系统角色
安装
[root@localhost ~]# yum -y install rhel-system-roles
...
Installed:
rhel-system-roles-1.0-20.el8.noarch
Complete!
查看安装后的系统角色
[root@localhost ~]# ls /usr/share/ansible/roles/
linux-system-roles.certificate linux-system-roles.network rhel-system-roles.kdump rhel-system-roles.postfix
linux-system-roles.kdump linux-system-roles.postfix rhel-system-roles.kernel_settings rhel-system-roles.selinux
linux-system-roles.kernel_settings linux-system-roles.selinux rhel-system-roles.logging rhel-system-roles.storage
linux-system-roles.logging linux-system-roles.storage rhel-system-roles.metrics rhel-system-roles.timesync
linux-system-roles.metrics linux-system-roles.timesync rhel-system-roles.nbde_client rhel-system-roles.tlog
linux-system-roles.nbde_client linux-system-roles.tlog rhel-system-roles.nbde_server
linux-system-roles.nbde_server rhel-system-roles.certificate rhel-system-roles.network
访问系统角色文档
[root@localhost ~]# ll /usr/share/doc/rhel-system-roles/
total 4
drwxr-xr-x. 2 root root 57 Feb 23 20:16 certificate
drwxr-xr-x. 2 root root 57 Feb 23 20:16 kdump
drwxr-xr-x. 2 root root 72 Feb 23 20:16 kernel_settings
drwxr-xr-x. 2 root root 72 Feb 23 20:16 logging
drwxr-xr-x. 2 root root 57 Feb 23 20:16 metrics
drwxr-xr-x. 2 root root 57 Feb 23 20:16 nbde_client
drwxr-xr-x. 2 root root 57 Feb 23 20:16 nbde_server
drwxr-xr-x. 2 root root 4096 Feb 23 20:16 network
drwxr-xr-x. 2 root root 57 Feb 23 20:16 postfix
drwxr-xr-x. 2 root root 93 Feb 23 20:16 selinux
drwxr-xr-x. 2 root root 57 Feb 23 20:16 storage
drwxr-xr-x. 2 root root 136 Feb 23 20:16 timesync
drwxr-xr-x. 2 root root 57 Feb 23 20:16 tlog
创建角色
从创建到使用分三步
- 创建角色目录结构
- 定义角色内容
- 在playbook中使用角色
ansible-galaxy init命令创建新角色的目录结构
[root@localhost project]# cd roles/
[root@localhost roles]# ansible-galaxy init test #创建一个名为“测试”的角色
- Role test was created successfully
[root@localhost roles]# ll
total 0
drwxr-xr-x. 10 root root 154 Feb 24 10:34 test
[root@localhost roles]# tree test/ #查看test的目录结构
test/
├── defaults
│ └── main.yml
├── files
├── handlers
│ └── main.yml
├── meta
│ └── main.yml
├── README.md
├── tasks
│ └── main.yml
├── templates
├── tests
│ ├── inventory
│ └── test.yml
└── vars
└── main.yml
定义角色内容
[root@localhost test]# vim tasks/main.yml
---
# tasks file for test 定义创建用户任务
- name: useradd
user:
name: {{ name }} #引用变量1
system: {{ state }} #引用变量2
在playbook中使用角色
添加用户
[root@localhost project]# cat test.yml
---
- hosts: yc
gather_facts: no
remote_user: root
vars:
name: yanchuang #作为变量嵌套在play的vars关键字中定义
state: true
roles: #roles模块引用test角色
- test
//运行
[root@localhost project]# ansible-playbook test.yml
......
//在受控机yc上验证
[root@yc ~]# id yanchuang
uid=999(yanchuang) gid=966(yanchuang) groups=966(yanchuang)
通过变量更改角色行为
在play的roles关键字中包含该角色时作为变量定义
[root@localhost project]# vim test.yml
---
- hosts: yc
gather_facts: no
remote_user: root
roles:
- test
name: yanchuang
state: true
作为变量嵌套在play的vars关键字中定义
[root@localhost project]# cat test.yml
---
- hosts: yc
gather_facts: no
remote_user: root
vars:
name: yanchuang
state: true
roles:
- test
重要
在play中使用角色变量时，变量的优先顺序可能会让人困惑。
- 几乎任何其他变量都会覆盖角色的默认变量，如清单变量、playvars变量，以及内嵌的角色参数等。
- 较少的变量可以覆盖角色的vars目录中定义的变量。事实、通过include_vars加载的变量、注册的变量和角色参数是其中一些具备这种能力的变量。清单变量和playvars无此能力。这非常重要，因为它有助于避免用户的play意外改变角色的内部功能。
- 不过，正如上述示例中最后一个所示，作为角色参数内嵌声明的变量具有非常高的优先级。它们可以覆盖角色的vars目录中定义的变量。如果某一角色参数的名称与playvars或角色vars中设置的变量或者清单变量或playbook变量的名称相同，该角色参数将覆盖另一个变量。
