包含与导入

一、管理大型的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: alltasks:
- name: install httpdimport_playbook: http.yml- name: start httpdimport_playbook: start_http.yml

四、包含和导入任务

1. 导入任务文件
   可以使用import_tasks功能将任务文件静态导入playbook内的play中

导入任务文件时，在解析该playbook时将直接插入该文件中的任务

playbook中的import_tasks的位置控制插入任务的位置以及多个导入的顺序

---
- hosts: alltasks:- name: install httpdimport_tasks: http.yml- name: start httpdimport_tasks: start_http.yml

注意：import_tasks和import_playbook处于不同的级别；import_playbook是与tasks平级；import_tasks则是tasks的子任务

导入任务文件时，在解析该playbook时将直接插入该文件中的任务。由于import_tasks在解析playbook时静态导入任务，因此对其工作方式有一些影响

使用import_tasks功能时，导入时设置的when等条件语句将应用于导入的每个任务

无法将循环用于import_tasks功能

如果使用变量来指定要导入的文件的名称，则将无法使用主机或组清单变量

2. 包含任务文件
   可以使用include_tasks功能将任务文件动态导入playbook中

---
- hosts: alltasks: - name: install httpdinclude_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中触发处理程序，在这种情况下，已包含文件中的所有任务都将运行

3. 注意事项
   如果新服务器需要全面配置，则管理员可以创建不同的任务集合，分别用于创建用户、安装软件包、配置服务、配置特权、设置对共享文件的访问权限、强化服务器、安装安全更新，以及安装监控代理等。每一任务集合可通过单独的自包含任务文件进行管理
   如果服务器由开发人员、系统管理员和数据库管理员统一管理，则每个组织可以编写自己的任务文件，再由系统经理进行审核和集成
   如果服务器要求特定的配置，它可以整合为按照某一条件来执行的一组任务。换句话说，仅在满足特定标准时才包含任务
   如果一组服务器需要运行某一项/组任务，则它/它们可以仅在属于特定主机组的服务器上运行
4. 管理任务文件
   为方便管理，可以创建专门用于任务文件的目录，并将所有任务文件保存在该目录中。然后playbook就可以从该目录包含或导入任务文件。这样就可以构建复杂的playbook，同时简化其结构和组件的管理

角色的结构

一、利用角色构造ansible playbook

1. 什么是角色
   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角色结构

1. 结构说明
   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中使用时不应更改
   注意：并非每个角色都拥有这些目录

三、定义变量和默认值

1. 定义变量
   角色变量通过在角色目录层次结构中创建含有键值对的vars/main.yml文件来定义(键值对：key = value)
   这些角色变量在角色yaml文件中引用{{ VAR_NAME }}，这些变量具有较高的优先级，无法被清单变量覆盖
2. 定义默认值
   默认变量允许为可在play中使用的变量设置默认值，以配置角色或自定义其行为
   它们通过在角色目录层次结构中创建含有键值对的defaults/main.yml文件来定义
   默认变量具有任何可用变量中最低的优先级。它们很容易被包括清单变量在内的任何其他变量覆盖
   这些变量旨在让用户在编写使用该角色的play时可以准确地自定义或控制它将要执行的操作。它们可用于向角色提供所需的信息，以正确地配置或部署某些对象
   在vars/main.yml或defaults/main.yml中定义具体的变量，但不要在两者中都定义，有意要覆盖变量的值时，应使用默认变量
3. 注意
   角色不应该包含特定于站点的数据。它们绝对不应包含任何机密，如密码或私钥
   这是因为角色应该是通用的，可以重复利用并自由共享。特定于站点的详细信息不应硬编码到角色中
   机密应当通过其他途径提供给角色。这是用户可能要在调用角色时设置角色变量的一个原因
   play中设置的角色变量可以提供机密，或指向含有该机密的Ansible Vault加密文件

四、在playbook中使用ansible角色

1. 在playbook中简单调用ansible角色

---
- host: allroles:- role_one- role_two- role_three

2. 角色调用
   对于每个指定的角色，角色任务、角色处理程序、角色变量和角色依赖项将按照顺序导入到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: shijiantongbuhosts: allvars:timesync_ntp_servers:- hostname: 0.rhel.pool.ntp.orgiburst: yestimezone: UTCroles:- rhel-system-roles.timesynctasks:- name: Set timezonetimezone:name: "{{ timezone }}"

注意
如果要设置不同的时区，可以使用tzselect命令查询其他有效的值。也可以使用timedatectl命令来检查当前的时钟设置。

二、SELINUX的使用

1. 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 roleblock:- include_role:name: rhel-system-roles.selinuxrescue:- name: Check for failure for other reasons than required rebootfail:when: not selinux_reboot_required- name: Restart managed hostreboot:- name: Reapply SELinux role to complete changesinclude_role:name: rhel-system-roles.selinux

3. 配置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'