包含与导入
一、管理大型的playbook
如果playbook很长或很复杂,我们可以将其分为较小的文件以便于管理
可采用模块化的方式将多个playbook组合为一个主要的playbook,或者将文件中的任务列表插入play
二、包含或导入文件
Ansible可以使用两种操作方式将内容带入playbook。可以包含内容和,也可以导入内容
包含内容是一个动态操作。在playbook运行期间,Ansible会在内容到达时处理所包含的内容
导入内容是一个静态操作。在运行开始之前,Ansible在最初解析playbook时预处理导入的内容
三、导入playbook
import_playbook指令允许将包含play列表的外部文件导入playbook。换句话说,可以把一个或多个额外playbook文件导入到playbook文件中
由于导入的内容是一个完整的playbook,因此import_playbook功能只能在playbook的顶层使用,不能在play内使用。如果导入多个playbook,则将按顺序导入并运行它们
导入两个额外playbook的主playbook的简单示例如下
[root@localhost project]# cat playbook.yml
---
- hosts: all
tasks:
- name: install httpd
import_playbook: http.yml
- name: start httpd
import_playbook: start_http.yml
四、包含和导入任务
- 导入任务文件
可以使用import_tasks功能将任务文件静态导入playbook内的play中
导入任务文件时,在解析该playbook时将直接插入该文件中的任务
playbook中的import_tasks的位置控制插入任务的位置以及多个导入的顺序
---
- hosts: all
tasks:
- name: install httpd
import_tasks: http.yml
- name: start httpd
import_tasks: start_http.yml
注意:import_tasks和import_playbook处于不同的级别;import_playbook是与tasks平级;import_tasks则是tasks的子任务
导入任务文件时,在解析该playbook时将直接插入该文件中的任务。由于import_tasks在解析playbook时静态导入任务,因此对其工作方式有一些影响
使用import_tasks功能时,导入时设置的when等条件语句将应用于导入的每个任务
无法将循环用于import_tasks功能
如果使用变量来指定要导入的文件的名称,则将无法使用主机或组清单变量
- 包含任务文件
可以使用include_tasks功能将任务文件动态导入playbook中
---
- hosts: all
tasks:
- name: install httpd
include_tasks: install_httpd.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中触发处理程序,在这种情况下,已包含文件中的所有任务都将运行
- 注意事项
如果新服务器需要全面配置,则管理员可以创建不同的任务集合,分别用于创建用户、安装软件包、配置服务、配置特权、设置对共享文件的访问权限、强化服务器、安装安全更新,以及安装监控代理等。每一任务集合可通过单独的自包含任务文件进行管理
如果服务器由开发人员、系统管理员和数据库管理员统一管理,则每个组织可以编写自己的任务文件,再由系统经理进行审核和集成
如果服务器要求特定的配置,它可以整合为按照某一条件来执行的一组任务。换句话说,仅在满足特定标准时才包含任务
如果一组服务器需要运行某一项/组任务,则它/它们可以仅在属于特定主机组的服务器上运行 - 管理任务文件
为方便管理,可以创建专门用于任务文件的目录,并将所有任务文件保存在该目录中。然后playbook就可以从该目录包含或导入任务文件。这样就可以构建复杂的playbook,同时简化其结构和组件的管理
角色的结构
一、利用角色构造ansible playbook
- 什么是角色
ansible角色提供了一种方法,让用户能以通用的方式更加轻松地重复利用ansible代码
我们可以在标准化目录结构中打包所有任务、变量、 文件、模板,以及调配基础架构或部署应用所需的其他资源,只需通过复制相关的目录,将角色从一个项目复制到另一个项目。然后,只需从一个play调用该角色就能执行它
借助编写良好的角色,可以从playbook中向角色传递调整其行为的变量,设置所有站点相关的主机名、IP地址、用户名,或其他在本地需要的具体详细信息
ansible角色的优点:
角色可以分组内容,从而与他人轻松共享代码
可以编写角色来定义系统类型的基本要素:web服务器、数据库服务器、git存储库,或满足其他通途
角色使得较大型项目更容易管理
角色可以由不同的管理员并行开发
除了自行编写、使用、重用和共享角色外,还可以从其他来源获取角色。一些角色已包含在rhel-system-roles软件包中,用户也可以从Ansible Galaxy网站获取由社区提供支持的许多角色
使用rhel-system-roles软件包使用角色
//在控制节点上查看本地的角色
[root@localhost ~]# ls /usr/share/ansible/roles/
//安装rhel-system-roles
[root@localhost ~]# yum list | grep rhel-system-roles
rhel-system-roles.noarch 1.0-9.el8 appstream
[root@localhost ~]# yum install -y rhel-system-roles
//在次查看本地的角色
[root@localhost ~]# ls /usr/share/ansible/roles/
linux-system-roles.kdump linux-system-roles.postfix linux-system-roles.storage rhel-system-roles.kdump rhel-system-roles.postfix rhel-system-roles.storage
linux-system-roles.network linux-system-roles.selinux linux-system-roles.timesync rhel-system-roles.network rhel-system-roles.selinux rhel-system-roles.timesync
从Ansible Galaxy网站获取由社区提供支持的许多角色,请访问:https://galaxy.ansible.com/
二、Ansible角色结构
- 结构说明
ansible色由子目录和文件的标准化结构定义
顶级目录定义角色本身的名称
文件整理到子目录中,子目录按照各个文件在角色中的用途进行命名,如tasks和handlers。files和templates子目录中包含由其他yaml文件中的任务引用的文件
. 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文件来定义(键值对:key = value)
这些角色变量在角色yaml文件中引用{{ VAR_NAME }},这些变量具有较高的优先级,无法被清单变量覆盖 - 定义默认值
默认变量允许为可在play中使用的变量设置默认值,以配置角色或自定义其行为
它们通过在角色目录层次结构中创建含有键值对的defaults/main.yml文件来定义
默认变量具有任何可用变量中最低的优先级。它们很容易被包括清单变量在内的任何其他变量覆盖
这些变量旨在让用户在编写使用该角色的play时可以准确地自定义或控制它将要执行的操作。它们可用于向角色提供所需的信息,以正确地配置或部署某些对象
在vars/main.yml或defaults/main.yml中定义具体的变量,但不要在两者中都定义,有意要覆盖变量的值时,应使用默认变量 - 注意
角色不应该包含特定于站点的数据。它们绝对不应包含任何机密,如密码或私钥
这是因为角色应该是通用的,可以重复利用并自由共享。特定于站点的详细信息不应硬编码到角色中
机密应当通过其他途径提供给角色。这是用户可能要在调用角色时设置角色变量的一个原因
play中设置的角色变量可以提供机密,或指向含有该机密的Ansible Vault加密文件
四、在playbook中使用ansible角色
- 在playbook中简单调用ansible角色
---
- host: all
roles:
- role_one
- role_two
- role_three
- 角色调用
对于每个指定的角色,角色任务、角色处理程序、角色变量和角色依赖项将按照顺序导入到playbook中
角色中的任何copy、script、template或include_tasks/import_tasks任务都可引用角色中相关的文件、模板或任务文件,且无需相对或绝对路径名称
Ansible将分别在角色的files、templates或tasks子目录中寻找它们
重要:
内嵌设置的角色变量具有非常高的优先级。它们将覆盖大多数其他变量
不要重复使用内嵌设置在play中任何其他位置的任何角色变量的名称,因为角色变量的值将覆盖清单变量和任何play中的vars
系统角色的使用
一、timesync的使用
假设需要在服务器上配置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。
- name: shijiantongbu
hosts: all
vars:
timesync_ntp_servers:
- hostname: 0.rhel.pool.ntp.org
iburst: yes
timezone: UTC
roles:
- rhel-system-roles.timesync
tasks:
- name: Set timezone
timezone:
name: "{{ timezone }}"
注意
如果要设置不同的时区,可以使用tzselect命令查询其他有效的值。也可以使用timedatectl命令来检查当前的时钟设置。
二、SELINUX的使用
- SELinux角色示例
rhel-system-roles.selinux角色可以简化SELinux配置设置的管理。它通过利用SELinux相关的Ansible模块来实施。与自行编写任务相比,使用此角色的优势是它能让用户摆脱编写这些任务的职责。取而代之,用户将为角色提供变量以对其进行配置,且角色中维护的代码将确保应用用户需要的SELinux配置。
此角色可以执行的任务包括:
设置enforcing或permissive模式
对文件系统层次结构的各部分运行restorecon
设置SELinux布尔值
永久设置SELinux文件上下文
设置SELinux用户映射
2. 调用SELinux角色
有时候,SELinux角色必须确保重新引导受管主机,以便能够完整应用其更改。但是,它本身从不会重新引导主机。如此一来,用户便可以控制重新引导的处理方式。
其工作方式为,该角色将一个布尔值变量selinux_reboot_required设为True,如果需要重新引导,则失败。你可以使用block/rescure结构来从失败中恢复,具体操作为:如果该变量未设为true,则让play失败,如果值是true,则重新引导受管主机并重新运行该角色。Play中的块看起来应该类似于:
- name: 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
- 配置SELinux角色
用于配置rhel-system-roles.selinux角色的变量的详细记录位于其README.md文件中。以下示例演示了使用此角色的一些方法
selinux_state变量设置SELinux的运行模式。它可以设为enforceing、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'
.*)?'
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'