本文介绍了Ansible的高级功能，包括包含与导入任务、角色构造、变量定义等内容。重点讲解了如何利用Ansible的角色功能来简化和重用复杂的任务流程。
1.包含于导入的用法
1.1 包含或导入文件
Ansible可以使用两种操作将内容带入playbook。可以包含内容，也可以导入内容
- 包含内容是一个动态操作。在playbook运行期间，Ansible会在内容到达时处理所包含的内容
- 导入内容是一个静态操作。在运行开始之前，Ansible在最初解析playbook时预处理导入的内容
1.2 导入plyabook
import_playbook指令允许将包含play列表的外部文件导入playbook。换句话说，可以把一个或多个额外playbook文件导入到主playbook文件中
由于导入的内容是一个完整的playbook，因此import_playbook功能只能在playbook的顶层使用，不能在play内使用。如果导入多个playbook，则将按顺序导入并运行它们
导入两个额外playbook的主playbook的简单示例如下所
---
- hosts: all
- name: install
import_playbook: install.yml
- name: start
import_playbook: start.yml
1.3包含和导入任务
1.3.1 导入任务文件
可以使用import_tasks功能将任务文件静态导入playbook内的play中。
导入任务文件时，在解析该playbook时将直接插入该文件中的任务。
Playbook中的import_tasks的位置控制插入任务的位置以及运行多个导入的顺序
---
- hosts: all
tasks:
- name: install
import_tasks: install.yml
- name: start
import_tasks: start.yml
- 注意：import_tasks和import_playbook处于不同的级别；import_playbook是与tasks平级；import_tasks则是tasks的子任务
导入任务文件时，在解析该playbook时将直接插入该文件中的任务。由于import_tasks在解析playbook时静态导入任务，因此对其工作方式有一些影响
- 使用import_tasks功能时，导入时设置的when等条件语句将应用于导入的每个任务
- 无法将循环用于import_tasks功能
- 如果使用变量来指定要导入的文件的名称，则将无法使用主机或组清单变量
1.3.2包含任务文件
可以使用include_tasks功能将任务文件动态导入playbook内的play中
---
- hosts: all
tasks:
- name: install
imclude_tasks: install.yml
在play运行并且这部分play到达前，include_tasks功能不会处理playbook中的内容
Playbook内容的处理顺序会影响包含任务功能的工作方式
- 使用include_tasks功能时，包含时设置的when等条件语句将确定任务是否包含在play中
- 如果运行ansible-playbook --list-tasks以列出playbook中的任务，则不会显示已包含任务文件中的任务
- 相比之下，import_tasks功能不会列出导入任务文件的任务，而列出已导入任务文件中的各个任务
- 不能使用ansible-playbook --start-at-task从已包含任务文件中的任务开始执行playbook
- 不能使用notify语句触发已包含任务文件中的处理程序名称。可以在包含整个任务文件的主playbook中触发处理程序，在这种情况下，已包含文件中的所有任务都将运行
2. 为外部play和任务定义变量
使用Ansible的导入和包含功能将外部文件中的play或任务合并到playbook中极大地增强了在Ansible环境中重用任务和playbook的能力
[root@ansible ansible]# cat playbook/install.yml
- name: install
yum:
name: "{{ package }}"
state: latest
[root@ansible ansible]# cat playbook/test.yml
---
- hosts: all
vars:
package: httpd
tasks:
- import_tasks: install.yml
使用相同的技术使play文件更具有可重用性。将play文件合并到playbook中时，传递变量以用于执行该play
[root@ansible ansible]# cat playbook/install.yml
---
- name: install
hosts: all
vars:
package: httpd
tasks:
- name: install
yum:
name: "{{ package }}"
state: latest
[root@ansible ansible]# cat playbook/test.yml
- name: install
import_playbook: install.yml
3. 利用角色构造ansible playbook
3.1什么是角色
Ansible角色提供了一种方法，让用户能以通用的方式更加轻松地重复利用Ansible代码。
我们可以在标准化目录结构中打包所有任务、变量、文件、模板，以及调配基础架构或部署应用所需的其他资源
只需通过复制相关的目录，将角色从一个项目复制到另一个项目。然后，只需从一个play调用该角色就能执行它
借助编写良好的角色，可以从playbook中向角色传递调整其行为的变量，设置所有站点相关的主机名、IP地址、用户名，或其他在本地需要的具体详细信息
Ansible具备的优点：
- 角色可以分组内容，从而与他人轻松共享代码
- 可以编写角色来定义系统类型的基本要素：Web服务器、数据库服务器、Git存储库，或满足其他用途
- 角色使得较大型项目更容易管理
- 角色可以由不同的管理员并行开发
除了自行编写、使用、重用和共享角色外，还可以从其他来源获取角色。一些角色已包含在rhel-system-roles软件包中，用户也可以从Ansible Galaxy网站获取由社区提供支持的许多角色
-
使用rhel-system-roles软件包使用角色
//在控制节点上查看本地的角色 [root@ansible ansible]# ls /usr/share/ansible/roles/ //安装rhel-system-roles [root@ansible ansible]# yum -y install rhel-system-roles //再次查看本地的角色 [root@ansible ansible]# ls /usr/share/ansible/roles/ linux-system-roles.certificate linux-system-roles.ssh rhel-system-roles.metrics linux-system-roles.crypto_policies linux-system-roles.sshd rhel-system-roles.nbde_client linux-system-roles.ha_cluster linux-system-roles.storage rhel-system-roles.nbde_server linux-system-roles.kdump linux-system-roles.timesync rhel-system-roles.network linux-system-roles.kernel_settings linux-system-roles.tlog rhel-system-roles.postfix linux-system-roles.logging linux-system-roles.vpn rhel-system-roles.selinux linux-system-roles.metrics rhel-system-roles.certificate rhel-system-roles.ssh linux-system-roles.nbde_client rhel-system-roles.crypto_policies rhel-system-roles.sshd linux-system-roles.nbde_server rhel-system-roles.ha_cluster rhel-system-roles.storage linux-system-roles.network rhel-system-roles.kdump rhel-system-roles.timesync linux-system-roles.postfix rhel-system-roles.kernel_settings rhel-system-roles.tlog linux-system-roles.selinux rhel-system-roles.logging rhel-system-roles.vpn [root@ansible ansible]# -
从Ansible Galaxy网站获取由社区提供支持的许多角色，请戳：https://galaxy.ansible.com/
3.2 ansible角色结构
Ansible角色由子目录和文件的标准化结构定义
顶级目录定义角色本身的名称。
文件整理到子目录中，子目录按照各个文件在角色中的用途进行命名，如tasks和handlers。files和templates子目录中包含由其他YAML文件中的任务引用的文件
实例：
head.yml
main.yml
roles/
common/
tasks/
handlers/
files/
templates/
vars/
defaults/
meta/
webservers/
tasks/
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中使用时不应更改。 |
- 注意：并非每个角色都拥有所有这些目录。
3.3 定义变量和默认值
3.3.1 定义变量
角色变量通过在角色目录层次结构中创建含有键值对的vars/main.yml文件来定义（键值对：key = value）
这些角色变量在角色YAML文件中引用：**{{ VAR_NAME }}，**这些变量具有较高的优先级，无法被清单变量覆盖
3.3.2 定义默认值
默认变量允许为可在play中使用的变量设置默认值，以配置角色或自定义其行为
它们通过在角色目录层次结构中创建含有键值对的defaults/main.yml文件来定义
默认变量具有任何可用变量中最低的优先级。它们很容易被包括清单变量在内的任何其他变量覆盖
这些变量旨在让用户在编写使用该角色的play时可以准确地自定义或控制它将要执行的操作。它们可用于向角色提供所需的信息，以正确地配置或部署某些对象
在vars/main.yml或defaults/main.yml中定义具体的变量，但不要在两者中都定义，有意要覆盖变量的值时，应使用默认变量
注意：
- 角色不应该包含特定于站点的数据。它们绝对不应包含任何机密，如密码或私钥
- 这是因为角色应该是通用的，可以重复利用并自由共享。特定于站点的详细信息不应硬编码到角色中
- 机密应当通过其他途径提供给角色。这是用户可能要在调用角色时设置角色变量的一个原因
- play中设置的角色变量可以提供机密，或指向含有该机密的Ansible Vault加密文件。
3.4 在palybook中使用ansbible角色
3.4.1 角色调用
对于每个指定的角色，角色任务、角色处理程序、角色变量和角色依赖项将按照顺序导入到playbook中
角色中的任何copy、script、template或include_tasks/import_tasks任务都可引用角色中相关的文件、模板或任务文件，且无需相对或绝对路径名称
Ansible将分别在角色的files、templates或tasks子目录中寻找它们
[root@ansible ansible]# cat playbook/main.yml
---
- hosts: all
roles:
- role: roles/role_one
- role: roles/role_two
[root@ansible ansible]#
重要：
- 内嵌设置的角色变量（角色参数）具有非常高的优先级。它们将覆盖大多数其他变量
- 务必要谨慎，不要重复使用内嵌设置在play中任何其他位置的任何角色变量的名称，因为角色变量的值将覆盖清单变量和任何play中的vars
3.5 控制执行顺序
3.5.1 顺序控制
对于playbook中的每个play，任务按照任务列表中的顺序来执行。执行完所有任务后，将执行任务通知的处理程序。
将角色添加到play中，角色任务将添加到任务列表的开头。如果play中包含第二个角色任务，其任务列表添加到第一个角色之后
角色处理程序添加到play中的方式与角色任务添加到play中相同，每个play定义一个处理程序列表；角色处理程序先添加到处理程序列表，后跟play的handlers部分中的任何处理程序
在某些情形中，可能需要在角色之前执行一些play任务。若要支持这样的情形，可以为play配置pre_tasks部分，列在此部分中的所有任务将在执行任何角色之前执行
- 如果这些任务中有任何一个通知了处理程序，则这些处理程序任务也在角色或普通任务之前执行
play也支持post_tasks关键字。这些任务在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后
除了将角色包含在play的roles部分中外，也可以使用普通任务将角色添加到play中。
-
使用include_role模块可以动态包含角色，使用import_role模块则可静态导入角色。
注意：
- include_role模块是在Ansible 2.3中新增的，而import_role模块则是在Ansible 2.4中新增的
3.6 时间同步角色示例
RHEL系统中时间同步角色的playbook是：rhel-system-rolses.timesync
首次使用时间同步角色可以在rhel-system-roles.timesync/README.md查看使用的帮助文档；里面包含使用的示例
演示实例：
//编写playbook
[root@ansible ansible]# cat playbook/time.yml
---
- name: time
hosts: all
vars:
timesync_ntp_servers:
- hostname: time1.aliyun.com
iburst: yes
timezone: UTC
roles:
- rhel-system-roles.timesync
[root@ansible ansible]#
//查看受管主机时间
[root@apache ~]# date
Sun Aug 1 23:53:31 EDT 2021
//执行play
[root@ansible ansible]# ansible-playbook playbook/time.yml
//再次查看
3.7 SELINUX角色示例
rhel-system-roles.selinux角色可以简化SELinux配置设置的管理。它通过利用SELinux相关的Ansible模块来实施。与自行编写任务相比，使用此角色的优势是它能让用户摆脱编写这些任务的职责。取而代之，用户将为角色提供变量以对其进行配置，且角色中维护的代码将确保应用用户需要的SELinux配置。
此角色可以执行的任务包括：
- 设置enforcing或permissive模式
- 对文件系统层次结构的各部分运行restorecon
- 设置SELinux布尔值
- 永久设置SELinux文件上下文
- 设置SELinux用户映射
3.7.1 调用SELinux角色
有时候，SELinux角色必须确保重新引导受管主机，以便能够完整应用其更改。但是，它本身从不会重新引导主机。如此一来，用户便可以控制重新引导的处理方式。
其工作方式为，该角色将一个布尔值变量selinux_reboot_required设为True，如果需要重新引导，则失败。你可以使用block/rescure结构来从失败中恢复，具体操作为：如果该变量未设为true，则让play失败，如果值是true，则重新引导受管主机并重新运行该角色。Play中的块看起来应该类似于：
- name: Apply SELinux role
block:
- include_role:
name: rhel-system-roles.selinux
rescue:
- name: Check for failure for other reasons than required reboot
fail:
when: not selinux_reboot_required
- name: Restart managed host
reboot:
- name: Reapply SELinux role to complete changes
include_role:
name: rhel-system-roles.selinux
3.7.2 配置SELinux角色
用于配置rhel-system-roles.selinux角色的变量的详细记录位于其README.md文件中。以下示例演示了使用此角色的一些方法。
selinux_state变量设置SELinux的运行模式。它可以设为enforcing、permissive或disabled。如果未设置，则不更改模式。
selinux_state: enforcing
selinux_booleans变量取一个要调整的SELinux布尔值的列表作为值。列表中的每一项是变量的散列/字典：布尔值的name、state（它应是on还是off），以及该设置是否应在重新引导后persistent。
本例将httpd_enable_homedirs永久设为on：
selinux_booleans:
- name: 'httpd_enable_homedirs'
state: 'on'
persistent: 'yes'
selinux_fcontext变量取一个要永久设置（或删除）的文件上下文的列表作为值。它的工作方式与selinux fcontent命令非常相似。
以下示例确保策略中包含一条规则，用于将/srv/www下所有文件的默认SELinux类型设为httpd_sys_content_t。
selinux_fcontexts:
- target: '/srv/www(/.*)?'
setype: 'httpd_sys_content_t'
state: 'present'
selinux_restore_dirs变量指定要对其运行restorecon的目录的列表：
selinux_restore_dirs:
- /srv/www
selinux_ports变量取应当具有特定SELinux类型的端口的列表作为值。
selinux_ports:
- ports: '82'
setype: 'http_port_t'
proto: 'tcp'
state: 'present'
扫一扫
364
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
