管理大项目
包含与导入
一、管理大型的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
四、包含和导入任务
1. 导入任务文件
-
可以使用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功能
- 如果使用变量来指定要导入的文件的名称，则将无法使用主机或组清单变量
2. 包含任务文件
-
可以使用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中触发处理程序，在这种情况下，已包含文件中的所有任务都将运行
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文件中的任务引用的文件
2. 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: all
roles:
- 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: 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的使用
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 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. 配置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'
217
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
