ansible从入门到精通（完整篇）

ansible从入门到精通（完整篇）

转自ansible从入门到精通（完整篇）

文章目录

01 Ansible介绍与安装

1. 介绍 Ansible

1.1 什么是 Ansible?

Ansible是一款自动化运维工具，基于Python开发，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。

Ansible是基于模块工作的，本身没有批量部署的能力。真正具有批量部署的是Ansible所运行的模块，Ansible只是提供一种框架。主要包括：
(1) 连接插件connection plugins：负责和被监控端实现通信；
(2) host inventory：指定操作的主机，是一个配置文件里面定义监控的主机；
(3) 各种模块核心模块、command模块、自定义模块；
(4) 借助于插件完成记录日志邮件等功能；
(5) playbook：剧本执行多个任务时，非必需可以让节点一次性运行多个任务。

Ansible架构图：

1.2 Ansible 无需代理

Ansible 围绕无代理架构构建。通常而言，Ansible 通过 OpenSSH 或 WinRM 连接它所管理的主机并且运行任务，方法通常是将称为 Ansible 模块的小程序推送至这些主机。这些程序用于将系统置于需要的特定状态。在 Ansible 运行完其任务后，推送的所有模块都会被删除。

Ansible 不需要批准使用任何特殊代理，然后再部署到受管主机上。由于没有代理，也不需要额外的自定义安全基础架构，

Ansible 具有多个重要的优点：

• 跨平台支持：Ansible 提供Linux、Windows、UNIX和网络设备的无代理支持，适用于物理、虚拟、云和容器环境。
• 人类可读的自动化：Ansible Playbook采用YAML文本文件编写，易于阅读，有助于确保所有人都能理解它们的用途。
• 完美描述应用：可以通过 Ansible Playbook进行每种更改，并描述和记录应用环境的每一个方面。
• 轻松管理版本控制：Ansible Playbook和项目是纯文本。它们可以视作源代码，放在现有版本控制系统中。
• 支持动态清单：可以从外部来源动态更新 Ansible 管理的计算机列表，随时获取所有受管服务器的当前正确列表，不受基础架构或位置的影响。
• 编排可与其他系统轻松集成：能够利用环境中现有的 HP SA、Puppet、Jenkins、红帽卫星和其他系统，并且集成到 Ansible 工作流中。

1.3 Ansible 方式

Ansible 的设计宗旨是工具易用，自动化易写易读。所以在创建自动化时我们应追求简单化。

Ansible 自动化语言围绕简单易读的声明性文本文件来构建。正确编写的 Ansible Playbook可以清楚地记录你的工作自动化。

Ansible 是一种要求状态引擎。它通过表达你所希望系统处于何种状态来解决如何自动化IT部署的问题。Ansible 的目标是通过仅执行必要的更改，使系统处于所需的状态。试图将 Ansible 视为脚本语言并非正确的做法。

2. 安装 Ansible

2.1 控制节点

Ansible 易于安装。 Ansible 软件只需要安装到要运行它的一个（或多个）控制节点上。由 Ansible管理的主机不需要安装 Ansible。

对控制节点的要求：

• 控制节点应是Linux或UNIX系统。不支持将Windows用作控制节点，但Windows系统可以是受管主机。
• 控制节点需要安装Python3（版本3.5或以上）或Python2（版本2.7或以上）。

如果操作系统是红帽8.0，Ansible 2.9可以自动使用 platform-python 软件包，该软件包支持使用Python的系统实用程序。你不需要从 AppStream安装python37或python27软件包。

[root@localhost ~]# yum list installed platform-python
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Installed Packages
platform-python.x86_64                   3.6.8-1.el8.0.1                    @anaconda

1
2
3
4
5
6

2.2 受管主机

Ansible的一大优点是受管主机不需要安装特殊代理。Ansible控制节点使用标准的网络协议连接受管主机，从而确保系统处于指定的状态。

受管主机可能要满足一些要求，具体取决于控制节点连接它们的方式以及它们要运行的模块。

Linux和UNIX受管主机需要安装有Python2（版本2.6或以上）或Python3（版本3.5或以上），这样才能运行大部分的模块。

对于红帽8，可以启用并安装python36应用流（或python27应用流）

yum module install python36

1

如果受管主机上启用了SELinux，还需要确保安装python3-libselinux软件包，然后才能使用与任何复制、文件或模板功能相关的模块。所以在工作的时候，应当把SELinux功能关闭。

2.3 基于Windows的受管主机

Ansible有许多专门为Windows系统设计的模块。这些模块列在https://docs.ansible.com/ansible/latest/modules/list_of_windows_modules.html部分中。

大部分专门为Windows受管主机设计的模块需要在受管主机上安装PowerShell 3.0或更高版本，而不是安装Python。此外，受管主机也需要配置PowerShell远程连接。Ansible还要求至少将.NET Framework 4.0或更高版本安装在Windows受管主机上。

本课程不对Windows受管主机做过多说明，未来在工作当中需要用到时请查阅以上官方文档链接。

2.4 受管网络设备

Ansible还可以配置受管网络设备，例如路由器和交换机。Ansible包含大量专门为此目的而设计的模块。其中包括对Cisco IOS、IOS XR和NX-OS的支持；Juniper Junos；Arsta EOS；以及基于VyOS的网络设备等。

我们可以使用为服务器编写playbook时使用的相同基本技术为网络设备编写Ansible Playbook。由于大多数网络设备无法运行Python，因此Ansible在控制节点上运行网络模块，而不是在受管主机上运行。特殊连接方法也用于与网络设备通信，通常使用SSH上的CLI、SSH上的XML或HTTP(S)上的API。

本课程不对受管网络设备做过多说明，未来在工作当中需要用到时请查阅官方文档链接https://docs.ansible.com/ansible/latest/modules/list_of_network_modules.html。

2.5 安装Ansible

# 提供YUM源
mv /etc/yum.repos.d/* /opt/
curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-vault-8.5.2111.repo
sed -i -e '/mirrors.cloud.aliyuncs.com/d' -e '/mirrors.aliyuncs.com/d' /etc/yum.repos.d/CentOS-Base.repo
yum clean all
yum makecache
yum -y install centos-release-ansible-29

# 安装ansible
yum -y install ansible
ansible --version

# 通过使用setup模块验证localhost上的ansible_python_version
ansible -m setup localhost|grep ansible_python_version

1
2
3
4
5
6
7
8
9
10
11
12
13
14

02 部署Ansible

1. 构建Ansible清单

1.1 定义清单

清单定义Ansible将要管理的一批主机。这些主机也可以分配到组中，以进行集中管理。组可以包含子组，主机也可以是多个组的成员。清单还可以设置应用到它所定义的主机和组的变量。

可以通过两种方式定义主机清单。静态主机清单可以通过文本文件定义。动态主机清单可以根据需要使用外部信息提供程序通过脚本或其他程序来生成。

1.2 使用静态清单指定受管主机

静态清单文件是指定Ansible目标受管主机的文本文件。可以使用多种不同的格式编写此文件，包括INI样式或YAML。

在最简单的形式中。INI样式的静态清单文件是受管主机的主机名或IP地址的列表，每行一个：

alpha.example.org
beta.example.org
192.168.1.100

1
2
3

但通常而言，可以将受管主机组织为主机组。通过主机组，可以更加有效的对一系列系统运行Ansible。这时，每一部分的开头为以中括号括起来的主机组名称。其后为该组中每一受管主机的主机名或IP地址，每行一个。

[webservers]
alpha.example.org
beta.example.org
192.168.1.100

www[001:006].example.com

[dbservers]
db01.intranet.mydomain.net
db02.intranet.mydomain.net
10.25.1.56

db-[99:101]-node.example.com

1
2
3
4
5
6
7
8
9
10
11
12
13

1.3 验证清单

若有疑问，可使用 ansible 命令验证计算机是否存在于清单中：

[root@localhost ~]# ansible db-99-node.example.com --list-hosts
  hosts (1):
    db-99-node.example.com
[root@localhost ~]# ansible db-999-node.example.com --list-hosts
[WARNING]: Could not match supplied host pattern, ignoring: db-999-node.example.com
[WARNING]: No hosts matched, nothing to do
  hosts (0):

1
2
3
4
5
6
7

运行以下命令来列出指定组中的所有主机：

[root@localhost ~]# ansible webservers --list-hosts
  hosts (2):
    alpha.example.org
    beta.example.org
    192.168.1.100

1
2
3
4
5

如果清单中含有名称相同的主机和主机组，ansible 命令将显示警告并以主机作为其目标。主机组则被忽略。

应对这种情况的方法有多种，其中最简单的是确保主机组不使用与清单中主机相同的名称。

1.4 覆盖清单的位置

/etc/ansible/hosts文件被视为系统的默认静态清单文件。不过，通常的做法是不使用该文件，而是在Ansible配置文件中为清单文件定义一个不同的位置。

1.5 构建Ansible清单

修改默认清单文件**/etc/ansible/hosts**添加以下内容：

172.16.103.129

[webservers]
172.16.103.130

172.16.103.131

1
2
3
4
5
6

使用以下命令列出默认清单文件中的所有受管主机：

ansible all --list-hosts

1

使用以下命令列出不属于任何组的受管主机：

ansible ungrouped --list-hosts

1

使用以下命令列出属于某组的受管主机：

ansible webservers --list-hosts

1

1.6 自定义清单文件

在/etc/ansible/目录中，创建一个名为inventory的自定义静态清单文件。

服务器清单规格

编辑/etc/ansible/inventory文件，将上表中所列出的主机加入受管主机序列。

[root@localhost ~]# vim /etc/ansible/inventory
[webservers]
172.16.103.129 ansible_user=root ansible_password=your_pass
172.16.103.130 ansible_user=root ansible_password=your_pass

[db-servers]
172.16.103.131 ansible_user=root ansible_password=your_pass

1
2
3
4
5
6
7

执行以下命令列出所有受管主机：

ansible all -i /etc/ansible/inventory --list-hosts

1

执行以下命令列出webservers组中的所有受管主机：

ansible webservers -i /etc/ansible/inventory --list-hosts

1

2. 管理Ansible配置文件

2.1 配置Ansible

可以通过修改 Ansible 配置文件中的设置来自定义 Ansible安装的行为。Ansible从控制节点上多个可能的位置之一选择其配置文件。

使用/etc/ansible/ansible.cfg
ansible软件包提供一个基本的配置文件，它位于**/etc/ansible/ansible.cfg**。如果找不到其他配置文件，则使用此文件。

使用~/.ansible.cfg
Ansible在用户的家目录中查找**.ansible.cfg文件。如果存在此配置文件并且当前工作目录中也没有ansible.cfg文件，则使用此配置取代/etc/ansible/ansible.cfg**。

使用./ansible.cfg
如果执行ansible命令的目录中存在ansible.cfg文件，则使用它，而不使用全局文件或用户的个人文件。这样，管理员可以创建一种目录结构，将不同的环境或项目存储在单独的目录中，并且每个目录包含为独特的一组设置而定制的配置文件。

推荐的做法是在需要运行Ansible命令的目录中创建ansible.cfg文件。此目录中也将包含任何供Ansible项目使用的文件，如清单和playbook。这是用于Ansible配置文件的最常用位置。实践中不常使用**~/.ansible.cfg或/etc/ansible/ansible.cfg**文件

使用ANSIBLE_CONFIG环境变量
我们可以通过将不同的配置文件放在不同的目录中，然后从适当的目录执行Ansible命令，以此利用配置文件。但是，随着配置文件数量的增加，这种方法存在局限性并且难以管理。有一个更加灵活的选项，即通过ANSIBLE_CONFIG环境变量定义配置文件的位置。定义了此变量时，Ansible将使用变量所指定的配置文件，而不用上面提到的任何配置文件。

2.2 配置文件优先级

ANSIBLE_CONFIG环境变量指定的任何文件将覆盖所有其他配置文件。如果没有设置该变量，则接下来检查运行ansible命令的目录中是否有ansible.cfg文件。如果不存在该文件，则检查用户的家目录是否有**.ansible.cfg文件。只有在找不到其他配置文件时，才使用全局/etc/ansible/ansible.cfg文件。如果/etc/ansible/ansible.cfg**配置文件不存在，Ansible包含它使用的默认值。

由于Ansible配置文件可以放入的位置有多种，因此Ansible当前使用哪一个配置文件可能会令人困惑。我们可以运行以下命令来清楚地确认所安装的Ansible版本以及正在使用的配置文件。

ansible --version

1

Ansible仅使用具有最高优先级的配置文件中的设置。即使存在优先级较低的其他配置文件，其设置也会被忽略，不会与选定配置文件中的设置结合。因此，如果你选择自行创建配置文件来取代全局**/etc/ansible/ansible.cfg**配置文件，就需要将该文件中所有需要的设置复制到自己的用户级配置文件中。用户组配置文件中未定义的设置将保持设为内置默认值，即使已在全局配置文件中设为某个其他值也是如此。

2.3 管理配置文件中的设置

Ansible配置文件由几个部分组成，每一部分含有以键值对形式定义的设置。部分的标题以中括号括起来。对于基本操作，请使用以下两部分：

• [defaults]部分设置Ansible操作的默认值
• [privilege_escalation]配置Ansible如何在受管主机上执行特权升级

例如，下面是典型的ansible.cfg文件：

[defaults]
inventory = ./inventory
remote_user = user
ask_pass = false

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = false

1
2
3
4
5
6
7
8
9
10

下表说明了此文件中的指令：
Ansible配置

2.4 配置连接

Ansible需要知道如何与其受管主机通信。更改配置文件的一个最常见原因是为了控制Ansible使用什么方法和用户来管理受管主机。需要的一些信息包括：

• 列出受管主机和主机组的清单的位置
• 要使用哪一种连接协议来与受管主机通信（默认为SSH），以及是否需要非标准网络端口来连接服务器
• 要在受管主机上使用哪一远程用户；这可以是root用户或者某一非特权用户
• 如果远程用户为非特权用户，Ansible需要知道它是否应尝试将特权升级为root以及如何进行升级（例如，通过sudo）
• 是否提示输入SSH密码或sudo密码以进行登录或获取特权

2.4.1 清单位置

[defaults]
inventory = ./inventory

1
2

2.4.2 连接设置

【defaults]
inventory = ./inventory

remote_user = root
ask_pass = true

1
2
3
4
5

2.4.3 升级特权

[defaults]
inventory = ./inventory
remote_user = someuser
ask_pass = false

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = false

1
2
3
4
5
6
7
8
9
10

2.4.4 非SSH连接

ansible localhost --list-hosts

1

2.5 配置文件注释

Ansible配置文件允许使用两种注释字符：井号或分号。

位于行开头的#号会注释掉整行。它不能和指令位于同一行中。

分号字符可以注释掉所在行中其右侧的所有内容。它可以和指令位于同一行中，只要该指令在其左侧。

3. 运行临时命令

使用临时命令可以快速执行单个Ansible任务，不需要将它保存下来供以后再次运行。它们是简单的在线操作，无需编写playbook即可运行。

临时命令对快速测试和更改很有用。例如，可以使用临时命令确保一组服务器上的**/etc/hosts**文件中存在某一特定的行。可以使用另一个临时命令在许多不同的计算机上高效的重启服务，或者确保特定的软件包为最新版本。

临时命令对于通过Ansible快速执行简单的任务非常有用。它们确实也存在局限，而且总体而言，要使用Ansible Playbook来充分发挥Ansible的作用。但在许多情形中，临时命令正是快速执行简单任务所需要的工具。

3.1 运行临时命令

Ansible运行临时命令的语法如下：

ansible host-pattern -m module [-a 'module arguments'] [-i inventory]

1

host-pattern参数用于指定在其上运行临时命令的受管主机。它可以是清单中的特定受管主机或主机组。也可以用后面的-i选项指定特定的清单而不使用默认清单。

-m选项将Ansible应在目标主机上运行的module名称作为参数。模块是为了实施任务而执行的小程序。一些模块不需要额外的信息，但其他模块需要使用额外的参数来指定其操作详情。-a选项以带引号字符串形式取这些参数的列表。

一种最简单的临时命令使用ping模块。此模块不执行ICMP ping，而是检查能否在受管主机上运行基于Python的模块。例如，以下临时命令确定清单中的所有受管主机能否运行标准的模块：

[root@localhost ~]# ansible all -m ping
172.16.103.131 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}
......

1
2
3
4
5
6
7
8
9

3.2 使用临时命令通过模块来执行任务

模块是临时命令用于完成任务的工具。Ansible提供了数百个能够完成不同任务的模块。通常我们可以查找一个经过测试的专用模块，作为标准安装的一部分来完成所需的任务。

ansible-doc -l命令可以列出系统上安装的所有模块。可以使用ansible-doc来按照名称查看特定模块的帮助文档，再查找关于模块将取什么参数作为选项的信息。例如以下命令显示ping模块的帮助文档，在帮助文档里面输入**q**命令表示退出：

ansible-doc ping

1

更多的模块信息请访问在线Ansible文档，网址：https://docs.ansible.com/ansible/latest/modules/modules_by_category.html。

Ansible常用模块

大部分模块会取用参数。可在模块的文档中找到可用于该模块的参数列表。临时命令可以通过-a选项向模块传递参数。无需参数时，可从临时命令中省略-a选项。如果需要指定多个参数，请以引号括起的空格分隔列表形式提供。

例如，以下临时命令使用user模块来确保runtime用户存在于172.16.103.129上并且其UID为4000：

ansible 172.16.103.129 -m user -a 'name=runtime uid=4000 state=present'

1

大多数模块为idempotent，这表示它们可以安全地多次运行；如果系统已处于正确的状态，它们不会进行任何操作。

3.3 在受管主机上运行任意命令

command模块允许管理员在受管主机的命令行中运行任意命令。要运行的命令通过-a选项指定为该模块的参数。例如，以下命令将对webservers组的受管主机运行hostname命令：

[root@localhost ~]# ansible webservers -m command -a 'hostname'
172.16.103.130 | CHANGED | rc=0 >>
node03-linux.example.com
172.16.103.129 | CHANGED | rc=0 >>
node02-linux.example.com

1
2
3
4
5

这条命令为每个受管主机返回两行输出。第一行是状态报告，显示对其运行临时操作的受管主机名称及操作的结果。第二行是使用Ansible command模块远程执行的命令的输出。

若要改善临时命令输出的可读性和解析，管理员可能会发现使对受管主机执行的每一项操作具有单行输出十分有用。使用-o选项以单行格式显示Ansible临时命令的输出。

[root@localhost ~]# ansible webservers -m command -a 'hostname' -o
172.16.103.130 | CHANGED | rc=0 | (stdout) node03-linux.example.com
172.16.103.129 | CHANGED | rc=0 | (stdout) node02-linux.example.com

1
2
3

command模块允许管理员对受管主机快速执行远程命令。这些命令不是由受管主机上的shell加以处理。因此，它们无法访问shell环境变量，也不能执行重定向和管道等shell操作。

在命令需要shell处理的情形中，管理员可以使用shell模块。与command模块类似，可以在临时命令中将要执行的命令作为参数传递给该模块。Ansible随后对受管主机远程执行该命令。与command模块不同的是，这些命令将通过受管主机上的shell进行处理。因此，可以访问shell环境变量，也可以使用重定向和管道等操作。

以下示例演示了command与shell的区别。如果尝试使用这两个模块执行内建的Bash命令set，只有使用shell模块才会成功：

[root@localhost ~]# ansible 172.16.103.129 -m command -a 'set'
172.16.103.129 | FAILED | rc=2 >>
[Errno 2] No such file or directory

[root@localhost ~]# ansible 172.16.103.129 -m shell -a 'set'
172.16.103.129 | CHANGED | rc=0 >>
BASH=/bin/sh
BASHOPTS=cmdhist:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=()
BASH_ARGC=()
BASH_ARGV=()
......

1
2
3
4
5
6
7
8
9
10
11
12

command和shell模块都要求受管主机上安装正常工作的Python。第三个模块是raw，它可以绕过模块子系统，直接使用远程shell运行命令。在管理无法安装Python的系统（如网络路由器）时，可以利用这个模块。它也可以用于将Python安装到主机上。

在大多数情况下，建议避免使用command、shell和raw这三个“运行命令”模块。

其他模块大部分都是幂等的，可以自动进行更改跟踪。它们可以测试系统的状态，在这些系统已处于正确状态时不执行任何操作。相反，以幂等方式使用“运行命令”模块要复杂得多。依靠它们，你更难以确信再次运行临时命令或playbook不会造成意外的失败。当shell或command模块运行时，通常会基于它是否认为影响了计算机状态而报告CHANGED状态。

有时候，“运行命令”模块是有用的工具，也是解决问题的好办法。如果确实需要使用它们，可能最好先尝试用command模块，只有在需要shell或raw模块的特殊功能时才利用它们。

3.4 配置临时命令的连接

受管主机连接和特权升级的指令可以在Ansible配置文件中配置，也可以使用临时命令中的选项来定义。使用临时命令中的选项定义时，它们将优先于Ansible配置文件中配置的指令。下表显示了与各项配置文件指令类同的命令行选项。

Ansible命令行选项

在使用命令行选项配置这些指令前，可以通过查询ansible --help的输出来确定其当前定义的值。

ansible --help

1

03 ansible常用模块

1. ansible常用模块使用详解

ansible常用模块有：

• ping
• yum
• template
• copy
• user
• group
• service
• raw
• command
• shell
• script

ansible常用模块raw、command、shell的区别：

• shell模块调用的/bin/sh指令执行
• command模块不是调用的shell的指令，所以没有bash的环境变量
• raw很多地方和shell类似，更多的地方建议使用shell和command模块。但是如果是使用老版本python，需要用到raw，又或者是客户端是路由器，因为没有安装python模块，那就需要使用raw模块了

2. ansible常用模块之ping

ping模块用于检查指定节点机器是否连通，用法很简单，不涉及参数，主机如果在线，则回复pong

[root@ansible ~]# ansible all -m ping
172.16.103.129 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

1
2
3
4
5

3. ansible常用模块之command

command模块用于在远程主机上执行命令，ansible默认就是使用command模块。

command模块有一个缺陷就是不能使用管道符和重定向功能。

//查看受控主机的/tmp目录内容
[root@ansible ~]# ansible 172.16.103.129 -a 'ls /tmp'
172.16.103.129 | SUCCESS | rc=0 >>
ansible_Xs1oym
systemd-private-fa034beb13644acfb2aadc35bfe64d46-chronyd.service-cVTNsE
systemd-private-fa034beb13644acfb2aadc35bfe64d46-vgauthd.service-XAgkCm
systemd-private-fa034beb13644acfb2aadc35bfe64d46-vmtoolsd.service-rwqet5

//在受控主机的/tmp目录下新建一个文件test
[root@ansible ~]# ansible 172.16.103.129 -a 'touch /tmp/test'
 [WARNING]: Consider using the file module with state=touch rather than running touch.  If you need to use command because
file is insufficient you can add warn=False to this command task or set command_warnings=False in ansible.cfg to get rid
of this message.

172.16.103.129 | SUCCESS | rc=0 >>


[root@ansible ~]# ansible 172.16.103.129 -a 'ls /tmp'
172.16.103.129 | SUCCESS | rc=0 >>
ansible_7YD229
systemd-private-fa034beb13644acfb2aadc35bfe64d46-chronyd.service-cVTNsE
systemd-private-fa034beb13644acfb2aadc35bfe64d46-vgauthd.service-XAgkCm
systemd-private-fa034beb13644acfb2aadc35bfe64d46-vmtoolsd.service-rwqet5
test


//command模块不支持管道符，不支持重定向
[root@ansible ~]# ansible 172.16.103.129 -a "echo 'hello world' > /tmp/test"
172.16.103.129 | SUCCESS | rc=0 >>
hello world > /tmp/test

[root@ansible ~]# ansible 172.16.103.129 -a 'cat /tmp/test'
172.16.103.129 | SUCCESS | rc=0 >>

[root@ansible ~]# ansible 172.16.103.129 -a 'ps -ef|grep vsftpd'
172.16.103.129 | FAILED | rc=1 >>
error: unsupported SysV option

Usage:
 ps [options]

 Try 'ps --help <simple|list|output|threads|misc|all>'
  or 'ps --help <s|l|o|t|m|a>'
 for additional help text.

For more details see ps(1).non-zero return code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

4. ansible常用模块之raw

raw模块用于在远程主机上执行命令，其支持管道符与重定向

//支持重定向
[root@ansible ~]# ansible 172.16.103.129 -m raw -a 'echo "hello world" > /tmp/test'
172.16.103.129 | SUCCESS | rc=0 >>
Shared connection to 172.16.103.129 closed.


[root@ansible ~]# ansible 172.16.103.129 -a 'cat /tmp/test'
172.16.103.129 | SUCCESS | rc=0 >>
hello world


//支持管道符
[root@ansible ~]# ansible 172.16.103.129 -m raw -a 'cat /tmp/test|grep -Eo hello'
172.16.103.129 | SUCCESS | rc=0 >>
hello
Shared connection to 172.16.103.129 closed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

5. ansible常用模块之shell

shell模块用于在受控机上执行受控机上的脚本，亦可直接在受控机上执行命令。
shell模块亦支持管道与重定向。

//查看受控机上的脚本
[root@localhost ~]# ll /scripts/
总用量 4
-rwxr-xr-x 1 root root 52 9月   7 22:49 test.sh


//使用shell模块在受控机上执行受控机上的脚本
[root@ansible ~]# ansible 172.16.103.129 -m shell -a '/bin/bash /scripts/test.sh &> /tmp/test'
172.16.103.129 | SUCCESS | rc=0 >>


[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'cat /tmp/test'
172.16.103.129 | SUCCESS | rc=0 >>
1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

6. ansible常用模块之script

script模块用于在受控机上执行主控机上的脚本

[root@ansible ~]# ll /etc/ansible/scripts/
总用量 4
-rw-r--r--. 1 root root 61 9月   8 18:59 a.sh
[root@ansible ~]# ansible 172.16.103.129 -m script -a '/etc/ansible/scripts/a.sh &>/tmp/a'
172.16.103.129 | SUCCESS => {
    "changed": true,
    "rc": 0,
    "stderr": "Shared connection to 172.16.103.129 closed.\r\n",
    "stderr_lines": [
        "Shared connection to 172.16.103.129 closed."
    ],
    "stdout": "",
    "stdout_lines": []
}


//查看受控机上的/tmp/a文件内容
[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'cat /tmp/a'
172.16.103.129 | SUCCESS | rc=0 >>
root:x:0:0:root:/root:/bin/bash
....此处省略N行
jerry:x:1000:1000::/home/jerry:/bin/bash

//由此可见确是在受控机上执行了主控机上的脚本，且输出记录到了受控机上。因为此处 \
//的jerry用户是在受控机上才有的用户

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

7. ansible常用模块之template

template模块用于生成一个模板，并可将其传输至远程主机上。

//下载一个163的yum源文件并开启此源
[root@ansible ~]# cd /etc/yum.repos.d/
[root@ansible yum.repos.d]# curl -o CentOS7-Base-163.repo http://mirrors.163.com/.help/CentOS7-Base-163.repo
[root@localhost ~]# sed -i 's/\$releasever/7/g' /etc/yum.repos.d/CentOS7-Base-163.repo
[root@localhost ~]# sed -i 's/^enabled=.*/enabled=1/g' /etc/yum.repos.d/CentOS7-Base-163.repo

//将设置好的163源传到受控主机
[root@ansible ~]# ansible 172.16.103.129 -m template -a 'src=/etc/yum.repos.d/CentOS7-Base-163.repo dest=/etc/yum.repos.d/163.repo'
172.16.103.129 | SUCCESS => {
    "changed": true,
    "checksum": "60b8868e0599489038710c45025fc11cbccf35f2",
    "dest": "/etc/yum.repos.d/163.repo",
    "gid": 0,
    "group": "root",
    "md5sum": "5a3e688854d9ceccf327b953dab55b21",
    "mode": "0644",
    "owner": "root",
    "size": 1462,
    "src": "/root/.ansible/tmp/ansible-tmp-1536311319.27-78101453778196/source",
    "state": "file",
    "uid": 0
}

//查看受控机上是否有163源
[root@localhost ~]# ls /etc/yum.repos.d/
163.repo

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

8. ansible常用模块之yum

yum模块用于在指定节点机器上通过yum管理软件，其支持的参数主要有两个

• name：要管理的包名
• state：要进行的操作

state常用的值：

• latest：安装软件
• installed：安装软件
• present：安装软件
• removed：卸载软件
• absent：卸载软件

若想使用yum来管理软件，请确保受控机上的yum源无异常。

//在受控机上查询看vsftpd软件是否安装
[root@localhost ~]# rpm -qa|grep vsftpd
[root@localhost ~]#


//在ansible主机上使用yum模块在受控机上安装vsftpd
[root@ansible ~]# ansible 172.16.103.129 -m yum -a 'name=vsftpd state=present'
172.16.103.129 | SUCCESS => {
    "changed": true,
    "msg": "warning: /var/cache/yum/x86_64/7Server/base/packages/vsftpd-3.0.2-22.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY\nImporting GPG key 0xF4A80EB5:\n Userid     : \"CentOS-7 Key (CentOS 7 Official Signing Key) <security@centos.org>\"\n Fingerprint: 6341 ab27 53d7 8a78 a7c2 7bb1 24c6 a8a7 f4a8 0eb5\n From       : http://mirrors.163.com/centos/RPM-GPG-KEY-CentOS-7\n",
    "rc": 0,
    "results": [
        "Loaded plugins: product-id, search-disabled-repos, subscription-manager\nThis system is not registered with an entitlement server. You can use subscription-manager to register.\nResolving Dependencies\n--> Running transaction check\n---> Package vsftpd.x86_64 0:3.0.2-22.el7 will be installed\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n================================================================================\n Package          Arch             Version                 Repository      Size\n================================================================================\nInstalling:\n vsftpd           x86_64           3.0.2-22.el7            base           169 k\n\nTransaction Summary\n================================================================================\nInstall  1 Package\n\nTotal download size: 169 k\nInstalled size: 348 k\nDownloading packages:\nPublic key for vsftpd-3.0.2-22.el7.x86_64.rpm is not installed\nRetrieving key from http://mirrors.163.com/centos/RPM-GPG-KEY-CentOS-7\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Installing : vsftpd-3.0.2-22.el7.x86_64                                   1/1 \n  Verifying  : vsftpd-3.0.2-22.el7.x86_64                                   1/1 \n\nInstalled:\n  vsftpd.x86_64 0:3.0.2-22.el7                                                  \n\nComplete!\n"
    ]
}


//查看受控机上是否安装了vsftpd
[root@localhost ~]# rpm -qa|grep vsftpd
vsftpd-3.0.2-22.el7.x86_64

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

9. ansible常用模块之copy

copy模块用于复制文件至远程受控机。

[root@ansible ~]# ls /etc/ansible/scripts/
a.sh
[root@ansible ~]# ansible 172.16.103.129 -m copy -a 'src=/etc/ansible/scripts/a.sh dest=/scripts/'
172.16.103.129 | SUCCESS => {
    "changed": true,
    "checksum": "83f66f804c195247885b013912cf9dc649f36391",
    "dest": "/scripts/a.sh",
    "gid": 0,
    "group": "root",
    "md5sum": "a63e880a932bba1160f329836cbfd730",
    "mode": "0644",
    "owner": "root",
    "size": 61,
    "src": "/root/.ansible/tmp/ansible-tmp-1536406467.26-35192956264311/source",
    "state": "file",
    "uid": 0
}


[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'ls /scripts/'
172.16.103.129 | SUCCESS | rc=0 >>
a.sh
test.sh

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

10. ansible常用模块之group

group模块用于在受控机上添加或删除组。

//在受控机上添加一个系统组，其gid为306，组名为mysql
[root@ansible ~]# ansible 172.16.103.129 -m group -a 'name=mysql gid=306 state=present'
172.16.103.129 | SUCCESS => {
    "changed": true,
    "gid": 306,
    "name": "mysql",
    "state": "present",
    "system": false
}
[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'grep mysql /etc/group'
172.16.103.129 | SUCCESS | rc=0 >>
mysql:x:306:


//删除受控机上的mysql组
[root@ansible ~]# ansible 172.16.103.129 -m group -a 'name=mysql state=absent'
172.16.103.129 | SUCCESS => {
    "changed": true,
    "name": "mysql",
    "state": "absent"
}
[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'grep mysql /etc/group'
172.16.103.129 | FAILED | rc=1 >>
non-zero return code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

11. ansible常用模块之user

user模块用于管理受控机的用户帐号。

//在受控机上添加一个系统用户，用户名为mysql，uid为306，设置其shell为/sbin/nologin，无家目录
[root@ansible ~]# ansible 172.16.103.129 -m user -a 'name=mysql uid=306 system=yes create_home=no shell=/sbin/nologin state=present'
172.16.103.129 | SUCCESS => {
    "changed": true,
    "comment": "",
    "create_home": false,
    "group": 306,
    "home": "/home/mysql",
    "name": "mysql",
    "shell": "/sbin/nologin",
    "state": "present",
    "system": true,
    "uid": 306
}
[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'grep mysql /etc/passwd'
172.16.103.129 | SUCCESS | rc=0 >>
mysql:x:306:306::/home/mysql:/sbin/nologin

[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'ls /home'
172.16.103.129 | SUCCESS | rc=0 >>
jerry


//修改mysql用户的uid为366
[root@ansible ~]# ansible 172.16.103.129 -m user -a 'name=mysql uid=366'
172.16.103.129 | SUCCESS => {
    "append": false,
    "changed": true,
    "comment": "",
    "group": 306,
    "home": "/home/mysql",
    "move_home": false,
    "name": "mysql",
    "shell": "/sbin/nologin",
    "state": "present",
    "uid": 366
}
[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'grep mysql /etc/passwd'
172.16.103.129 | SUCCESS | rc=0 >>
mysql:x:366:306::/home/mysql:/sbin/nologin


//删除受控机上的mysql用户
[root@ansible ~]# ansible 172.16.103.129 -m user -a 'name=mysql state=absent'
172.16.103.129 | SUCCESS => {
    "changed": true,
    "force": false,
    "name": "mysql",
    "remove": false,
    "state": "absent"
}
[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'grep mysql /etc/passwd'
172.16.103.129 | FAILED | rc=1 >>
non-zero return code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

12. ansible常用模块之service

service模块用于管理受控机上的服务。

//查看受控机上的vsftpd服务是否启动
[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'systemctl is-active vsftpd'
172.16.103.129 | FAILED | rc=3 >>
unknownnon-zero return code

//启动受控机上的vsftpd服务
[root@ansible ~]# ansible 172.16.103.129 -m service -a 'name=vsftpd state=started'
172.16.103.129 | SUCCESS => {
    "changed": true,
    "name": "vsftpd",
    "state": "started",
    "status": {
        "ActiveEnterTimestampMonotonic": "0",
        ....此处省略N行
}

//查看受控机上的vsftpd服务是否启动
[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'systemctl is-active vsftpd'
172.16.103.129 | SUCCESS | rc=0 >>
active


//查看受控机上的vsftpd服务是否开机自动启动
[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'systemctl is-enabled vsftpd'
172.16.103.129 | FAILED | rc=1 >>
disablednon-zero return code

//设置受控机上的vsftpd服务开机自动启动
[root@ansible ~]# ansible 172.16.103.129 -m service -a 'name=vsftpd enabled=yes'
172.16.103.129 | SUCCESS => {
    "changed": true,
    "enabled": true,
    "name": "vsftpd",
    "status": {
        "ActiveEnterTimestamp": "六 2018-09-08 00:02:39 EDT",
        ....此处省略N行
}

//查看受控机上的vsftpd服务是否开机自动启动
[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'systemctl is-enabled vsftpd'
172.16.103.129 | SUCCESS | rc=0 >>
enabled


//停止受控机上的vsftpd服务
[root@ansible ~]# ansible 172.16.103.129 -m service -a 'name=vsftpd state=stopped'
172.16.103.129 | SUCCESS => {
    "changed": true,
    "name": "vsftpd",
    "state": "stopped",
    "status": {
        "ActiveEnterTimestamp": "六 2018-09-08 00:02:39 EDT",
        ....此处省略N行
}
[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'systemctl is-active vsftpd'
172.16.103.129 | FAILED | rc=3 >>
inactivenon-zero return code

[root@ansible ~]# ansible 172.16.103.129 -m shell -a 'ss -antl'
172.16.103.129 | SUCCESS | rc=0 >>
State      Recv-Q Send-Q Local Address:Port               Peer Address:Port
LISTEN     0      128          *:22                       *:*
LISTEN     0      100    127.0.0.1:25                       *:*
LISTEN     0      128         :::22                      :::*
LISTEN     0      100        ::1:25                      :::*

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

04 playbook

1. 实施playbook

1.1 Ansible Playbook与临时命令

临时命令可以作为一次性命令对一组目标主机运行一项简单的任务。不过，若要真正发挥Ansible的力量，需要了解如何使用playbook以便轻松重复的方式对一组目标主机执行多项复杂的任务。

play是针对清单中选定的主机运行的一组有序任务。playbook是一个文本文件，其中包含由一个或多个按特定顺序运行的play组成的列表。

Play可以将一系列冗长而复杂的手动管理任务转变为可轻松重复的例程，并且具有可预测的成功成果。在playbook中，可以将play内的任务序列保存为人类可读并可立即运行的形式。根据任务的编写方式，任务本身记录了部署应用或基础架构所需的步骤。

1.2 格式化Ansible Playbook

前面我们学习了临时命令模块，下面以一条命令做为案例来讲解下其在playbook中是如何编写的。

ansible 172.16.103.129 -m user -a 'name=runtime uid=4000 state=present'

1

这个任务可以将其编写为一个单任务的play并保存在playbook中。生成的playbook如下方所示：

---
- name: Configure important user consistently
  hosts: 172.16.103.129
  task:
    - name: runtime exists with UID 4000
      user:
        name: runtime
        uid: 4000
        state: present

1
2
3
4
5
6
7
8
9

Playbook是以YAML格式编写的文本文件，通常使用扩展名yml保存。Playbook使用空格字符缩进来表示其数据结构。YAML对用于缩进的空格数量没有严格的要求，但有两个基本的规则：

• 处于层次结构中同一级别的数据元素（例如同一列表中的项目）必须具有相同的缩进量。
• 如果项目属于其他项目的子项，其缩进量必须大于父项

只有空格字符可用于缩进，不允许使用tab键。约定俗成的缩进量一般是一级2个空格。

Playbook开头的一行由三个破折号（—）组成，这是文档开始标记。其末尾可能使用三个圆点（…）作为文档结束标记，尽管在实践中这通常会省略。

在这两个标记之间，会以一个play列表的形式来定义playbook。YAML列表中的项目以一个破折号加空格开头。例如，YAML列表可能显示如下：

- apple
- orange
- grape

1
2
3

Play本身是一个键值对集合。同一play中的键应当使用相同的缩进量。以下示例显示了具有三个键的YAML代码片段。前两个键具有简单的值。第三个将含有三个项目的列表作为值。

- name: just an example
  hosts: webservers
  tasks:
    - first
    - second
    - third

1
2
3
4
5
6

作为play中的一部分，tasks属性按顺序实际列出要在受管主机上运行的任务。列表中各项任务本身是一个键值对集合。

还以上面创建用户的play为例，play中唯一任务有两个键：

• name是记录任务用途的可选标签。最好命名所有的任务，从而帮助记录自动流程中的每一步用途。
• user是要为这个任务运行的模块。其参数作为一组键值对传递，它们是模块的子项（name、uid和state）。

下面再来看一个含有多项任务的tasks属性案例：

tasks:
  - name: web server is enabled
    service:
      name: httpd
      enabled: true
      
  - name: NTP server is enabled
    service:
      name: chronyd
      enabled: true
      
  - name: Postfix is enabled
    service:
      name: postfix
      enabled: true

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

playbook中play和任务列出的顺序很重要，因为Ansible会按照相同的顺序运行它们。

1.3 运行playbook

absible-playbook命令可用于运行playbook。该命令在控制节点上执行，要运行的playbook的名称则作为参数传递。

ansible-playbook site.yml

1

在运行playbook时，将生成输出来显示所执行的play和任务。输出中也会报告执行的每一项任务的结果。

以下示例中显示了一个简单的playbook的内容，后面是运行它的结果。

[root@localhost ~]# mkdir playdemo
[root@localhost ~]# cd playdemo/
[root@localhost playdemo]# vim webserver.yml
---
- name: play to setup web server
  hosts: webservers
  tasks:
  - name: latest httpd version installed
    yum:
      name: httpd
      state: latest
      
  - name: service is enabled
    service:
      name: httpd
      enabled: true
      
[root@localhost playdemo]# ansible-playbook webserver.yml 
PLAY [play to setup web server] *****************************************************

TASK [Gathering Facts] **************************************************************
ok: [172.16.103.129]
ok: [172.16.103.130]

TASK [latest httpd version installed] ***********************************************
ok: [172.16.103.129]
ok: [172.16.103.130]

TASK [service is enabled] ***********************************************************
changed: [172.16.103.129]
changed: [172.16.103.130]

PLAY RECAP **************************************************************************
172.16.103.129             : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
172.16.103.130             : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

请注意，在playbook运行时，屏幕中会显示每个play和任务的name键的值。（Gathering Facts任务是一项特别的任务，setup模块通常在play启动时自动运行这项任务。）对于含有多个play和任务的playbook，设置name属性后可以更加轻松地监控playbook执行的进展。

通常而言，Ansible Playbook中的任务是幂等的，而且能够安全地多次运行playbook。如果目标受管主机已处于正确的状态，则不应进行任何更改。如果再次运行这个playbook，所有任务都会以状态OK传递，且不报告任何更改。

1.4 提高输出的详细程度

ansible-playbook命令提供的默认输出不提供详细的任务执行信息。ansible-playbook -v命令提供了额外的信息，总共有四个级别。

配置Playbook执行的输出详细程序

1.5 语法验证

在执行playbook之前，最好要进行验证，确保其内容的语法正确无误。ansible-playbook命令提供了一个–syntax-check选项，可用于验证playbook的语法。

下例演示了一个playbook成功通过语法验证：

[root@localhost playdemo]# ansible-playbook --syntax-check webserver.yml
playbook: webserver.yml

1
2

语法验证失败时，将报告语法错误。输出中包含语法问题在playbook中的大致位置。

下例演示了一个playbook语法验证失败的情况：

[root@localhost playdemo]# ansible-playbook --syntax-check webserver.yml
Syntax Error while loading YAML.
  did not find expected '-' indicator

The error appears to be in '/root/playdemo/webserver.yml': line 3, column 1, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

- name: play to setup web server
hosts: webservers
^ here

1
2
3
4
5
6
7
8
9
10
11
12

1.6 执行空运行

可以使用-C选项对playbook执行空运行。这会使Ansible报告在执行该playbook时将会发生什么更改，但不会对受管主机进行任何实际的更改。

下例演示了一个playbook的空运行，它包含单项任务，可确保在受管主机上安装了最新版本的httpd软件包。注意该空运行报告此任务会对受管主机产生的更改。

ansible-playbook -C webserver.yml 

1

2. 实施多个play

2.1 缩写多个play

Playbook是一个YAML文件，含有由一个或多个play组成的列表。记住一个play按顺序列出了要对清单中的选定主机执行的任务。因此，如果一个playbook中有多个play，每个play可以将其任务应用到单独的一组主机。

在编排可能涉及对不同主机执行不同任务的复杂部署时，这会大有帮助。我们可以这样进行编写：对一组主机运行一个play，完成后再对另一组主机运行另一个play。

缩写包含多个play的playbook非常简单。Playbook中的各个play编写为playbook中的顶级列表项。各个play是含有常用play关键字的列表项。

以下示例显示了含有两个play的简单playbook。第一个play针对172.16.103.129运行，第二个play则针对172.16.103.131运行。

---
# This is a simple playbook with two plays

- name: first play
  hosts: 172.16.103.129
  tasks:
    - name: first task
      yum:
        name: httpd
        status: present

    - name: second task
      service:
        name: httpd
        enabled: true

- name: second play
  hosts: 172.16.103.131
  tasks:
    - name: first task
      service:
        name: mariadb
        enabled: true

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

2.2 play中的远程用户和特权升级

Play可以将不同的远程用户或特权升级设置用于play，取代配置文件中指定的默认设置。这些在play本身中与hosts或tasks关键字相同的级别上设置。

2.2.1 用户属性

remote_user: remoteuser

1

2.2.2 特权升级属性

become: true

1

become_method: sudo

1

become_user: privileged_user

1

- name: /etc/hosts is up to date
  hosts: 172.16.103.129
  remote_user: automation
  become: yes
  
  tasks:
    - name: 172.16.103.129 in /etc/hosts
      lineinfile:
        path: /etc/hosts
        line: '172.16.103.129 web1.example.com'
        state: present

1
2
3
4
5
6
7
8
9
10
11

2.3 查找用于任务的模块

2.3.1 模块文档

ansible-doc -l

1

ansible-doc yum     # 显示yum模块的帮助文档

1

ansible-doc -s yum

1

- name: Non-idepotent approach with shell module
  shell: echo "nameserver 172.16.103.2" > /etc/resolv.conf

1
2

- name: Idempotent approach with copy module
  copy:
    dest: /etc/resolv.conf
    content: "nameserver 172.16.103.2\n"

1
2
3
4

2.3.2 Playbook语法变化

# This is a YAML comment
some data # This is also a YAML comment

1
2

this is a string

'this is another string'

"this is yet another a string"

1
2
3
4
5

include_newlines: |
  Example Company
  123 Main Street
  Atlanta, GA 30303

1
2
3
4

fold_newlines: >
  This is an example
  of a long string,
  that will become
  a single sentence once folded.

1
2
3
4
5

name: svcrole
svcservice: httpd
svcport: 80

1
2
3

{name: svcrole, svcservice: httpd, svcport: 80}

1

hosts:
  - servera
  - serverb
  - serverc

1
2
3
4

hosts: [servera, serverb, serverc]

1

2.3.3 过时的“键=值” playbook简写

tasks:
  - name: shorthand form
    service: name=httpd enabled=true state=started

1
2
3

tasks:
  - name: normal form
    service:
      name: httpd
      enabled: true
      state: started

1
2
3
4
5
6

05 管理变量、机密和事实

1. 管理变量

1.1 Ansible变量简介

Ansible支持利用变量来存储值，并在Ansible项目的所有文件中重复使用这些值。这可以简化项目的创建和维护，并减少错误的数量。

通过变量，可以轻松地在Ansible项目中管理给定环境的动态值。例如，变量可能包含下面这些值：

• 要创建的用户
• 要安装的软件包
• 要重新启动的服务
• 要删除的文件
• 要从互联网检索的存档

1.1.1 命名变量

1.1.2 定义变量

1.2 playbook中的变量

变量在Ansible Playbook中发挥着重要作用，因为它们可以简化playbook中变量数据的管理。

1.2.1 在Playbook中定义变量

- hosts: all
  vars:
    user: joe
    home: /home/joe

1
2
3
4

- hosts: all
  vars_files:
    - vars/users.yml

1
2
3

user: joe
home: /home/joe

1
2

1.2.2 在Playbook中使用变量

vars:
  user: joe
  
tasks:
  # This line will read: Creates the user joe
  - name: Creates the user {{ user }}
    user:
      # This line will create the user named joe
      name: "{{ user }}"

1
2
3
4
5
6
7
8
9

1.3 主机变量和组变量

直接应用于主机的清单变量分为两在类：

• 主机变量，应用于特定主机
• 组管理，应用于一个主机组或一组主机组中的所有主机

主机变量优先于组变量，但playbook中定义的变量的优先级比这两者更高。

若要定义主机变量和组变量，一种方法是直接在清单文件中定义。这是较旧的做法，不建议采用，但你可能会在未来的工作当中遇到。

定义172.16.103.129的ansible_user主机变量：

[servers]
172.16.103.129 ansible_user=joe

1
2

定义servers主机组的user组变量：

[servers]
172.16.103.129
172.16.103.130

[servers:vars]
user=joe

1
2
3
4
5
6

定义servers组的user组变量，该组由两个主机组成，每个主机组有两个服务器：

[servers1]
node1.example.com
node2.example.com

[servers2]
node3.example.com
node4.example.com

[servers:children]
servers1
servers2

[servers:vars]
user=joe

1
2
3
4
5
6
7
8
9
10
11
12
13
14

此做法存在一些缺点，它使得清单文件更难以处理，在同一文件中混合提供了主机和变量信息，而且采用的也是过时的语法。

1.3.1 使用目录填充主机和组变量

user: joe

1

[root@localhost ~]# mkdir ~/project
[root@localhost ~]# vim ~/project/inventory
[datacenter1]
node1.example.com
node2.example.com

[datacenter2]
node3.example.com
node4.example.com

[datacenters:children]
datacenter1
datacenter2

1
2
3
4
5
6
7
8
9
10
11
12
13

[root@localhost ~]# mkdir ~/project/groupo_vars
[root@localhost ~]# vim ~/project/groupo_vars/datacenters
package: httpd

1
2
3

[root@localhost ~]# vim ~/project/groupo_vars/datacenter1
package: httpd
[root@localhost ~]# vim ~/project/groupo_vars/datacenter2
package: apache2

1
2
3
4

[root@localhost ~]# mkdir ~/project/host_vars
[root@localhost ~]# vim ~/project/host_vars/node1.example.com
package: httpd
[root@localhost ~]# vim ~/project/host_vars/node2.example.com
package: apache2
[root@localhost ~]# vim ~/project/host_vars/node3.example.com
package: mariadb-server
[root@localhost ~]# vim ~/project/host_vars/node4.example.com
package: mysql-server

1
2
3
4
5
6
7
8
9

[root@localhost ~]# tree ~/project
/root/project
├── ansible.cfg
├── group_vars
│   ├── datacenters
│   ├── datacenters1
│   └── datecenters2
├── host_vars
│   ├── node1.example.com
│   ├── node2.example.com
│   ├── node3.example.com
│   └── node4.example.com
├── inventory
└── playbook.yml

2 directories, 10 files

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

1.4 从命令行覆盖变量

清单变量可被playbook中设置的变量覆盖，这两种变量又可通过在命令行中传递参数到ansible或ansible-playbook命令来覆盖。在命令行上设置的变量称为额外变量。

当需要覆盖一次性运行的playbook的变量的已定义值时，额外变量非常有用。例如：

ansible-playbook main.yml -e "package=apache2"

1

1.5 使用数组作为变量

除了将同一元素相关的配置数据（软件包列表、服务列表和用户列表等）分配到多个变量外，也可以使用数组。这种做法的一个好处在于，数组是可以浏览的。

例如，假设下列代码片段：

user1_first_name: Bob
user1_last_name: Jones
user1_home_dir: /users/bjones
user2_first_name: Anne
user2_last_name: Cook
user2_home_dir: /users/acook

1
2
3
4
5
6

这将可以改写成名为users的数组：

users:
  bjones:
    first_name: Bob
    last_name: jones
    home_dir: /users/bjones
  acook:
    first_name: Anne
    last_name: Cook
    home_dir: /users/acook

1
2
3
4
5
6
7
8
9

然后可以使用以下变量来访问用户数据：

# Returns 'Bob'
users.bjones.first_name

# Returns '/users/acook'
users.acook.home_dir

1
2
3
4
5

由于变量被定义为Python字典，因此可以使用替代语法：

# Returns 'Bob'
users['bjones']['first-name']

# Returns '/users/acook'
users['acook']['home_dir']

1
2
3
4
5

如果键名与python方法或属性的名称（如discard、copy和add）相同，点表示法可能会造成问题。使用中括号表示法有助于避免冲突和错误。

但要声明的是，上面介绍的两种语法都有效，但为了方便故障排除，建议在任何给定Ansible项目的所有文件中一致地采用一种语法，不要混用。

1.6 使用已注册变量捕获命令输出

可以使用register语句捕获命令输出。输出保存在一个临时变量中，然后在playbook中可用于调试用途或者达成其他目的，例如基于命令输出的特定配置。

以下playbook演示了如何为调试用途捕获命令输出：

---
- name: Installs a package and prints the result
  hosts: all
  tasks:
    - name: Install the package
      yum:
        name: httpd
        state: installed
      register: install_result
                                                        
    - debug: var=install_result

1
2
3
4
5
6
7
8
9
10
11

运行该playbook时，debug模块用于将install_result注册变量的值转储到终端。

[root@localhost ~]# ansible-playbook playbook.yml 
PLAY [Installs a package and prints the result] *************************************

TASK [Gathering Facts] **************************************************************
ok: [172.16.103.129]

TASK [Install the package] **********************************************************
ok: [172.16.103.129]

TASK [debug] ************************************************************************
ok: [172.16.103.129] => {
    "install_result": {
        "changed": false,
        "failed": false,
        "msg": "",
        "rc": 0,
        "results": [
            "httpd-2.4.6-93.el7.centos.x86_64 providing httpd is already installed"
        ]
    }
}

PLAY RECAP **************************************************************************
t129                       : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

2. 管理机密

2.1 Ansible Vault

Ansible可能需要访问密码或API密钥等敏感数据，以便能配置受管主机。通常，此信息可能以纯文本形式存储在清单变量或其他Ansible文件中。但若如此，任何有权访问Ansible文件的用户或存储这些Ansible文件的版本控制系统都能够访问此敏感数据。这显示存在安全风险。

Ansible提供的Ansible Vault可以加密和解密任何由Ansible使用的结构化数据文件。若要使用Ansible Vault，可通过一个名为ansible-vault的命令行工具创建、编辑、加密、解密和查看文件。Ansible Vault可以加密任何由Ansible使用的结构化数据文件。这可能包括清单变量、playbook中含有的变量文件、在执行playbook时作为参数传递的变量文件，或者Ansible角色中定义的变量。

2.1.1 创建加密的文件

[root@localhost ~]# ansible-vault create secret.yml
New Vault password: redhat
Confirm New Vault password: redhat

1
2
3

ansible-vault create --vault-password-file=vault-pass secret.yml

1

2.1.2 查看加密的文件

ansible-vault view secret.yml

1

2.1.3 编辑现有的加密文件

ansible-vault edit secret.yml

1

2.1.4 加密现有的文件

ansible-vault encrypt secret1.yml secret2.yml

1

2.1.5 解密现有的文件

ansible-vault decrypt secret1.yml --output=secret1-decrypted.yml

1

2.1.6 更改加密文件的密码

ansible-vault rekey secret.yml

1

ansible-vault rekey --new-vault-password-file=NEW_VAULT_PASSWORD_FILE secret.yml

1

2.2 playbook和ansible vault

要运行可访问通过Ansible Vault加密的文件的playbook，需要向ansible-playbook命令提供加密密码。如果不提供密码，playbook将返回错误：

[root@localhost ~]# ansible-playbook site.yml
ERROR: A Vault password must be specified to decrypt vars/api_key.yml

1
2

要为playbook提供vault密码，可使用–vault-id选项。例如，要以交互方式提供vault密码，请使用下例中所示的–vault-id @prompt：

ansible-playbook --vault-id @prompt site.yml

1

此外，也可使用–vault-password-file选项指定以纯文本存储加密密码的文件。密码应当在该文件中存储为一行字符串。由于该文件包含敏感的纯文本密码，因此务必要通过文件权限和其他安全措施对其加以保护。

ansible-playbook --vault-password-file=vault-pw-file site.yml

1

也可以使用ANSIBLE_VAULT_PASSWORD_FILE环境变量，指定密码文件的默认位置。

从Ansible2.4开始，可以通过ansible-playbook使用多个Ansible Vault密码。要使用多个密码，需要将多个**–vault-id或–vault-password-file选项传递给ansible-playbook**命令。

ansible-playbook --vault-id one@prompt --vault-id two@prompt site.yml

1

注意：@prompt前面的vaultIDone和two可以是任何字符，甚至可以完全省略它们。不过，如果在使用ansible-vault命令加密文件时使用**–vault-id id选项，则在运行ansible-playbook时，将最先尝试匹配ID的密码。如果不匹配，将会尝试用户提供的其他密码。没有ID的vaultID@prompt实际上是default@prompt的简写，这意味着提示输入vaultIDdefault**的密码。

2.2.1 变量文件管理的推荐做法

.
├── ansible.cfg
├── group_vars
│   └── webservers
│       └── vars
├── host_vars
│   └── 172.16.103.129
│       ├── vars
│       └── vault
├── inventory
└── playbook.yml

1
2
3
4
5
6
7
8
9
10
11

3. 管理事实

3.1 描述Ansible事实

Ansible事实是Ansible在受管主机上自动检测到的变量。事实中包含有与主机相关的信息，可以像play中的常规变量、条件、循环或依赖于从受管主机收集的值的任何其他语句那样使用。

为受管主机收集的一些事实可能包括：

• 主机名称
• 内核版本
• 网络接口
• IP地址
• 操作系统版本
• 各种环境变量
• CPU数量
• 提供的或可用的内存
• 可用磁盘空间

借助事实，可以方便地检索受管主机的状态，并根据该状态确定要执行的操作。例如：

• 可以根据含有受管主机当前内核版本的事实运行条件任务，以此来重启服务器
• 可以根据通过事实报告的可用内存来自定义MySQL配置文件
• 可以根据事实的值设置配置文件中使用的IPv4地址

通常，每个play在执行第一个任务之前会先自动运行setup模块来收集事实。

查看为受管主机收集的事实的一种方式是，运行一个收集事实并使用debug模块显示ansible_facts变量值的简短playbook。

- name: Fact dump
  hosts: all
  tasks:
    - name: Print all facts
      debug:
        var: ansible_facts

1
2
3
4
5
6

运行该playbook时，事实将显示在作业输出中：

ansible-playbook facts.yml

1

Playbook以JSON格式显示ansible_facts变量的内容。

下表显示了可能从受管节点收集的并可在playbook中使用的一些事实：
Ansible事实的示例

如果变量的值为散列/字典类型，则可使用两种语法来获取其值。比如：

• ansible_facts[‘default_ipv4’][‘address’]也可以写成ansible_facts.default_ipv4.address
• ansible_facts[‘dns’][‘nameservers’]也可以写成ansible_facts.dns.nameservers

在playbook中使用事实时，Ansible将事实的变量名动态替换为对应的值：

---
- hosts: all
  tasks:
  - name: Prints various Ansible facts
    debug:
      msg: >
        The default IPv4 address of {{ ansible_facts.fqdn }}
        is {{ ansible_facts.default_ipv4.address }}

1
2
3
4
5
6
7
8

3.2 Ansible事实作为变量注入

在Ansible2.5之前，事实是作为前缀为字符串ansible_的单个变量注入，而不是作为ansible_facts变量的一部分注入。例如，ansible_facts[‘distribution’]事实会被称为ansible_distribution。

许多较旧的playbook仍然使用作为变量注入的事实，而不是在ansible_facts变量下创建命名空间的新语法。我们可以使用临时命令来运行setup模块，以此形式显示所有事实的值。以下示例中使用一个临时命令在受管主机172.16.103.129上运行setup模块：

ansible 172.16.103.129 -m setup

1

选定的Ansible事实名称比较

目前，Ansible同时识别新的事实命名系统（使用ansible_facts）和旧的2.5前“作为单独变量注入的事实”命名系统。

将Ansible配置文件的**[default]部分中inject_facts_as_vars参数设置为False**，可关闭旧命名系统。默认设置目前为True。

inject_facts_as_vars的默认值在Ansible的未来版本中可能会更改为False。如果设置为False，则只能使用新的**ansible_facts.***命名系统引用Ansible事实。所以建议大家一开始就要适应这种方式。

3.3 关闭事实收集

有时我们不想为play收集事实。这样做的原因可能有：

• 不准备使用任何事实
• 希望加快play速度
• 希望减小play在受管主机上造成的负载
• 受管主机因为某种原因无法运行setup模块
• 需要安装一些必备软件后再收集事实

以上种种原因导致我们可能想要永久或暂时关闭事实收集的功能，要为play禁用事实收集功能，可将gather_facts关键字设置为no：

---
- name: This play gathers no facts automatically
  hosts: large_farm
  gather_facts: no

1
2
3
4

即使play设置了gather_facts: no，也可以随时通过运行使用setup模块的任务来手动收集事实：

---
- name: gather_facts
  hosts: 172.16.103.129
  gather_facts: no
  tasks:
    - name: get gather_facts
      setup:
    - name: debug
      debug:
        var: ansible_facts

1
2
3
4
5
6
7
8
9
10

3.4 创建自定义事实

除了使用系统捕获的事实外，我们还可以自定义事实，并将其本地存储在每个受管主机上。这些事实整合到setup模块在受管主机上运行时收集的标准事实列表中。它们让受管主机能够向Ansible提供任意变量，以用于调整play的行为。

自定义事实可以在静态文件中定义，格式可为INI文件或采用JSON。它们也可以是生成JSON输出的可执行脚本，如同动态清单脚本一样。

有了自定义事实，我们可以为受管主机定义特定的值，供play用于填充配置文件或有条件地运行任务。动态自定义事实允许在play运行时以编程方式确定这些事实的值，甚至还可以确定提供哪些事实。

默认情况下，setup模块从各受管主机的**/etc/ansible/facts.d目录下的文件和脚本中加载自定义事实。各个文件或脚本的名称必须以.fact**结尾才能被使用。动态自定义事实脚本必须输出JSON格式的事实，而且必须是可执行文件。

以下是采用INI格式编写的静态自定义事实文件。INI格式的自定义事实文件包含由一个部分定义的顶层值，后跟用于待定义的事实的键值对：

[packages]
web_package = httpd
db_package = mariadb-server

[users]
user1 = joe
user2 = jane

1
2
3
4
5
6
7

同样的事实可能以JSON格式提供。以下JSON事实等同于以上示例中INI格式指定的事实。JSON数据可以存储在静态文本文件中，或者通过可执行脚本输出到标准输出：

{
  "packages": {
    "web_package": "httpd",
    "db_package": "mariadb-server"
  },
  "users": {
    "user1": "joe",
    "user2": "jane"
  }
}

1
2
3
4
5
6
7
8
9
10

自定义事实文件不能采用playbook那样的YAML格式。JSON格式是最为接近的等效格式。

自定义事实由setup模块存储在ansible_facts.ansible_local变量中。
事实按照定义它们的文件的名称来整理。例如，假设前面的自定义事实由受管主机上保存为**/etc/ansible/facts.d/custom.fact**的文件生成。在这种情况下，ansible_facts.ansible_local[‘custom’][‘users’][‘user1’]的值为joe。

可以利用临时命令在受管主机上运行setup模块来检查自定义事实的结构。

ansible 172.16.103.129 -m setup

1

自定义事实的使用方式与playbook中的默认事实相同：

---
- hosts: all
  tasks:
  - name: Prints various Ansible facts
    debug:
      msg: >
        The package to install on {{ ansible_facts['fqdn'] }}
        is {{ ansible_facts['ansible_local']['cutstom']['packages']['web_package'] }}

1
2
3
4
5
6
7
8

3.5 使用魔法变量

一些变量并非事实或通过setup模块配置，但也由Ansible自动设置。这些魔法变量也可用于获取与特定受管主机相关的信息。

最常用的有四个：

另外还有许多其他的“魔法变量”。有关更多信息，请参见以下链接：
https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable。
若要深入了解它们的值，一个途径是使用debug模块报告特定主机的hostvars变量的内容：

ansible 172.16.103.129 -m debug -a 'var=hostvars["localhost"]'

1

06 实施任务控制

1. 编写循环和条件任务

1.1 利用循环迭代任务

通过利用循环，我们无需编写多个使用同一模块的任务。例如，他们不必编写五个任务来确保存在五个用户，而是只需编写一个任务来对含有五个用户的列表迭代，从而确保它们都存在。

Ansible支持使用loop关键字对一组项目迭代任务。可以配置循环以利用列表中的各个项目、列表中各个文件的内容、生成的数字序列或更为复杂的结构来重复任务。

1.1.1 简单循环

- name: Postfix is running
  service:
    name: postfix
    state: started
    
- name: Devecot is running
  service:
    name: dovecot
    state: started

1
2
3
4
5
6
7
8
9

- name: Postfix and Devecot are running
  service:
    name: "{{ item }}"
    state: started
  loop:
    - postfix
    - dovecot

1
2
3
4
5
6
7

vars:
  mail_services:
    - postfix
    - dovecot

tasks:
  - name: Postfix and Dovecot are running
    service:
      name: "{{ item }}"
      state: started
    loop: "{{ mail_services }}"

1
2
3
4
5
6
7
8
9
10
11

1.1.2 循环散列或字典列表

- name: Users exist and are in the correct groups
  user:
    name: "{{ item.name }}"
    state: present
    groups: "{{ item.groups }}"
  loop:
    - name: jane
      groups: wheel
    - name: joe
      groups: root

1
2
3
4
5
6
7
8
9
10

1.1.3 较早样式的循环关键字

vars:
  data:
    - user0
    - user1
    - user2
tasks:
  - name: "with_items"
    debug:
      msg: "{{ item }}"
    with_items: "{{ data }}"

1
2
3
4
5
6
7
8
9
10

1.1.4 将Register变量与Loop一起使用

[root@localhost ~]# vim loop_register.yml
---
- name: Loop Register Test
  gather_facts: no
  hosts: 172.16.103.129
  tasks:
    - name: Looping Echo Task
      shell: "echo This is my item: {{ item }}"
      loop:
        - one
        - two
      register: echo_results    # 注册echo_results变量
      
    - name: Show echo_results variable
      debug:
        var: echo_results       # echo_results变量的内容显示在屏幕上
        
[root@localhost ~]# ansible-playbook loop_register.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

[root@localhost ~]# vim new_loop_register.yml
---
- name: Loop Register Test
  gather_facts: no
  hosts: 172.16.103.129
  tasks:
    - name: Looping Echo Task
      shell: "echo This is my item: {{ item }}"
      loop:
        - one
        - two
      register: echo_results
      
    - name: Show stdout from the previous task.
      debug:
        msg: "STDOUT from previous task: {{ item.stdout }}"
      loop: "{{ echo_results['results'] }}"

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

1.2 有条件地运行任务

Ansible可使用conditionals在符合特定条件时执行任务或play。例如，可以利用一个条件在Ansible安装或配置服务前确定受管主机上的可用内存。

我们可以利用条件来区分不同的受管主机，并根据它们所符合的条件来分配功能角色。Playbook变量、注册的变量和Ansible事实都可通过条件来进行测试。可以使用比较字符串、数字数据和布尔值的运算符。

以下场景说明了在Ansible中使用条件的情况：

• 可以在变量中定义硬限制（如min_memory）并将它与受管主机上的可用内存进行比较。
• Ansible可以捕获并评估命令的输出，以确定某一任务在执行进一步操作前是否已经完成。例如，如果某一程序失败，则将路过批处理。
• 可以利用Ansible事实来确定受管主机网络配置，并决定要发送的模板文件（如，网络绑定或中继）。
• 可以评估CPU的数量，来确定如何正确调节某一Web服务器。
• 将注册的变量与预定义的变量进行比较，以确定服务是否已更改。例如，测试服务配置文件的MD5检验以和查看服务是否已更改。

1.2.1 条件任务语法

---
- name: Simple Boolean Task Demo
  hosts: 172.16.103.129
  vars:
    run_my_task: True
    
  tasks:
    - name: httpd package is installed
      yum:
        name: httpd
      when: run_my_task

1
2
3
4
5
6
7
8
9
10
11

---
- name: Test Variable is Defined Demo
  hosts: 172.16.103.129
  vars:
    my_service: httpd
    
  tasks:
    - name: "{{ my_service }} package is installed"
      yum:
        name: "{{ my_service }}"
      when: my_service is defined

1
2
3
4
5
6
7
8
9
10
11

---
- name: Demonstrale the "in" keyword
  hosts: 172.16.103.129
  gather_facts: yes
  vars:
    supported_distros:
      - RedHat
      - Fedora
  tasks:
    - name: Install httpd using yum, where supported
      yum:
        name: httpd
        state: present
      when: ansible_distribution in supported_distros

1
2
3
4
5
6
7
8
9
10
11
12
13
14

1.2.2 测试多个条件

when: ansible_distribution == "Redhat" or ansible_distribution == "Fedora"

1

when: ansible_distribution_version == "7.5" and ansible_kernel == "3.10.0-327.el7.x86_64"

1

when:
  - ansible_distribution_version == "7.5"
  - ansible_kernel == "3.10.0-327.el7.x86_64"

1
2
3

when: >
  ( ansible_distribution == "Redhat" and
    ansible_distribution_major_version == "7" )
  or
  ( ansible_distribution == "Fedora" and
    ansible_distribution_major_version == "28" )

1
2
3
4
5
6

1.3 组合循环和有条件任务

循环和条件可以组合使用。

在下例中，yum模块将安装mariadb-server软件包，只要/上挂载的文件系统具有超过300MB的可用空间。ansible_mounts事实是一组字典，各自代表一个已挂载文件系统的相关事实。循环迭代列表中每一字典，只有找到了代表两个条件都为真的已挂载文件系统的字典时，条件语句才得到满足。

- name: install mariadb-server if enough space on root
  yum:
    name: mariadb-server
    state: latest
  loop: "{{ ansible_mounts }}"
  when: item.mount == "/" and item.size_available > 300000000

1
2
3
4
5
6

对某个任务结合使用when和loop时，将对每个项检查when语句。

下面是组合使用条件和注册变量的另一个示例。

---
- name: Restart HTTPD if Postfix is Running
  hosts: 172.16.103.129
  tasks:
    - name: Get Postfix server status
      command: /usr/bin/systemctl is-active postfix     # Postfix是否在运行？
      ignore_errors: yes    # 如果它不在运行并且命令失败，则不停止处理。
      register: result      # 将模块的结果信息保存在名为result的变量中
      
    - name: Restart Apache HTTPD based on Postfix status
      service:
        name: httpd
        state: restarted
      when: result.rc == 0      # 评估Postfix任务的输出。如果systemctl命令的退出代码为0，\
                                # 则Postfix激活并且此任务重启httpd服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

2. 实施处理程序

2.1 ansible处理程序

Ansible模块设计为具有幂等性。这表示，在正确编写的playbook中，playbook及其任务可以运行多次而不会改变受管主机，除非需要进行更改使受管主机进入所需的状态。

但在时候，在任务确实更改系统时，可能需要运行进一步的任务。例如，更改服务配置文件时可能要求重新加载该服务以便使其更改的配置生效。

处理程序是响应由其他任务触发的通知的任务。仅当任务在受管主机上更改了某些内容时，任务才通知其处理程序。每个处理程序具有全局唯一的名称，在playbook中任务块的末尾触发。如果没有任务通过名称通知处理程序，处理程序就不会运行。如果一个或多个任务通知处理程序，处理程序就会在play中的所有其他任务完成后运行一次。因为处理程序就是任务，所以可以在处理程序中使用他们将用于任何其他任务的模块。通常而言，处理程序被用于重新引导主机和重启服务。

处理程序可视为非活动任务，只有在使用notify语句显式调用时才会被触发。在下列代码片段中，只有配置文件更新并且通知了该任务，restart apache处理程序才会重启Apache服务器：

tasks:
  - name: copy demo.example.conf configuratioon template      # 通知处理程序的任务
    template:
      src: /var/lib/templates/demo.example.conf.template
      dest: /etc/httpd/conf.d/demo.example.conf
    notify:         # notify语句指出该任务需要触发一个处理程序
      - restart apache     # 要运行的处理程序的名称

handlers:       # handlers关键字表示处理程序任务列表的开头
  - name: restart apache   # 被任务调用的处理程序的名称
    service:    # 用于该处理程序的模块
      name: httpd
      state: restarted

1
2
3
4
5
6
7
8
9
10
11
12
13

在上面的例子中，restart apache处理程序只有在template任务通知已发生更改时才会触发。一个任务可以在其notify部分中调用多个处理程序。Ansible将notify语句视为数组，并且迭代处理程序名称：

tasks:
  - name: copy demo.example.conf configuration template
    template:
      src: /var/lib/templates/demo.exammple.conf.template
      dest: /etc/httpd/conf.d/demo.example.conf
    notify:
      - restart mysql
      - restart apache

handlers:
  - name: restart mysql
    service:
      name: mariadb
      state: restarted
      
  - name: restart apache
    service:
      name: httpd
      state: restarted

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

2.2 使用处理程序的好处

使用处理程序时需要牢记几个重要事项：

• 处理程序始终按照play的handlers部分指定的顺序运行。它们不按在任务中由notify语句列出的顺序运行，或按任务通知它们的顺序运行。
• 处理程序通常在相关play中的所有其他任务完成后运行。playbook的tasks部分中某一任务调用的处理程序，将等到tasks下的所有任务都已处理后才会运行。
• 处理程序名称存在于各play命名空间中。如果两个处理程序被错误地给予相同的名称，则仅会运行一个。
• 即使有多个任务通知处理程序，该处理程序依然仅运行一次。如果没有任务通知处理程序，它就不会运行。
• 如果包含notify语句的任务没有报告changed结果（例如，软件包已安装并且任务报告ok），则处理程序不会获得通知。处理程序将被跳过，直到有其他任务通知它。只有相关任务报告了changed状态，Ansible才会通知处理程序。

处理程序用于在任务对受管主机进行更改时执行额外操作。它们不应用作正常任务的替代。

3. 处理任务失败

3.1 管理play中的任务错误

Ansible评估任务的返回代码，从而确定任务是成功还是失败。通常而言，当任务失败时，Ansible将立即在该主机上中止play的其余部分并且跳过所有后续任务。

但有些时候，可能希望即使在任务失败时也继续执行play。例如，或许预期待定任务有可能会失败，并且希望通过有条件地运行某项其他任务来修复。

Ansible有多种功能可用于管理任务错误。

3.2 忽略任务失败

默认情况下，任务失败时play会中止。不过，可以通过忽略失败的任务来覆盖此行为。可以在任务中使用ignore_errors关键字来实现此目的。

下列代码片段演示了如何在任务中使用ignore_errors，以便在任务失败时也继续在主机上执行playbook。例如，如果notapkg软件包不存在，则yum模块将失败，但若将ignore_errors设为yes，则执行将继续。

- name: Latest version of notapkg is installed
  yum:
    name: notapkg
    state: latest
  ignore_errors: yes

1
2
3
4
5

3.3 任务失败后强制执行处理程序

通常而言，如果任务失败并且play在该主机上中止，则收到play中早前任务通知的处理程序将不会运行。如果在play中设置force_handlers: yes关键字，则即使play因为后续任务失败而中止也会调用被通知的处理程序。

下列代码片段演示了如何在play中使用force_handlers关键字，以便在任务失败时也强制执行相应的处理程序：

---
- hosts: 172.16.103.129
  force_handlers: yes
  tasks:
    - name: a task which always notifies its handler
      command: /bin/true
      notify: restart the database
      
    - name: a task which fails because the package doesn't exist
      yum:
        name: notapkg
        state: latest
        
  handlers:
    - name: restart the database
      service:
        name: mariadb
        state: restarted

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

请记住，处理程序会在任务报告changed结果时获得通知，而在任务报告ok或failed结果时不会获得通知。

3.4 指定任务失败条件

可以在任务中使用failed_when关键字来指定表示任务已失败的条件。这通常与命令模块搭配使用，这些模块可能成功执行了某一命令，但命令的输出可能指示了失败。

例如，可以运行输出错误消息的脚本，并使用该消息定义任务的失败状态。下列代码片段演示了如何在任务中使用failed_when关键字：

tasks:
  - name: Run user creation script
    shell: /usr/local/bin/create_users.sh
    register: command_result
    failed_when: "'Password missing' in command_result.stdout"

1
2
3
4
5

fail模块也可用于强制任务失败。上面的场景也可以编写为两个任务：

tasks:
  - name: Run user creation script
    shell: /usr/local/bin/create_users.sh
    register: command_result
    ignore_errors: yes
    
  - name: Report script failure
    fail:
      msg: "The password is missing in the output"
    when: "'Password missing' in command_result.stdout"

1
2
3
4
5
6
7
8
9
10

我们可以使用fail模块为任务提供明确的失败消息。此方法还支持延迟失败，允许在运行中间任务以完成或回滚其他更改。

3.5 指定何时任务报告 “Changed” 结果

当任务对托管主机进行了更改时，会报告 changed 状态并通知处理程序。如果任务不需要进行更改，则会报告ok并且不通知处理程序。

changed_when关键字可用于控制任务在何时报告它已进行了更改。例如，下一示例中的shell模块将用于获取供后续任务使用的Kerberos凭据。它通常会在运行时始终报告changed。为抵制这种更改，应设置changed_when: false，以便它仅报告ok或failed。

- name: get Kerberos credentials as "admin"
  shell: echo "{{ krb_admin_pass }}" | kinit -f admin
  changed_when: false

1
2
3

以下示例使用shell模块，根据通过已注册变量收集的模块的输出来报告changed：

tasks:
  - shell:
      cmd: /usr/local/bin/upgrade-database
    register: command_result
    changed_when: "'Success' in command_result.stdout"
    notify:
      - restart_database

handlers:
  - name: restart_database
    service:
      name: mariadb
      state: restarted

1
2
3
4
5
6
7
8
9
10
11
12
13

3.6 Ansible块和错误处理

在playbook中，块是对任务进行逻辑分组的子句，可用于控制任务的执行方式。例如，任务块可以含有when关键字，以将某一条件应用到多个任务：

- name: block example
  hosts: 172.16.103.129
  tasks:
    - name: installing and configuring Yum versionlock plugin
      block:
      - name: package needed by yum
        yum:
          name: yum-plugin-versionlock
          state: present
      - name: lock version of tadata
        lineinfile:
          dest: /etc/yum/pluginconf.d/versionlock.list
          line: tzdata-2020j-1
          state: present
      when: ansible_distribution == "Redhat"

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

通过块，也可结合rescue和always语句来处理错误。如果块中的任何任务失败，则执行其rescue块中的任务来进行恢复。在block子句中的任务以及rescue子句中的任务（如果出现故障）运行之后，always子句中的任务运行。总结：

• block：定义要运行的主要任务
• rescue：定义要在block子句中定义的任务失败时运行的任务
• always：定义始终都独立运行的任务，不论block和rescue子句中定义的任务是成功还是失败

以下示例演示了如何在playbook中实施块。即使block子句中定义的任务失败，rescue和always子句中定义的任务也会执行。

tasks:
  - name: Upgrade DB
    block:
      - name: upgrade the database
        shell:
          cmd: /usr/local/lib/upgrade-database
    rescue:
      - name: revert the database upgrade
        shell:
          cmd: /usr/local/lib/revert-database
    always:
      - name: always restart the database
        service:
          name: mariadb
          state: restarted

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

block中的when条件也会应用到其rescue和always子句（若存在）。

07 在被管理节点上创建文件或目录

1. 修改文件并将其复制到主机

1.1 描述文件模块

Files模块库包含的模块允许用户完成与Linux文件管理相关的大多数任务，如创建、复制、编辑和修改文件的权限和其他属性。下表提供了常用文件管理模块的列表：

常用文件模块

1.2 files模块的自动化示例

在受管主机上创建、复制、编辑和删除文件是用户可以使用Files模块库中的模块实施的常见任务。
以下示例显示了可以使用这些模块自动执行常见文件管理任务的方式。

1.2.1 确保受管主机上存在文件

- name: Touch a file and set permissions
  file:
    path: /path/to/file
    owner: user1
    group: group1
    mode: 0640
    state: touch

1
2
3
4
5
6
7

1.2.2 修改文件属性

[root@localhost ~]# ls -Z samba_file
- rw-r--r-- owner group unconfined_u:object_r:user_home_t:s0 samba_file

1
2

- name: SELinux type is set to samba_share_t
  file:
    path: /path/to/samba_file
    setype: samba_share_t

1
2
3
4

[root@localhost ~]# ls -Z samba_file
- rw-r--r-- owner group unconfined_u:object_r:samba_share_t:s0 samba_file

1
2

1.2.3 使SELinux文件上下文更改具有持久性

- name: SELinux type is persistently set to samba_share_t
  sefcontext:
    target: /path/to/samba_file
    setype: samba_share_t
    state: present

1
2
3
4
5

1.2.4 在受管主机上复制和编辑文件

- name: Copy a file to managed hosts
  copy:
    src: file
    dest: /path/to/file

1
2
3
4

- name: Retrieve SSH key from reference host
  fetch:
    src: "/home/{{ user }}/.ssh/id_rsa.pub"
    dest: "files/keys/{{ user }}.pub"

1
2
3
4

- name: Add a line of text to a file
  lineinfile:
    path: /path/to/file
    line: 'Add this line to the file'
    state: present

1
2
3
4
5

- name: Add additional lines to a file
  blockinfile:
    path: /path/to/file
    block: |
      First line in the additional block of text
      Second line in the additional block of text
    state: present

1
2
3
4
5
6
7

# BEGIN ANSIBLE MANAGED BLOCK
First line in the additional block of text
Second line in the additional block of text
# END ANSIBLE MANAGED BLOCK

1
2
3
4

1.2.5 从受管主机中删除文件

- name: Make sure a file does not exist on managed hosts
  file:
    dest: /path/to/file
    state: absent

1
2
3
4

1.2.6 检索受管主机上的文件状态

- name: Verify the checksum of a file
  stat:
    path: /path/to/file
    checksum_algorithm: md5
  register: result
  
- debug
  msg: "The checksum of the file is {{ result.stat.checksum }}"

1
2
3
4
5
6
7
8

- name: Examine all stat output of /etc/passwd
  hosts: 172.16.103.129
  
  tasks:
    - name: stat /etc/passwd
      stat:
        path: /etc/passwd
      register: results
      
    - name: Display stat results
      debug:
        var: results

1
2
3
4
5
6
7
8
9
10
11
12

1.2.7 同步控制节点和受管主机之间的文件

- name: synchronize local file to remote files
  synchronize:
    src: file
    dest: /path/to/file

1
2
3
4

2. 使用jinja2模板部署自定义文件

2.1 jinja2简介

Ansible将jinja2模板系统用于模板文件。Ansible还使用jinja2语法来引用playbook中的变量。

变量和逻辑表达式置于标记或分隔符之间。例如，jinja2模板将**{% EXPR %}用于表达式或逻辑（如循环），而{{ EXPR }}则用于向最终用户输出表达式或变量的结果。后一标记在呈现时将被替换为一个或多个值，对最终用户可见。使用{# COMMENT #}**语法括起不应出现在最终文件中的注释。

在下例中，第一行中含有不会包含于最终文件中的注释。第二行中引用的变量被替换为所引用的系统事实的值。

{# /etc/hosts line #}
{{ ansible_facts['default_ipv4']['address'] }}      {{ ansible_facts['hostname'] }}

1
2

2.2 构建jinja2模板

jinja2模板由多个元素组成：数据、变量和表达式。在呈现jinja2模板时，这些变量和表达式被替换为对应的值。模板中使用的变量可以在playbook的vars部分中指定。可以将受管主机的事实用作模板中的变量。

请记住，可以使用ansible system_hostname -i inventory_file -m setup命令来获取与受管主机相关的事实。

下例演示了如何使用变量及Ansible从受管主机检索的事实创建**/etc/ssh/sshd_config的模板。当执行相关的playbook**时，任何事实都将被替换为所配置的受管主机中对应的值。

注意：包含jinja2模板的文件不需要有任何特定的文件扩展名（如.j2）。但是，提供此类文件扩展名会让你更容易记住它是模板文件。

# {{ ansible_managed }}
# DO NOT MAKE LOCAL MODIFICATIONS TO THIS FILE AS THEY WILL BE LOST

Port {{ ssh_port }}
ListenAddress {{ ansible_facts['default_ipv4']['address'] }}

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

SyslogFacility AUTHPRIV

PermitRootLogin {{ root_allowed }}
AllowGroups {{ groups_allowed }}

AuthorizedKeyFile /etc/.rht_authorized_keys .ssh/authorized_keys

PasswordAuthentication {{ passwords_allowed }}

ChallengeResponseAuthentication no

GSSAPIAuthentication yes
GSSAPICleanupCredentials no

UsePAM yes

X11Forwarding yes
UsePrivilegeSeparation sandbox

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS

Subsystem sftp /usr/libexec/openssh/sftp-server

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

2.3 部署jinja2模板

jinja2模板是功能强大的工具，可用于自定义要在受管主机上部署的配置文件。创建了适用于配置文件的jinja2模板后，它可以通过template模板部署到受管主机上，该模块支持将控制节点中的本地文件转移到受管主机。

若要使用template模块，请使用下列语法。与src键关联的值指定来源jinja2模板，而与dest键关联的值指定要在目标主机上创建的文件。

tasks:
  - name: template render
    template:
      src: /tmp/j2-template.j2
      dest: /tmp/dest-config-file.txt

1
2
3
4
5

template模块还允许指定已部署文件的所有者、组、权限和SELINUX上下文，就像file模块一样。它也可以取用validate选项运行任意命令（如visudo -c），在将文件复制到位之前检查该文件的语法是否正确。

有关更多详细信息，请参阅ansible-doc template

2.4 管理模板文件

为避免系统管理员修改Ansible部署的文件，最好在模板顶部包含注释，以指示不应手动编辑该文件。

可使用ansible_managed指令中设置的"Ansible managed"字符串来执行此操作。这不是正常变量，但可以在模板中用作一个变量。ansible_managed指令在ansible.cfg文件中设置：

ansible_managed = Ansible managed

1

要将ansible_managed字符串包含在jinja2模板内，请使用下列语法：

{{ ansible_managed }}

1

2.5 控制结构

用户可以在模板文件中使用jinja2控制结构，以减少重复输入，为play中的每个主机动态输入条目，或者有条件地将文本插入到文件中。

2.5.1 使用循环

{% for user in users %}
    {{ user }}
{% endfor %}

1
2
3

{# for statement #}
{% for myuser in users if not myuser == "root" %}
User number {{ loop.index }} - {{ myuser }}
{% endfor %}

1
2
3
4

{% for myhost in groups['myhosts'] %}
{{ myhost }}
{% endfor %}

1
2
3

- name: /etc/hosts is up to date
  hosts: all
  gather_facts: yes
  tasks:
    - name: Deploy /etc/hosts
      template:
        src: templates/hosts.j2
        dest: /etc/hosts

1
2
3
4
5
6
7
8

{% for host in groups['all'] %}
{{ hostvars['host']['ansible_facts']['default_ipv4']['address'] }}      {{ hostvars['host']['ansible_facts']['fqdn'] }}     {{ hostvars['host']['ansible_facts']['hostname'] }}
{% endfor %}

1
2
3

2.5.2 使用条件句

{% if finished %}
{{ result }}
{% endif %}

1
2
3

2.5.3 变量过滤器

{{ output | to_json }}
{{ output | to_yaml }}

1
2

{{ output | to_nice_json }}
{{ output | to_nice_yaml }}

1
2

{{ output | from_json }}
{{ output | from_yaml }}

1
2

2.5.4 变量测试

tasks:
...output omitted...
  - debug: msg="the execution was aborted"
    when: returnvalue is failed

1
2
3
4

08 管理大项目

1. 利用主机模式选择主机

1.1 引用清单主机

主机模式用于指定要作为play或临时命令的目标的主机。在最简单的形式中，清单中受管主机或主机组的名称就是指定该主机或主机组的主机模式。

在play中，hosts指定要针对其运行play的受管主机。对于临时命令，以命令行参数形式将主机模式提供给ansible命令。

本节中将通篇使用以下示例清单来演示主机模式。

[root@localhost ~]# cat myinventory 
web.example.com
data.example.com

[lab]
labhost1.example.com
labhost2.example.com

[test]
test1.example.com
test2.example.com

[datacenter1]
labhost1.example.com
test1.example.com

[datacenter2]
labhost2.example.com
test2.example.com

[datacenter:children]
datacenter1
datacenter2

[new]
172.16.103.129
172.16.103.130

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

要演示如何解析主机模式，我们将执行Ansible Playbook的playbook.yml，使用不同的主机模式来以此示例清单中受管主机的不同子集作为目标。

1.2 受管主机

最基本的主机模式是单一受管主机名称列在清单中。这将指定该主机是清单中ansible命令要执行操作的唯一主机。

在该playbook运行时，第一个Gathering Facts任务应在与主机模式匹配的所有受管主机上运行。此任务期间的故障可能导致受管主机从play中移除。

如果清单中明确列出了IP地址，而不是主机名，则可以将其用作主机模式。如果IP地址未列在清单中，我们就无法用它来指定主机，即使该IP地址会在DNS中解析到这个主机名。

以下示例演示了如何使用主机模式来引用清单中包含的IP地址。

[root@localhost ~]# vim playbook.yml
---
- hosts: 172.16.103.129


[root@localhost ~]# ansible-playbook playbook.yml 
PLAY [172.16.103.129] ***************************************************************

TASK [Gathering Facts] **************************************************************
ok: [172.16.103.129]

PLAY RECAP **************************************************************************
172.16.103.129             : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

1
2
3
4
5
6
7
8
9
10
11
12
13

注意：
在清单中通过IP地址引用受管主机存在一个问题，那就是难以记住play或临时命令所针对的主机使用了哪个IP地址。但是，如果没有可解析的主机名，我们可能必须按IP地址指定主机以进行连接。

可以通过设置ansible_host主机变量，在清单中将某一别名指向特定的IP地址。例如，你的清单中可以有一个名为dummy.example的主机，然后通过创建含有以下主机变量的host_vars/dummy.example文件，将使用该名称的连接指向IP地址172.16.103.129：

ansible_host: 172.16.103.129

1

1.3 使用组指定主机

当组名称用作主机模式时，它指定Ansible将对属于该组的成员的主机执行操作。

---
- hosts: lab

1
2

记住，有一个名为all的特别组，它匹配清单中的所有受管主机。

---
- hosts: all

1
2

还有一个名为ungrouped的特别组，它包括清单中不属于任何其他组的所有受管主机：

---
- hosts: ungrouped

1
2

1.4 使用通配符匹配多个主机

若要达成与all主机模式相同的目标，另一种方法是使用*通配符，它将匹配任意字符串。如果主机模式只是带引号的星号，则清单中的所有主机都将匹配。

---
- hosts: '*'

1
2

重要

一些在主机模式中使用的字符对shell也有意义。通过ansible使用主机模式从命令行运行临时命令时，这可能会有问题。建议大家在命令行中使用单引号括起使用的主机模式，防止它们被shell意外扩展。
类似的，如果在Ansible Playbook中使用了任何特殊通配符或列表字符，必须将主机模式放在单引号里，确保能够正确解析主机模式。

---
- hosts: '!test1.example.com,development'

1
2

也可使用*字符匹配包含特定子字符串的受管主机或组。
例如，以下通配符主机模式匹配以**.example.com**结尾的所有清单名称：

---
- hosts: '*.example.com'

1
2

以下示例使用通配符主机模式来匹配开头为**192.168.2.**的主机或主机组的名称：

---
- hosts: '192.168.2.*'

1
2

以下示例使用通配符主机模式来匹配开头为datacenter的主机或主机组的名称。

---
- hosts: 'datacenter*'

1
2

重要

通配符主机模式匹配所有清单名称、主机和主机组。它们不区别名称是DNS名、IP地址还是组，这可能会导致一些意外的匹配。
例如，根据示例清单，比较上一示例中指定datacenter主机模式的结果和data主机模式的结果：

---
- hosts: 'data*'

1
2

1.5 列表

可以通过逻辑列表来引用清单中的多个条目。主机模式的逗号分隔列表匹配符合任何这些主机模式的所有主机。

如果提供受管主机的逗号分隔列表，则所有这些受管主机都将是目标：

---
- hosts: labhost1.example.com,test2.example.com,192.168.2.2

1
2

如果提供组的逗号分隔列表，则属于任何这些组的所有主机都将是目标：

---
- hosts: lab,datacenter1

1
2

也可以混合使用受管主机、主机组和通配符，如下所示：

---
- hosts: 'lab,data*,192.168.2.2'

1
2

注意
也可以用冒号（:）取代逗号。不过，逗号是首选的分隔符，特别是将IPv6地址用作受管主机名称时。

如果列表中的某一项以与符号（&）开头，则主机必须与该项匹配才能匹配主机模式。它的工作方式类似于逻辑AND。

例如，根据我们的示例清单，以下主机模式将匹配lab组中同时也属于datacenter1组的计算机：

---
- hosts: lab,&datacenter1

1
2

我们也可以通过主机模式**&lab,datacenter1或datacenter,&lab指定datacenter1组中的计算机只有在同时也属于lab**组时才匹配。

通过在主机模式的前面使用感叹号（!）表示从列表中排除匹配某一模式的主机。它的工作方式类似于逻辑NOT。

根据示例清单，以下示例匹配datacenter组中定义的所有主机，但test2.example.com除外：

---
- hosts: datacenter,!test2.example.com

1
2

也可以使用模式**‘!test2.example.com,datacenter’**来获得相同的结果。

最后一个示例演示了使用匹配测试清单中的所有主机的主机模式，datacenter1组中的受管主机除外。

---
- hosts: all,!datacenter1

1
2

2. 管理动态清单

2.1 动态生成清单

前面我们用到的静态清单编写比较容易，对于管理小型基础架构而言也很方便。不过，如果要操作许多台计算机，或者在计算机更替非常快的环境中工作，可能难以让静态清单文件保持最新状态。

大多数大型IT环境中没有系统来跟踪可用的主机以及它们的组织方式。例如，可能有外部目录服务通过Zabbix等监控系统维护，或者位于FreeIPA或Active Directory服务器上。Cobbler等安装服务器或红帽卫星等管理服务可能跟踪部署的裸机系统。类似地，Amazon Web ServicesEC2或OpenStack部署等云服务，或者基于Vmware或红帽虚拟化的虚拟机基础架构可能是有关那些更替的实例和虚拟机的信息来源。

Ansible支持动态清单脚本，这些脚本在每当Ansible执行时从这些类型的来源检索当前的信息，使清单能够实时得到更新。这些脚本是可以执行的程序，能够从一些外部来源收集信息，并以JSON格式输出清单。

动态清单脚本的使用方式与静态清单文本文件一样。清单的位置可以直接在当前的ansible.cfg文件中指定，或者通过**-i**选项指定。如果清单文件可以执行，则它将被视为动态清单程序，Ansible会尝试运行它来生成清单。如果文件不可执行，则它将被视为静态清单。

清单位置可以在ansible.cfg配置文件中通过inventory参数进行配置。默认情况下，它被配置为**/etc/ansible/hosts**。

2.2 开源社区脚本

2.3 编写动态清单程序

如果使用的目录系统或基础架构没有动态清单脚本，我们可以编写自定义清单程序。可以使用任何编程语言编写自定义程序，但传递适当的选项时必须以JSON格式返回清单信息。

ansible-inventory命令是学习如何以JSON格式编写Ansible清单的有用工具。

要以JSON格式显示清单文件的内容，请运行ansible-inventory --list命令。可以使用**-i**选项指定要处理的清单文件的位置，或仅使用当前Ansible配置设置的默认清单。

以下示例演示了如何使用ansible-inventory命令来处理INI样式的清单文件并以JSON格式输出。

[root@localhost ~]# cat inventory
workstation1.lab.example.com

[webservers]
web1.lab.example.com
web2.lab.example.com

[databases]
db1.lab.example.com
db2.lab.example.com


[root@localhost ~]# ansible-inventory -i inventory --list

1
2
3
4
5
6
7
8
9
10
11
12
13

如果要自己编写动态清单脚本，可以通过部署动态清单来源[https://docs.ansible.com/ansible/latest/dev_guide/developing_inventory.html]获得更详细的信息。以下是一个简略概要。

脚本以适当的解释器行（例如，#!/usr/bin/python）开头并且可以执行，以便Ansible能够运行它。

在传递–list选项时，脚本必须显示清单中所有主机和组的JSON编码散列/字典。

在最简单的形式中，组可以是一个受管主机列表。在这个清单脚本的JSON编码输出示例中，webservers是一个主机组，该组内含web1.lab.example.com和web2.lab.example.com受管主机。databases主机组的成员有db1.lab.example.com和db2.lab.example.com主机。

[root@localhost ~]# ./inventoryscript --list
{
    "webservers": ["web1.lab.example.com","web2.lab.example.com"],
    "databases": ["db1.lab.example.com","db2.lab.example.com"]
}

1
2
3
4
5

此外，每个组的值可以是JSON散列/字典，含有由每一受管主机、任何子组和可能设置的任何组变量组成的列表。下一示例显示了一个比较复杂的动态清单的JSON编码输出。boston组具有两个子组（backup和ipa）、自己的三个受管主机，以及一个组变量集合（example_host: false）。

{
    "webservers": [
        "web1.lab.example.com",
        "web2.lab.example.com"
    ],
    "boston": {
        "children": [
            "backup",
            "ipa"
        ],
        "vars": {
            "example_host": false
        },
        "hosts": [
            "server1.demo.example.com",
            "server2.demo.example.com",
            "server3.demo.example.com",
        ]
    },
    "backup": [
        "server4.demo.example.com"
    ],
    "ipa": [
        "server5.demo.example.com"
    ],
    "_meta": {
        "hostvars": {
            "server5.demo.example.com": {
                "ntpserver": "ntp.demo.example.com",
                "dnsserver": "dns.demo.example.com"
            }
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

该脚本也支持–host managed-host选项。此选项必须显示由与该主机关联的变量组成的JSON散列/字典，或者空白的JSON散列/字典。

[root@localhost ~]# ./inventoryscript --host server5.demo.example.com
{
    "ntpserver": "ntp.demo.example.com",
    "dnsserver": "dns.demo.example.com"
}

1
2
3
4
5

注意
通过–host hostname选项调用时，该脚本必须显示指定主机的变量的JSON散列/字典。如果不提供任何变量，则可能显示空白的JSON散列或字典。

另外，如果–list选项返回名为_meta的顶级元素，则可以在一次脚本调用中返回所有主机变量，从而提升脚本性能。此时，不会进行–host调用。

有关详细信息，请参见部署动态清单来源[https://docs.ansible.com/ansible/latest/dev_guide/developing_inventory.html]。

下面是一个脚本示例：

[root@localhost ~]# vim inventory.py
#!/usr/bin/env python

'''
Example custom dynamic inventory script for Ansible, in Python.
'''

import os
import sys
import argparse

try:
    import json
except ImportError:
    import simplejson as json

class ExampleInventory(object):

    def __init__(self):
        self.inventory = {}
        self.read_cli_args()

        # Called with `--list`.
        if self.args.list:
            self.inventory = self.example_inventory()
        # Called with `--host [hostname]`.
        elif self.args.host:
            # Not implemented, since we return _meta info `--list`.
            self.inventory = self.empty_inventory()
        # If no groups or vars are present, return empty inventory.
        else:
            self.inventory = self.empty_inventory()

        print json.dumps(self.inventory);

    # Example inventory for testing.
    def example_inventory(self):
        return {
            'group': {
                'hosts': ['172.16.103.129', '172.16.103.130'],
                'vars': {
                    'ansible_ssh_user': 'root',
                    'ansible_ssh_pass': '123456',
                    'example_variable': 'value'
                }
            },
            '_meta': {
                'hostvars': {
                    '172.16.103.129': {
                        'host_specific_var': 'foo'
                    },
                    '172.16.103.130': {
                        'host_specific_var': 'bar'
                    }
                }
            }
        }

    # Empty inventory for testing.
    def empty_inventory(self):
        return {'_meta': {'hostvars': {}}}

    # Read the command line args passed to the script.
    def read_cli_args(self):
        parser = argparse.ArgumentParser()
        parser.add_argument('--list', action = 'store_true')
        parser.add_argument('--host', action = 'store')
        self.args = parser.parse_args()

# Get the inventory.
ExampleInventory()

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

如何使用这个脚本呢？

chmod +x inventory.py
./inventory.py --list
./inventory.py --host 172.16.103.129

1
2
3

ansible使用这个动态清单来管理主机：

ansible all -i inventory.py -m ping
ansible 172.16.103.129 -i inventory.py -m ping

1
2

2.4 管理多个清单

Ansible支持在同一运行中使用多个清单。如果清单的位置是一个目录（不论是由**-i选项设置的、是inventory**参数的值，还是以某种其他方式设置的），将组合该目录中包含的所有清单文件（不论是静态还是动态）来确定清单。该目录中的可执行文件将用于检索动态清单，其他文件则被用作静态清单。

清单文件不应依赖于其他清单文件或脚本来解析。例如，如果静态清单文件指定某一个组应当是另一个组的子级，则它也需要具有该组的占位符条目，即使该组的所有成员都来自动态清单。

[cloud-east]

[servers]
test.demo.example.com

[servers:children]
cloud-east

1
2
3
4
5
6
7

这可以确保不论清单文件以什么顺序解析，它们在内部都一致。

注意
清单文件的解析顺序不是由文档指定的。目前，如果存在多个清单文件，它们会按照字母顺序进行解析。如果一个清单源依赖于另一个清单源的信息，则它们的加载顺序可能会确定清单文件是按预期工作还是引发错误。因此，务必要确保所有文件都自相一致，从而避免意外的错误。

Ansible会忽略清单目录中以特定后缀结尾的文件。这可以通过在Ansible配置文件中的inventory_ignore_extensions指令来控制。有关更多信息，请参阅Ansible官方文档。

使用动态清单：https://docs.ansible.com/ansible/latest/user_guide/intro_dynamic_inventory.html
开发动态清单：https://docs.ansible.com/ansible/latest/dev_guide/developing_inventory.html

3. 配置并行

3.1 使用分叉在ansible中配置并行

当Ansible处理playbook时，会按顺序运行每个play。确定play的主机列表之后，Ansible将按顺序运行每个任务。通常，所有主机必须在任何主机在play中启动下一个任务之前成功完成任务。

理论上，Ansible可以同时连接到play中的所有主机以执行每项任务。这非常适用于小型主机列表。但如果该play以数百台主机为目标，则可能会给控制节点带来沉重负担。

Ansible所进行的最大同时连接数由Ansible配置文件中的forks参数控制。默认情况下设为5，这可通过以下方式之一来验证。

[root@localhost ~]# grep forks /etc/ansible/ansible.cfg 
#forks          = 5

[root@localhost ~]# ansible-config dump|grep -i forks
DEFAULT_FORKS(default) = 5

[root@localhost ~]# ansible-config list|grep -i forks
DEFAULT_FORKS:
  description: Maximum number of forks Ansible will use to execute tasks on target
  - {name: ANSIBLE_FORKS}
  - {key: forks, section: defaults}
  name: Number of task forks

1
2
3
4
5
6
7
8
9
10
11
12

例如，假设Ansible控制节点配置了5个forks的默认值，并且play具有10个受管主机。Ansible将在前5个受管主机上执行play中的第一个任务，然后在其他5个受管主机上对第一个任务执行第二轮。在所有受管主机上执行第一个任务后，Ansible将继续一次在5受管主机的组中的所有受管主机上执行下一个任务。Ansible将依次对每个任务执行此操作，直到play结束。

forks的默认值设置得非常保守。如果你的控制节点正在管理Linux主机，则大多数任务将在受管主机上运行，并且控制节点的负载较少。在这种情况下，通常可以将forks的值设置得更高，可能接近100，然后性能就会提高。

如果playbook在控制节点上运行很多代码，则应明智地提高forks限值。如果使用Ansible管理网络路由器和交换机，则大多数模块在控制节点上运行而不是在网络设备上运行。由于这会增加控制节点上的负载，因此其支持forks数量增加的能力将显著低于仅管理Linux主机的控制节点。

可以从命令行覆盖Ansible配置文件中forks的默认设置。ansible和ansible-playbook命令均提供-f或–forks选项以指定要使用的forks数量。

3.2 管理滚动更新

通常，当Ansible运行play时，它会确保所有受管主机在启动任何主机进行下一个任务之前已完成每个任务。在所有受管主机完成所有任务后，将运行任何通知的处理程序。

但是，在所有主机上运行所有任务可能会导致意外行为。例如，如果play更新负载均衡Web服务器集群，则可能需要在进行更新时让每个Web服务器停止服务。如果所有服务器都在同一个play中更新，则它们可能全部同时停止服务。

避免此问题的一种方法是使用serial关键字，通过play批量运行主机。在下一批次启动之前，每批主机将在整个play中运行。

在下面的示例中，Ansible一次在两个受管主机上执行play，直至所有受管主机都已更新。Ansible首先在前两个受管主机上执行play中的任务。如果这两个主机中的任何一个或两个都通知了处理程序，则Ansible将根据这两个主机的需要运行处理程序。在这两个受管主机上执行完play时，Ansible会在接下来的两个受管主机上重复该过程。Ansible继续以这种方式运行play，直到所有受管主机都已更新。

---
- name: Rolling update
  hosts: webservers
  serial: 2
  tasks:
  - name: latest apache httpd package is installed
    yum:
      name: httpd
      state: latest
    notify: restart apache
    
  handlers:
  - name: restart apache
    service:
      name: httpd
      state: restarted

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

假设上一示例中的webservers组包含5个Web服务器，它们位于负载均衡器后面。将serial参数设置为2后，play一次将运行两台Web服务器。因此，5台Web服务器中的大多数服务器将始终可用。

相反，如果不使用serial关键字，将同时在5台Web服务器上执行play和生成的处理程序。这可能会导致服务中断，因为Web服务将在所有Web服务器上同时重新启动。

重要
出于某些目的，每批主机算作在主机子集上运行的完整play。这意味着，如果整个批处理失败，play就会失败，这将导致整个playbook运行失败。

在设置了serial: 2的上一个场景中，如果出现问题并且处理的前2个主机的play失败，则playbook将中止，其余3个主机将不会通过play运行。这是一个有用的功能，因为只有一部分服务器会不可用，使服务降级而不是中断。

serial关键字也可以指定为百分比。此百分比应用于play中的主机总数，以确定滚动更新批处理大小。无论百分比为何，每一工序的主机数始终为1或以上。

4. 包含和导入文件

4.1 管理大型playbook

如果playbook很长或很复杂，我们可以将其分成较小的文件以便于管理。可采用模块化方式将多个playbook组合为一个主要playbook，或者将文件中的任务列表插入play。这样可以更轻松地在不同项目中重用play或任务序列。

4.2 包含或导入文件

Ansible可以使用两种操作将内容带入playbook。可以包含内容，也可以导入内容。

包含内容是一个动态操作。在playbook运行期间，Ansible会在内容到达时处理所包含的内容。

导入内容是一个静态操作。在运行开始之前，Ansible在最初解析playbook时预处理导入的内容。

4.3 导入playbook

import_playbook指令允许将包含play列表的外部文件导入playbook。换句话说，可以把一个或多个额外playbook导入到主playbook中。

由于导入的内容是一个完整的playbook，因此import_playbook功能只能在playbook的顶层使用，不能在play内使用。如果导入多个playbook，则将按顺序导入并运行它们。

导入两个额外playbook的主playbook的简单示例如下所示：

- name: Prepare the web server
  import_playbook: web.yml
  
- name: Prepare the database server
  import_playbook: db.yml

1
2
3
4
5

还可以使用导入的playbook在主playbook中交替play。

- name: Play 1
  hosts: localhost
  tasks:
    - debug:
      msg: Play 1
      
- name: Import Playbook
  import_playbook: play2.yml

1
2
3
4
5
6
7
8

在此例中，Play 1首先运行，然后运行从play2.ymlplaybook中导入的play。

4.4 导入和包含任务

可以将任务文件中的任务列表导入或包含在play中。任务文件是包含一个任务平面列表的文件：

[root@localhost ~]# cat webserver_tasks.yml
- name: Installs the httpd package
  yum:
    name: httpd
    state: latest
    
- name: Starts the httpd service
  service:
    name: httpd
    state: started

1
2
3
4
5
6
7
8
9
10

4.4.1 导入任务文件

---
- name: Install web server
  hosts: webservers
  tasks:
  - import_tasks: webserver_tasks.yml

1
2
3
4
5

4.4.2 包含任务文件

---
- name: Install web server
  hosts: webservers
  tasks:
  - include_tasks: webserver_tasks.yml

1
2
3
4
5

4.4.3 任务文件的用例

4.4.4 管理任务文件

4.5 为外部play和任务定义变量

使用Ansible的导入和包含功能将外部文件中的play或任务合并到playbook中极大地增强了在Ansible环境中重用任务和playbook的能力。为了最大限度地提高重用可能性，这些任务和play文件应尽可能通用。变量可用于参数化play和任务元素，以扩大任务和play的应用范围。

例如，以下任务文件将安装Web服务所需的软件包，然后启用并启动必要的服务。

---
- name: Install the httpd package
  yum:
    name: httpd
    state: latest
- name: Start the httpd service
  service:
    name: httpd
    enabled: True
    state: started

1
2
3
4
5
6
7
8
9
10

如果如下例所示对软件包和服务元素进行参数化，则任务文件也可用于安装和管理其他软件及其服务，而不仅仅用于Web服务。

---
- name: Install the {{ package }} package
  yum:
    name: "{{ package }}"
    state: latest
- name: Start the {{ service }} service
  service:
    name: "{{ service }}"
    enabled: True
    state: started

1
2
3
4
5
6
7
8
9
10

随后，在将任务文件合并到一个playbook中时，定义用于执行该任务的变量，如下所示：

...output omitted...
  tasks:
    - name: Import task file and set variables
      import_tasks: task.yml
      vars:
        package: httpd
        service: service

1
2
3
4
5
6
7

Ansible使传递的变量可用于从外部文件导入的任务。

使用相同的技术使play文件更具有可重用性。将play文件合并到playbook中时，传递变量以用于执行该play，如下所示：

...output omitted...
- name: Import play file and set the variable
  import_playbook: play.yml
  vars:
    package: mariadb

1
2
3
4
5

09 利用角色简化playbook

1. 描述角色结构

1.1 利用角色构造ansible playbook

随着开发更多的playbook，我们可能会发现有很多机会重复利用以前缩写的playbook中的代码。或许，一个用于为某一应用配置MySQL数据库的play可以改变用途，通过利用不同的主机名、密码和用户来为另一个应用配置MySQL数据库。

但在现实中，这个play可能比较冗长且复杂，有许多包含或导入的文件，以及用于管理各种情况的任务和处理程序。将所有这些代码复制到另一playbook中可能比较困难。

Ansible角色提供了一种方法，让用户能以通用的方式更加轻松地重复利用Ansible代码。我们可以在标准化目录结构中打包所有任务、变量、文件、模板，以及调配基础架构或部署应用所需的其他资源。只需通过复制相关的目录，将角色从一个项目复制到另一个项目。然后，只需从一个play调用该角色就能执行它。

借助编写良好的角色，可以从playbook中向角色传递调整其行为的变量，设置所有站点相关的主机名、IP地址、用户名，或其他在本地需要的具体详细信息。例如，部署数据库服务器的角色可能已编写为支持多个变量，这些变量用于设置主机名、数据库管理员用户和密码，以及需要为安装进行自定义的其他参数。角色的作者也可以确保在选择不在play中设置变量值时，为这些变量设定合理的默认值。

Ansible角色具有下列优点：

• 角色可以分组内容，从而与他人轻松共享代码
• 可以编写角色来定义系统类型的基本要素：Web服务器、数据库服务器、Git存储库，或满足其他用途
• 角色使得较大型项目更容易管理
• 角色可以由不同的管理员并行开发

除了自行编写、使用、重用和共享角色外，还可以从其他来源获取角色。一些角色已包含在rhel-system-roles软件包中，用户也可以从Ansible Galaxy网站获取由社区提供支持的许多角色。

1.2 检查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/

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

以下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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Ansible角色子目录

并非每个角色都拥有所有这些目录。

1.3 定义变量和默认值

角色变量通过在角色目录层次结构中创建含有键值对的vars/main.yml文件来定义。与其他变量一样，这些角色变量在角色YAML文件中引用：{ { VAR_NAME }}。这些变量具有较高的优先级，无法被清单变量覆盖。这些变量旨在供角色的内部功能使用。

默认变量允许为可在play中使用的变量设置默认值，以配置角色或自定义其行为。它们通过在角色目录层次结构中创建含有键值对的defaults/main.yml文件来定义。默认变量具有任何可用变量中最低的优先级。它们很容易被包括清单变量在内的任何其他变量覆盖。这些变量旨在让用户在编写使用该角色的play时可以准确地自定义或控制它将要执行的操作。它们可用于向角色提供所需的信息，以正确地配置或部署某些对象。

在vars/main.yml或defaults/main.yml中定义具体的变量，但不要在两者中都定义。有意要覆盖变量的值时，应使用默认变量。

注意： 角色不应该包含特定于站点的数据。它们绝对不应包含任何机密，如密码或私钥。 这是因为角色应该是通用的，可以重复利用并自由共享。特定于站点的详细信息不应硬编码到角色中。 机密应当通过其他途径提供给角色。这是用户可能要在调用角色时设置角色变量的一个原因。play中设置的角色变量可以提供机密，或指向含有该机密的Ansible Vault加密文件。

1.4 在playbook中使用ansible角色

在playbook中使用角色非常简单。下例演示了调用Ansible角色的一种方式：

---
- hosts: remote.example.com
  roles:
    - role1
    - role2

1
2
3
4
5

对于每个指定的角色，角色任务、角色处理程序、角色变量和角色依赖项将按照顺序导入到playbook中。角色中的任何copy、script、template或include_tasks/import_tasks任务都可引用角色中相关的文件、模板或任务文件，且无需相对或绝对路径名称。Ansible将分别在角色的files、templates或tasks子目录中寻找它们。

如果使用roles部分将角色导入到play中，这些角色会在用户为该play定义的任何任务之前运行。

以下示例设置role2的两个角色变量var1和var2的值。使用role2时，任何defaults和vars变量都会被覆盖。

---
- hosts: remote.example.com
  roles:
    - role: role1
    - role: role2
      var1: val1
      var2: val2

1
2
3
4
5
6
7

以下是在此情形中用户可能看到的另一种等效的YAML语法：

---
- hosts: remote.example.com
  roles:
    - role: role1
    - { role: role2, var1: val1, var2: val2 }

1
2
3
4
5

尽管这种写法更精简，但在某些情况下它更加难以阅读。

重要 正如前面的示例中所示，内嵌设置的角色变量（角色参数）具有非常高的优先级。它们将覆盖大多数其他变量。 务必要谨慎，不要重复使用内嵌设置在play中任何其他位置的任何角色变量的名称，因为角色变量的值将覆盖清单变量和任何play中的vars。

1.5 控制执行顺序

对于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:
      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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

在上例中，每个部分中都执行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

1
2
3
4
5
6
7
8

注意 include_role模块是在Ansible 2.3中新增的，而import_role模块则是在Ansible 2.4中新增的。

2. 利用系统角色重用内容

2.1 红帽企业Linux系统角色

自RHEL7.4开始，操作系统随附了多个Ansible角色，作为rhel-system-roles软件包的一部分。在RHEL8中，该软件包可以从AppStream中获取。以下是每个角色的简要描述：

RHEL系统角色

系统角色的目的是在多个版本之间标准化红帽企业Linux子系统的配置。使用系统角色来配置版本6.10及以上的任何红帽企业Linux主机。

2.2 简化配置管理

举例而言，RHEL7的建议时间同步服务为chronyd服务。但在RHEL6中，建议的服务为ntpd服务。在混合了RHEL6和7主机的环境中，管理员必须管理这两个服务的配置文件。

借助RHEL系统角色，管理员不再需要维护这两个服务的配置文件。管理员可以使用rhel-system-roles.timesync角色来配置RHEL6和7主机的时间同步。一个包含角色变量的简化YAML文件可以为这两种类型的主机定义时间同步配置。

2.3 安装RHEL系统角色

RHEL系统角色由rhel-system-roles软件包提供，该软件包可从AppStream流获取。在Ansible控制节点上安装该软件包。

安装RHEL系统角色

yum -y install rhel-system-roles

1

安装后，RHEL系统角色位于**/usr/share/ansible/roles**目录中：

ls -l /usr/share/ansible/roles/

1

红帽企业Linux中的默认roles_path在路径中包含**/usr/share/ansible/roles**，因此在playbook引用这些角色时Ansible可以很轻松的找到它们。

注意 如果在当前Ansible配置文件中覆盖了roles_path，设置了环境变量ANSIBLE_ROLES_PATH，或者roles_path中更早列出的目录下存在另一个同名的角色，则Ansible可能无法找到系统角色。

2.4 访问RHEL系统角色的文档

安装后，RHEL系统角色的文档位于**/usr/share/doc/rhel-system-roles-/**目录中。文档按照子系统整理到子目录中：

[root@localhost ~]# ll /usr/share/doc/rhel-system-roles/
total 4
drwxr-xr-x 2 root root   57 Aug 22 15:26 kdump
drwxr-xr-x 2 root root 4096 Aug 22 15:26 network
drwxr-xr-x 2 root root   57 Aug 22 15:26 postfix
drwxr-xr-x 2 root root   93 Aug 22 15:26 selinux
drwxr-xr-x 2 root root   57 Aug 22 15:26 storage
drwxr-xr-x 2 root root  136 Aug 22 15:26 timesync

1
2
3
4
5
6
7
8

每个角色的文档目录均包含一个README.md文件。README.md文件含有角色的说明，以及角色用法信息。

README.md文件也会说明影响角色行为的角色变量。通常，README.md文件中含有一个playbook代码片段，用于演示常见配置场景的变量设置。

部分角色文档目录中含有示例playbook。首次使用某一角色时，请查看文档目录中的任何额外示例playbook。

RHEL系统角色的角色文档与Linux系统角色的文档相匹配。使用Web浏览器来访问位于Ansible Galaxy网站https://galaxy.ansible.com/docs/上的角色文档。

2.5 时间同步角色示例

假设需要在服务器上配置NTP时间同步。我们可以自行编写自动化来执行每一个必要的任务。但是，RHEL系统角色中有一个可以执行此操作角色，那就是rhel-system-roles.timesync。

该角色的详细记录位于**/usr/share/doc/rhel-system-roles/timesync目录下的README.md**中。此文件说明了影响角色行为的所有变量，还包含演示了不同时间同步配置的三个playbook代码片段。

为了手动配置NTP服务器，该角色具有一个名为timesync_ntp_servers的变量。此变量取一个要使用的NTP服务器的列表作为值。列表中的每一项均由一个或多个属性构成。两个关键属性如下：

timesync_ntp_servers属性

根据这一信息，以下示例play使用rhel-system-roles.timesync角色将受管主机配置为利用快速初始同步从三个NTP服务器获取时间。此外，还添加了一个任务，以使用timezone模块将主机的时区设为UTC。

- name: Time Synchronization Play
  hosts: servers
  vars:
    timesync_ntp_servers:
      - hostname: 0.rhel.pool.ntp.org
        iburst: yes
      - hostname: 1.rhel.pool.ntp.org
        iburst: yes
      - hostname: 2.rhel.pool.ntp.org
        iburst: yes
    timezone: UTC
    
  roles:
    - rhel-system-roles.timesync

  tasks:
    - name: Set timezone
      timezone:
        name: "{{ timezone }}"

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

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

此示例在play的vars部分中设置角色变量，但更好的做法可能是将它们配置为主机或主机组的清单变量。

例如一个playbook项目具有以下结构：

[root@localhost playbook-project]# tree
.
├── ansible.cfg
├── group_vars
│   └── servers
│       └── timesync.yml
├── inventory
└── timesync_playbook.yml

1
2
3
4
5
6
7
8

timesync.yml定义时间同步变量，覆盖清单中servers组内主机的角色默认值。此文件看起来类似于：

timesync_ntp_servers:
  - hostname: 0.rhel.pool.ntp.org
    iburst: yes
  - hostname: 1.rhel.pool.ntp.org
    iburst: yes
  - hostname: 2.rhel.pool.ntp.org
    iburst: yes
timezone: UTC

1
2
3
4
5
6
7
8

timesync_playbook.yml的内容简化为：

- name: Time Synchronization Play
  hosts: servers
  roles:
    - rhel-system-roles.timesync
  tasks:
    - name: Set timezone
      timezone:
        name: "{{ timezone }}"

1
2
3
4
5
6
7
8

该结构可清楚地分隔角色、playbook代码和配置设置。Playbook代码简单易读，应该不需要复杂的重构。角色内容由红帽进行维护并提供支持。所有设置都以清单变量的形式进行处理。

该结构还支持动态的异构环境。具有新的时间同步要求的主机可能会放置到新的主机组中。相应的变量在YAML文件中定义，并放置到相应的group_vars（或host_vars）子目录中。

2.6 SELINUX角色示例

rhel-system-roles.selinux角色可以简化SELinux配置设置的管理。它通过利用SELinux相关的Ansible模块来实施。与自行编写任务相比，使用此角色的优势是它能让用户摆脱编写这些任务的职责。取而代之，用户将为角色提供变量以对其进行配置，且角色中维护的代码将确保应用用户需要的SELinux配置。

此角色可以执行的任务包括：

• 设置enforcing或permissive模式
• 对文件系统层次结构的各部分运行restorecon
• 设置SELinux布尔值
• 永久设置SELinux文件上下文
• 设置SELinux用户映射

2.7 调用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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

2.8 配置SELinux角色

用于配置rhel-system-roles.selinux角色的变量的详细记录位于其README.md文件中。以下示例演示了使用此角色的一些方法。

selinux_state变量设置SELinux的运行模式。它可以设为enforcing、permissive或disabled。如果未设置，则不更改模式。

selinux_state: enforcing

1

selinux_booleans变量取一个要调整的SELinux布尔值的列表作为值。列表中的每一项是变量的散列/字典：布尔值的name、state（它应是on还是off），以及该设置是否应在重新引导后persistent。

本例将httpd_enable_homedirs永久设为on：

selinux_booleans:
  - name: 'httpd_enable_homedirs'
    state: 'on'
    persistent: 'yes'

1
2
3
4

selinux_fcontext变量取一个要永久设置（或删除）的文件上下文的列表作为值。它的工作方式与selinux fcontent命令非常相似。

以下示例确保策略中包含一条规则，用于将/srv/www下所有文件的默认SELinux类型设为httpd_sys_content_t。

selinux_fcontexts:
  - target: '/srv/www(/.*)?'
    setype: 'httpd_sys_content_t'
    state: 'present'

1
2
3
4

selinux_restore_dirs变量指定要对其运行restorecon的目录的列表：

selinux_restore_dirs:
  - /srv/www

1
2

selinux_ports变量取应当具有特定SELinux类型的端口的列表作为值。

selinux_ports:
  - ports: '82'
    setype: 'http_port_t'
    proto: 'tcp'
    state: 'present'

1
2
3
4
5

3. 创建角色

角色创建流程
在Ansible中创建角色不需要特别的开发工具。创建和使用角色包含三个步骤：

1. 创建角色目录结构
2. 定义角色内容
3. 在playbook中使用角色

3.1 创建角色目录结构

默认情况下，Ansible在Ansible Playbook所在目录的roles子目录中查找角色。这样，用户可以利用playbook和其他支持文件存储角色。

如果Ansible无法在该位置找到角色，它会按照顺序在Ansible配置设置roles_path所指定的目录中查找。此变量包含要搜索的目录的冒号分隔列表。此变量的默认值为：

~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles

1

这允许用户将角色安装到由多个项目共享的系统上。例如，用户可能将自己的角色安装在自己的主目录下的~/.ansible/roles子目录中，而系统可能将所有用户的角色安装在/usr/share/ansible/roles目录中。

每个角色具有自己的目录，采用标准化的目录结构。例如，以下目录结构包含了定义motd角色的文件。

[root@localhost ~]# tree roles/
roles/
└── motd
    ├── defaults
    │   └── main.yml
    ├── files
    ├── handlers
    ├── meta
    │   └── main.yml
    ├── tasks
    │   └── main.yml
    └── templates
        └── motd.j2

1
2
3
4
5
6
7
8
9
10
11
12
13

README.md提供人类可读的基本角色描述、有关如何使用该角色的文档和示例，以及其发挥作用所需要满足的任何非Ansible要求。
meta子目录包含一个main.yml文件，该文件指定有关模块的作者、许可证、兼容性和依赖项的信息。
files子目录包含固定内容的文件，而templates子目录则包含使用时可由角色部署的模板。
其他子目录中可以包含main.yml文件，它们定义默认的变量值、处理程序、任务、角色元数据或变量，具体取决于所处的子目录。

如果某一子目录存在但为空，如本例中的handlers，它将被忽略。如果某一角色不使用功能，则其子目录可以完全省略。例如，本例中的vars子目录已被省略。

3.2 创建角色框架

可以使用标准Linux命令创建新角色所需的所有子目录和文件。此外，也可以通过命令行实用程序来自动执行新角色创建过程。

ansible-galaxy命令行工具可用于管理Ansible角色，包括新角色的创建。用户可以运行ansible-galaxy init来创建新角色的目录结构。指定角色的名称作为命令的参数，该命令在当前工作目录中为新角色创建子目录。

[root@localhost playbook-project]# cd roles/
[root@localhost roles]# ansible-galaxy init my_new_role
- Role my_new_role was created successfully
[root@localhost roles]# ls my_new_role/
defaults  files  handlers  meta  README.md  tasks  templates  tests  vars

1
2
3
4
5

3.3 定义角色内容

创建目录结构后，用户必须编写角色的内容。ROLENAME/tasks/main.yml任务文件是一个不错的起点，它是由角色运行的主要任务列表。

下列tasks/main.yml文件管理受管主机上的/etc/motd文件。它使用template模块将名为motd.j2的模板部署到受管主机上。因为template模块是在角色任务而非playbook任务内配置的，所以从角色的templates子目录检索motd.j2模板。

[root@localhost ~]# cat roles/motd/tasks/main.yml
---
# tasks file for motd

- name: deliver motd file
  template:
    src: motd.j2
    dest: /etc/motd
    owner: root
    group: root
    mode: 0444

1
2
3
4
5
6
7
8
9
10
11

下列命令显示motd角色的motd.j2模板的内容。它引用了Ansible事实和system_owner变量。

[root@localhost ~]# cat roles/motd/templates/motd.j2
This is the system {{ ansible_facts['hostname'] }}.

Today's date is: {{ ansible_facts['date_time']['date'] }}.

Only use this system with permission.
You can ask {{ system_owner }} for access.

1
2
3
4
5
6
7

该角色为system_owner变量定义一个默认值。角色目录结构中的defaults/main.yml文件就是设置这个值的位置。

下列defaults/main.yml文件将system_owner变量设置为user@host.example.com。此电子邮件地址将写入到该角色所应用的受管主机上的/etc/motd文件中。

[root@localhost ~]# cat roles/motd/defaults/main.yml
---
system_owner: user@host.example.com

1
2
3

3.4 角色内容开发的推荐做法

角色允许以模块化方式编写playbook。为了最大限度地提高新开发角色的效率，请考虑在角色开发中采用以下推荐做法：

• 在角色自己的版本控制存储库中维护每个角色。Ansible很适合使用基于git的存储库。
• 角色存储库中不应存储敏感信息，如密码或SSH密钥。敏感值应以变量的形式进行参数化，其默认值应不敏感。使用角色的playbook负责通过Ansible Vault变量文件、环境变量或其他ansible-playbook选项定义敏感变量。
• 使用ansible-galaxy init启动角色，然后删除不需要的任何目录和文件。
• 创建并维护README.md和meta/main.yml文件，以记录用户的角色的用途、作者和用法。
• 让角色侧重于特定的用途或功能。可以编写多个角色，而不是让一个角色承担许多任务。
• 经常重用和重构角色。避免为边缘配置创建新的角色。如果现有角色能够完成大部分的所需配置，请重构现有角色以集成新的配置方案。使用集成和回归测试技术来确保角色提供所需的新功能，并且不对现有的playbook造成问题。

3.5 定义角色依赖项

角色依赖项使得角色可以将其他角色作为依赖项包含在内。例如，一个定义文档服务器的角色可能依赖于另一个安装和配置web服务器的角色。依赖关系在角色目录层次结构中的meta/main.yml文件内定义。

以下是一个示例meta/main.yml文件。

dependencies:
  - role: apache
    port: 8080
  - role: postgres
    dbname: serverlist
    admin_user: felix

1
2
3
4
5
6

默认情况下，角色仅作为依赖项添加到playbook中一次。若有其他角色也将它作为依赖项列出，它不会再次运行。此行为可以被覆盖，将meta/main.yml文件中的allow_duplicates变量设置为yes即可。

重要 限制角色对其他角色的依赖。依赖项使得维护角色变得更加困难，尤其是当它具有许多复杂的依赖项时。

3.6 在playbook中使用角色

要访问角色，可在play的roles:部分引用它。下列playbook引用了motd角色。由于没有指定变量，因此将使用默认变量值应用该角色。

[root@localhost ~]# cat use-motd-role.yml
---
- name: use motd role playbook
  hosts: remote.example.com
  remote_user: devops
  become: true
  roles:
    - motd

1
2
3
4
5
6
7
8

执行该playbook时，因为角色而执行的任务可以通过角色名称前缀来加以识别。

[root@localhost ~]# ansible-playbook -i inventory use-motd-role.yml

1

上述情形假定motd角色位于roles目录中。

3.7 通过变量更改角色的行为

编写良好的角色利用默认变量来改变角色行为，使之与相关的配置场景相符。这有助于让角色变得更为通用，可在各种不同的上下文中重复利用。

如果通过以下方式定义了相同的变量，则角色的defaults目录中定义的变量的值将被覆盖：

• 在清单文件中定义，作为主机变量或组变量
• 在playbook项目的group_vars或host_vars目录下的YAML文件中定义
• 作为变量嵌套在play的vars关键字中定义
• 在play的roles关键字中包含该角色时作为变量定义

下例演示了如何将motd角色与system_owner角色变量的不同值搭配使用。角色应用到受管主机时，指定的值someone@host.example.com将取代变量引用。

[root@localhost ~]# cat use-motd-role.yml
---
- name: use motd role playbook
  hosts: remote.example.com
  remote_user: devops
  become: true
  vars:
    system_owner: someone@host.example.com
  roles:
    - role: motd

1
2
3
4
5
6
7
8
9
10

以这种方式定义时，system_owner变量将替换同一名称的默认变量的值。嵌套在vars关键字内的任何变量定义不会替换在角色的vars目录中定义的同一变量的值。

下例也演示了如何将motd角色与system_owner角色变量的不同值搭配使用。指定的值someone@host.example.com将替换变量引用，不论是在角色的vars还是defaults目录中定义。

[root@localhost ~]# cat use-motd-role.yml
---
- name: use motd role playbook
  hosts: remote.example.com
  remote_user: devops
  become: true
  roles:
    - role: motd
      system_owner: someone@host.example.com

1
2
3
4
5
6
7
8
9

重要 在play中使用角色变量时，变量的优先顺序可能会让人困惑。 - 几乎任何其他变量都会覆盖角色的默认变量，如清单变量、playvars变量，以及内嵌的角色参数等。 - 较少的变量可以覆盖角色的vars目录中定义的变量。事实、通过include_vars加载的变量、注册的变量和角色参数是其中一些具备这种能力的变量。清单变量和playvars无此能力。这非常重要，因为它有助于避免用户的play意外改变角色的内部功能。 - 不过，正如上述示例中最后一个所示，作为角色参数内嵌声明的变量具有非常高的优先级。它们可以覆盖角色的vars目录中定义的变量。如果某一角色参数的名称与playvars或角色vars中设置的变量或者清单变量或playbook变量的名称相同，该角色参数将覆盖另一个变量。

4 使用ansible galaxy部署角色

4.1 介绍ansible galaxy

Ansible Galaxy [https://galaxy.ansible.com]是一个Ansible内容公共资源库，这些内容由许许多多Ansible管理员和用户编写。它包含数千个Ansible角色，具有可搜索的数据库，可帮助Ansible用户确定或许有助于他们完成管理任务的角色。Ansible Galaxy含有面向新的Ansible用户和角色开发人员的文档和视频链接。

此外，用于从Ansible Galaxy获取和管理角色的ansible-galaxy命令也可用于为您的项目获取和管理自有的git存储库中的角色。

4.1.1 获取Ansible Galaxy帮助

4.1.2 浏览Ansible Galaxy中的角色

4.2 Ansible Galaxy命令行工具

4.2.1 从命令行搜索角色

ansible-galaxy search 'redis' --platforms EL

1

ansible-galaxy info geerlingguy.redis

1

4.2.2 从Ansible Galaxy安装角色

ansible-galaxy install geerlingguy.redis -p roles/

1

4.2.3 使用要求文件安装角色

- src: geerlingguy.redis
  version: "1.5.0"

1
2

ansible-galaxy install -r roles/requirements.yml -p roles

1

[root@localhost project]# cat roles/requirements.yml
# from Ansible Galaxy, using the latest version
- src: geerlingguy.redis

# from Ansible Galaxy, overriding the name and using a specific version
- src: geerlingguy.redis
  version: "1.5.0"
  name: redis_prod
  
# from any Git-based repository, using HTTPS
- src: https://gitlab.com/guardianproject-ops/ansible-nginx-acme.git
  scm: git
  version: 56e00a54
  name: nginx-acme
  
# from any Git-based repository, using SSH
- src: git@gitlab.com:guardianproject-ops/ansible-nginx-acme.git
  scm: git
  version: master
  name: nginx-acme-ssh
  
# from a role tar ball, given a URL
# supports 'http', 'https', or 'file' protocols
- src: file:///opt/local/roles/myrole.tar
  name: myrole

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

[root@localhost project]# ansible-galaxy install -r roles/requirements.yml -p roles

1

4.2.4 管理下载的角色

ansible-galaxy list

1

ansible-galaxy remove nginx-acme-ssh
ansible-galaxy list

1
2

[root@localhost project]# cat use-role.yml
---
- name: use redis_prod for prod machines
  hosts: redis_prod_servers
  remote_user: devops
  become: True
  roles:
    - redis_prod

- name: use geerlingguy.redis for Dev machines
  hosts: redis_dev_servers
  remote_user: devops
  become: True
  roles:
    - geerlingguy.redis

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

4.1.1 获取Ansible Galaxy帮助

4.1.2 浏览Ansible Galaxy中的角色

4.2 Ansible Galaxy命令行工具

4.2.1 从命令行搜索角色

ansible-galaxy search 'redis' --platforms EL

1

ansible-galaxy info geerlingguy.redis

1

4.2.2 从Ansible Galaxy安装角色

ansible-galaxy install geerlingguy.redis -p roles/

1

4.2.3 使用要求文件安装角色

- src: geerlingguy.redis
  version: "1.5.0"

1
2

ansible-galaxy install -r roles/requirements.yml -p roles

1

[root@localhost project]# cat roles/requirements.yml
# from Ansible Galaxy, using the latest version
- src: geerlingguy.redis

# from Ansible Galaxy, overriding the name and using a specific version
- src: geerlingguy.redis
  version: "1.5.0"
  name: redis_prod
  
# from any Git-based repository, using HTTPS
- src: https://gitlab.com/guardianproject-ops/ansible-nginx-acme.git
  scm: git
  version: 56e00a54
  name: nginx-acme
  
# from any Git-based repository, using SSH
- src: git@gitlab.com:guardianproject-ops/ansible-nginx-acme.git
  scm: git
  version: master
  name: nginx-acme-ssh
  
# from a role tar ball, given a URL
# supports 'http', 'https', or 'file' protocols
- src: file:///opt/local/roles/myrole.tar
  name: myrole

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

[root@localhost project]# ansible-galaxy install -r roles/requirements.yml -p roles

1

4.2.4 管理下载的角色

ansible-galaxy list

1

ansible-galaxy remove nginx-acme-ssh
ansible-galaxy list

1
2

[root@localhost project]# cat use-role.yml
---
- name: use redis_prod for prod machines
  hosts: redis_prod_servers
  remote_user: devops
  become: True
  roles:
    - redis_prod

- name: use geerlingguy.redis for Dev machines
  hosts: redis_dev_servers
  remote_user: devops
  become: True
  roles:
    - geerlingguy.redis

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15