Ansible-真实世界的自动化指南-全-

Ansible 真实世界的自动化指南（全）

原文：annas-archive.org/md5/45da098d029511fe40b242af6b47fdaa

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

自动化是 IT 现代化的关键，使用正确的自动化工具是组织自动化旅程中的关键一步。Ansible 是一款开源自动化软件，您可以使用它来自动化大多数 IT 和应用基础设施组件的操作，包括服务器、存储、网络和应用平台。Ansible 是目前 IT 领域最知名的开源自动化工具之一，并且拥有强大的社区支持，全球有超过 5000 名活跃贡献者。

Ansible 不是一种通过阅读学习的技术。本书将通过实际的 playbook、配置和实践示例，帮助你理解并实践 Ansible 的自动化功能。它将帮助你理解 Ansible 自动化的基础，并且随着学习的深入，你将逐步学会如何使用 Ansible 自动化日常任务。

你将学习到实际的 IT 自动化用例和实践示例，如简单的系统报告、安全扫描和每周重启 Linux 机器。之后，书中将教你如何在 Ansible 自动化中实现协作，以及如何自动化其他设备和平台，如 Microsoft Windows、网络设备、VMware、AWS 和 GCP。你还将学习如何在 DevOps 工作流程中使用 Ansible，结合 Jenkins 进行集成，以及在 Kubernetes 上管理容器和应用程序。为了进一步扩展你在企业自动化方面的知识，本书还将教你 Red Hat Ansible 自动化平台、机密管理以及 Ansible 与其他工具（如 Jira 和 ServiceNow）的集成。本书中还有章节讲解如何使用原始命令和 API 调用通过 Ansible 自动化不被支持的设备和平台。在书籍结束之前，你还将探索如何为生产环境存储被管理节点信息、变量、凭证和 playbook 的 Ansible 最佳实践。

完成Ansible 实践自动化后，你将具备在工作环境中发现自动化用例、设计和部署自动化解决方案的技能。

本书适合的人群

本书面向希望使用 Ansible 作为自动化工具的系统工程师和 DevOps 工程师。书中提供了参考资料和实际示例，帮助你在工作环境中启动 IT 自动化。

本书内容

第一章，Ansible 自动化—简介，为你介绍了 Ansible，并教你如何安装和配置 Ansible 以及配置被管理的节点。

第二章，从简单的自动化开始，教你如何识别可以自动化的手动任务，找到合适的 Ansible 模块，并使用文本编辑器进行 Ansible 配置。

第三章，自动化你的日常工作，是你开始为实际用例开发 Ansible playbook 的章节，涉及系统信息收集、系统重启和安全扫描等内容。你还将学习 Ansible 集合、Ansible 中的机密管理以及自动化通知。

第四章，探索自动化开发中的协作，讲解了版本控制在 IT 自动化中的重要性，并介绍了使用源代码管理工具存储 Ansible 工件的最佳实践。

第五章，扩展你的自动化视野，介绍了如何从工作场所中发现自动化的应用场景，并检查自动化的可行性。本章还教你如何在 Ansible 中使用动态清单。

第六章，自动化 Microsoft Windows 和网络设备，是你发现使用 Ansible 自动化 Microsoft Windows 和网络设备的可能性。本章将涵盖 Windows 自动化、VyOS 信息收集以及在 Cisco ASA 设备上创建访问控制列表等实际示例。

第七章，管理你的虚拟化和云平台，讲解了基础设施即代码（IaC）的概念，并介绍了如何将 Ansible 用作 IaC 工具，提供了管理 VMware、AWS 和 GCP 平台的实际示例。

第八章，帮助数据库团队实现自动化，介绍了数据库操作的基础知识，例如安装数据库服务器、创建数据库、表格和数据库用户。

第九章，在 DevOps 流程中实现自动化，是你将学习 DevOps 及其在 DevOps 流程中使用 Ansible 的章节，提供了减少部署时间、管理应用负载均衡器和滚动更新的实际示例。本章还讲解了如何将 Ansible 与 Terraform 集成。

第十章，使用 Ansible 管理容器，继续探讨 Ansible 和 DevOps，介绍了如何使用 Ansible 管理应用容器。本章涉及的实际应用包括部署容器主机、在 CI/CD 流水线中使用 Ansible、构建容器以及管理多容器应用。

第十一章，使用 Ansible 管理 Kubernetes，深入探讨基于容器的应用场景，介绍了 Kubernetes，并讲解了如何使用 Ansible 管理 Kubernetes 集群和应用程序。本章教你如何在 Kubernetes 平台上部署、管理和扩展容器化应用。

第十二章，将 Ansible 与您的工具集成，介绍了企业自动化工具 Red Hat Ansible Automation Platform（AAP）。本章教您如何使用 AAP 进行自动化，并通过实际案例，如数据库管理、Jenkins 集成和 Slack 通知，来讲解这些方法。

第十三章，使用 Ansible 进行密钥管理，解释了使用 Ansible Vault 处理自动化中的敏感数据的方法，以及如何在 Ansible playbook 中使用加密数据。

第十四章，保持自动化简单高效，教您关于 Ansible 自动化控制器中的调查表单和工作流作业模板的内容。本章还涵盖了安全自动化及将 Ansible 集成到监控工具中的方法。

第十五章，自动化非标准平台和操作，教您如何使用原始命令和 API 命令自动化处理不受支持的平台。本章还教您如何开发自定义 Ansible 模块，以便在没有现成模块时使用。

第十六章，Ansible 在生产环境中的最佳实践，是您学习 Ansible 生产环境最佳实践的章节，内容包括如何组织 Ansible 制品、库存和变量。本章还涵盖了凭证管理和 playbook 开发的最佳实践。

为了充分利用本书

在本书中，我将首先指导您完成 Ansible 自动化工具的安装和部署，之后，我将解释一些实际的 IT 使用案例和如何使用 Ansible 自动化这些操作的方法。由于本书的重点是不同的自动化使用案例，部分章节可能会有额外的技术要求，如对某项特定技术的基础知识或对实验环境（如 Kubernetes 集群）的访问。对于这一点，如果您想进行实践，我还介绍了如何安排开发环境的方法。请始终参考 Ansible 文档 docs.ansible.com 和章节中提供的其他链接以进一步学习。

对于测试和开发，您可以获得免费的 RHEL 订阅（developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux）。也可以将 RHEL8 替换为其他操作系统，如 Fedora、CentOS 或 Ubuntu，但可能需要调整 playbook 中的某些命令和模块。

如果你正在阅读本书的电子版或数字版，建议自己输入命令并编写 playbook，而不是从书中复制粘贴。然而，你可以访问本书的 GitHub 仓库（下一节会提供链接）来查看代码、代码片段和 playbooks，供参考。

下载示例代码文件

你可以从 GitHub 上下载本书的示例代码文件，链接为 github.com/PacktPublishing/Ansible-for-Real-life-Automation。如果代码有更新，GitHub 仓库中的代码会进行更新。你可以指出代码示例中的问题或提交与本书相关的任何问题，通过在 GitHub 仓库中创建问题票据来联系。

我们还提供了其他代码包，来自我们丰富的书籍和视频目录，网址是 github.com/PacktPublishing/。欢迎查看！

下载彩色图片

我们还提供了包含书中截图/图表彩色图片的 PDF 文件。你可以在这里下载：packt.link/TVh0m。

使用的规范

本书中使用了若干文本规范。

文本中的代码：表示文本中的代码词汇、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 账户名。示例：“配置 KUBECONFIG 环境变量，因为我们的 kubeconfig 文件名与默认文件名不同（/home/ansible/.kube/minikube-config 与 /home/ansible/.kube/config）。”

代码块如下所示：

[ansible@ansible Chapter-11]$ export KUBECONFIG=$KUBECONFIG:/home/ansible/.kube/minikube-config

一些代码片段和输出以图片形式展示，以便更好地阅读和简洁表达。

粗体：表示新术语、重要单词或你在屏幕上看到的词汇。例如，菜单或对话框中的词汇会以这种方式出现在文本中。示例：“更新你的作业模板，并通过进入 Job Template | Edit，然后点击 Credential 旁边的 Search 按钮，添加新的 vault 凭证。”

提示或重要说明

显示方式如下。

联系我们

我们欢迎读者的反馈。

一般反馈：如果你对本书的任何部分有疑问，请在邮件主题中提及书名，并通过 customercare@packtpub.com 向我们发送邮件。

勘误：虽然我们已经尽最大努力确保内容的准确性，但错误还是有可能发生。如果你在本书中发现了错误，感谢你向我们报告。请访问 www.packtpub.com/support/errata，选择你的书籍，点击勘误提交表格链接，并填写详细信息。

盗版：如果您在互联网上遇到任何非法复制的作品，我们将非常感激您提供材料的地址或网站名称。请通过 copyright@packt.com 联系我们，并附上相关链接。

如果您有兴趣成为作者：如果您在某个领域具有专业知识，并且有兴趣撰写或参与书籍创作，请访问 authors.packtpub.com。

分享您的想法

阅读完 Ansible 实践自动化 后，我们很期待听到您的想法！请点击这里直接进入亚马逊书评页面并分享您的反馈。

您的反馈对我们和技术社区非常重要，将帮助我们确保提供高质量的内容。

第一部分：将 Ansible 作为您的自动化工具

在这一部分中，您将清晰地了解如何开始使用 Ansible 自动化，并自动化您的基本日常工作。

本书的这一部分包含以下章节：

第一章**，Ansible 自动化——简介
第二章**，从简单的自动化开始
第三章**，自动化您的日常工作
第四章**，探索自动化开发中的协作

第一章：Ansible 自动化 – 介绍

Ansible 是一个开源的自动化和编排软件，可用于自动化大多数 IT 基础设施组件的操作，包括服务器、存储、网络和应用平台。Ansible 是目前 IT 世界中最受欢迎的自动化工具之一，并且有强大的社区支持，全球有超过 5,000 名贡献者。

本章节我们将涵盖以下主题：

什么是 Ansible？我应该在哪里使用这个自动化工具？
部署 Ansible
配置你的管理节点

截至目前，Ansible 仅在 Linux/Unix 平台上可用，但这并不意味着你不能使用 Ansible 来自动化其他操作系统（OSs）或设备。实际上，使用 Ansible 可以自动化几乎所有与 IT 基础设施相关的组件，因为有成千上万个支持的模块可以支持 Ansible 自动化。

技术要求

以下是继续本章节所需的技术要求：

对 Linux 操作系统有基本了解，并能够处理 Linux 中的基本操作
一台或多台 Linux 机器

本章节中使用的代码和代码片段在Red Hat Enterprise Linux 8（RHEL8）上进行了测试。本章节的所有 Ansible 代码、Ansible playbooks、命令和代码片段可以在 GitHub 仓库中找到，网址为：github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-01。

你好，工程师们！

系统工程师的主要职责是构建和管理用于托管应用程序及其数据的 IT 基础设施。过去，使用的应用程序数量较少，因此基础设施的规模也较小。随着应用程序和组件的增长，IT 基础设施也在不断扩展，系统工程师和系统管理员开始遇到资源瓶颈。换句话说，系统工程师花更多时间在构建、维护和支持基础设施上，而不是花时间改进和优化基础设施设计。

对于支持团队来说，90%的事件工单都是简单的修复，包括磁盘空间满、用户账户被锁定、卷未挂载等等。但支持工程师仍然需要手动登录每一台服务器，逐一解决这些问题。

任务可能包括修复服务器上的磁盘空间不足问题、安装某些软件包、修补操作系统、创建虚拟机或重置用户密码；工程师在多个系统上重复执行相同的工作，这促使了自动化操作的发明。最初，自动化的解决方案是由个别工程师开发和维护的自定义脚本，但由于缺乏协作、维护或责任机制，这些自定义自动化脚本并没有成为企业的真正解决方案。如果开发人员离开公司，脚本就会变成孤儿，接下来的工程师将创建自己的自定义脚本。

随着 DevOps 方法论和实践的引入，开发人员、系统工程师、运维团队和其他平台团队开始协作，彼此之间的界限变得越来越模糊，形成了一个更具责任感的生态系统。每个人开始构建和维护应用程序及其底层 IT 基础设施，这反过来使得自动化的使用场景变得更加复杂和庞大。

什么是 Ansible？我应该在哪里使用这个工具？

Ansible 是一个开源自动化工具，由 Michael DeHaan 于 2012 年 2 月 20 日编写并发布。2013 年，Ansible, Inc.（最初名为AnsibleWorks, Inc.）由 Michael DeHaan、Timothy Gerla 和 Saïd Ziouani 创立，他们的目标是为 Ansible 提供商业支持和赞助。2015 年，Ansible 被 Red Hat 收购，Red Hat 按照开源社区的期望，支持并推广 Ansible。

截至目前，Ansible 控制节点仅适用于基于 Linux/Unix 的平台（如 Red Hat Enterprise Linux、CentOS、Fedora、Debian 或 Ubuntu 等大多数通用操作系统），无法在 Windows 上原生安装（可以使用 Windows 子系统 for Linux 或虚拟机来实现）。这并不意味着你不能使用 Ansible 来自动化 Windows 操作。你可以在 Linux 上使用 Ansible 控制节点，管理 Windows 机器以及其他设备和平台，如网络设备、防火墙设备、云平台和容器平台。截至目前，有超过 3200 个 Ansible 模块可供使用，对于 Windows 操作系统，单独有超过 100 个 Ansible 模块来自动化 Windows 操作。

Ansible 支持的 Windows 操作系统

Ansible 可以管理包括 Windows 7、8.1 和 10 在内的桌面操作系统，以及包括 Windows Server 2008、2008 R2、2012、2012 R2、2016 和 2019 在内的服务器操作系统。有关更多详细信息，请参考 docs.ansible.com/ansible/latest/user_guide/windows_setup.xhtml#host-requirements。

Ansible 的社区版本像其他开源软件一样可以免费使用，但红帽也提供基于 Ansible 的产品——红帽 Ansible 自动化平台，该平台需要付费订阅。你可以使用社区版 Ansible 或带有订阅的红帽支持版本。Ansible 自动化平台面向企业使用，提供如 基于角色的访问控制（RBAC）、图形用户界面（GUI）、应用程序编程接口（API）、冗余和可扩展性等功能。当你需要为更大的团队、多个工程师共同工作时，考虑这些选项，尤其是在你需要审计、追踪和其他集成时。详细了解 Ansible 自动化平台，请访问 www.ansible.com/products/automation-platform。

红帽 Ansible 自动化平台

红帽的企业自动化产品在 2019 年 9 月之前被称为 Ansible Tower，直到宣布推出红帽 Ansible 自动化平台（www.ansible.com/blog/introducing-red-hat-ansible-automation-platform）。Ansible 自动化平台中的组件被重新命名为更有意义的名称，如自动化控制器和执行环境。详细了解 Ansible 自动化平台，请访问 www.redhat.com/en/technologies/management/ansible。

Ansible 文档可在 docs.ansible.com 获取。

前提条件

我们将在一个名为 Ansible 剧本 的 YAML 文件中编写自动化步骤。Ansible 将解析剧本文件并在目标机器上执行任务：

你应该了解 Linux 基础知识；正如我之前提到的，目前只能在 Linux 或 Unix 机器上安装 Ansible。这并不意味着你需要成为 Linux 专家，但你需要能够处理 Linux 中的基本操作，如文件管理和文件编辑。
你需要理解 YAML 语法，这很简单，因为 YAML 是最容易阅读的文件格式之一。

Ansible 基于 Python 编程语言，但你无需学习 Python 或任何编程语言即可开发 Ansible 自动化剧本。

什么是 YAML？

YAML 不是标记语言（YAML）是一种人类可读的语言格式，广泛应用于现代工具和软件中，包括 Ansible、Kubernetes 和 OpenShift。例如，YAML 常用作应用程序数据和配置的文件格式。

Ansible 控制节点要求

Ansible 控制节点机器没有特定的硬件要求。可以使用具有 512 MB 内存和一个虚拟中央处理单元（vCPU）的机器。遵循一些标准的虚拟机（VM）规范，例如 4 GB 或更高，因为在管理更多节点和并行运行更多任务时，可能需要更多的内存。至于磁盘，你可以遵循标准的虚拟机规范，因为 Ansible 是一个小型程序，不需要太多的磁盘空间。使用任何安装了 Python 3.8 或更新版本的 Linux/Unix 机器。

Ansible 控制节点要求

在 https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.xhtml#control-node-requirements 查找 Ansible 控制节点要求。

Ansible 管理节点要求

目标节点（管理节点）应该安装 Python 2.6 或更高版本（推荐使用 3.x），以便执行任务。对于 Windows 机器，需要安装 PowerShell 和.NET。

Ansible 还支持以下内容：

网络设备
VMware
公有云如 AWS、Azure 和 GCP
安全设备

Python 2.x 结束生命周期

在具有 Python 2.x 的机器上安装 Ansible，但 Python 2.x 已经在 2020 年 1 月 1 日结束生命周期（EOL），最好使用最新版本的 Python。有关 Python 2 结束生命周期的更多细节，请访问www.python.org/doc/sunset-python-2/。

Ansible 是无代理的

Ansible 自动化涉及两种类型的机器。安装 Ansible 程序的机器被称为Ansible 控制节点。控制节点可以是任何机器，一台专用服务器，甚至是你的工作站，它会存放你的 Ansible 剧本和其他配置。然后，你想要自动化的机器或设备被称为受管主机。你将从控制节点运行 Ansible 任务和剧本，这些任务将在目标节点或受管节点上执行。

下图展示了 Ansible 的基本组件：

图 1.1 – Ansible 及其组件

Ansible 是无代理的，你不需要在管理节点上安装任何类型的代理。Ansible 使用默认的连接方式与管理节点进行通信，例如ssh、WinRM、http或其他适当的协议。在上手过程中，你需要配置管理节点的凭证，例如使用 SSH 密钥的 SSH 凭证，或用于 WinRM 连接的 SSL 证书。这是一次性设置，之后可以随时配置或更改。你可以为不同的管理节点使用相同或不同的凭证，并为单个节点或一组管理节点配置凭证。在本章的后续章节中，你将了解受管节点和清单。

Ansible 架构

下图展示了 Ansible 内部结构及其组件的结构：

图 1.2 – Ansible 和组件

Ansible 库存

Ansible 库存是一个文件或脚本，提供有关受管节点的详细信息，包括主机名、连接方式、使用的凭证以及其他许多细节。可以通过静态库存文件、动态库存脚本或使用配置管理数据库（CMDB）将库存传递给 Ansible。CMDB 就是提供受管节点信息的 CMDB。最佳实践是在环境中将 CMDB 与 Ansible 集成，以避免频繁更新静态库存文件，但这不是强制性的组件。

可以在库存文件中添加任意数量的受管节点，如下所示：

图 1.3 – 带有受管节点的 Ansible 库存

最佳实践是根据关键性、服务器类型和环境将受管节点信息分隔到多个库存文件中。你将在第十六章中学习更多关于库存最佳实践的内容，存储远程主机信息 – 库存最佳实践。

动态库存插件将从你的虚拟化平台（如 VMware、OpenStack、AWS、Azure 和 GCP）或其他容器平台（如 Kubernetes）收集受管节点的详细信息。在 Ansible GitHub 仓库中，提供了超过 40 个动态库存插件供使用。如果需要，可以使用它们，或者如果这些插件不适合你的需求，可以创建自己的动态库存脚本。

Ansible 动态库存

要了解有关 Ansible 动态库存的更多信息，请访问docs.ansible.com/ansible/latest/user_guide/intro_dynamic_inventory.xhtml 和 github.com/ansible/ansible/tree/stable-2.9/contrib/inventory。

Ansible 插件

Ansible 插件是帮助启用灵活且可扩展架构的小段代码。你有 Ansible 可执行文件，并根据需要添加插件以支持其他功能和能力，像其他软件一样。Ansible 中有不同类型的插件，如 ssh，并且可以使用名为 docker 或 buildah 的连接插件来连接容器。如果需要，安装并使用这些插件。

Ansible 插件

阅读更多关于 Ansible 插件的信息，请访问docs.ansible.com/ansible/latest/plugins/plugins.xhtml。

Ansible 模块

Ansible 模块是一个可重用的独立脚本，可以用于实现某些特定任务。模块提供了一个定义好的接口，选项接受参数并以 JSON 格式将信息返回给 Ansible。当你使用模块执行任务时，模块脚本会在目标机器上使用 Python 执行，或者在 Windows 机器上使用 PowerShell 执行。

例如，以下 Ansible 内容使用了一个 ping 模块来验证与目标机器的连通性，另一个任务使用 yum 模块来通过 yum 包管理器在受管节点上安装 httpd package：

图 1.4 – Ansible ping 模块和 yum 模块

我之前提到过，我们可以使用 Ansible 来自动化网络设备和防火墙设备，但我们都知道，不能在这些设备上安装 Python 或 PowerShell。与大多数 Ansible 模块不同，网络模块并不直接在网络设备上运行。相反，这些模块会从 Ansible 控制节点本身执行，并在目标网络设备上运行适当的命令以完成任务。从用户的角度来看，网络模块的执行方式与其他模块没有区别，你仍然像使用其他模块一样使用它们。你可以像管理其他 Linux 机器和 Windows 机器一样管理网络设备，只是使用不同的连接方式，例如network_cli、netconf和httpapi。

阅读：网络自动化有何不同

访问docs.ansible.com/ansible/latest/network/getting_started/network_differences.xhtml了解更多关于网络设备自动化的信息。

Ansible 内容集合

在 2.10 版本之前，Ansible 是一个包含所有模块和库的大包，但社区发展非常迅速，成千上万的新模块被贡献到 Ansible 中。每当社区或供应商提供新的模块或模块的新版本时，用户需要等待下一个 Ansible 版本的发布才能获取更新的模块。为了解决这个依赖问题，出现了一种新的分发方式，将 Ansible 模块从 Ansible 基础中分离出来，作为 Ansible 内容集合，或简而言之，Ansible 集合来分发。你可以选择单独安装 Ansible，或者安装包含 Ansible 集合的 Ansible 包。如果你需要管理一些不同的节点或系统（例如，管理 VMware 私有云或自动化 Fortigate 防火墙设备），那么安装所需的 Ansible 集合并使用它。这种模块化使你可以只安装所需的模块和插件，而不是安装所有可用的模块。

下图展示了 Ansible 集合从旧版 Ansible 的过渡：

图 1.5 – 从 Ansible 到 Ansible 核心和 Ansible 集合的转换

另外，请注意一些 Ansible 基础和 Ansible 集合重构中的变化：

在版本 2.9.x 之前：该包包含了 ansible 以及所有的 Ansible 模块和其他插件。
从版本 2.10++ 开始：Ansible 被重命名为 ansible-base，并且模块被移到了 Ansible 集合（供应商和社区）。
从版本 2.11++ 开始：ansible-base 被重命名为 ansible-core。
当你安装 Ansible 3.x 或 Ansible 4.x 时，你安装的是 Ansible 社区包，其中包括 ansible-core 和所有的 Ansible 集合（供应商和社区）。

重构 Ansible 项目

阅读博客文章 ansible.com/blog/thoughts-on-restructuring-the-ansible-project 和 ansible.com/blog/the-future-of-ansible-content-delivery 以了解更多关于 Ansible 集合过渡的内容。

Ansible playbook

Ansible playbook 是一个用 YAML 格式编写的简单文件，里面包含自动化任务的指令列表。以下图解展示了 Ansible playbook 的组件、语法和结构：

图 1.6 – Ansible playbook 基本组件

在 play 中的每个任务都会运行一个模块，在目标节点上执行某些特定的工作。一个 play 中可以有多个任务，一个 playbook 中可以有多个 play，如图所示。play、任务和模块参数通过 YAML 格式中的缩进来区分。在此示例中，我们有一个包含两个 play 的 playbook。

在第一个 play 中，启用内网服务，我们针对 node1 运行任务 —— 请查看 hosts: node1 这一行。

在任务下方，查看两个任务：

第一个任务是使用 yum 模块安装 httpd 包。
第二个任务是使用 service 模块启动 httpd 服务。

然后，我们在 playbook 中有第二个 play，测试内网 Web 服务器，其中只有一个任务：

使用 uri 模块测试内网 Web 服务器

Ansible 将解析此 playbook 并逐一在目标节点上执行任务。

Ansible 用例

使用 Ansible，几乎可以构建、管理或维护 IT 基础设施中的所有组件：

服务器和存储
网络设备、防火墙、软件定义网络（SDNs）和负载均衡器
应用程序组件
容器和容器平台
数据库应用程序
公有云和私有云

你需要从日常工作中找到用例，并找出你每天重复执行的任务数量最多的任务，并将这些任务视为自动化候选任务。以下是此类用例的示例列表：

操作系统补丁
应用程序和包部署
应用程序的编排
配置管理
基础设施供应
持续交付
安全性和合规性审计及整改
数据库预配和管理

在接下来的章节中，我们将学习如何安装和配置 Ansible。

安装 Ansible

有多种方法可以在系统上安装 Ansible，例如使用默认的包管理器（yum、apt、dnf），使用 Python 的 pip，或安装源代码本身。根据你的环境和限制，按照官方文档中提供的任何方法进行安装（docs.ansible.com/ansible/latest/installation_guide/intro_installation.xhtml）。如果你使用的是操作系统包管理器，如 dnf、yum 或 apt，则需要 sudo 权限（或 root 访问权限）来安装 Ansible。

请注意，在 Ansible 控制节点上使用 Ansible 时，不需要 root 或 sudo 权限。在以下代码片段中，sudo 权限用于安装和更新包。

验证依赖关系

如你所知，Ansible 需要 Python 才能工作，因此你需要先检查 Python 是否已安装：

图 1.7 – 检查已安装的 Python 包和版本

如果你已经安装了受支持的 Python 版本，则按下节所述继续安装 Ansible。

使用包管理器安装 Ansible

根据操作系统，你需要在安装 Ansible 之前添加并启用适当的仓库。例如，如果你使用 Red Hat Enterprise Linux (RHEL)，则需要确保已设置 Red Hat 订阅，并启用仓库以安装 Ansible：

图 1.8 – 安装 Ansible 包

使用以下命令验证已安装的 Ansible 版本：

图 1.9 – 验证 Ansible 安装

从此输出中，可以看到 Ansible 的版本（2.9.27）、使用的默认配置文件（配置文件 = /etc/ansible/ansible.cfg）、模块搜索路径、正在使用的 Python 版本和其他细节。

上述 Ansible 版本来自你在操作系统中配置的默认仓库。如果你想安装最新或不同版本的 Ansible，则需要按照不同的方法进行操作。

使用 Python pip 安装 Ansible

如果系统中没有安装 pip，则需要安装 pip，然后使用 Python pip 安装 Ansible，如下所示：

图 1.10 – 使用 Python pip 安装 Ansible

请注意，当你执行 pip install ansible 时，你正在安装包含 ansible-core 和 Ansible 集合的 Ansible 包。我在本章前面已经解释过 Ansible 集合。

基于 Pip 的 Ansible 安装和支持

最好的做法是根据操作系统的包管理器来进行安装，这样可以自动获得适当的支持和更新。此外，基于 pip 的安装方式在软件有新版本时维护和升级较为困难。

如果你想安装特定版本的 ansible、ansible-base 或 ansible-core，可以按照以下方式使用版本信息：

图 1.11 – 使用 pip 安装特定版本的 Ansible

现在让我们检查一下 Ansible 的版本：

图 1.12 – 检查 Ansible 版本

查看 DEPRECATION WARNING 消息，并在开发环境中忽略该消息。但在生产环境中，你需要确保使用 Ansible 支持的 Python 版本。

Ansible 安装

查看 Ansible 文档，获取不同操作系统和方法的安装说明：docs.ansible.com/ansible/latest/installation_guide/intro_installation.xhtml

部署 Ansible

在开始自动化任务之前，你需要使用 ansible.cfg 文件为你的环境配置 Ansible。Ansible 会按以下顺序在四个地方查找配置文件：

$ANSIBLE_CONFIG：环境变量中的配置文件路径
./ansible.cfg：当前目录中的配置文件
~/.ansible.cfg：主目录中的配置文件
/etc/ansible/ansible.cfg：默认配置文件

最佳实践是将项目特定的 ansible.cfg 文件保存在项目目录中：

图 1.13 – 创建 ansible.cfg 文件

在 ansible.cfg 文件中添加一些基本配置：

图 1.14 – ansible.cfg 文件的内容

在 ansible.cfg 中保留 remote_user = devops 不是最佳实践；最好在清单文件中为不同的主机和主机组配置该项。你将在本章的创建 Ansible 清单部分了解这一点。

现在再次检查 Ansible 版本，查看差异，并确认 Ansible 正在使用 /home/ansible/ansible-demo/ansible.cfg 作为配置文件：

图 1.15 – 检查 Ansible 使用的是哪个 ansible.cfg 文件

在 ansible.cfg 中，你有许多其他参数可以配置，但并非所有参数都是必需的。如果在自定义的 ansible.cfg 文件中没有指定某些参数，Ansible 会根据需要加载默认配置。

查看另一个示例ansible.cfg文件，它包含一些重要的参数，这些参数决定了 Ansible 中的权限提升。这些参数决定了目标节点上的sudo或su操作：

图 1.16 – 另一个包含权限提升参数的 ansible.cfg 示例

在前面的示例中，发生了以下情况：

Ansible 将以devops用户身份登录远程节点，且无需输入密码（ask_pass = false）。
Ansible 将自动通过sudo方法将权限提升（become = true）至root（become_user = root），并且会要求输入sudo密码。可以通过设置become_ask_pass = false来关闭此功能。

为 Ansible 库存中的不同节点配置不同的凭据。你将在本章后续部分学习这一点。

还要注意，在前面的示例中，我还没有创建任何库存文件。我只是将库存文件名提到为./hosts。

创建 Ansible 库存

可以为你的库存文件使用任何名称，例如hosts、inventory、myhosts或production-servers。不要将这个 hosts 文件与/etc/hosts文件混淆。当你的库存文件中有越来越多的管理节点时，可以将库存文件分为不同的组或分成多个库存文件。例如，将生产服务器和设备放入一个名为production-hosts的文件中，将预发布节点放入staging-hosts文件中；对此没有任何限制。还要注意，如果你通过yum或apt工具安装 Ansible，则会有一个默认的库存文件，路径为/etc/ansible/hosts，其中包含示例库存内容。可以参考该文件开始使用，但最佳做法是在你的项目目录中创建一个项目特定的库存文件。你可以按照以下格式创建ini或yaml格式的库存文件：

图 1.17 – 在项目目录中创建库存文件

按如下方式在文件中添加内容并保存：

图 1.18 – 示例库存文件

你无需添加localhost，因为localhost条目在 Ansible 中是隐式的。这意味着我们仍然可以调用localhost节点，Ansible 会自动创建隐式条目。在前面的示范中，我添加了这个条目作为示例。由于localhost是本地机器，你将不会使用 SSH 连接，而且可以告诉 Ansible 将 localhost 的连接类型设置为local：

localhost ansible_connection=local

记住 IP 地址或长主机名的节点并不容易。在 Ansible 中，可以为主机使用任何名称，并通过ansible_host参数指定实际的名称或 IP 地址。

现在，请更新你的清单，使用正确的条目名称。请注意，这是可选的，但最佳实践是使用可读名称，而非 IP 地址和长完全限定域名（FQDNs）：

图 1.19 – 具有可读名称和 ansible_host 的 Ansible 清单

默认的ansible_connection是ssh，你无需在清单中提及该项。如果你使用其他连接类型，则需要指定它们，例如local、winrm或paramiko。

在此添加任意数量的节点，并使用多个主机组（如前面示例中的dev主机组）。

现在，测试你的清单，确保 Ansible 能够读取和理解你的清单和主机。请注意，你并没有通过此命令连接到主机：

图 1.20 – 列出清单主机

创建另一个包含一些虚拟托管节点的清单文件：

图 1.21 – 另一个具有更多主机和组的 Ansible 清单

在上面的清单中，请参见以下内容：

你有四个主机组：myself、intranet、database和everyone。
everyone是myself、intranet和database主机组的父组。

现在你有两个清单文件：

图 1.22 – 项目目录中的多个清单文件

要使用不同的清单文件，你无需更改ansible.cfg的内容；相反，使用-i开关动态指定清单文件。Ansible 将采用指定的清单文件，而不是ansible.cfg文件中配置的文件，示例如下：

图 1.23 – 使用不同的清单文件列出清单主机

使用--help选项查看 Ansible 命令的所有可用开关：

图 1.24 – 使用不同的清单文件列出清单主机

也可以使用模式来过滤托管主机，支持的模式有很多。例如，我们可以仅显示*techbeatly.com的托管节点：

图 1.25 – 使用模式选择主机

Ansible 主机模式

在docs.ansible.com/ansible/latest/user_guide/intro_patterns.xhtml查阅有关模式、目标主机和组的更多信息。

了解更多关于 Ansible 动态库存的信息，请访问 docs.ansible.com/ansible/latest/user_guide/intro_dynamic_inventory.xhtml 和 github.com/ansible/ansible/tree/stable-2.9/contrib/inventory。

在下一节中，我们将学习如何配置管理节点和连接。

配置你的管理节点

使用任何支持的认证机制从 Ansible 控制节点连接到管理节点，例如基于 SSH 密钥的认证、基于用户名和密码的认证以及 SSL 证书认证等。

设置基于 SSH 密钥的认证

使用 Ansible 的临时命令可以自动化大多数以下步骤，但我们将使用手动方法，以便了解所需的后台配置。

创建用户（例如 devops）并在 node-1 上启用 SSH 密钥认证的步骤如下：

在目标节点上创建一个专用用户（例如：node01），步骤如下。（这不是强制的，也可以使用任何现有用户帐户，并在 Ansible 中进行配置。）

图 1.26 – 创建新用户并设置密码

如果没有 ansible_host 选项，或者在 /etc/hosts 中添加条目以进行本地 DNS 解析。

启用新用户的 sudo 访问权限，因为在目标节点执行任何特权操作时，必须具有此访问权限：

图 1.27 – 为新用户启用特权访问

在 Ansible 控制 节点上创建 SSH 密钥对。可以创建任何支持的类型和大小。请注意，如果已有相同名称的密钥，请记得使用不同的名称或备份原始 SSH 密钥对：

图 1.28 – 在 Ansible 控制节点上生成 SSH 密钥对

验证 SSH 密钥权限：

图 1.29 – 验证 SSH 密钥权限

使用 ssh-copy-id 命令将 SSH 公钥从 Ansible 控制节点复制到 devops 用户下的管理节点：

图 1.30 – 将 SSH 公钥复制到管理节点

如果遇到密码认证或复制问题，可以手动将 /home/ansible/.ssh/id_rsa.pub 中的公钥内容复制到管理节点的 /home/devops/.ssh/authorized_keys 文件中。

验证从 Ansible 控制节点到管理节点的无密码 SSH 访问：

图 1.31 – 无密码登录到管理节点

如何设置基于 SSH 密钥的认证

查看如何设置基于 SSH 密钥的认证步骤，详见www.techbeatly.com/2018/06/how-to-setup-ssh-key-based-authentication.xhtml。

在下一节中，我们将探讨使用多个凭据来管理不同受管节点的选项。

多个用户和凭据

如果你有不同的凭据用于不同的受管节点，请在你的清单文件中配置远程用户名、要使用的 SSH 密钥等信息。让我为我们的node01受管节点展示一个示例：

图 1.32 – 配置受管节点的 SSH 密钥信息

在后面的示例中，我们为dev主机组使用了一个变量部分，并提到了 SSH 密钥和远程用户的详细信息。

Ansible 即时命令

ansible命令可用于在受管节点上执行单个任务而无需剧本；这被称为ping）到受管节点，创建一个用户帐户、复制一些文件或重启一个服务，并执行这些任务而不编写 Ansible 剧本。

例如，可以使用ping模块测试从 Ansible 到受管节点node01的连接，使用此用户和 SSH 密钥对：

图 1.33 – 使用 ping 模块的 Ansible 即时命令

在前面的代码片段中，由于你的localhost也包含在清单中（隐式地），当你提到all时，任务将在localhost和node01节点上执行。Ansible 的ping模块不仅仅是一个常规的网络 ping（ICMP）；它将登录到受管节点并返回结果pong。

使用shell模块执行另一个 Ansible 即时命令，检查 Ansible 用于连接的远程用户：

图 1.34 – 使用 shell 模块的 Ansible 即时命令

从前面的输出中可以看到，localhost是以默认的ansible用户执行的，而dev节点是以devops用户执行的。

现在，使用shell模块执行多个命令：

图 1.35 – 在 shell 模块中执行多个命令

请注意，前面的示例用于演示shell模块，类似的细节可以使用ansible_facts收集，而无需此类任务。

图 1.36 – 使用 setup 模块的 Ansible 即时命令

你将在第三章，自动化你的日常任务中了解更多关于ansible_facts的内容。

使用 Ansible 安装软件包

你需要确保目标机器上配置并启用了软件包仓库（yum或apt）。

在 node01 上安装 vim 包：

图 1.37 – 使用 dnf 模块的 Ansible 临时命令

从上面的输出中可以看出，你正在使用 devops 用户连接到管理节点，这个用户是普通用户。你无需在 ansible.cfg 中添加 become 相关设置；相反，在执行 ansible 命令时，传递此 become 开关，即 -b。 (对于 Ansible playbook，你可以在 play 层级或任务层级启用或禁用特权提升)：

图 1.38 – 使用 dnf 模块和特权模式安装包

根据输出，包的安装已成功。

上面的临时执行可以按如下方式写入 playbook：

图 1.39 – 使用 Ansible playbook 安装包

你将会在第二章，从简单的自动化开始，学习更多关于编写 playbook 的内容。

现在，使用 Ansible 临时命令移除相同的包；将 state=latest 替换为 state=absent：

图 1.40 – 使用 Ansible 临时命令移除包

我们现在已经成功使用 Ansible 安装和卸载了一个包。

概要

在本章中，你已经了解了 Ansible 的核心概念，Ansible 的工作原理以及关键术语，包括 Ansible 清单、playbook、任务、Ansible 控制节点、管理节点和模块。你还学习了基本的 Ansible 安装、配置和部署，以及管理节点配置、SSH 密钥凭证和无密码 SSH 的重要性。

在下一章中，你将学习如何从简单的自动化 playbook 和执行开始。接着，你将学习如何找到适合的 Ansible 模块用于 playbook 开发和远程节点连接方式。

进一步阅读

Ansible 文档: https://docs.ansible.com/ansible/latest/index.xhtml
Ansible 控制节点要求: https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.xhtml#control-node-requirements
Ansible 动态清单: https://docs.ansible.com/ansible/latest/user_guide/intro_dynamic_inventory.xhtml 和 https://github.com/ansible/ansible/tree/stable-2.9/contrib/inventory
Ansible 自动化平台: https://www.ansible.com/blog/introducing-red-hat-ansible-automation-platform
安装 Ansible: https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.xhtml
网络自动化的不同之处: https://docs.ansible.com/ansible/latest/network/getting_started/network_differences.xhtml

第二章：从简单自动化开始

当你开始自动化之旅时，首先从简单的用例入手，而不是自动化复杂的工作流。找出三个小的用例，这些用例能帮助你更快地学习自动化并在你的环境中实施。Ansible 有一个平滑的学习曲线，但选择合适的用例作为你的第一个自动化项目同样重要。三个很好的初始自动化用例示例包括简单的任务，如应用程序部署、资产信息收集以及简单的文件操作，如复制操作。

在本章中，我们将覆盖以下主题：

识别需要自动化的手动任务
寻找要使用的 Ansible 模块
配置你的文本编辑器以支持 Ansible
连接到远程节点

你将通过在学习如何使用凭证和其他参数之前，先找到合适的模块来创建基本的自动化任务。

技术要求

本章你将需要以下技术要求：

一台用于 Ansible 控制节点的 Linux 机器
一台或多台配置了 Red Hat 仓库的 Linux 机器（如果你使用的是其他 Linux 操作系统，而不是Red Hat Enterprise Linux（RHEL），请确保已配置适当的仓库以获取软件包和更新）

本章的所有 Ansible 代码、Ansible 剧本、命令和片段都可以在本书的 GitHub 仓库中找到，链接为 github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-02。

识别需要自动化的手动任务

在上一章中，你学习了如何使用 Ansible 临时命令手动执行远程管理节点上的任务，使用的是 Ansible 模块。现在，你将学习如何从简单的 Ansible 剧本和任务开始。记住，在执行任何 Ansible 任务之前，你需要将管理节点的详细信息添加到你的库存文件中。

我们将从一个简单的自动化任务开始，以理解 Ansible 剧本的基本概念。对于这个示例，我们假设你已经安装并配置了 chronyd 应用程序。chrony 应用程序是 chronyd 的实现，是 Red Hat Enterprise Linux 8 和 SUSE Linux Enterprise Server 15 中默认的 NTP 客户端和服务器，并且在许多 Linux 发行版中都可以使用。

对于我们的示例 Ansible 剧本，我们将执行以下操作：

在所有节点上安装 chrony 包。
调整 chrony 配置。
启动 chronyd 服务并启用它。

下图显示了用于部署和配置 chrony 应用程序的 Ansible 与 node1 的连接：

图 2.1 – 配置 Ansible 以自动化 chrony

按照以下步骤创建 Ansible 工件以安装 chronyd，包括 ansible.cfg、hosts 文件和 Ansible 剧本：

首先，创建一个名为Chapter-02的新目录，并像上一章那样在该目录中创建ansible.cfg文件：

图 2.2 – Ansible 配置文件 (ansible.cfg)

接下来，在与 node1 受管节点相同的目录下创建 hosts 文件：

图 2.3 – 带有 node1 的 Ansible 清单文件

在同一目录下创建一个名为install-package.yaml的 playbook 文件，内容如下：

图 2.4 – 安装 chrony 的 Ansible playbook

在前面的 playbook 中，您只有一个名为 Install Chrony Package 的 play，以及一个名为 Ensure Chrony package is installed 的任务。还要注意 hosts: node1 行，因为您正在安装软件包到您的受管节点——也就是 node1。

Ansible 完全限定集合名称 (FQCN)

正如我们在第一章中学到的，Ansible 自动化 – 介绍，在 Ansible 内容集合 部分，许多插件和模块已移至 Ansible 2.10 中的内容集合。playbook 可以正常工作，但最佳实践是使用 ansible.builtin.dnf 作为 FQCN，其中 dnf 是模块名称，且是 ansible-core 的一部分。另一个例子是 google.cloud.gcp_compute_disk，其中 google 是集合的作者，cloud 是集合名称，gcp_compute_disk 是创建 Google Cloud 磁盘的模块名称。有关集合的更多信息，请阅读：docs.ansible.com/ansible/latest/user_guide/collections_using.xhtml。

使用 ansible-playbook 命令执行 playbook，您将看到以下输出：

图 2.5 – chrony 包安装 playbook

这样，playbook 就已成功执行。以下截图显示了成功状态：

图 2.6 – chrony 包安装消息

现在，登录到目标机器 node1 并验证安装：

图 2.7 – 在 node1 上安装的 chrony 包

现在，您需要创建一个可以在所有服务器上使用的chrony配置。

在相同目录（Chapter-02）下创建 Chapter-02/chrony.conf.sample 文件。根据您组织的标准，为 chrony 配置添加更多详细信息：

图 2.8 – 示例 chrony 配置

在剧本中添加一个名为Copy chrony configuration to node的任务，使用template模块将示例chrony配置复制到节点。然后，使用service模块启动chronyd服务。

完整的剧本如下所示：

图 2.9 – 安装和配置 chrony 的剧本

再次执行剧本并验证，如下图所示：

图 2.10 – 展开后的剧本与 chrony 配置

在上述示例中，Ensure chrony package is installed任务的状态为ok。这意味着所需的状态已经达到，因此无需再次安装chrony包。因此，Ansible 不会对该任务采取任何行动。

在 Ansible 中，这一特性称为幂等性，意味着如果执行一个操作的结果与当前状态相同，则该任务无需进一步操作。大多数 Ansible 模块是幂等的，这将帮助你在受管节点上多次运行相同的剧本而不会产生任何影响（docs.ansible.com/ansible/latest/reference_appendices/glossary.xhtml#term-Idempotency）。

现在，验证目标节点上的详细信息：

图 2.11 – node1 上的 chrony 配置和服务状态

上述剧本可以用来自动化你的chrony配置，适用于成千上万的服务器，并且只需几分钟就能完成任务。

Ansible 模块参考

请参考以下文档，了解你在剧本中使用的模块：

查找要使用的 Ansible 模块

在本节中，你将学习如何在 Ansible 剧本中查找适合的模块和文档。

使用ansible-doc命令查找可用的模块和详细信息：

图 2.12 – Ansible 模块列表

它将是一个长列表或短列表，具体取决于你的 Ansible 安装类型。（回顾前一章中解释的ansible、ansible-base和ansible-core之间的区别。）你可以按照以下方式检查可用的模块总数：

[ansible@ansible Chapter-02]$ ansible-doc -l |wc -l
6108

通过调用模块名称并使用-s（--snippet）参数检查模块详情，如下所示：

图 2.13 – dnf 模块的 Ansible 模块片段

或者，检查模块的完整详情如下：

图 2.14 – dnf 模块的 Ansible 模块详情

上面的输出显示了模块的示例用法和所有参数。这就像是模块文档的离线副本。如果你想在模块列表中交互式地搜索某个特定模块，可以执行ansible-doc -l命令，然后按/键并输入模块名称进行搜索，如下截图所示：

图 2.15 – 在 ansible-doc 中搜索模块

当你按下Enter键时，如果搜索项存在，它将被高亮显示。这可以通过以下截图看到。按N键可以查找下一个包含相同文本的项目：

图 2.16 – 在 ansible-doc 列表中查找模块

使用ansible-doc列出所有其他插件，包括connection插件、become插件、lookup、filters等。

以下截图显示了可用的become插件：

图 2.17 – Ansible become 插件

以下截图显示了可用的connection插件：

图 2.18 – Ansible 连接插件

到此，你已经学会了如何使用ansible-doc命令查找所需的模块和模块文档。接下来，你将学习如何配置文本编辑器以编辑 Ansible playbook。

配置你的文本编辑器以支持 Ansible

由于YAML对缩进非常敏感，因此在使用文本编辑器开发和编辑 playbook 时，需要格外小心。你可以使用任何你喜欢的文本编辑器来编辑 Ansible playbook，并根据需要配置编辑器。

如果你能够使用像 Visual Studio Code 或 Atom 这样的 GUI 编辑器，请跳过本节内容，因为 GUI 编辑器可以轻松通过多个插件配置，以更高效地进行 Ansible 内容开发。有关 Ansible 内容开发的工具和程序详情，请参考 docs.ansible.com/ansible/latest/community/other_tools_and_programs.xhtml。现在，让我们学习如何为 Ansible YAML 文件配置 Vim 编辑器。使用 Vim 变量启用或禁用 Vim 编辑器中的功能：

[ansible@ansible Chapter-02]$ vim install-package.yaml

现在，按下Esc，接着按 : 并输入 set nu 来启用行号，如下图所示：

图 2.19 – 配置 Vim 编辑器以显示行号

你将看到行号显示在编辑器的左侧。但是当你关闭 Vim 编辑器会话并重新打开时，所有这些变量会被重置。为了避免逐一启用这些功能，你可以在主目录下的 .vimrc 文件中配置这些 Vim 变量。

创建一个 ~/.vimrc 文件，并添加以下内容来配置 Vim 支持 YAML 文件：

图 2.20 – 配置 ~/.vimrc 文件

以下表格列出了一些可用的 Vim 变量：

表 2.1 – Vim 变量列表

完成 ~/.vimrc 文件后，尝试通过编辑任何 YAML 文件来检查 Vim 编辑器：

[ansible@ansible Chapter-02]$ vim install-package.yaml

你将看到行号和其他语法高亮。尝试编辑文件；当你编辑行时，缩进会自动创建。你仍然可以使用Tab键，因为 Vim 会根据你的 vimrc 配置将Tab替换为两个空格。以下截图展示了启用 vimrc 配置后 Vim 编辑器的示例界面：

图 2.21 – 配置为 YAML 文件的 Vim 编辑器

请参阅 www.techbeatly.com/setup-your-vim-editor-for-ansible-playbook/ 中的 设置你的 Vim 编辑器以支持 Ansible Playbook，了解更多关于 Vim 编辑器配置 YAML 的内容。

什么是 Vim 编辑器？

Vim 是一个著名的文本编辑器，适用于 Linux 平台。Vim 编辑器具有高度的可配置性，非常适合开发和编辑任何复杂的 Linux 文件。更多详情请参考 www.vim.org。

连接到远程节点

最佳实践是使用动态清单，以避免频繁更改静态清单文件。然而，这取决于你的环境。另一个最佳实践是根据环境、重要性或其他参数分离清单文件。以下截图展示了基于工作负载环境的示例清单文件。如你所见，生产、开发和暂存设备分别有不同的目录和文件：

图 2.22 – 基于环境的 Ansible 清单分离

你需要确保 Ansible 控制节点到受管节点的连接是安全的。对于 Linux/Unix 受管节点，使用ssh连接（这是默认连接方式）并使用基于密钥的身份验证，如在第一章**“配置受管节点”部分所解释的那样。可能会有无法使用 SSH 密钥的情况，在这种情况下，你可以使用用户名和加密密码进行身份验证；这将在第十三章中讲解，使用 Ansible 进行密钥管理。

对于 Windows 机器，使用WinRM协议，Ansible 可以用它连接并执行 Windows 机器上的任务。然而，你需要在 Windows 机器上配置一些项，如启用 WinRM 监听器、打开 WinRM 的端口等。

使用ansible-doc命令查看WinRM连接插件，如下所示：

图 2.23 – Ansible WinRM 连接插件

你也可以在清单或 playbook 中配置受管主机的连接方式。你还可以在执行 playbook 时进行配置。以下截图展示了ansible_connection=winrm方法用于win2019清单组。该组下的所有主机将使用winrm作为连接方式：

图 2.24 – 在 Ansible 清单中配置 WinRM

你也可以在 Ansible playbook 中提及连接类型，如下所示：

图 2.25 – 在 Ansible playbook 中配置 WinRM

如果你想动态地提供连接方式，可以在执行ansible-playbook命令时传递此信息：

图 2.26 – 在执行 Ansible playbook 时传递 WinRM 连接

对于网络和防火墙设备，使用基于设备类型和兼容性的支持连接协议。你将在第六章中了解更多内容，自动化 Microsoft Windows 和网络设备。

请参考 Ansible 连接插件文档，网址：docs.ansible.com/ansible/latest/plugins/connection.xhtml，以了解更多信息。

总结

在本章中，你学习了如何开发一个简单的 playbook 来自动化 chrony 包的部署和服务管理。你学习了如何使用 ansible-doc 命令查找模块及其详细信息，包括模块示例和使用的参数。你还探索了如何使用 ansible-doc 命令查找连接插件和成为插件。之后，你学习了如何配置你的 Vim 编辑器，以便轻松编辑 Ansible YAML 文件。最后，你学习了如何配置被管理节点的连接方法。

在下一章，你将学习如何使用 Ansible 自动化你的日常任务，开发实际用例，并将其应用到你的工作场所。

进一步阅读

若要了解本章所涉及的更多信息，请访问以下链接：

Ansible 的工具和程序: docs.ansible.com/ansible/latest/community/other_tools_and_programs.xhtml
Ansible 幂等性: docs.ansible.com/ansible/latest/reference_appendices/glossary.xhtml#term-Idempotency
Ansible 在 Windows 上的自动化: www.techbeatly.com/ansible-windows/
Ansible 模块介绍: docs.ansible.com/ansible/latest/user_guide/modules_intro.xhtml
Ansible 连接插件: docs.ansible.com/ansible/latest/plugins/connection.xhtml

第三章：自动化您的日常工作

是否在为找到适合 Ansible 自动化的使用案例而苦恼？您的工作场所是寻找自动化使用案例的绝佳起点。跟踪您或您的团队每天重复执行的任务，您会发现自动化这些任务的机会。这些任务可能是简单的服务器信息收集、操作系统版本采集，或者是每周一次的重启工作。

在本章中，您将学习如何利用 Jinja2 模板创建报告和电子邮件，并借助 Ansible 完成这些任务。您还将学习如何以模块化的方式开发 Ansible 工件，并动态地包括任务和变量。

本章将涵盖以下主题：

使用 Ansible 收集服务器详细信息
收集系统信息
使用 Ansible 进行系统扫描与修复
使用 Ansible 实现自动化的每周系统重启
自动化通知

我们将从 ansible_facts 开始，学习如何提取系统报告所需的数据。本章将解释如何收集数据、将其插入到 HTML 报告中，并存储到 Web 服务器上。接着，您将学习如何配置标准的系统文件，并通过电子邮件通知自动化服务器重启。

技术要求

以下是本章的技术要求：

用于 Ansible 控制节点的 Linux 机器
配置了 Red Hat 仓库的两台或更多 Linux 机器（如果您使用的是其他 Linux 操作系统而非Red Hat Enterprise Linux（RHEL）机器，请确保您已经配置了适当的仓库，以便获取包和更新）

本章的所有 Ansible 配置、playbook、命令和代码片段可以在本书的 GitHub 仓库中找到，地址是：github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-03。

使用 Ansible 收集服务器详细信息

在上一章中，您学习了如何通过使用简单的 playbook 和任务来利用 Ansible 进行基本的自动化。本章中，您将通过自动化您工作场所中的一些简单的日常任务，进一步加深理解。

一个最新的、易于访问的系统清单是每个系统工程师和 IT 团队的梦想。在大型企业中，常常使用配置管理数据库（CMDB）软件。然而，工程师们必须维护自己的电子表格，以便跟踪他们管理的服务器和设备信息。当您使用虚拟机和虚拟设备等软件定义基础设施时，验证和更新这些本地电子表格将变得非常繁琐。

使用 Ansible 可以自动化维护这些信息，如下图所示：

图 3.1 – 使用 Ansible 维护系统信息数据库

Ansible 和 ansible_facts 可以用来创建和更新系统库存数据库或您自己的 CMDB。ansible_facts 提供从目标节点（被管理节点）收集的详细和有用的数据，并存储在 setup 模块中，这个过程发生在每个 play 的开始。如果您还记得 chrony 包的安装 playbook，可以查看 TASK [Gathering Facts] 行，那里显示了 setup 模块在后台运行：

图 3.2 – 由 setup 模块执行的 Ansible 信息收集任务

ansible_facts 可用于在 playbook 中做出决策，例如，如果系统内存低于要求的值，则跳过任务，或根据目标节点的操作系统版本安装特定的软件包。

Ansible 角色

An Ansible 角色是一个包含任务、处理器、模板和变量的集合，用于配置目标系统，使其达到所需状态。Ansible 角色使得内容共享变得简单，因为我们可以在角色目录中包含所需的变量、任务、模板和其他文件。Ansible 角色旨在实现可重用性和协作支持，以便将相同的角色分发给团队或公众。其他用户可以使用这些角色来完成相同的任务：

使用 Ansible 角色，我们可以轻松地将 playbook 的内容与其他团队共享，只需共享整个角色目录。例如，可以编写 install_dbserver 或 setup_webserver 角色，并在之后将其与公众或其他团队共享。
更大的项目可以通过模块化的方式进行创建。
不同的用户可以并行创建不同的角色并共享同一个项目。例如，开发人员 1 编写 install_dbserver 角色，开发人员 2 则专注于 setup_webserver 角色。

接下来让我们学习 Ansible 角色的目录结构。

角色目录结构

Ansible 角色的内容以有组织的方式进行排列。顶层目录定义了角色本身的名称，如下截图所示（我们将在本章稍后创建这些角色及其内容）：

图 3.3 – 包含角色的示例项目目录

在前面的截图中，我的 roles 目录下有两个角色，分别是 deploy-web-server 和 security-baseline-rhel8。其中一些目录包含 main.yml 文件，里面包含任务、变量或处理器：

Defaults/main.yml：包含角色的变量，在使用该角色时可以被覆盖。
tasks/main.yml：包含使用角色时要执行的主要任务列表。
vars/main.yml：包含角色的内部变量。
files：包含可以从此角色引用的静态文件。
templates：这是可以通过该角色使用的 jinja2 模板。
handlers/main.yml：这包含了处理程序定义。
meta/main.yml：这定义了此角色的一些元数据，如作者、许可、平台和依赖关系。
tests：这是一个清单。test.yml 文件可以用来测试这个角色。

默认变量可以在 defaults/main.yml 中定义；其他角色变量可以在 vars/main.yml 中定义。但是，根据变量的位置和变量优先级，Ansible 将应用适当的变量值。参阅 docs.ansible.com/ansible/latest/user_guide/playbooks_variables.xhtml#understanding-variable-precedence 以了解更多关于变量优先级的信息。

Ansible 角色

在 Ansible Galaxy 中有超过 10,000 个角色可供使用（galaxy.ansible.com），这些角色由社区贡献。用户可以自由下载并用于 Ansible 自动化过程。如果组织需要认证的内容集合（集合和角色），则可以通过访问 Red Hat Automation Hub（在 console.redhat.com 门户）来找到它们。阅读 docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.xhtml 以了解更多关于 Ansible 角色的信息。可以在 galaxy.ansible.com/RedHatOfficial 找到官方的 Red Hat 角色。

Ansible Jinja2 模板

使用 template 模块（或 Ansible 的 template 过滤器）将 Jinja2 模板转换为实际内容或文件。Ansible 将根据需要替换变量的值。

例如，标准的 /etc/motd 文件可以通过动态地使用适当的值部署到服务器上。你的 Jinja2 模板将如下所示（根据你的自定义可能有所不同）：

图 3.4 – 用于 motd 文件的 Jinja2 模板

在剧本中，你将 template 文件，并使用 template 模块将其传输到目标机器（不要使用 copy 模块，因为模板化将无法工作）：

图 3.5 – 在剧本中使用模板模块

在目标机器上，Jinja2 模板中的变量将被替换为相应的值，如下所示：

图 3.6 – 使用 Jinja2 模板创建的 /etc/motd 文件

模板中可以使用任何复杂度和循环来生成动态输出文件。一些使用案例包括生成报告、Web 服务器配置（HTTPS、Nginx）、系统配置文件（/etc/hosts、/etc/motd 和 /etc/fstab）等。

Ansible Jinja2 模板

阅读更多关于 Ansible Jinja2 模板的内容，请访问 docs.ansible.com/ansible/latest/user_guide/playbooks_templating.xhtml。

在此使用案例中，您将使用 ansible_facts 从 node1（如果有其他机器，也可以从它们获取）提取所需的信息，并将其作为 HTML 报告存储在 Web 服务器（node2）中，如下图所示：

图 3.7 – 用于 Ansible CMDB 使用案例的机器

对于以下使用案例，我们需要部署一个 Web 服务器。我们将使用 Ansible 在 node2 上部署和配置 Web 服务器。

按照以下步骤使用 Ansible 角色部署 Web 服务器：

在您的 Ansible 控制节点上，创建一个名为 Chapter-03 的新目录，并创建一个 ansible.cfg 文件，如下所示：

图 3.8 – ansible.cfg 文件

在与 node-1 管理节点相同的目录中创建一个 hosts 文件（使用您实验室或环境中的正确 IP 地址）：

图 3.9 – Ansible 清单（hosts）文件

在上面的截图中，[nodes:vars] 是组变量。这些变量将在 nodes 主机组下对所有管理节点可用。

现在，创建一个 Ansible 角色，在 node2 上使用 Apache 部署 Web 服务器：
```
[ansible@ansible Chapter-03]$ mkdir roles
[ansible@ansible Chapter-03]$ cd roles/
```
一旦创建了 roles 目录，使用 ansible-galaxy 命令初始化一个新的 Ansible 角色。ansible-galaxy 命令将初始化并创建该角色的骨架目录结构：

图 3.10 – 使用 ansible-galaxy 命令初始化 Ansible 角色

图 3.11 – 角色目录的内容

将以下任务添加到 roles/deploy-web-server/tasks/main.yml 文件中，以安装 firewalld 和 httpd 软件包：

图 3.12 – 安装 httpd 和 firewalld

向角色中添加更多任务，以启用防火墙服务并允许 httpd 服务通过防火墙，如下所示：

图 3.13 – Ansible web 部署角色 – 启用 firewalld 服务并允许 httpd 通过防火墙

最后，添加启用并启动 httpd 服务的任务，如下所示：

图 3.14 – Ansible web 部署角色 – 启用并启动 httpd

tasks/main.yml文件将创建/var/www/html目录，并安装httpd和firewalld包。然后，它将启动httpd和firewalld服务，并在防火墙中打开httpd端口。

删除deploy-web-server角色目录中其他不需要的目录和文件（自动生成的）。在这种情况下，保持不变并继续进行下一步。

创建一个名为Chapter-03/deploy-web.yml的剧本，这样您就可以部署 Web 服务器（记得返回到主目录——即Chapter-03）：

图 3.15 – 调用角色的 Ansible 剧本

现在，您的目录将包含以下内容：

图 3.16 – 项目目录内容

执行deploy-web.yml剧本以在node2上部署 Web 服务器：

图 3.17 – 执行 Web 服务器部署剧本

相同的剧本可以执行多次，Ansible 将在后台根据所需的状态执行或跳过操作。这个特性在 Ansible 中称为幂等性，Ansible 模块将检查所需的状态（例如，安装包或复制文件），并仅在需要时执行操作。

Ansible 的幂等性

“一个操作是幂等的，如果执行一次的结果与重复执行多次的结果相同，而中间没有任何干预操作。” – Ansible 词汇表（docs.ansible.com/ansible/latest/reference_appendices/glossary.xhtml）

让我们再次执行相同的剧本并检查差异。在这里，我们可以看到ok状态而不是changed（图 3.17），因为 Ansible 并没有执行该操作。这是因为firewalld和httpd包已经安装，并且服务已经启动（所需的状态已经满足）：

图 3.18 – 再次执行部署剧本，并注意到ok状态而不是changed

现在，通过访问服务器 IP 或完全限定域名（FQDN）在浏览器中验证 Web 服务器（根据操作系统和版本的不同，您可能会看到不同或相似的页面）：

图 3.19 – 默认 Apache 网页

登录到node2并删除默认的welcome.conf文件，以便您可以查看/var/www/html目录的内容：

[root@node-2 ~]# mv /etc/httpd/conf.d/welcome.conf .

这在生产环境中不是最佳实践，您需要为 Web 服务器配置适当的权限和目录列表选项。提到上述步骤是为了演示和说明 Web 服务器的功能。

这样，你就使用 Ansible 角色部署了一个 Web 服务器，用于存储系统信息报告或 CMDB。

注意

有许多开源项目可以用于实现 CMDB，比如使用 Ansible facts 的 Ansible-CMDB（ansible-cmdb.readthedocs.io/en/latest/）。请参考项目文档和仓库以获取详细信息。

收集系统信息

在本节中，你将从ansible_facts中提取所需的信息，并在你在上一节中创建的 Web 服务器中生成 HTML 报告。

ansible_facts包含关于嵌套字典和列表的很多信息。搜索并浏览内容，找到报告中需要的重要信息。

要查看ansible_facts的内容，请执行以下临时命令：

图 3.20 – 使用临时命令后的 Ansible facts 输出

使用管道符号（|）后的less或more命令可以将输出保持在顶部，无需滚动到页面底部。你可以使用箭头键向下或向上滚动，或者通过搜索文本来查找它（/ + <text>）。

在github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-03/node1-ansible-facts中找到 Linux 机器的ansible_facts详细信息。

按照以下步骤，使用前面setup输出中的一些变量：

创建一个名为Chapter-03/roles/system-report的角色来生成 HTML 报告，如下所示：

图 3.21 – 创建一个新的 Ansible 角色用于系统报告

创建一个名为roles/system-report/templates/system-information.xhtml.j2的 Jinja2 模板文件，并在模板文件中添加 HTML 头部和其他细节：

图 3.22 – 用于 HTML 报告的 Jinja2 模板

在github.com/PacktPublishing/Ansible-for-Real-life-Automation/blob/main/Chapter-03/roles/system-report/templates/system-information.xhtml.j2中找到完整的 Jinja2 模板。你可能已经注意到模板中使用的变量，如下所示：

{{ ansible_hostname }}：托管节点的主机名。
{{ ansible_all_ipv4_addresses }}：IP 地址列表。
{{ ansible_architecture }}：目标机器的架构。
{{ ansible_distribution }}和{{ ansible_distribution_version }}：操作系统的发行版和版本。
{{ report_admin_email }}：这是一个你需要在剧本中定义的自定义变量。

创建 roles/system-report/tasks/main.yml 文件，内容如下：

图 3.23 – 系统报告角色的任务文件

在上述示例中，template 模块会将模板转换为目标 HTML 文件，并用相应的值替换变量。由于报告需要保存在 web 服务器路径中，任务将委托给 node2（即 web 服务器）。

创建 Chapter-03/system-info.yml playbook 并包含 system-report 角色：

图 3.24 – 用于收集系统信息的 Ansible playbook

执行 playbook 并验证其输出：

图 3.25 – 收集系统信息

检查 web 服务器以查看报告，如下所示：

图 3.26 – 在 web 服务器上生成的报告

点击 node1.xhtml 查看其内容，如下所示：

图 3.27 – Ansible 生成的系统信息报告

这是一个非常基础的 HTML 报告模板，说明了 Jinja2 模板和 ansible_facts 的功能。可以通过增加额外的项、CSS 样式，甚至不同的格式（如 Markdown、CSV 或 JSON）来扩展模板。此外，也可以将报告保存在其他位置，如 GitHub 服务器或具有认证的 web 服务器。

使用 Ansible 进行系统扫描和修复

安全扫描和修复至关重要，组织每年在这一领域投入更多的时间和金钱。当操作系统和应用程序有新功能和变更时，你将有更多的配置需要检查和验证，以确保最佳的安全实践已到位。在 Ansible 的帮助下，能够自动化系统和设备的安全扫描和修复任务。

本节中，你将基于 CIS Red Hat Enterprise Linux 8 基准，自动化一些基本的安全性和合规性配置。

CIS 基准

CIS 提供了确保系统和平台安全与合规的最佳实践和配置。请参考 www.cisecurity.org/cis-benchmarks 了解更多 CIS 基准的信息。

当我们在 playbook 或角色中有多个任务时，可以将任务拆分为多个文件，并使用 include_tasks 模块动态调用它们。例如，可以将不同的安全修复任务拆分为不同的任务文件，以便从 main.yaml 中调用，如下图所示：

图 3.28 – 将任务拆分为多个文件

这种方法可以帮助我们以动态和模块化的方式开发、测试和执行任务。

按照以下步骤开发一个安全修复用例：

创建一个名为Chapter-03/roles/security-baseline-rhel8的新角色：

图 3.29 – 创建一个新的安全基准角色

将必要的安全基准配置添加到roles/security-baseline-rhel8/tasks/main.yml。

正如我在本节开始时提到的（图 3.28），在这个示例中，你将学习如何将任务拆分成多个文件，并以模块化方式开发 playbook。将以下内容添加到roles/security-baseline-rhel8/tasks/main.yml中：

图 3.30 – 安全基准角色的主任务文件

你有两个任务，两个任务都通过include_tasks模块调用了其他任务文件。你需要注意其中一行，内容如下：

when: “’01.01’ not in baseline_exclusions”：这是我们添加到任务中的一个机制，用于通过when语句控制特定基准规则的执行。Ansible 会检查条件并根据该条件执行或跳过任务。在这种情况下，你需要定义一个名为baseline_exclusions的列表变量，并将特定项目添加到排除执行的列表中。（可以使用任何其他字符串或编号系统，这只是本示范中的一个样例列表。）

创建一个名为roles/security-baseline-rhel8/tasks/part-01.yml的文件，内容如下，用于安装sudo并启用sudo日志记录：

图 3.31 – part-01.yml 用于 sudo 配置

第一个任务将安装sudo包，而第二个任务将启用sudo日志记录。你需要注意其中一行，内容如下：

line: ‘Defaults logfile=”{{ sudo_log }}”’：你需要在 playbook 中定义这个sudo_log变量。

创建一个名为roles/security-baseline-rhel8/tasks/part-02.yml的任务文件，内容如下，用于部署默认的/etc/motd和/etc/issue文件：

图 3.32 – part-02.yml 用于 motd 配置

第一个任务将部署默认内容到/etc/motd，而第二个任务将部署内容到/etc/issue文件。

在roles/security-baseline-rhel8/files/目录下为motd和issue文件创建以下默认内容：

图 3.33 – 默认的 motd 和 issue 文件

验证你 Ansible 角色的文件，以确保所有内容都已到位，如下截图所示：

图 3.34 – 安全基准角色的内容

你可以删除其他不再使用的目录。然而，在这种情况下，保持一切如原样。

变量可以保存在你的剧本中，甚至可以保存在清单文件内，但当你有更多变量需要维护时，管理内容将变得不容易。创建一个目录来存放变量，如下所示：
```
[ansible@ansible Chapter-03]$ mkdir vars
```
创建一个名为vars/common.yml的变量文件，用于存放公共变量，并将sudo_log和其他变量添加到该文件中（记得在文件中根据需要添加变量和值）：

图 3.35 – 创建一个变量文件

创建另一个名为vars/baseline_exclusions.yml的变量文件，用于存放baseline_exclusions变量：

图 3.36 – 为基准排除创建一个变量文件

我们可以通过取消注释该行（例如，‘01.01’）来禁用安全检查，以便在执行任务之前让 Ansible 进行检查。

作为最佳实践，你需要将所有在 Ansible 角色中使用的变量的默认值保存在一个文件中。可以使用roles/security-baseline-rhel8/defaults/main.yml文件来实现这个目的：

图 3.37 – security-baseline-rhel8 角色的默认变量

现在，创建主剧本security-compliance-rhel8.yml，并确保它包含以下内容：

图 3.38 – 主剧本 – security-compliance-rhel8.yml

请注意，在前面的剧本中，我们并没有硬编码主机。相反，我们使用了一个名为NODES的变量。这个变量将通过hosts传递给剧本，以避免剧本意外地在错误的服务器上执行。（关于extra-vars的更多内容将在下一节中讲解。）

同时，注意vars_files，我们在其中包含了之前创建的两个变量文件。在这里，剧本正在调用security-baseline-rhel8角色。

执行剧本并将NODES详细信息作为额外变量传递：

图 3.39 – 执行安全基准剧本并确保子任务被执行

登录到node1并验证已实施的项目（注意登录提示）：

图 3.40 – 验证 node1 登录屏幕上 motd 的内容

通过为任务添加更多的验证和检查来增强你的剧本。同时，在执行作业时生成报告，并发送或保存以备后续审计使用。

Ansible 与第三方安全工具的集成

可以将 Ansible 与其他第三方平台和工具集成，如 OpenSCAP 或 Red Hat Insight。在这种情况下，你需要开发剧本来控制扫描和修复，而不是手动扫描和修复系统上的配置。有关更多信息，请参阅 www.ansible.com/use-cases/security-and-compliance 和 www.open-scap.org/。

Ansible --extra-vars

extra-vars 包含将覆盖所有其他变量的变量。使用动态额外变量有助于根据值控制剧本，并且在你使用 Ansible AWX 或 Ansible Automation Controller 中的调查表单时也非常有用，因为变量可以通过 GUI 方法（调查表单）定义。--extra-vars 可以作为单个值、多对键值对、JSON 格式传递，或从变量文件读取，如下所示：

图 3.41 – Ansible extra-vars 示例

Ansible --extra-vars

阅读更多有关运行时变量的信息，请访问 docs.ansible.com/ansible/latest/user_guide/playbooks_variables.xhtml#defining-variables-at-runtime。还可以查看自动化控制器调查表单，网址为 docs.ansible.com/automation-controller/latest/html/userguide/job_templates.xhtml#surveys。

在下一部分，你将学习如何使用 Ansible 自动化定期重启作业。

使用 Ansible 自动化每周系统重启

定期和计划的系统重启是 IT 环境中的标准过程，旨在确保服务器和应用程序正常运行，并通过服务重启操作保持环境稳定。尽管执行 reboot 命令时很简单，但重启过程及其相关手续并非简单明了。

通用服务器重启活动涉及多个步骤，如下图所示：

图 3.42 – 典型系统重启作业工作流

想象一下，每周你需要重启数百台服务器，而你的团队规模太小，无法在周末处理如此重要的操作。通过使用 Ansible 自动化整个工作流，可以在重启前进行备份操作，并在重启后进行服务验证。

Ansible 的 reboot 模块首次出现在 Ansible 2.7（2018 年）。在撰写时，该模块是 ansible-core 的一部分，包含在所有 Ansible 安装中。

创建一个 Ansible 剧本以重启机器，具体如下：

创建 Chapter-03/system-reboot.yml 剧本，内容如下：

图 3.43 – 用于重启任务的 Ansible playbook

执行 playbook：

[ansible@ansible Chapter-03]$ ansible-playbook system-reboot.yml -e “NODES=nodes”

如下所示，验证 node1 上的重启状态：

图 3.44 – 在 node1 上验证重启状态

在重启系统之前，增强 playbook，添加快照任务（例如，VMWare 或 OpenStack 备份）或文件备份（例如，/etc/hosts、/etc/motd 或 /etc/fstab）。同时，创建额外的任务来验证服务器上所需的服务是否正在运行，例如 httpd 或 mysql 服务。如果你使用的是自动化控制器或 Ansible AWS，那么可以将这些自动化任务设置为每周或每日执行；任务将根据预定计划自动执行，无需任何用户交互（有关更多详细信息，请参考 第十二章，将 Ansible 与工具集成）。

Ansible 重启模块

有关 Ansible reboot 模块的更多信息，请参见 docs.ansible.com/ansible/latest/collections/ansible/builtin/reboot_module.xhtml。

自动化通知

通知管理员和最终用户你在环境中所做的更改非常重要。无论是简单的软件包安装还是系统重启，最终用户都应该知道停机时间和正在发生的更改。与其手动发送电子邮件，不如使用 Ansible 的 mail 模块来自动化电子邮件通知。Ansible mail 模块功能强大，支持大多数电子邮件功能，包括自定义头信息、附件和安全性。

使用 Ansible Vault 加密敏感数据

如果电子邮件服务器（SMTP）未开放（未配置为无需身份验证即可发送电子邮件），则需要使用用户名和密码（应用密码或密钥）对 SMTP 服务器进行身份验证。将此类敏感信息以明文存储并不是最佳实践，因此你需要以安全的方式存储它。要存储这类敏感信息，可以使用密钥库工具，信息将在加密格式中保存。幸运的是，Ansible 提供了一个内置功能，叫做 Ansible Vault，用于存储和管理加密内容。

Ansible Vault 会使用你提供的密码（vault 密码）对文件进行加密，并使敏感数据对普通用户不可读。当 Ansible 想要读取数据时，Ansible 会要求输入 vault 密码；你需要通过键盘输入或通过密钥文件提供密码。

使用 ansible-vault create 命令创建一个 vault 文件。请不要忘记 vault 密码，否则你将无法解密内容：

图 3.45 – 使用 Ansible Vault 创建一个秘密变量文件

完成后，一个文本编辑器（例如vim）将打开，以便你输入敏感文件的内容。添加你的内容并保存文件：

mysecretusername: username 
mysecretpassword: password

如果你尝试读取该文件，你将看到加密的内容，如下所示：

图 3.46 – Ansible Vault 文件加密后的样子

使用ansible-vault view命令查看文件内容；Ansible 会要求输入 vault 密码，如下所示：

图 3.47 – 查看 Ansible Vault 文件的内容

你将在接下来的练习中使用这个 Ansible Vault 来保护 SMTP 服务器的用户名和密码安全。

我们将在第十三章中更详细地讨论 Ansible Vault，使用 Ansible 进行秘密管理。

使用 Ansible Vault 加密内容

使用 Ansible Vault 时，你有更多选项，如编辑、加密、解密、更换密钥等。有关更多详细信息，请参考第十三章，使用 Ansible 进行秘密管理，并查看文档docs.ansible.com/ansible/latest/user_guide/vault.xhtml了解更多关于 Ansible Vault 的信息。

在本练习中，你将通过在系统重启前后添加电子邮件通知来增强之前的每周重启剧本：

创建一个名为Chapter-03/roles/send-email的新角色：

图 3.48 – 创建一个用于发送电子邮件的 Ansible 角色

在roles/send-email/tasks/main.yml中添加一个任务：

图 3.49 – 发送电子邮件角色的任务文件

注意

mail模块的delegate_to: localhost行需要在 localhost（此处为 Ansible 控制节点）上执行，而不是在被管理节点上执行。

如果你的 SMTP 服务器已配置为开放且不需要身份验证，则跳过username和password变量。在这种情况下，你需要创建一个秘密文件来保存用户名和密码。（这里保留了cc和attach选项作为注释，供演示使用。通过添加这些功能，完全可以增强该用例。）

使用 Ansible Vault 创建一个名为vars/smtp_secrets.yml的新变量文件（记住 vault 密码）：

图 3.50 – 使用 Ansible Vault 创建一个秘密变量文件

添加秘密文件的内容并保存它：

图 3.51 – 向 Vault 文件中添加变量并保存它 (:wq)

创建一个新的剧本 Chapter-03/system-reboot-with-email.yml，并包含以下内容（或者，复制之前的 system-reboot.yml 文件并重命名）：

图 3.52 – 带有电子邮件通知的 Ansible 剧本用于重启（1）

添加重启和电子邮件的任务，如下所示：

图 3.53 – 带有电子邮件通知的 Ansible 剧本用于重启（2）

请注意，email_report_body 和 email_smtp_subject 的不同值应根据作业（重启前或重启后）使用。

到此为止，您已经在剧本中包含了 send-email 角色所需的所有变量，除了 email_smtp_username 和 email_smtp_password。这是因为它们是敏感信息，您不能将它们作为明文存储在此；相反，您应将它们包含在您的秘密变量文件（vars/smtp_secrets.yml）中，并通过 Ansible Vault 加密该文件。

执行该剧本：

图 3.54 – 执行没有 vault 密码的 Ansible 剧本

Ansible 正在尝试解密密钥文件，但没有提供 vault 密码（vault 密码）。执行相同的剧本，但在末尾添加 --ask-vault-password 开关（默认情况下，Ansible 不会询问或提示 vault 密码）：

图 3.55 – 执行带有 vault 密码的 Ansible 剧本

检查您的收件箱（您的 email_smtp_to_address）是否收到来自 Ansible 的自动电子邮件：

图 3.56 – 电子邮件通知

作为练习，改进剧本，通过发送所有服务器的合并邮件，而不是单独发送每个邮件或在邮件中附加作业总结报告。

使用 Ansible 发送电子邮件

有关 Ansible 邮件模块的更多信息，请参考 docs.ansible.com/ansible/latest/collections/community/general/mail_module.xhtml。

总结

在本章中，您学会了如何创建 Ansible 角色、Jinja2 模板和 Ansible Vault 密钥。您还学会了如何从 Ansible 事实收集系统信息，并使用 Jinja2 模板来创建报告和配置。您练习的用例非常通用，例如收集系统信息、配置标准系统文件、重启服务器和发送电子邮件通知。作为练习，您可以通过添加更多任务和验证（例如在发送电子邮件之前验证重启活动等）来改进这些用例。

在下一章中，你将学习版本控制系统（VCSs）在 Ansible 中的重要性，保持 Ansible 工件安全的最佳实践，以及如何启用协作与共享，以提高 Ansible 工件的质量。

进一步阅读

要了解本章涉及的更多主题，请查看以下资源：

如何将额外的变量传递给 Ansible playbook：www.redhat.com/sysadmin/extra-variables-ansible-playbook
Ansible 在安全和合规性方面的应用：www.ansible.com/use-cases/security-and-compliance

第四章：探索自动化开发中的协作

当你作为一个团队工作时，协作是团队和谐的关键。与其将你的自动化内容和知识藏在自己手里，不如与团队，甚至其他部门共享。这样，内容将对更多人有用，而且他们还可以贡献自己的想法和技巧。与自定义脚本相比，Ansible 内容更易读，其他人更容易理解。因此，他们可以修改内容并通过修复 bug 或增加功能来贡献。你可以使用任何标准的方法来保存和分发你的 Ansible 自动化内容，比如 Git 服务器、Subversion 或任何其他版本控制系统（VCS）。

在本章中，你将学习以下内容：

版本控制在 IT 自动化中的重要性
我应该把自动化工件保存在何处？
在 Git 服务器上管理自动化内容
协作是自动化的关键

你将从 GitHub 帐户配置和访问管理开始，学习如何与团队共享内容。你还将了解如何管理来自其他用户的贡献，而不丢失原始内容。

本章重点讲解 Git 以及如何使用 Git 管理 Ansible 内容。如果你已经熟悉 Git 和 GitHub，可以跳过关于这些话题的部分。

技术要求

以下是继续本章所需的技术要求：

一台用于 Ansible 控制节点的 Linux 机器。
一台或多台配置了 Red Hat 仓库的 Linux 机器（如果你使用的是其他 Linux 操作系统而非 RHEL 机器，确保你已配置适当的仓库，以便获取软件包和更新）。
创建一个新的 GitHub 帐户所需的电子邮件地址（如果你还没有 GitHub 帐户的话）。
有关源代码控制服务器和版本控制系统的基础知识。

本章所有的 Ansible 代码、Ansible 剧本、命令和代码片段都可以在 GitHub 仓库中找到，链接为github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-04。

版本控制在 IT 自动化中的重要性

就像任何其他软件、配置或脚本一样，最好不要把你的 Ansible 剧本和配置保存在本地机器上，也就是 Ansible 控制节点。将自动化内容保存在本地 Ansible 控制节点上有许多不推荐的原因，下面列出了一些：

如果 Ansible 控制节点出现问题，你将丧失所有的自动化内容，这是不可取的。
如果有人不小心删除了文件或更改了配置，你将没有机会恢复原始内容。
如果你想更改配置或剧本，那么你需要备份文件和配置。这是常见的做法，以防万一发生问题，你可以恢复到文件的旧版本。

你需要将 Ansible 自动化内容视为软件代码，它应该能够跟踪每一次更改，并且随时可以选择使用旧版本。保持多个版本的内容将使你能够自由地对自动化剧本和配置进行持续的修改，并且给予你信心。这也会实施单一真实来源的实践，即你的 Ansible 剧本和变量都保存在一个中心位置，并跟踪所有更改。

版本控制系统（VCS），如 Git 和 Subversion，将帮助你跟踪 Ansible 自动化内容和配置的更改。根据技术的不同，这些工具将在内容发生更改时创建新的版本。

你将把内容保存在 Git 服务器中作为仓库，仓库是文件和目录的集合。可以根据内容创建和维护多个 Git 仓库，例如，一个 Git 仓库用于存储软件包安装剧本和任务，另一个 Git 仓库用于 Linux 修复自动化，等等。你将在本章接下来的部分中实践如何创建和管理 Git 仓库。

Git 文档

请访问 git-scm.com/doc 查阅参考手册、书籍和视频，学习 Git。了解 Git 中的重要术语，如分支、提交、推送、拉取、克隆和暂存。由于本书专注于 Ansible，我们不会详细讲解这些主题。

请注意，软件配置管理（SCM）与 VCS 不同，但 VCS 是 SCM 的一部分或子集。

选择 Git 服务器

选择任何类型的版本控制系统（VCS），但在本章中，我们将重点介绍如何使用 Git 服务器来存储你的 Ansible 自动化内容。组织使用企业级 Git 解决方案，如GitHub 企业版、GitLab 企业版（EE）和Atlassian Bitbucket。如果你在环境中没有 Git 服务器，那么可以轻松地通过任何免费且开源的解决方案来搭建一个，例如 GitLab 社区版（CE）、Gogs 和 Gitea。大多数这些解决方案都包含了图形用户界面（GUI），你可以使用它们来处理任何一般的 Git 用例，包括 Ansible 自动化内容。

GitHub

GitHub 是一个托管服务提供商，用于版本控制仓库和其他持续集成/持续交付（CI/CD）操作。你可以创建一个个人 GitHub 账户，并创建无限制的公共或私人仓库来存储你的软件或配置。GitHub 的主要限制之一是，你不能为你的环境托管一个私人 GitHub 服务器。

GitLab

GitLab (gitlab.com) 是另一种托管的版本控制系统提供商，类似于 GitHub，但具有不同的功能和服务。GitLab 提供公共托管服务器 (gitlab.com)，也支持通过 GitLab EE 或 CE 进行私有托管。

如何安装 Git 服务器

参考www.techbeatly.com/build-your-own-git-server-using-gogs/了解如何使用 Gogs 在简单的 Docker 容器中安装 Git 服务器。如果你想安装 GitLab CE，请参考about.gitlab.com/install/上的文档，获取详细的安装说明。

我们已经学习了将 Ansible 自动化内容存储在 Git 服务器上的重要性，以及可用的不同 Git 服务器。在下一节中，我们将学习将 Ansible 内容存储在 Git 中的最佳实践和仓库指南。

我应该将自动化工件存储在哪里？

根据自动化和内容类型，将你的 playbooks 和配置保存在多个 Git 仓库中。

Ansible 和 Git 仓库的最佳实践

有许多最佳实践用于将你的 Ansible 自动化内容保存在版本控制系统（VCS）中。

Ansible 角色的仓库

如果你仅创建 Ansible 角色（不再常见单独创建用于分发的角色，而不包含集合），那么为每个角色创建一个 Git 仓库，以便开发和协作更为便捷，无需依赖其他任务和配置。参见 图 4.1 中的示例 ansible-role 仓库。

图 4.1 – 为 Ansible 角色创建单独的仓库

Ansible 集合仓库

如果你正在创建 Ansible 集合，那么每个集合创建一个 Git 仓库，以便简化开发和管理。将现有的 Ansible 角色、库、模块以及其他插件移至 Ansible 集合仓库，并以标准方式进行分发。参见 图 4.2 中的示例 ansible-collection 仓库。

图 4.2 – Ansible 集合仓库

为团队创建专用仓库

最佳实践是为不同的团队创建不同的仓库，如果他们正在处理不同的项目，这样可以使仓库管理更加简便和透明。

为清单创建专用仓库

将不同环境和组的清单保存在单独的 Git 仓库中，有助于在 playbooks 中高效使用它们。此外，这一做法可以避免在错误的清单中意外执行自动化任务。例如，你可以将生产服务器保存在一个仓库中，将开发服务器保存在另一个仓库中，如 图 4.3 所示：

图 4.3 – 不同环境的 Ansible 清单目录结构

通过将不同环境的清单分离到不同的 Git 仓库中，您可以控制对这些清单数据的访问权限，例如谁可以修改或使用这些内容。

如果您使用 Ansible 控制器，这个操作同样会帮助您，因为可以从项目仓库中导入清单。请阅读 docs.ansible.com/automation-controller/latest/html/userguide/inventories.xhtml#sourced-from-a-project 了解更多信息。

在 Git 服务器中管理自动化内容

在本节中，您将学习如何创建 GitHub（github.com）账户、创建、安装和配置仓库，并将 Ansible 自动化内容保存在仓库中。

设置 GitHub 账户

如果您已经拥有 GitHub 的个人账户或企业账户，则可以跳过账户创建步骤：

打开您的网页浏览器，访问 github.com，然后点击页面右上角的注册按钮。
在下一个页面中输入您的电子邮件地址、密码和用户名，如图 4.4所示。GitHub 会告知您用户名是否可用，因为 GitHub 中的用户名必须唯一：

图 4.4 – 创建 GitHub 账户

点击继续并完成下一个页面上的简单拼图（验证码）来验证您的身份。完成后，创建您的账户。
在下一个页面中，GitHub 会要求您输入在注册邮箱中收到的一次性代码。请检查您的邮箱以获取该代码（图 4.5）。

图 4.5 – 从邮箱中获取激活令牌

将代码输入到 GitHub 窗口中并完成注册过程（图 4.6）。

图 4.6 – 在 GitHub 中输入一次性令牌

现在，您将进入 GitHub 主页并看到您的激活账户（图 4.7）。

图 4.7 – GitHub 账户主页

其他 Git 服务器

使用其他 Git 服务，如 GitLab（https://gitlab.com）或 Bitbucket（bitbucket.org），注册过程基本相同。

创建您的第一个 Git 仓库

在这个练习中，您将创建一个新的 Git 仓库来存储您的剧本和配置文件：

从 GitHub 主页，点击右上角的 + 图标，并从菜单中选择 新建仓库。

图 4.8 – 创建新的仓库

输入新仓库的详细信息，如仓库名称和描述。同时选择仓库的可见性，可以是公开仓库或私有仓库。同时，勾选 添加 README 文件 选项，如 图 4.9 所示。

图 4.9 – 输入新的仓库名称和详细信息

注意

随时可以更改所有这些配置，但最佳实践是不要更改仓库名称，因为这可能会破坏你的集成和路径。

输入所有细节后，点击 创建仓库 按钮。

GitHub 会显示带有默认 README.md 文件内容的仓库（图 4.10）。该文件是自动创建的，因为我们在上一步中勾选了 添加 README 文件 选项。

图 4.10 – 带有 README.md 文件的 GitHub 仓库默认视图

README.md 是一个特殊文件，用于传达有关仓库或仓库内目录的重要信息。GitHub 会将 README.md 文件的内容以 HTML 等效格式渲染和显示，这是添加仓库信息、文档等的好方法。

Markdown 格式

.md 扩展名用于 Markdown 文件，它是一种轻量级标记语言。Markdown 语言用于通过纯文本编辑器创建格式化文本，之后渲染成 HTML 或其他格式。有关详细信息，请阅读 www.markdownguide.org/getting-started。

在本地机器上安装 Git

你可以通过 GitHub 网络用户界面本身创建和管理 Git 仓库及其内容，但这有限制，因为你不能进行任何批量操作，比如在一次提交中更改多个文件。你也可以通过任何兼容的 Git 命令行或图形界面工具来管理仓库和内容，比如默认的 Git 命令行、GitHub Desktop、Sourcetree、TortoiseGit、SmartGit 和 Tower。

在本练习中，你将安装并使用 Git 命令行工具来访问和管理 Git 仓库：

在 Ansible 控制节点上安装 Git，请使用以下命令：
```
[ansible@ansible ~]$ sudo yum install git
```

接下来，验证 Git 版本：

[ansible@ansible ~]$ git version
git version 2.27.0

配置 Git 用户名和电子邮件地址。此步骤将更新你 Git 环境中的全局用户名和电子邮件地址。你需要使用在创建 GitHub 账户时使用的用户名和电子邮件地址：
```
[ansible@ansible ~]$ git config --global user.name “demouser-2022”
[ansible@ansible ~]$ git config --global user.email “M demo1@techbeatly.com”
```

请注意，使用其他虚拟用户名或电子邮件地址是可能的，因为这些信息不会作为 GitHub 访问的凭据，而是用于本地用户的身份标识。

Git 命令行和图形界面客户端

请访问 git-scm.com/book/en/v2/Getting-Started-Installing-Git 查找如何在不同操作系统上安装 Git 的方法。Git GUI 客户端用于更好地管理 Git 仓库，而无需频繁执行命令行操作。请访问 https://git-scm.com/downloads/guis 查找可用的 Git GUI 客户端。

在 GitHub 中配置 SSH 密钥

您可以使用用户名和密码访问并管理您的 GitHub 仓库，但每次更新 Git 服务器中的内容时输入用户名和密码并不理想。这时我们可以利用 SSH 密钥，您可以使用相同或不同的 SSH 密钥来配置 GitHub 访问。

在本练习中，您将配置 SSH 公钥以实现通过 Git 客户端与 GitHub 的无缝、无需密码的访问：

获取 SSH 公钥内容。使用在第一章《Ansible 自动化 – 简介》章节中的设置基于 SSH 的身份验证部分创建的相同 SSH 密钥对。复制公钥内容，如图 4.11所示：

图 4.11 – 复制 SSH 公钥内容

转到 GitHub | 设置。

图 4.12 – 打开 GitHub 设置

在左侧选择SSH 和 GPG 密钥选项卡（图 4.13）。

图 4.13 – GitHub 账户 SSH 和 GPG 密钥配置

点击新增 SSH 密钥按钮，输入标题（任何可识别的名称）和我们在步骤 1中复制的 SSH 公钥内容。点击添加 SSH 密钥。

图 4.14 – 添加 SSH 公钥内容

GitHub 会要求您输入密码以确认此次 SSH 密钥添加操作。

验证 SSH 密钥是否已添加（图 4.15）。

图 4.15 – 验证 SSH 密钥

在此处添加任意数量的密钥；例如，如果您希望从另一台工作站（或笔记本电脑）管理 GitHub 仓库，则可以在此添加该工作站的 SSH 公钥。另外，注意如果您发现某些 SSH 密钥没有使用或已经泄露，您可以从此页面删除它们并拒绝访问。

向 GitHub 添加 SSH 密钥

请参考 docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account 了解更多详细信息。

向 Git 仓库添加内容

在本练习中，你将把之前创建的自动化剧本（位于第二章，从简单自动化开始）和配置添加到新创建的 GitHub 仓库中。为此，你需要克隆远程仓库（位于github.com）到本地计算机：

访问 GitHub 并进入你的仓库。

图 4.16 – GitHub 仓库详情

找到代码按钮，点击下拉箭头，切换到SSH选项，并复制命令将仓库克隆到本地计算机。

图 4.17 – 获取 GitHub 仓库 URL

由于你已经配置了 SSH 密钥，你可以使用基于 SSH 的克隆并访问仓库。如果你使用基于 HTTPS 的克隆，每次将内容更新到远程仓库时，GitHub 都会要求你输入用户名和密码。

在你的 Ansible 控制节点上，执行git clone命令：

图 4.18 – 克隆 Git 仓库到本地计算机

检查克隆的 Git 仓库的内容：

图 4.19 – 列出克隆的 Git 仓库内容

查看在创建 Git 仓库时自动生成的README.md文件。.git目录包含关于该仓库的所有信息，包括远程仓库和提交详情。

将你在Chapter-02练习中创建的文件移动/复制到此目录，并验证文件是否如图 4.20所示，已存在该目录中：

图 4.20 – 文件移动后 Git 本地仓库的内容

检查git status并注意图 4.21中所示的更改：

图 4.21 – 未追踪文件的 git status 输出

从前面的输出中，你可以理解以下事实：

ansible.cfg、chrony.conf.sample、hosts 和 install-package.yaml 文件不在 Git 数据库中，称为未追踪文件。
如果你想将它们添加到 Git，你需要使用git add命令。

将未追踪的文件添加到 Git（你可以逐个添加或一次性添加所有文件）：
```
[ansible@ansible ansible-package-installation]$ git add *
```

再次检查git status，如图 4.22所示。

图 4.22 – 在将文件添加到 Git 仓库后执行 git status

还需注意，文件尚未传输到远程仓库（GitHub）。

使用git commit命令提交更改到 Git。使用适当的注释来标识仓库中的更改：

图 4.23 – git commit 输出

现在，使用git push命令将更改推送到远程仓库，如图 4.24所示：

图 4.24 – 推送更改到远程 Git 仓库

这将把所有文件和更改传输到远程仓库。

验证 GitHub 上的内容。

图 4.25 – 验证远程仓库中的推送内容

如我们所见，文件已经可以在 Git 仓库中找到。

在 GitHub 上验证提交历史。点击Commits链接（如图 4.25所示，位于Code按钮下方）查看提交记录。

图 4.26 – 在 GitHub 中验证 Git 提交

你可以通过参考 Git 文档来探索提交记录和历史：https://git-scm.com/docs/gittutorial。

现在，我们已经学会了如何将 Ansible 内容添加到 Git 仓库，并通过 GitHub 用户界面查看版本历史。在下一个章节，我们将学习如何管理 Git 仓库中的贡献和协同开发。

协作是自动化的关键

现在，你已经将 Ansible 自动化内容添加到你的 GitHub 仓库中。这带来了几个优点：

在你进行更改之前，不需要备份文件（进行更改后，记得测试、提交并将更改推送到远程 GitHub 仓库）。
随时将内容拉取到任何机器上进行测试。例如，你可以将代码下载到本地工作站并进一步开发。完成更改后，将其推送回远程仓库；新版本的代码将存储在那里。
其他用户和开发人员可以在无需访问你的 Ansible 控制节点的情况下测试和贡献你的代码。你只需允许其他用户适当的访问权限。
如果更新后某些代码无法正常工作，你可以随时回退到旧版本的代码。

让我们在下一个环节学习如何使用 Git 分支。

使用 Git 分支

Git 提供了一个名为分支的功能，它可以帮助你在同一个 Git 仓库中创建多个版本（或分支）。main（以前称为master）和所有 Git 提交都会进入main分支。

你可以在 Git 仓库中创建多个分支，以利用 Git 工作流：

为development和staging创建多个分支以跟踪更改。一旦development和staging分支的内容经过测试并确认没有问题，就可以将这些分支的内容合并到 Git 仓库的main分支中。通过这种做法，main分支将只包含经过测试和清理的代码。
为修补程序或 bug 修复创建不同的分支，并在测试后将其合并到main分支。
创建一个分支，供用户提交他们的代码，经过测试后合并到 main 分支。

你可以根据开发工作流和组织的需求选择任何类型的分支策略。在我们的练习中，我们将使用一个简单的 Git 分支策略，如 图 4.27 所示：

图 4.27 – Git 分支管理

Git 分支和合并可能会因为不同的原因发生。以下是 Git 工作流中典型的任务：

main 分支将包含代码，例如，你的自动化内容的 1.0 版本。
根据需要创建新的功能分支。一旦功能分支经过测试并准备好使用，你将提交一个合并请求（PR，或 拉取请求）。这是贡献者通知 Git 仓库维护者，要求审查功能分支中的代码并将其合并到项目的主分支中的阶段。例如，你可以称这个版本为代码的 2.0。
如果你在代码中发现任何问题，复制一个 bugfix 分支（与功能分支相同），并提出另一个 PR，将更改合并到主分支中。你可以称这个版本为 2.1。

让我们通过一个例子来更好地理解这个概念。

实现 Git 分支管理

在这个练习中，你将学习如何创建多个分支并以不同的用户身份进行贡献。

在这个练习中，我使用了另一台工作站，以不同的 GitHub 用户身份（例如 ginigangadharan）克隆之前创建的仓库。你可以创建另一个 GitHub 账户，或者问问你的朋友是否可以用他们的账户来测试这个：

从网页浏览器中以不同用户（例如：ginigangadharan）的身份分叉原始仓库。点击如 图 4.28 所示的 Fork 按钮。

图 4.28 – 作为不同用户打开仓库

GitHub 会询问目标账户，如 图 4.29 所示（如果你有其他组织账户），以便分叉仓库，并会在新用户账户中创建原始仓库的副本。

图 4.29 – 分叉仓库

现在，你可以看到在新账户下创建了一个新的仓库，这个仓库是从原始仓库分叉（forked）出来的。

图 4.30 – Forked 仓库详情

将此仓库克隆到你的工作站并检查内容；记得使用新的仓库 URL 进行克隆：

图 4.31 – 从新用户账户克隆 Git 仓库

创建一个名为 feature-1 的新的 Git 分支：
```
$ git branch feature-1
```

切换到新分支：

$ git checkout feature-1
Switched to branch ‘feature-1’

检查 Git 分支：
```
$ git branch
* feature-1
  Main
```

在这里，你可以看到 * 符号，表示当前分支。

现在，你可以更新你的代码，例如，修改一些代码行或向 playbook 中添加一些任务。
检查 git status 以查看更改：

图 4.32 – 更新仓库内容后的 Git 状态

你可以看到 install-package.yaml（或你更改的任何文件）已在那里高亮显示。

添加更改的文件并将更改提交到 Git；记得使用适当的提交信息来标识更改：

图 4.33 – 添加更新到 Git 并提交更改

检查 git log 以查看提交历史，如 图 4.34 所示：

图 4.34 – Git 日志中提交的详细信息

将新的分支和更改推送到远程仓库：

图 4.35 – 推送更改到远程 Git 仓库

现在，更新后的代码已出现在新用户的 GitHub 仓库中，这是原始仓库的一个分叉副本。

转到新用户的 GitHub 仓库并选择 拉取请求。

图 4.36 – GitHub 仓库中的拉取请求

点击 新建拉取请求 按钮，选择仓库和分支，然后点击 创建拉取请求 按钮提交 PR（根据需要提供 PR 评论）：

图 4.37 – 在 GitHub 仓库中创建拉取请求

现在，返回到 demouser-2022 用户的 GitHub 账户，查看 PRs。你将看到来自其他用户（即 ginigangadharan）的 PR，并可以打开该 PR。验证合并，检查是否有冲突，然后点击 合并拉取请求 按钮接受此用户的更改。

图 4.38 – GitHub 仓库中拉取请求的详细信息

现在你已经在 Git 仓库中获得了来自另一个用户的最新贡献。

请注意，这只是一个非常基础的 Git 工作流，你需要包括额外的步骤，比如添加 PR 审批、在合并到 main 分支之前创建测试，以及根据需求执行其他政策。

使用上述工作流接受其他用户和团队的贡献，而无需完全开放你的仓库访问权限，这是常见的开源软件使用方法。

小结

在本章中，你已经了解了版本控制在 IT 自动化环境中的重要性。你学习了 Git 的基础知识以及不同的 Git 服务器和提供商。你还实践了创建 GitHub 账户、Git 仓库等步骤，并了解了如何接受其他用户对你的 Git 内容的贡献、分支方法以及 PR 流程。

在下一章中，你将学习如何从你的工作场所和个人项目中找到更多的自动化使用案例。你还将学习更多关于清单管理和不同策略来保持你管理的节点信息。

进一步阅读

若要了解本章所涉及的主题，请访问以下链接：

什么是 Git?: git-scm.com/docs/gittutorial
什么是版本控制?: en.wikipedia.org/wiki/Version_control
什么是拉取请求?: docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
同步你的分支: docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/keeping-your-local-repository-in-sync-with-github/syncing-your-branch

第二部分：寻找使用案例和集成

本书的这一部分将解释如何在 IT 环境中的实际应用案例中使用 Ansible。它还将涵盖大多数常见的项目，如基础设施、平台和应用程序。

本书的这一部分包括以下章节：

第五章**, 扩展你的自动化领域
第六章**, 自动化微软 Windows 和网络设备
第七章**, 管理你的虚拟化和云平台
第八章**, 帮助数据库团队实现自动化
第九章**, 在 DevOps 工作流中实现自动化
第十章**, 使用 Ansible 管理容器
第十一章**, 使用 Ansible 管理 Kubernetes
第十二章**, 将 Ansible 与你的工具集成
第十三章**, 使用 Ansible 进行秘密管理

第五章：扩展你的自动化领域

在合适的地方和适当的层级应用自动化是非常重要的。通常，在寻找自动化应用场景时，人们会犯错，自动化了不合适的任务，最终浪费了金钱、精力和时间。这就是为什么我们需要分析环境和日常任务，找出最适合作为自动化候选的任务的原因。我们可以通过使用诸如事件票据、客户变更请求和项目任务等统计数据来获取这些信息。

在本章节中，你将学习以下内容：

在日常工作中寻找自动化的应用场景
自动化的可行性和可用性
在自动化过程中涉及团队成员
Ansible 动态库存

我们将从标准方法开始，分析任务，找出任务的最大数量，并检查自动化的可行性。我们还将探索IT 服务管理（ITSM）工具与 Ansible 自动化平台之间的集成机会。我们还将实践 Ansible 动态库存与如亚马逊网络服务（AWS）等公共云，并探索 Ansible 主机变量和组变量的重要性。

技术要求

以下是继续本章节所需的技术要求：

一台 Linux 机器作为 Ansible 控制节点（需要有互联网连接）
一台或多台配置了 Red Hat 仓库的 Linux 机器作为管理节点（如果你使用非 RHEL 机器，请确保已配置适当的仓库以获取软件包和更新）
AWS 平台的基础知识，并拥有一个或多个已创建测试机器的 AWS 账户

本章节的所有 Ansible 工件、剧本、命令和代码片段都可以在 GitHub 仓库中找到，地址为github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-05。

在日常工作中寻找自动化的应用场景

我们都知道，IT 环境中每个员工都在执行一些任务，而大多数时间，他们每天都在重复同样的工作。环顾四周，我们可以看到很多例子，如下所示：

系统工程师正在构建服务器和虚拟机，安装软件包，修补旧系统，等等。
网络工程师正在配置新的网络设备和防火墙设备，基于请求配置端口和虚拟局域网（VLANs），修补设备固件，以及许多其他任务。
开发人员每次当编程语言或软件库有新版本时，都在为构建其编程环境而苦恼。他们还花费大量时间测试代码并等待测试结果。
存储管理员正在花费宝贵的时间来配置磁盘空间和存储设备。
一名数据库管理员抱怨新数据库服务器的配置延迟，以及网络或系统准备情况的问题。
一名数据库用户正在为简单的数据库密码重置任务的延迟而苦恼。
操作团队正为事件和警报的洪流而苦恼，他们花费时间筛选虚假警报，导致工作效率低下。
安全团队正在努力修复违规问题，并确保系统符合安全标准。

该列表并不全面；您还会在工作场所发现许多额外的任务和场景。

评估任务

您可以从 ITSM 系统（如 ServiceNow、Remedy 和 Jira）中获取每日或每周的任务报告或详细信息。在此场景中，我们将使用平台团队常见的任务，但您可以使用任何任务、团队或方法进行评估。我们已提取了一周的报告，如图 5.1所示：

图 5.1 – 示例任务报告

我们可以从图表中（图 5.2）看到最关键的任务，这些任务花费了系统工程师最多的时间和精力：

图 5.2 – 每周任务汇总

根据这个非常小的图表，我们几乎可以识别出需要自动化并节省时间的任务。

如果我们查看更多的细节，可以看到任务请求的来源（图 5.3）以及进一步的自动化范围和机会：

图 5.3 – 每周任务来源汇总

大多数 ITSM 工具可以与自动化工具集成，帮助我们从工具本身触发自动化执行。

Ansible 和 ITSM

例如，当用户通过 ServiceNow 门户请求在 Linux 服务器上部署软件包时，您可以配置您的 Ansible Automation Platform，根据 ServiceNow 提供的输入细节触发软件包安装任务。在自动化任务完成后，Ansible 将结果返回到 ServiceNow 工单，创建工单的用户可以在无需等待工程师手动更新工单的情况下查看详细信息。

请注意，您需要使用 Ansible AWX 或 Red Hat Ansible Automation Platform（AAP）进行此集成，单独的 Ansible 控制节点无法实现这一点。

图 5.4展示了与 ITSM 工具和 Ansible AWX 或 Red Hat AAP 的简单集成。您将在第十二章《将 Ansible 与您的工具集成》中了解更多关于 Ansible 和 ITSM 工具集成的内容。

图 5.4 – Ansible 与 ITSM 工具的集成

ITSM 软件

ITSM 软件将帮助组织跟踪和管理其 IT 基础设施的操作、资源及其他相关使用情况：www.gartner.com/reviews/market/it-service-management-tools。

自动化和信息技术基础设施库合规性

当我们谈论使用 ITSM 和自动化工具进行自动化操作时，利益相关者通常会提出关于信息技术基础设施库（ITIL）的实践和合规性问题。IT 自动化并不意味着您需要绕过组织的最佳实践或 ITIL 流程；相反，您是将那些需要人工手动反复执行的任务自动化。例如，您仍然需要在 ITSM 系统中遵循标准的变更审批流程，只有在请求获得批准执行后，工具才会触发自动化操作。

在本节中，我们了解了一些简单的方法来从工作空间中找出自动化使用场景。您可以将复杂的操作拆分为小任务，并从简单的自动化使用场景开始。我们将在下一节中学习如何研究这些使用场景并将其转化为自动化候选项。

自动化的可行性和可用性

我们都需要明白，并非所有的使用场景或重复性工作都适合自动化。我们需要研究并确认是否可以使用 Ansible 自动化来实现这些任务。

一旦找到了使用场景，您可以通过提问自己一些问题来了解自动化使用场景的可行性和可用性。

这个使用场景有多复杂？

您需要考虑您要自动化的使用场景或工作流的复杂性。如果使用场景过于复杂，您可以将其拆分为更小的使用场景。为了避免任何可能的延迟或障碍，您需要从较小的使用场景开始。

例如，如果您想自动化 Linux操作系统（OS）的补丁任务，您可以将工作拆分为多个使用场景，如下所示：

拍摄虚拟机快照。
备份配置。
操作系统补丁任务。
补丁安装和重启后验证操作系统。
在出现故障时恢复快照。

通过这样做，您将更有信心开始自动化之旅，同时，团队中的不同成员也可以在自己的专业领域作出贡献。

我可以减少人为错误吗？

想一想通过为某个使用场景实现自动化，我们能避免多少人为失误。如果任务包含多个步骤，工程师在执行任务时很有可能会遗漏某些步骤或在输入过程中出现拼写错误。这类任务是自动化的好候选项，因为使用自动化工作流时，您无需担心错误和拼写问题。

例如，假设您有一个任务需要部署一个数据库集群，其中有数百个步骤，部分步骤如下：

为集群节点配置 IP 地址。
在集群节点上安装多个包。
在节点上配置多个文件。
配置集群和心跳。
配置虚拟 IP 和虚拟接口等。

在这种情况下，你可以开发 Ansible 剧本来覆盖每一个任务，从而节省大量的时间和精力。

我可以减少部署时间并加快任务速度吗？

自动化可以提高任务、部署和交付的速度，这是一个经过验证的事实。自动化能够显著减少操作所需的时间，因为一个触发器就能完成整个工作流程，工程师无需观察监视器或控制台的错误和状态更新。

所以，你应该问自己关于使用场景的问题，并考虑通过自动化这个任务是否能够节省时间。

例如，如果你使用 Ansible 自动化操作系统补丁任务，你只需通过一个命令触发数百台服务器的补丁更新，然后等待任务完成。你不需要登录到不同的服务器，切换控制台，收集日志或记录事件的时间。你可以将每个任务包含在 Ansible 剧本中，并收集摘要或报告以供后续审核使用。

我执行这个任务的频率有多高？

如果任务执行不频繁（例如，一年一次），那么为该任务开发自动化内容可能没什么用。但如果任务是针对多台服务器执行的，那么这个自动化用例就是有效的，也是一个很好的候选，因为在执行时，你将需要更少的资源，因为自动化将处理复杂的工作流程。

始终将手动任务所需的时间与开发 Ansible 剧本内容所需的时间进行比较。你还需要考虑当前任务可能因为资源不可用或任务复杂性较高而执行得不那么频繁。通过自动化这些任务，你可以提高任务的执行频率，因为使用 Ansible 剧本执行任务时所需的努力更少。

例如，假设你需要管理成千上万台服务器，而由于团队规模较小，操作系统补丁每 6 个月只能更新一次，而且我们都知道工程师需要花费几个小时才能完成单台服务器的补丁更新。由于操作系统补丁任务的复杂性和关键性，你只能在非工作时间（通常是周末）进行操作，并且你需要安排工程师在周末轮流进行这项工作。如果你能通过 Ansible 自动化这个任务，工程师将花费更少的时间，你几乎可以每个月或在需要时随时进行操作系统补丁更新。

我通过自动化这个任务可以节省多少时间？

考虑是否自动化可以帮助节省一些时间，并帮助工程师专注于改进他们的工作流程。对于某些任务，工程师需要坐在工作站前，直到任务达到特定阶段，并且无论工作时间如何，他们都需要交互式地完成任务。

例如，对于每周的系统重启任务，你需要等待系统启动并正常运行，然后才能集中精力处理工作流中的下一个机器。Ansible 可以帮助你自动化这个重启、验证和系统恢复过程，以应对紧急情况。你可以在并行或串行工作流中安排任务，而不必等待某台机器完成重启活动。

我能节省一些钱吗？

从技术角度来看，这并不是主要原因，但降低成本是组织寻求自动化其 IT 和应用基础设施的最常见原因之一。你可以将节省的成本与节省的时间一起评估，因为工程师将花更多时间在改进和更好的实践上，而不是重复处理相同的工作。此外，减少人为错误将有助于减少服务中断，从而减少组织的成本。

你可以根据你组织的需求，在使用案例选择标准和评估中添加更多事实和问题。

在下一部分中，我们将学习如何在 Ansible 清单中组织和存储受管节点信息，以及需要遵循的不同最佳实践。

在自动化过程中涉及团队

一个常见的误解是，寻找使用案例并实施自动化的责任仅仅落在系统团队、平台团队或基础设施团队身上。当我们探索我们的工作环境和日常任务时，我们会发现有成千上万的任务可以使用 Ansible 自动化。可能是数据库团队管理数据库服务器和实例，网络团队处理网络操作，或者应用团队希望更有效地部署其应用程序更新。在环境中实施自动化是一个协作过程，我们需要来自不同团队的支持和指导。

例如，典型的数据库配置步骤可以在 图 5.5 中看到：

图 5.5 – 典型的数据库配置任务

在 图 5.5 中列出的许多任务都可以使用 Ansible 自动化，并且工作流可以在几分钟内完成，而不是几天或几周。数据库团队需要分享更多关于数据库操作和自动化机会的见解，因为他们是数据库相关主题的 主题专家 (SMEs)。

我们有关于使用 Ansible 学习数据库自动化的详细章节，你可以在 第八章 中找到，帮助数据库团队实现自动化。

我们可以以 Windows 服务器自动化为例，因为总有一种误解，认为 Ansible 仅适用于 Linux，不能用于 Windows 服务器自动化。这是不正确的，Ansible 可以用于自动化大多数 Windows 管理和操作。Ansible Windows 集合中大约有 100 个模块，可以通过 Ansible Galaxy 下载，地址如下：

community.windows – galaxy.ansible.com/community/windows
Ansible.windows – galaxy.ansible.com/ansible/windows

请参阅图 5.6，了解 Windows 中典型的用户创建工作：

图 5.6 – Windows 用户创建工作流

整个工作流可以通过 Ansible playbook 中的几个任务进行自动化，Windows 团队可以在环境中的数千台服务器上重用相同的自动化工件。作为 Ansible 内容开发人员，你可以与 Windows 平台团队合作，找到更多类似的使用案例来实施自动化。你将在第六章中了解更多关于 Windows 自动化的内容，自动化 Microsoft Windows 和网络设备。

让我们再探讨一个云平台团队面临的使用案例机会和挑战。当你将 Ansible 自动化引入到管理公共或私有云的云平台团队时，他们总是会面临一个两难问题——如何在虚拟机、磁盘、网络等方面频繁变化时，每次更新 Ansible 清单中的受管节点信息。在接下来的章节中，我们将学习如何使用动态清单插件处理 Ansible 清单中大量动态管理的节点。

Ansible 动态清单

当节点数量较少或资产集几乎固定时（如不经常重建的裸金属服务器或虚拟机），在静态清单文件中管理受管节点信息是容易的。但如果你的环境包含许多动态节点，如多个公共或私有云平台上的虚拟机、Kubernetes 或 OpenShift 平台上的节点，那么将受管节点信息保存在静态文件中就会变得困难，因为你需要跟踪这些变化并将其更新到清单文件中，包括 IP 地址、登录凭证等。在这种情况下，你可以使用 Ansible 中的动态清单功能，基本上是一些自定义脚本和清单插件，从这些虚拟化或容器平台收集清单信息。

当你将动态库存传递给 Ansible 时，库存插件将被执行，并将从你的虚拟化平台收集受管节点的详细信息。这些信息将作为常规库存数据传递给 Ansible，Ansible 将根据节点选择为这些受管节点执行自动化任务。

你可以为任何受支持的平台使用动态库存插件，例如 VMware、OpenStack、AWS、Azure、GCP，或者来自其他容器平台（如 Kubernetes、OpenShift 等），如图 5.7所示：

图 5.7 – Ansible 静态和动态库存

你可以按如下方式列出所有可用的动态插件：

[ansible@ansible inventories]$ ansible-doc -t inventory -l

请注意，如果你安装了额外的 Ansible 集合，你将看到更多的库存插件，因为某些集合可能也包含库存插件。

Ansible 库存插件

欲了解更多有关 Ansible 库存插件的详细信息，可以访问docs.ansible.com/ansible/latest/plugins/inventory.xhtml。旧版动态库存脚本可在docs.ansible.com/ansible/latest/user_guide/intro_dynamic_inventory.xhtml 和 github.com/ansible/ansible/tree/stable-2.9/contrib/inventory 查找。

使用 Ansible 动态库存与 AWS

在本次练习中，你将学习如何安装 Ansible 集合，以及如何使用 Ansible 库存插件管理 AWS 云。你将使用amazon.aws集合中提供的默认 AWS 库存插件。

假设条件

我们假设以下内容：

你有一个 AWS 账户（免费套餐足以完成本练习）。
你具备基本的 AWS 平台知识，足以创建新用户和 EC2 实例。

安装 AWS 集合和库

首先，我们需要在使用库存插件之前安装所需的 Ansible 集合和插件：

配置ansible.cfg文件中的集合路径。默认情况下，ansible-galaxy会将 Ansible 集合（和角色）安装到默认路径，这个路径位于你的主目录下（例如，/home/ansible/.ansible/collections/ansible_collections）。在这种情况下，我们将告诉 Ansible 将集合安装到一个特定路径，以便更好地进行管理。请在ansible.cfg文件中配置COLLECTIONS_PATHS行：
```
[defaults]
inventory = ./hosts 
remote_user = devops
ask_pass = false       
COLLECTIONS_PATHS = ./collections
```

使用ansible-galaxy命令安装amazon.aws集合：

[ansible@ansible Chapter-05]$ ansible-galaxy collection install amazon.aws

验证已安装的集合：

图 5.8 – 已安装 Ansible AWS 集合

你可以看到该集合已安装在你的PROJECT_DIRECTORY/collections路径中。

验证已安装的 AWS 库存插件：

图 5.9 – AWS 清单插件

安装 python3-boto3 包。AWS 模块和插件要求系统中必须有 boto3 包：
```
[ansible@ansible Chapter-05]$ sudo dnf install python3-boto3
```

如果您的 Ansible 是通过 Python 安装的，那么可以使用 pip install boto3 命令安装 boto3。

安装 Ansible AWS 集合后，您需要创建一个用于 Ansible 访问 AWS 平台的 AWS 用户。

如果您使用的是 Ansible 自动化平台的自动化执行环境，那么所有的依赖项和库可以打包在执行环境镜像中。详情请参见 www.ansible.com/products/execution-environments。

创建 AWS 用户和凭证

要使 AWS ec2 清单插件访问您的 AWS 账户，您需要使用标准方法配置 AWS 凭证，如图 5.10所示：

转到AWS 控制台 | IAM | 用户 | 添加用户并选择程序访问：

图 5.10 – 创建具有编程访问权限的 AWS 用户

为新用户添加适当的权限（不要授予用户AdministratorAccess权限，以免影响生产账户），如图 5.11所示：

图 5.11 – 为新 AWS 用户应用权限

如果需要，添加标签并点击创建用户。请记得复制访问密钥 ID和秘密访问密钥，如图 5.12所示，因为我们在接下来的步骤中需要这些信息。

图 5.12 – AWS 用户访问密钥 ID 和秘密访问密钥

创建用户账户后，您需要在 Ansible 控制节点上配置访问密钥和秘密访问密钥。

在 Ansible 控制节点上配置 AWS 凭证

现在，您需要在控制节点上配置 AWS 凭证信息：

在您的 Ansible 控制节点机器上添加新的 AWS 凭证。如果您有多个凭证，则按照以下方式将其作为新配置文件添加（例如，default 和 ansible 配置文件）：

图 5.13 – AWS 配置文件设置

按照如下方式更新 config 文件：

图 5.14 – AWS 配置文件

请记得在接下来的步骤中使用正确的 AWS 配置文件名称（在我们的示例中为 ansible）。

使用 AWS aws_ec2 清单插件

配置完 AWS 凭证后，您可以开始测试动态清单插件：

创建一个包含 ec2 插件信息的清单文件。我们还将包含过滤 ec2 实例的位置信息：

图 5.15 – AWS ec2 实例的清单文件

通过传递清单位置（inventories/aws/）来验证动态清单插件：

图 5.16 – 验证 AWS 动态清单

动态清单插件将使用你在之前步骤中配置的账户访问 AWS 平台，并以 Ansible 可以读取并用于执行的格式返回结果。（我们使用了--graph选项来查看概览，但你也可以使用其他选项，如--list。）

你可以通过标签和主机名添加更多的过滤器，如下所示：
```
filters:
  tag:Environment: dev
  tag:Criticality:
    - low
```
插件将根据你在清单 YAML 文件中配置的过滤器返回结果：

图 5.17 – 带有附加过滤器的 AWS 动态清单

如果你已经配置了ec2实例（使用 AWS ec2 模板或其他方法），那么你现在可以测试访问：

图 5.18 – 使用 AWS 动态清单进行 Ansible ping 测试

安全外壳（SSH）

SSH 是一种加密网络协议，帮助用户以安全的方式访问目标系统。阅读 www.techtarget.com/searchsecurity/definition/Secure-Shell 了解更多关于 SSH 的信息。

在前面的练习中，你已经学会了如何使用 Ansible 动态清单插件，并在没有将受管节点信息添加到任何静态文件中的情况下使用清单。对于所有其他云平台和容器平台，这个过程大致相同，因为你通常可以找到并使用合适的清单插件来实现它们的动态清单。

Ansible 清单插件选项

查看官方文档以获取清单插件的附加选项和过滤器：docs.ansible.com/ansible/latest/plugins/inventory.xhtml 和 docs.ansible.com/ansible/latest/collections/amazon/aws/aws_ec2_inventory.xhtml 以及 docs.ansible.com/ansible/latest/user_guide/playbooks_variables.xhtml#understanding-variable-precedence。

总结

在本章中，你已经学习了如何在工作场所中找到自动化使用案例，并确定这些自动化使用案例的可行性和可用性。你还探索了团队间合作在实施更好自动化使用案例中的重要性。稍后，你学习了如何使用 Ansible 动态清单，并练习了如何使用 AWS ec2 清单插件的 Ansible 清单插件。

在下一章中，我们将学习 Windows 自动化的基础知识以及可用的远程连接方法。我们还将通过实践部分学习使用 Ansible 进行网络自动化的基础知识。

进一步阅读

要了解本章涉及的更多主题，请访问以下链接：

Ansible ServiceNow 集合: github.com/ansible-collections/servicenow.itsm
使用 Red Hat Ansible 自动化平台自动化 ServiceNow: www.ansible.com/blog/certified-collection-servicenow
Ansible 使用案例: www.ansible.com/use-cases
如何构建你的库存: docs.ansible.com/ansible/latest/user_guide/intro_inventory.xhtml
库存技巧: docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.xhtml#inventory-tips
使用动态库存: docs.ansible.com/ansible/latest/user_guide/intro_dynamic_inventory.xhtml
Ansible AWS 集合: docs.ansible.com/ansible/latest/collections/amazon/aws/index.xhtml
Ansible 与 Windows: www.ansible.com/for/windows
Ansible Windows 指南: docs.ansible.com/ansible/latest/user_guide/windows.xhtml

第六章：使用 Ansible 自动化 Microsoft Windows 和网络设备

由于技术的复杂性和广泛的多样性，信息技术领域没有一种适合所有的工具。这在自动化软件中同样适用，但幸运的是，由于大量的社区支持和提供这些服务的供应商的贡献（如云平台、网络设备和软件平台），Ansible 可以用于大多数 IT 自动化用例。

当我们谈论基本系统自动化时，我们知道使用 Ansible 自动化 Linux 机器有多么容易。然而，我们也可以同样地对 Microsoft Windows 机器进行自动化。有社区集合和认证内容集合用于管理 Microsoft Windows 操作，如用户管理、防火墙、系统管理、软件包管理和注册表配置。

同样地，我们通过不同的集合拥有数千个模块，用于管理诸如 Cisco、FortiGate、Palo Alto、VyOS、F5 和 CheckPoint 等网络设备。为了熟悉网络自动化，我们将讨论 VyOS 和 Cisco ASA 设备的网络连接方法和配置。

在本章中，我们将涵盖以下主题：

Ansible 远程连接方法
使用 Ansible 自动化 Microsoft Windows 服务器
网络自动化简介
使用 Ansible 收集 VyOS 信息
在 Cisco ASA 设备中创建 ACL 条目

首先，您将了解 Ansible 中可用的不同连接方法。然后，您将学习如何使用 Ansible 配置和自动化 Microsoft Windows 任务。最后，您将学习如何使用 Ansible 进行网络自动化。

技术要求

本章的技术要求如下：

一个用作 Ansible 控制节点的 Linux 机器
一个或多个作为受管节点的 Linux 机器，并配置了 Red Hat 仓库（如果您使用非 RHEL 机器，则确保配置了适当的仓库以获取软件包和更新）
一个或多个 Microsoft Windows 机器（我们使用了 Windows 2019 服务器）
一个或多个网络设备/虚拟设备（用于实践本章的网络自动化用例）
包括用户创建和软件包管理在内的 Microsoft Windows 机器基础管理知识
包括 IP 配置和访问配置在内的网络设备基础管理知识

本章的所有 Ansible 代码、playbook、命令和片段均可在本书的 GitHub 代码库中找到：github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-06。

Ansible 远程连接方法

默认情况下，Ansible 使用 SSH 协议（本地 OpenSSH）与远程机器进行通信，正如你在本书中前面所学到的。对于没有 SSH 服务器选项的远程节点，可以使用其他连接方法，如 Microsoft Windows 远程机器的 WinRM，或基于 API 的远程设备（如 Cisco NXAPI 和 Arista eAPI）的httpapi。

下图展示了 Ansible 用于自动化不同设备和平台的不同连接方法：

图 6.1 – Ansible 使用的连接方法

你可以找到可用的 Ansible ansible-doc命令，如下所示：

图 6.2 – Ansible 连接插件

Ansible 清单和连接参数

请参考docs.ansible.com/ansible/latest/user_guide/intro_inventory.xhtml#connecting-to-hosts-behavioral-inventory-parameters，了解 SSH、Docker 等连接的具体连接参数。

在你的 Ansible 控制节点上的连接插件数量将取决于你所使用的 Ansible 集合，因为默认情况下，Ansible 只提供少量的连接选项，如ssh、winrm、local等。其余的连接插件来自你已安装的 Ansible 集合。

你还可以查看关于ansible-doc命令的详细信息，如下所示：

图 6.3 – Docker 连接插件的详细信息

在前面的输出中，我们可以看到关于community.docker.docker连接插件的详细信息，包括它的使用方式。

你将在下一节中学到更多关于 Ansible 连接变量和可用选项的内容。

Ansible 连接变量

你可以通过 Ansible 清单参数和其他变量来控制远程连接的详细信息。更多关于 Ansible 特殊变量的内容，请参考文档：docs.ansible.com/ansible/latest/reference_appendices/special_variables.xhtml。以下截图显示了清单变量部分。这里提到了不同的远程连接详细信息，如ansible_connection、ansible_port和ansible_user：

图 6.4 – Ansible 清单变量与特殊变量

可以配置不同的值和变量，如下所示：

ansible_connection：指定要使用的连接类型，如ssh、local（用于localhost节点）、winrm或docker：

# inventory
[local]
localhost ansible_connection=local
[web]
node1 
[windows]
Win2019 ansible_connection: “winrm”

ansible_host：如果远程节点的名称或 IP 地址与清单中的名称不同，则使用实际的名称或 IP 地址。
ansible_user：用于远程节点身份验证的用户账户。
ansible_password：用于 ansible_user 身份验证的密码。请注意，保持 ansible_password 为明文密码并不是最佳实践；你应考虑使用 Ansible Vault 对其进行加密（请参阅 第三章，自动化你的日常工作，以及 使用 Ansible Vault 加密敏感数据 部分，和 第十三章，使用 Ansible 进行密钥管理），或者采用基于 SSH 密钥的身份验证（参见 第一章，配置你的托管节点 部分）。
ansible_port：如果远程连接端口不是 22（默认 SSH 端口），则需要指定用于远程连接的端口号。

在接下来的章节中，我们将学习关于 SSH 连接参数及如何为托管节点配置它。

SSH 连接参数

此外，还存在一些 SSH 特定变量，如 ansible_ssh_private_key_file 和 ansible_ssh_common_args，用于为不同的托管节点分配不同的 SSH 密钥（如果需要）：

图 6.5 – Ansible SSH 特定变量

到此，你已经了解了可用于控制连接的 Ansible 连接方法和连接参数。现在，让我们学习如何使用 Ansible 自动化 Microsoft Windows 服务器。

使用 Ansible 自动化 Microsoft Windows 服务器

如我之前提到的，Ansible 仅适用于 Linux/Unix 平台，但这并不意味着你不能使用 Ansible 来自动化 Microsoft Windows 机器。你可以在 Linux/Unix 机器（即 Ansible 控制节点）上使用 Ansible，像这样自动化你的 Microsoft Windows 机器：

图 6.6 – Ansible 和托管节点

可以使用多个 Ansible 内容集合来进行 Microsoft Windows 自动化。总共有超过 100 个 Ansible 模块可用于自动化 Microsoft Windows 任务：

来自社区的 Ansible Windows 模块 (galaxy.ansible.com/community/windows) 包含 84 个模块。
Red Hat 提供的 Ansible Windows 模块 (galaxy.ansible.com/ansible/windows) 包含 40 个模块。

在接下来的几节中，你将进一步了解 Ansible Windows 自动化，如支持的 Microsoft Windows 版本、前提条件、凭据配置以及库存配置。

Ansible Windows 指南

官方 Ansible 文档门户提供了如何配置和设置 Microsoft Windows 机器以便使用 Ansible 进行自动化的详细信息。请参考 docs.ansible.com/ansible/latest/user_guide/windows.xhtml 和 www.techbeatly.com/ansible-windows 获取更多信息。

支持的 Microsoft Windows 操作系统

Ansible 可以管理大多数通用的 Microsoft Windows 操作系统版本，如下所示：

Microsoft Windows 7
Microsoft Windows 8.1
Microsoft Windows 10
Microsoft Windows Server 2008
Microsoft Windows Server 2008 R2
Microsoft Windows Server 2012
Microsoft Windows Server 2012 R2
Microsoft Windows Server 2016
Microsoft Windows Server 2019

Microsoft Windows 自动化 – Ansible 控制节点的先决条件

对于 Ansible 控制节点，没有特殊要求，只需安装 Python pywinrm 库，安装方法如下：

如果您正在使用 Python 虚拟环境，请记得激活虚拟环境（如果不是，则跳过此步骤）：
```
$ source ~/python-venv/ansible210/bin/activate
```

安装 pywinrm 库：

$ python3 -m pip install --user --ignore-installed pywinrm

确保在 Ansible 使用的 Python 环境中安装了 pywinrm 库（检查 ansible --version 以查看它使用的 Python 版本）。

Microsoft Windows 自动化 – 被管理节点的先决条件

Microsoft Windows 机器应安装并配置以下项：

PowerShell 3.0 或更新版本（某些 Ansible 模块需要更新版本的 PowerShell，具体要求请参考所用模块的文档）。
.NET 4.0 或更新版本。
应该创建并启用 WinRM 监听器 – Ansible 默认使用 WinRM 连接到 Microsoft Windows 机器。Microsoft Windows 远程管理（WinRM）是一个基于 SOAP 的远程管理协议，通过 HTTP 或 HTTPS 进行通信。
应配置 Microsoft Windows 防火墙，允许通过 5985（HTTP）和/或 5986（HTTPS）端口的流量。如果 Ansible 控制节点与 Microsoft Windows 机器之间存在额外的防火墙或网络流量控制，请确保相应端口也被允许。

配置 Microsoft Windows 机器上的用户帐户和 WinRM

在本练习中，您将配置 Microsoft Windows 机器上的用户和 WinRM：

登录到 Microsoft Windows 机器并创建一个名为 ansible 的新用户。使用任意方法创建此用户：

注意

可以使用默认的 Administrator 用户组成员身份来演示自动化而不会遇到问题。有关如何管理 Windows Server 用户帐户的详细信息，请参阅文档 docs.microsoft.com/en-us/windows-server-essentials/manage/manage-user-accounts-in-windows-server-essentials。

图 6.7 – 在 Microsoft Windows 服务器上创建新用户帐户

类似于 Linux 中的 sudo 权限，你需要为从 Ansible 连接到 Microsoft Windows 机器的 Microsoft Windows 用户提供管理员权限。将新的 ansible 用户添加到管理员组，如下所示：

图 6.8 – 将 Ansible 用户添加到管理员组

使用 (Get-Host).Version 命令验证 PowerShell 版本：

图 6.9 – 检查 PowerShell 版本

下一步是配置 WinRM 侦听器并启用 Microsoft Windows 管理节点上的 WinRM 服务。你可以使用 Ansible ConfigureRemotingForAnsible.ps1 仓库中现成的脚本，而不必在 PowerShell 中执行多个命令 (github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1)。

下载脚本并在 Microsoft Windows 机器上执行，如下所示：

图 6.10 – 使用脚本在 Microsoft Windows 机器上配置 WinRM

如果你的 Microsoft Windows 机器位于离线环境中，可以从其他机器下载脚本并将其传输到 Microsoft Windows 机器。

在脚本成功执行后，使用 winrm e winrm/config/listener 命令验证 WinRM 配置：

图 6.11 – 验证 WinRM 配置

然后使用winrm get winrm/config命令验证 WinRM 配置。
验证来自 Ansible 控制节点的端口访问：

图 6.12 – 使用 WinRM 验证 Ansible 与 Microsoft Windows 的连接

配置你的 Microsoft Windows 主机以便由 Ansible 管理

请参考www.techbeatly.com/configure-your-windows-host-to-manage-by-ansible/ 或 docs.ansible.com/ansible/latest/user_guide/windows_winrm.xhtml 以获取更多资料。

现在，Microsoft Windows 管理节点已准备好通过 WinRM 连接。接下来，你需要在 Ansible 端配置这些细节。在下一节中，你将学习如何配置 Ansible 清单以连接到 Microsoft Windows 管理节点。

配置 Ansible 访问 Microsoft Windows 机器

在本练习中，您将为 Ansible 控制节点配置 Microsoft Windows 用户和其他访问详细信息：

在 Ansible 清单中为 Microsoft Windows 创建主机条目（根据需要替换 IP 地址）：
```
[windows]
win2019 ansible_host=192.168.56.22
```

创建一个目录用于 Ansible 组变量：

[ansible@ansible Chapter-06]$ mkdir group_vars

添加group_vars/windows组变量文件，以配置ansible_connection、ansible_port和用户凭据。这些是特殊变量；有关所有特殊变量，请参阅ansible_前缀（参阅docs.ansible.com/ansible/latest/reference_appendices/special_variables.xhtml文档了解有关特殊变量的更多信息）：

图 6.13 – 用于 Windows 的 Ansible 组变量

请注意，在关键环境中使用用户名和密码进行基本身份验证并不是最佳实践。对于生产环境和关键环境，建议使用通过 Ansible Vault 加密的密码，或将凭据保存在 Ansible 自动化控制器（或 Ansible Tower）中。此外，您可能需要创建一个与管理员不同的用户。您还应该考虑使用 SSL 证书和其他安全方法，从 Ansible 控制节点连接 Microsoft Windows 机器。

使用 HTTPS 和 SSL 进行 Ansible Windows 管理

考虑使用 SSL 证书和其他安全方法，从 Ansible 控制节点（或自动化控制器）连接 Microsoft Windows 机器。请参考www.techbeatly.com/ansible-windows-management-using-https-and-ssl了解更多信息。

验证 Ansible 与 Microsoft Windows 机器的连接：

图 6.14 – 使用 win_ping 模块测试 Ansible 与 Microsoft Windows 的连接

与ping模块（用于 Linux 机器）类似，win_ping模块将建立与目标机器的连接，如果连接成功，将显示pong消息。

Microsoft Windows 自动化 – 使用 Ansible 创建 Windows 用户

在本练习中，您将使用 Ansible 在 Microsoft Windows 机器上创建一个新用户：

创建一个新的 Ansible playbook，命名为Chapter-06/windows-create-user.yaml，并添加以下详细信息：

图 6.15 – 用于在 Microsoft Windows 中创建用户的 Ansible playbook

执行 Ansible playbook：

图 6.16 – 执行 Ansible playbook 以在 Microsoft Windows 中创建用户

将清单节点作为额外变量

在前面的 playbook 中，我们没有硬编码 hosts 信息，而是在执行 playbook 时传递了 windows 主机组。

验证 Microsoft Windows 机器，查看用户是否已创建：

图 6.17 – 使用 Ansible 创建的新 Windows 用户账户

查找更多来自工作场所的 Microsoft Windows 自动化用例，例如包部署、组策略更新、Active Directory 操作、防火墙管理、服务管理，甚至执行 PowerShell 脚本。

Ansible 用于 Windows 自动化

请访问 www.ansible.com/for/windows 了解更多关于 Ansible Windows 自动化的信息。访问 aap2.demoredhat.com/exercises/ansible_windows 查找有关使用 Ansible 进行 Microsoft Windows 自动化的工作坊和实践课程。

在下一部分，你将学习使用 Ansible 进行网络自动化的基础知识。

网络自动化简介

使用 Ansible 进行网络自动化基于不同的连接方法。与 Linux/Unix 和 Microsoft Windows 自动化相比，Ansible 网络自动化有一些差异。同时，注意 Ansible 可以用于自动化现有的网络自动化工具，如使用可用的 Cisco ACI 模块自动化 Cisco ACI (docs.ansible.com/ansible/latest/scenario_guides/guide_aci.xhtml)。

在 Ansible 控制节点上执行任务

之前，你已经学到 Ansible 是建立在 Python 之上的，因此必须在远程节点上安装 Python 才能执行自动化任务（Microsoft Windows 模块是用 PowerShell 编写的，必须设置 winrm 连接才能使用 PowerShell 模块）。与 Linux/Microsoft Windows 节点不同，许多网络设备没有 Python，无法运行 Python 脚本。因此，网络自动化模块会在 Ansible 控制节点中处理和执行；所有实际命令将在目标网络设备上执行。

不同的连接方法

网络任务执行可以支持多种通信方法，具体取决于网络设备的操作系统及其版本：

图 6.18 – Ansible 网络通信协议（来源：docs.ansible.com）

你需要指定用于网络设备连接的适当方法、特权升级方法（become_method，如 enable）以及网络设备的操作系统，如下图所示：

图 6.19 – Ansible 网络设备清单

在前面的截图中，我们使用了以下内容：

ansible_connection=ansible.netcommon.network_cli 指定要使用的连接插件
ansible_become_method=enable 使用 enable 作为特权提升方法
ansible_network_os=cisco.ios.ios 表示网络设备的操作系统

网络通信协议

参阅 docs.ansible.com/ansible/latest/network/getting_started/network_differences.xhtml#multiple-communication-protocols 了解使用 Ansible 进行网络自动化时支持的不同通信协议。

在下一部分，你将学习如何创建一个 Ansible playbook，以收集来自 VyOS 网络设备的信息。

使用 Ansible 收集 VyOS 信息

这是一个可选练习，让你熟悉使用 Ansible 进行网络自动化。我们假设你已经掌握了在虚拟机中安装和配置 VyOS 设备的基本知识，并且可以使用你选择的虚拟化平台。

从 support.vyos.io/en/downloads 下载 VyOS 镜像，并将其安装为虚拟设备（更多细节请参考 VyOS 文档 https://support.vyos.io/en/kb）。

VyOS 网络操作系统

VyOS 是一个基于 Debian Linux 的开源网络操作系统。VyOS 提供了大部分网络功能，例如路由、虚拟私人网络（VPNs）、防火墙、网络地址转换（NAT）等。详情请参见 vyos.io。

在以下练习中，你将创建一个简单的 Ansible playbook，以从 VyOS 设备（或虚拟设备）收集操作系统信息：

将 VyOS 虚拟机的详细信息添加到 Ansible 清单中：

[ansible@ansible Chapter-06]$ mkdir inventories/
[ansible@ansible Chapter-06]$ cd inventories/

按如下方式更新清单：

图 6.20 – 使用 VyOS 设备信息更新 Ansible 清单

创建一个名为 Chapter-06/vyos-facts.yaml 的 playbook 来收集 VyOS 事实：

图 6.21 – 用于从 VyOS 设备收集详细信息的 Ansible playbook

执行 playbook，如下所示：

图 6.22 – VyOS 收集事实的 playbook 输出

通过收集更多事实并使用你在第三章中学到的方法生成报告，扩展 playbook，自动化你的日常工作。

在下一部分，你将通过在 Cisco ASA 设备中创建 访问控制列表（ACL）条目来了解一些更高级的网络自动化使用案例。

在 Cisco ASA 设备中创建 ACL 条目

Cisco ASA 是一种安全设备，具备防火墙、病毒防护、入侵预防和 VPN 功能。请参考 www.cisco.com/c/en/us/products/security/adaptive-security-appliance-asa-software/index.xhtml 了解更多关于 Cisco ASA 的信息。

Cisco ASA 集合 (galaxy.ansible.com/cisco/asa) 提供了模块和插件，用于自动化 Cisco ASA 操作。在本节中，您将学习如何使用 Cisco ASA 模块在 Cisco ASA 设备中创建 ACL 条目。

第一个任务是使用 ansible-galaxy 命令安装 Cisco ASA 集合，如下所示：

$ ansible-galaxy collection install cisco.asa

像您配置 VyOS 连接变量一样，您需要配置 Cisco ASA 设备的连接变量，如下所示：

图 6.23 – Cisco ASA 清单变量

和往常一样，记得使用 Ansible Vault（或 Ansible 自动化控制器中的凭证）加密密码，而不是将其作为明文值保存在文件中。另外，注意我们为 Cisco ASA 设备使用的连接变量，例如 ansible_network_os=cisco.asa.asa 和 ansible_connection=ansible.netcommon.network_cli。

一个典型的 ACL 条目创建任务包括多个步骤，如下图所示：

图 6.24 – Cisco ASA 的 ACL 条目创建步骤

遵循组织的政策和程序，执行标准的前置任务和后置任务。最佳实践是基于特定操作创建 Ansible 角色，例如创建对象组、备份配置或创建 ACL 条目。为了使这个过程更容易理解，我为本示例使用了一个单一的 Playbook，如下所示：

图 6.25 – 带变量的 Cisco ACL Playbook

在实际环境中，从仓库中的变量文件（作为事实源）获取这些变量（如 图 6.25 所示），或通过 Ansible 自动化控制器（或 Ansible Tower）中的调查表格收集它们。

向 Playbook 中添加任务，执行 图 6.24 中解释的步骤。

首先，您必须使用 cisco.asa.asa_command 模块将当前配置备份到 TFTP 服务器，如下所示：

图 6.26 – 使用 Playbook 任务备份 Cisco ASA

添加任务，使用 cisco.asa.asa_ogs 模块创建对象组，如下所示：

图 6.27 – 创建对象组的 Playbook 任务

最后，添加任务以使用 cisco.asa.asa_acls 模块创建 ACL 条目，如下所示：

图 6.28 – 创建 ACL 条目的剧本任务

执行剧本并验证任务是否已完成：

图 6.29 – Cisco ASA ACL 剧本执行

一旦剧本成功执行，请通过登录 Cisco ASA 设备来验证其详细信息。以下截图显示了示例输出：

图 6.30 – 从 Cisco ASA 设备控制台验证 ACL 条目的创建

然后，登录 TFTP 服务器并验证备份是否已从剧本任务中创建：

图 6.31 – 在 TFTP 服务器中验证配置备份

通过添加多个规则、对象组和其他备份方法，可以扩展此用例。有关更多信息，请参阅docs.ansible.com/ansible/latest/collections/cisco/asa/index.xhtml中的 Cisco ASA 模块文档。

扩展你对其他网络设备的知识，例如 Cisco、Arista、Juniper Network 或 HPE 设备，但请记住使用适当的连接方法和参数。

网络自动化中的 Ansible

请参阅docs.ansible.com/ansible/latest/network/index.xhtml中的文档，了解更多关于网络自动化基础知识的内容。还可以查看网络入门(docs.ansible.com/ansible/latest/network/getting_started/index.xhtml)，以开始配置网络自动化。

访问www.ansible.com/use-cases/network-automation?hsLang=en-us了解更多关于 Red Hat Ansible 网络自动化的信息。还可以查看 Ansible 网络自动化工作坊(aap2.demoredhat.com/exercises/ansible_network)，获取实践指南。

总结

在本章中，你学习了 Ansible 中不同的远程连接方法和连接变量。之后，你使用 Ansible 探索了 Microsoft Windows 自动化。你学习了如何从 Ansible 连接到 Microsoft Windows 机器，并使用 Ansible 剧本创建一个新的用户账户。

你还学习了 Linux 和 Windows 在网络自动化中的区别。你使用 VyOS 设备探索了简单的网络自动化，并使用收集系统信息的事实收集剧本。

最后，你学习了如何使用 Cisco ASA 集合，并实现了一个用于在 Cisco ASA 设备中创建 ACL 条目的用例。

在下一章中，你将学习如何使用 Ansible 来自动化你的虚拟化和云平台，如 VMware、AWS 和 Google Cloud Platform。

深入阅读

要了解本章中涉及的主题，请查看以下资源：

Cisco ACI 指南：docs.ansible.com/ansible/latest/scenario_guides/guide_aci.xhtml
自定进度的 Ansible 自动化平台互动实验室：www.redhat.com/en/engage/redhat-ansible-automation-202108061218
使用 Ansible 进行网络自动化：www.ansible.com/integrations/networks
Ansible 网络自动化工作坊：aap2.demoredhat.com/exercises/ansible_network/

第七章：管理您的虚拟化和云平台

自虚拟化和云计算引入以来，组织能够使用程序化的方法处理其 IT 基础设施，因为大多数 IT 组件是软件定义的，例如软件定义数据中心（SDDC）、软件定义存储（SDS）、软件定义网络（SDN）等。但是，这些额外的技术层也使得基础设施管理更加复杂，因为工程师需要同时处理底层基础设施和上层虚拟组件。

Ansible 可以帮助您自动化底层云基础设施以及上层虚拟组件的管理，例如虚拟化平台（VMware、OpenStack、Red Hat Virtualization 等）的自动化集群配置。它还可以帮助您配置虚拟组件，如虚拟机、虚拟网络和虚拟存储。

本章将覆盖以下主题：

基础设施即代码简介
使用 Ansible 管理云平台
使用 Ansible 自动化 VMware vSphere 资源
使用 Ansible 作为 AWS 的 IaC 工具
使用 Ansible 在 GCP 中创建资源

首先，您将学习如何配置必要的身份验证，并在虚拟化平台（如 VMware vCenter）和公共云平台（如 GCP 和 AWS）中配置资源。

技术要求

本章的技术要求如下：

用于 Ansible 控制节点的 Linux 机器（需要能够访问互联网）
管理云平台（VMware、GCP 和 AWS）的知识
访问 VMware vCenter 控制台和 API（针对 VMware 用例）
访问 AWS 控制台和 API
访问 GCP 控制台和 API

本章的所有 Ansible 代码、剧本、命令和代码片段可以在本书的 GitHub 仓库中找到：github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-07

基础设施即代码简介

基础设施即代码（IaC）是一种方法，用于将基础设施的细节和配置作为软件代码进行配置和管理，并通过修改代码来更改基础设施，而不是每次需要时修改基础设施。许多专门的工具和软件用于 IaC，包括 Ansible。与手动部署基础设施组件（如虚拟机、存储、网络、策略等）不同，您可以开发 IaC 并使用工具自动化部署基础设施。下图展示了与以下内容相关的典型 IaC 组件：

基础设施组件的详细信息将以特定格式（例如 YAML 剧本）存储为代码。
IaC 工具（例如 Ansible）将根据基础设施代码在私有或公共云中创建和管理基础设施组件：

图 7.1 – 典型的基础设施即代码组件

在接下来的章节中，你将学习如何使用 Ansible 作为基础设施即代码（IaC）工具，在私有和公共云平台上部署和管理基础设施。

使用 Ansible 管理云平台

正如你在前几章中所学到的，Ansible 可以管理 Linux、Windows 和网络设备。但是虚拟化平台的工作方式不同，无法使用基于 SSH 的连接和操作来自动化这些平台。这些平台大多数提供 应用程序编程接口 (API) 和 软件开发工具包 (SDK) 访问方式，帮助我们通过 HTTP（或 HTTPS）访问和控制这些平台。由于 Ansible 可以使用 SDK（Python 库）并通过 HTTP/HTTPS 进行通信，因此可以自动化任何提供这种访问方式的平台。

下图展示了 Ansible 用于与管理设备和平台进行通信的不同连接方式：

图 7.2 – Ansible 连接方式

应用程序编程接口

API 是一种连接或协议，允许一个系统通过一套专用的指令和结果与另一个系统进行通信。与命令行工具不同，命令行工具是用于人机交互的，而基于 API 的访问可以帮助以编程方式和受控的方式自动化和控制这些系统。了解更多关于 API 的内容，请访问 en.wikipedia.org/wiki/API。

Ansible 拥有数百个模块（参见 图 7.3）和插件，支持云自动化，并且它们作为特定云平台或虚拟化平台的集合提供。通过这些模块，可以创建和管理云资源，如虚拟机、虚拟私有网络、虚拟磁盘、访问策略、无服务器组件、容器等：

图 7.3 – Ansible 云模块

在 docs.ansible.com/ansible/2.9/modules/list_of_cloud_modules.xhtml（适用于 Ansible 2.9）上找到云模块的完整列表。自 Ansible 集合推出以来，这些模块已经迁移到相应的云集合中。请查看 Ansible Galaxy 中的集合页面（galaxy.ansible.com），以查看所有插件、角色和剧本，这些内容是 Ansible 内容集合的一部分。例如，以下截图显示了 VMware 集合的社区 Ansible 集合页面（galaxy.ansible.com/community/vmware）：

图 7.4 – Ansible VMware 集合

在 Ansible Galaxy 中搜索集合，并使用来自社区或供应商的适当集合。以下截图展示了在 Ansible Galaxy 门户中搜索 aws 集合的结果：

图 7.5 – AWS 集合在 Ansible Galaxy 中的结果

通过探索 Ansible Galaxy 门户，你将发现来自社区和供应商的成千上万的贡献。通过使用 Ansible 集合，可以利用现有的角色、模块和剧本，节省开发剧本的时间。

在下一节中，你将学习如何通过使用连接方法、模块等来管理 VMware。

使用 Ansible 自动化 VMware vSphere 资源

我们将从一些简单的 VMware 自动化用例开始，例如虚拟机的配置、管理等。community.vmware 包含大约 150 个模块和其他插件：

图 7.6 – 社区提供的 Ansible VMware 集合

community.vmware 集合依赖于 pyvmomi 和 community.vmware 集合，你需要安装适当的包以便 Ansible 使用它。

VMware 已经推出了 vmware.vmware_rest，通过 REST API 来管理操作，而不是使用 Python 库和 SDK。vmware.vmware_rest 包含大约 130 个模块和其他插件：

图 7.7 – VMware 提供的 Ansible VMware REST API 集合

根据你的 vSphere 版本和模块需求，使用这些 Ansible 集合中的任何一个。

VMware Ansible 集合

基于 Python 库的 Ansible VMware 社区集合可以在 galaxy.ansible.com/community/vmware 获取。基于 REST API 的集合可以在 galaxy.ansible.com/vmware/vmware_rest 获取。

Ansible VMware 自动化前提条件

要使用 VMware 集合，你需要满足以下要求：

安装 Ansible VMware 集合。
安装所需的库。

VMware vCenter 实验室

如果你没有 VMware 实验室用于测试和练习，可以获取 VMware vSphere 的评估版（customerconnect.vmware.com/en/web/vmware/evalcenter?p=vsphere-eval-7）并将其安装在你的家庭服务器上。参考如何安装 VMware vSphere Hypervisor ESXi（www.techbeatly.com/how-to-install-vmware-vsphere-hypervisor-esxi）和如何安装 VMware vCenter Server Appliance（www.techbeatly.com/how-to-install-vmware-vcenter-server-appliance）来搭建 VMware 家庭实验室。

安装 Ansible VMware 集合

使用ansible-galaxy命令安装集合。默认情况下，ansible-galaxy会将集合的内容存储在HOME_DIRECTORY/.ansible/collections路径中。为了避免任何依赖问题，最佳实践是将集合存储在项目目录中，而不是主目录中。按照以下方式在ansible.cfg中配置集合路径：

图 7.8 – ansible.cfg 配置文件与 collection_paths

执行ansible-galaxy命令时，集合将根据配置被下载并存储在项目目录中，如下图所示（请参阅VMware Ansible 集合页面，网址为galaxy.ansible.com查看安装命令；请参阅前面的信息框查找链接）：

图 7.9 – 安装 VMware 集合

使用ansible-galaxy collection list命令验证集合的详细信息，如下所示：

图 7.10 – 列出已安装的集合

如果你已经安装了 Ansible 社区包，那么默认集合将作为 Python 的site-packages的一部分存在。最新安装的集合可以在你自定义的集合目录中看到，前面截图中已显示。

安装所需的 Python 库

所需的 Python 库和 SDK 列表将存储在集合文件夹中的requirements.txt文件内，如下所示：

图 7.11 – requirements.txt 中的集合依赖项

使用pip install命令安装 Ansible 集合的所有依赖项，如下所示：

图 7.12 – 安装集合所需的依赖项

如果你正在为 Ansible 使用 Python 虚拟环境，请记得激活适当的虚拟环境，并在虚拟环境中安装必要的库。

自动化执行环境

Red Hat Ansible Tower 使用 Python 虚拟环境来处理依赖项，如 Python 库、集合等。在 ansible-core 和所需的集合中。有关更多详细信息，请参考 www.ansible.com/products/execution-environments。学习如何使用 ansible-builder 工具构建新的执行环境（容器镜像）（docs.ansible.com/automation-controller/latest/html/userguide/execution_environments.xhtml）。

在 Ansible 中配置 VMware 虚拟机

在本练习中，您将创建 Ansible 内容来在 VMware 集群中配置虚拟机。

在继续此练习之前，您必须具备以下配置和详细信息：

VMware vCenter 中的虚拟机模板（Linux 或 Windows）
虚拟机模板中用于访问新虚拟机的默认用户帐户
拥有足够权限的 VMware vCenter 用户名和密码，以便在集群中创建和管理资源
用于保存虚拟机的数据中心、集群、数据存储和文件夹的详细信息

通过登录到 VMware vCenter 并使用 VMware 虚拟机模板创建一些测试机器，确保适当的权限已经设置好。一旦确认了访问和权限，开始为 VMware 虚拟机配置开发 Ansible 工件。

创建用于虚拟机配置的 Ansible 自动化工件

您需要声明并传递一些变量以进行 vCenter 访问和虚拟机创建。将这些变量保存在 playbook 中或单独的文件中。按照以下步骤操作：

将 vCenter 凭据存储在您的 Ansible Vault 文件中——即 vars/vmware-credential.yaml：

图 7.13 – 为您的 VMware 凭据创建 Ansible Vault 文件

将 VMware vCenter 用户名和密码添加到文件中并保存 Vault 文件：
```
vcenter_username: yourvmwareadmin
vcenter_password: yoursecretpassword
```

请记住 Vault 密码，因为在执行 playbook 时将需要它。

创建另一个名为 vars/common-vars.yml 的变量文件，用于存储关于新虚拟机的详细信息（有关详细信息，请参阅本书 GitHub 仓库中的 Chapter-07）：

图 7.14 – VMware 集群和虚拟机的变量

可以在其中添加多个虚拟机详细信息并循环任务。然而，我们这里只涉及了使用单个虚拟机。

使用 ansible-galaxy role init 命令创建用于虚拟机配置的角色，如下所示：

图 7.15 – 使用 ansible-galaxy role init 命令初始化一个新角色

将必要的任务添加到 roles/vmware-provision-vm-from-template/tasks/main.yml：

图 7.16 – 带有子任务文件的 main.yaml

tasks/main.yml 包含两个任务，用于调用子任务文件。第一个任务进行预检查，以确保在继续创建虚拟机之前不存在同名的虚拟机。如果没有虚拟机存在，则根据 when: vm_check.failed 条件执行下一个任务。这是一种最佳实践，因为在 playbook 中需要添加所有可能的验证和错误处理。

创建 roles/vmware-provision-vm-from-template/tasks/vmware-provisioning-pre-check.yaml 的必要内容。如果虚拟机已存在，还要显示一条消息：

图 7.17 – vmware-provisioning-pre-check.yaml

创建 roles/vmware-provision-vm-from-template/tasks/vmware-provisioning-task.yaml 并添加一个任务来创建新的 VMware 虚拟机（请参考本书的 GitHub 仓库查看完整代码），如下面的截图所示：

图 7.18 – VMware 虚拟机创建任务文件

最佳实践是将变量的默认值保存在 roles/vmware-provision-vm-from-template/defaults/main.yml 中，并在执行 playbook 时传递实际值：

图 7.19 – VMware 角色的默认变量

创建主 playbook，Chapter-07/vmware-provision-vm-from-template.yml。由于执行是在本地机器上进行的，适用于 API 和 HTTP 基础平台，确保已配置 hosts: localhost，如下所示：

图 7.20 – 创建 VMware 基础设施的主 playbook

可以根据需要将变量保存在 group_vars 或 host_vars 中。然而，在这里我们采用了变量文件的方法，以便轻松展示此用例。

在前面的代码片段中，使用了 ansible.builtin.wait_for 模块，等待新创建的虚拟机通过 SSH 上线。我们使用了虚拟机的 IP 地址、端口 22（SSH），并指示 Ansible 等待一段时间（vm_wait_for_ssh_time）。详细了解 wait_for 模块，请参阅 docs.ansible.com/ansible/latest/collections/ansible/builtin/wait_for_module.xhtml。

一旦虚拟机启动并运行，将新虚拟机添加到动态主机组 vmwarenewvms 中，以进行后期配置任务，如下所示：

图 7.21 – 将新创建的虚拟机添加到 Ansible 库中

通过使用 VMware 的动态库存插件代替手动添加主机，可以自动检测新创建的虚拟机并在接下来的任务中使用它们。有关更多详情，请参阅 docs.ansible.com/ansible/latest/collections/community/vmware/vmware_vm_inventory_inventory.xhtml。此外，参阅 第五章，扩展您的自动化范围，其中包含 Ansible 动态库存 部分，了解如何将 Ansible 动态库存与 AWS 一起使用。

在同一个 Ansible playbook 中创建另一个 play 来执行后期配置任务，例如创建新用户、配置系统文件和安装新软件包，如下所示：

图 7.22 – 用于后期配置任务的 playbook 中的第二个 play

当您使用 Ansible 自动化控制器（Ansible 自动化平台的一部分）或 Ansible AWX 时，可以将 playbook 拆分为多个作业模板，并创建作业工作流，如下图所示：

图 7.23 – 工作流模板（来源：docs.ansible.com）

在 第十二章，将 Ansible 集成到您的工具中 中，您将了解工作流作业模板和 Ansible 自动化控制器。参阅 docs.ansible.com/automation-controller/latest/html/userguide/workflows.xhtml 了解更多关于工作流模板的内容。

执行 ansible-playbook vmware-provision-vm-from-template.yml playbook，使用 --ask-vault-password 参数并提供 vault 密码，如下所示：

图 7.24 – 执行 playbook 来创建 VMware 虚拟机

向后期配置部分添加更多任务，以自动化虚拟机配置工作流，并将其作为端到端虚拟机配置的单一工作流。在接下来的部分中，您将了解 Amazon Web Services (AWS) 的云管理以及如何将 Ansible 用作基础设施即代码（IaC）工具。

在 vSphere Client 中创建一个模板

请参阅 docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.hostclient.doc/GUID-40BC4243-E4FA-4A46-8C8B-F50D92C186ED.xhtml 了解 VMware 模板创建流程。

将 Ansible 用作 AWS 的基础设施即代码（IaC）工具

在本节中，您将创建 Ansible 内容，用于通过 Ansible 配置和管理 AWS 资源。假设每当您需要创建一个新的 EC2 实例时，您需要执行多个手动步骤，例如创建一个新的虚拟私有云（VPC）、一个新的安全组、网络访问策略以及许多其他项目。您还需要进行后配置步骤，例如创建新的用户帐户、安装软件包、配置应用程序等。

在 Ansible AWS 集合的帮助下，可以自动化所有这些任务，并管理基础设施的整个生命周期。

AWS 免费套餐

要实践 AWS 和 Ansible 的用例，可以使用 AWS 免费套餐，该套餐提供超过 100 种 AWS 资源，免费使用。访问aws.amazon.com/free (图 7.25)并注册免费的 AWS 免费套餐账户来查找它们：

图 7.25 – 使用超过 100 种服务的 AWS 免费套餐访问

确保您的 AWS 资源使用量在 AWS 免费套餐限制范围内，以避免与您的账户连接的信用卡或借记卡被收费。请参考aws.amazon.com/aws-cost-management/aws-budgets/了解如何配置预算警报和其他计费详情。

我已确保以下演示仅使用基于 AWS 免费套餐的资源，这样您的 AWS 免费套餐账户将不会产生额外费用。但在完成测试后，也很重要要从 AWS 账户中删除这些资源。

安装 Ansible AWS 集合

如您在上一节中所学，可以使用ansible-galaxy命令来安装 Ansible AWS 集合。如果项目需要多个集合，可以创建一个requirements.yaml文件，并在其中列出所需的集合和角色：

图 7.26 – 包含集合详细信息的 requirements.yaml 文件

一旦requirements.yaml文件已更新，通过调用requirements.yaml文件，使用ansible-galaxy命令安装集合：

图 7.27 – 使用 requirements.yaml 安装集合

该集合将安装在您在ansible.cfg中配置的Chapter-07/collections路径下。请验证集合，如下所示：

图 7.28 – Ansible 集合列表

现在，Ansible 的 AWS 自动化集合已准备好使用。现在，开始开发您的 Ansible 剧本。

为 AWS 基础设施创建 Ansible IaC 内容

在此场景中，将安装两个 Web 服务器并配置网站内容，在 弹性负载均衡器（ELB）后面提供服务，如下图所示：

图 7.29 – 构建 Web 服务器基础设施和应用程序

可以创建多个角色来处理 Ansible 自动化内容中的多个资源，如下图所示：

图 7.30 – 管理云平台的 Ansible 角色

查看 amazon.aws 集合文档（galaxy.ansible.com/amazon/aws），了解安装 boto 和 boto3 Python 库的 Python 库要求。您在 第五章《扩展您的自动化领域》中已学习如何操作。请参考该章节学习如何配置 AWS 凭证，以便进行此自动化作业。

为 AWS 环境创建变量

有关 AWS 区域、VPC 和子网的详细信息存储在 Chapter-07/vars/aws-common-vars.yml 文件中（请参阅 GitHub 上的课程仓库）：

图 7.31 – vars/aws-common-vars.yml 中的 AWS 相关变量

一旦有关 AWS 云的详细信息存储在变量中，就必须创建一个变量来存储 EC2 实例的详细信息。

AWS 中的默认 VPC

当您开始使用 AWS VPC 时，每个 AWS 区域将默认存在一个 VPC，包含以下资源：

每个 可用区（AZ）中的子网（公共）
一个互联网网关
DNS 解析

在本示范中，我们将使用 amazon.aws.ec2_vpc_net Ansible 模块。请参阅官方文档（docs.aws.amazon.com/vpc/latest/userguide/default-vpc.xhtml）了解更多信息。

列出 EC2 实例

有关新 EC2 实例的详细信息存储在 vars/aws-ec2-new.yml 文件中：

图 7.32 – 变量文件中的新 EC2 详细信息

通过此变量可以控制 EC2 实例的数量，因为您将使用循环来配置它们。现在，您必须配置 AWS 安全组变量。

创建 AWS 安全组

使用 amazon.aws.ec2_group 模块在 roles/aws-create-sg/tasks/main.yml 中创建一个新安全组，并配置所需规则，如下所示：

图 7.33 – 安全组任务

如果您的应用程序在不同端口上提供服务，请相应添加端口并根据需要调整剧本。一旦完成此操作，您必须创建 SSH 密钥对任务。

创建 SSH 密钥对

可以使用 amazon.aws.ec2_key 模块创建新的密钥对。在 roles/aws-create-keypair/tasks/main.yml 中，将使用本地密钥对（~/.ssh/id_rsa.pub）：

图 7.34 – 创建 SSH 密钥资源

这个密钥对非常重要，因为您稍后需要使用它来访问 EC2 实例并配置 Web 服务器和其他细节。在前面的代码块中，我们使用了工作站上的现有 SSH 密钥对（~/.ssh/id_rsa.pub）及其公钥，在 AWS 中创建了这个新的密钥对资源，以便我们不需要重新下载私钥。现在，您必须添加用于创建弹性负载均衡器（ELB）的任务。

创建弹性负载均衡器

可以使用 amazon.aws.ec2_elb_lb 模块在 roles/aws-create-elb/tasks/main.yml 中创建新的 ELB，如下所示：

图 7.35 – 创建 Amazon ELB

如果您使用的是不同版本的 AWS Ansible 集合，请查看适当的 Ansible 模块以创建负载均衡器，并相应地更改 playbook。现在，您已准备好创建 EC2 实例任务。

创建 EC2 实例

最后，开始创建 EC2 实例。然而，您必须确保不会创建重复的虚拟机。最佳实践是在 playbook 中添加验证，以避免自动发生任何错误，因为 AWS 不会对创建具有相同名称的多个实例提出警告。

在 roles/aws-create-ec2/tasks/main.yml 中创建必要的任务以收集现有实例。只有当实例不存在时，才继续创建 EC2 实例：

图 7.36 – 获取 EC2 实例

如果 EC2 实例已经存在，则不应再次创建新 EC2 实例。因此，根据 existing_ec2_list 创建新的 EC2 实例，如下所示：

图 7.37 – 如果实例不存在，则创建 EC2 实例

创建 EC2 实例后，您需要收集新创建的 EC2 实例的详情，并等待它们启动并响应在线状态，如下所示：

图 7.38 – 收集新创建的 EC2 实例信息

一旦 EC2 实例启动并运行，收集其详情，以便您可以将它们更新到 ELB：

图 7.39 – 收集新 EC2 实例的详情

使用收集的详情（ec2_existing_collected），在后台更新 ELB 实例项，如下所示：

图 7.40 – 在后台更新 ELB 实例详情

ELB 和后端实例已经准备好并已连接，但 EC2 实例内还没有运行任何程序。现在，你需要在其中安装 Web 服务器及其内容。为此，收集新创建的 EC2 实例详细信息，放入动态主机组中，以便进行后置配置任务，如下所示：

图 7.41 – 使用新的 EC2 实例详细信息更新库存

与前面的截图中所示的收集主机详细信息不同，你也可以利用 Ansible 动态库存。参见第五章，扩展自动化领域，Ansible 动态库存 部分，了解如何在 AWS 中使用 Ansible 动态库存。

一旦你准备好了所有角色中的任务，就按照适当的顺序在主剧本中使用这些角色。

集成 AWS 配置工作流的主剧本

IaC 配置工作流写在主剧本中——即 Chapter-07/aws-infra-provisioning.yaml（请参考本书的 GitHub 仓库获取完整代码）。作为最佳实践，变量可以存储在 group_vars 或 host_vars 下。然而，我们采用了变量文件的方法来简化此用例的演示。按照以下顺序使用之前创建的角色：

图 7.42 – AWS 基础设施配置剧本

在同一个剧本中，后置配置任务已经被添加到名为 Deploy Webserver to EC2 instances 和 hosts: ec2webservers 的不同 play 下（即在 roles/aws-create-ec2/tasks/main.yml 中创建的动态主机组）。

deploy-web-server 角色将安装 httpd Web 服务器，并安装 firewalld，同时配置 Web 服务器以提供默认的网站内容。以下截图显示了后置配置的 play 以及一个可选的 play，用于展示 ELB 地址，这样你就不需要登录 AWS 控制台去检查访问网站的 URL：

图 7.43 – 第二个 play 中的后置配置任务

执行剧本时，工作流将触发基础设施和应用程序的配置：

[ansible@ansible Chapter-07]$ ansible-playbook aws-infra-provisioning.yaml

最后，后置配置任务完成后，将显示以下信息：

图 7.44 – 显示 ELB 详细信息的 Ansible 剧本

向配置工作流中添加更多资源，例如额外的 EBS 卷、网络访问控制规则，以及来自自定义 AMI 或快照的镜像。后置配置可以根据需要通过更多配置来扩展。

现在，你需要创建剧本内容来删除资源，以完成完整的 IaC 生命周期。

通过使用销毁剧本完成 IaC 生命周期

Chapter-07/aws-infra-destroy.yaml 剧本将负责销毁资源和清理任务（请参考本书的 GitHub 仓库获取完整代码）：

图 7.45 – AWS 基础设施销毁剧本

如果不再需要资源，可以使用销毁剧本销毁整个基础设施：

[ansible@ansible Chapter-07]$ ansible-playbook aws-infra- destroy.yaml

在本节中，您学习了如何创建 AWS 资源并管理实施基础设施即代码（IaC）实践的端到端生命周期。在下一节中，您将探索类似的 Google Cloud Platform（GCP）自动化。

Ansible 与 AWS 集成

阅读更多关于 Ansible AWS 集成的信息：www.ansible.com/integrations/cloud/amazon-web-services。

使用 Ansible 在 GCP 中创建资源

与 VMware 和 AWS 类似，借助 Ansible GCP 内容集合，您可以创建和管理 GCP 资源。

Ansible GCP 自动化的前提条件

在开始之前，您需要确保为 Ansible GCP 自动化配置了必要的前提条件。

正如您在 VMware、AWS 和其他平台上所学的那样，您需要安装相关的 Ansible 内容集合。在本例中，如果尚未安装，您必须安装 google.cloud 集合：

[ansible@ansible Chapter-07]$ ansible-galaxy collection install google.cloud

google.cloud 集合包含约 170 个模块、角色和其他插件，用于自动化 GCP 基础设施及其资源。

google.cloud 集合中的模块需要在系统上安装以下 Python 库：

$ pip install requests google-auth

如果您正在使用 Python 虚拟环境进行 Ansible 操作，请确保将库安装到正确的路径。

用于 Google Cloud 的 Ansible

通过阅读 Google Cloud Platform 手册，了解更多 Ansible GCP 自动化内容：docs.ansible.com/ansible/latest/scenario_guides/guide_gce.xhtml。同时，访问 galaxy.ansible.com/google/cloud 查阅 Google Cloud Ansible 集合，探索 GCP 自动化的 Ansible 模块。

GCP 免费试用

为了练习 GCP 和 Ansible 的使用案例，可以通过 GCP 免费试用获得超过 20 项 GCP 服务，免费使用。访问 cloud.google.com/free 并注册 GCP 免费层账户。我已经确保以下演示仅使用基于 GCP 免费层的资源，因此不会对您的账户产生额外费用。完成测试后，记得从您的 GCP 账户中删除这些资源。

配置 GCP 凭证

使用你的 GCP 服务账户或机器账户配置 Ansible 自动化平台访问（更多信息请参阅下面的信息框）。创建服务账户并下载 JSON 文件后，配置 Ansible 使用该 JSON 文件作为 GCP 访问凭证。

可以将凭证配置为模块参数或环境变量，具体如下：

GCP_AUTH_KIND
GCP_SERVICE_ACCOUNT_EMAIL
GCP_SERVICE_ACCOUNT_FILE
GCP_SCOPES

根据环境和实践，选择合适的方法，类似于我们为 VMware 和 AWS 所做的。

创建 GCP 服务账户

请参考 developers.google.com/identity/protocols/oauth2/service-account#creatinganaccount 了解如何创建 GCP 服务账户，并创建和下载 JSON 密钥文件。

使用 Ansible 创建 GCP 实例

在此练习中，您将创建 Ansible 内容以在 GCP 中创建一个简单的计算实例：

创建一个名为 vars/gcp-details.yaml 的变量文件，以便您可以存储 GCP 凭证详细信息，如下所示：

图 7.46 – Ansible 的 GCP 配置变量

创建 Chapter-07/gcp-create-instance.yml 剧本。根据需要使用 google.cloud.gcp_compute_network 创建新的 VPC 网络，并配置新的 GCP 实例以便它使用新的 VPC 网络。在此练习中，您将使用 default VPC 网络，并添加一个任务来获取 default VPC 网络的详细信息：

图 7.47 – GCP 配置剧本

向同一剧本中添加一个任务，使用 Debian 9 操作系统创建 GCP 实例启动磁盘（根据需要使用其他公共镜像或自己的私有镜像）：

图 7.48 – 为新虚拟机创建 GCP 磁盘

instance_source_disk 变量将包含有关磁盘的详细信息。我们将在下一步将此信息传递给实例创建任务。

添加一个任务来创建 GCP 实例，并传递网络和磁盘详细信息，如下所示：

图 7.49 – 创建带有网络和磁盘详细信息的 GCP 实例

执行 Ansible gcp-create-instance.yml 剧本：

[ansible@ansible Chapter-07]$ ansible-playbook gcp-create-instance.yml

如下所示，在 GCP 控制台验证实例详细信息：

图 7.50 – 在 GCP 控制台验证实例

同时，验证磁盘详细信息，如下所示：

图 7.51 – 在 GCP 控制台验证磁盘详细信息

可用大约 170 个模块，几乎可以管理 GCP 中的所有云资源，包括计算、磁盘、网络、负载均衡器、防火墙、路由、云构建、自动扩展、DNS、数据库、Spanner 等。

Ansible GCP 模块

请参考官方文档查看可用的 Ansible GCP 模块：docs.ansible.com/ansible/latest/collections/google/cloud/index.xhtml。

总结

在本章中，你了解了 IaC 的概念以及如何使用 Ansible 作为 IaC 工具。你还了解了 Ansible 如何管理虚拟化和云平台，如 VMware、AWS 和 GCP。然后，你了解了这些平台的不同方法和凭证配置，以便 Ansible 能够访问并执行自动化操作。

接下来，你了解了可用于 VMware、AWS 和 GCP 的 Ansible 模块和集合。通过开发用于创建新虚拟机（EC2 实例或 GCP 实例）的基本 playbook，你已经开始了基础设施自动化和管理的旅程。扩展 playbook 的内容，构建适合你云和虚拟化环境的使用案例。

在下一章中，你将学习如何帮助非平台团队使用 Ansible 进行自动化应用场景，例如使用 Ansible 构建和管理数据库。

进一步阅读

要了解更多本章内容的相关主题，请查看以下资源：

什么是基础设施即代码（IaC）？: www.redhat.com/en/topics/automation/what-is-infrastructure-as-code-iac
Ansible VMware 指南: docs.ansible.com/ansible/2.5/scenario_guides/guide_vmware.xhtml
VMware API 和 SDK 文档: www.vmware.com/support/pubs/sdk_pubs.xhtml
介绍 VMware REST Ansible 内容集合: www.ansible.com/blog/introducing-the-vmware-rest-ansible-content-collection
Ansible Amazon Web Services 指南: docs.ansible.com/ansible/latest/collections/amazon/aws/docsite/guide_aws.xhtml

第八章：帮助数据库团队实现自动化

有状态应用程序，按定义必须持久保存数据。因此，当我们谈论有状态应用程序时，数据将成为关键因素，因此也涉及数据库服务器。根据你要存储的数据类型，选择任何支持的数据库软件。这包括事务数量、应用程序所需的性能、高可用性和故障切换支持以及许多其他因素。然而，更重要的考虑因素是准备数据存储、安装必要的依赖项、软件包或库。在维护方面，这将是一个持续的过程，因为我们需要处理备份、数据转储、快照和在故障情况下的恢复。

Ansible 可以帮助你应对这种情况。有数百个 Ansible 数据库模块可以帮助你实现数据库自动化任务，包括数据库安装、部署、管理表格、管理用户以及许多其他任务。

本章将涵盖以下主题：

Ansible 在数据库操作中的应用
安装数据库服务器
使用 Ansible 创建和管理数据库
自动化 PostgreSQL 操作
使用 ITSM 和 Ansible 自动化密码重置

我们将学习如何安装 PostgreSQL 数据库服务器，创建数据库，配置数据库表格，用户认证等。你还将了解在使用 Ansible 和IT 服务管理（ITSM）工具时进行零接触自动化的集成机会。

技术要求

以下是继续本章所需的技术要求。

用于 Ansible 控制节点的 Linux 机器（需要有互联网连接）
用于安装和配置 PostgreSQL 服务器的 Linux 机器
数据库（PostgreSQL）和服务器的基础知识

本章的所有 Ansible 代码、剧本、命令和片段可以在本书的 GitHub 仓库中找到，地址为 github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-08。

Ansible 在数据库操作中的应用

数据库操作不仅仅涉及部署数据库服务器，还包括日常操作，如管理数据库、表格、数据库用户、权限或访问。Ansible 可以通过适当的 Ansible 模块与大多数著名的数据库服务进行交互，如下图所示：

图 8.1 – Ansible 数据库自动化

一些最常见的数据库自动化用例如下：

部署独立数据库服务器
配置高可用性（HA）数据库集群
创建数据库和表格
管理用户账户
管理权限
管理数据库和服务器访问
备份和恢复操作
实现数据复制和镜像
自动化数据库故障切换

在 Ansible 数据库集合和模块的帮助下，我们可以自动化大多数这些操作。在下一节中，你将学习如何使用 Ansible 安装 PostgreSQL 数据库服务器。

请参考本章结尾的 进一步阅读 部分，获取更多资源。

安装数据库服务器

如果你是数据库管理员，或者你了解数据库服务器的工作原理，那么你一定知道按照应用需求管理和维护服务与数据的痛苦与挑战。自从虚拟化和基于云的平台引入以来，配置虚拟机、磁盘和其他资源已经不再是大问题。然而，我们仍然需要自动化选项来配置数据库服务器和数据库实例。公共云服务提供商（CSPs）提供了所谓的托管数据库解决方案，它们提供一键部署服务，但在大多数情况下，如果我们有更严格的要求，往往无法对这些服务拥有太多控制和透明度。因此，组织不得不使用自托管的数据库服务器，并遵循手动部署和管理过程。

在第七章，管理你的虚拟化和云平台中，你学习了如何自动化基础设施的配置，包括虚拟机和磁盘。在本章中，我们将探讨如何自动化数据库任务，例如安装数据库服务器，或配置数据库或表，如下图所示：

图 8.2 – 基本数据库操作

幸运的是，Ansible 提供了丰富的模块和插件，用于部署和管理数据库服务器，如 Microsoft SQL、MySQL、PostgreSQL、InfluxDB、MongoDB、ProxySQL 或 Vertica。在接下来的章节中，你将了解基于 Ansible 的数据库部署基础知识。

使用 Ansible 安装 PostgreSQL

如果参考官方文档，安装 PostgreSQL 是简单的。然而，你需要安装 PostgreSQL 所需的所有依赖项和库。你还需要配置数据库服务器的详细信息。幸运的是，Ansible Galaxy 上有很多写得很好的 Ansible 角色，我们可以下载并使用它们来安装和配置 PostgreSQL 服务器（以及其他数据库服务器）。下图展示了我们在 Ansible Galaxy 中搜索 postgresql 角色的过程：

图 8.3 – 在 Ansible Galaxy 中搜索 postgresql 角色

在本练习中，你将使用由社区成员 Jeff Geerling 贡献的 geerlingguy.postgresql Ansible 角色安装一个简单的独立 PostgreSQL 服务器，该角色的链接为 galaxy.ansible.com/geerlingguy/postgresql。请按照以下步骤进行：

确保你的 ansible.cfg 文件已根据项目配置了特定的角色和集合页面：

图 8.4 - 配置 ansible.cfg

使用 ansible-galaxy 命令安装角色，如下所示：

图 8.5 – 使用 ansible-galaxy 命令安装 Ansible 角色

创建一个名为 Chapter-08/vars/postgres.yaml 的变量文件，以便传递一些用户详细信息、要创建的数据库和 hba 条目，更新 geerlingguy.postgresql 角色。此角色将根据你传递给 Playbook 的变量自动创建资源。如果你不希望自动创建此类条目和配置，可以跳过此步骤：

图 8.6 – PostgreSQL 数据库的变量

重要提示

postgresql_users have been specified in plain text for demonstration purposes. You should consider using encrypted passwords using Ansible Vault or other appropriate methods.

创建 Chapter-08/postgres-deploy.yaml Playbook，如下所示：

图 8.7 – 部署 PostgreSQL 服务器的 Playbook

添加一个任务，允许 PostgreSQL 的远程连接并重启 PostgreSQL 服务。最后，在防火墙中允许数据库端口 5432，如下所示的代码片段。如果使用的是其他防火墙服务模块（例如 community.general.ufw），请根据需要进行修改：

图 8.8 – 打开端口和数据库服务的任务

执行 Playbook 并部署 PostgreSQL 服务器：

图 8.9 – 执行 Ansible Playbook 部署 PostgreSQL

登录到数据库服务器（node1），并通过切换到 postgres 用户来验证数据库服务器的详细信息，如下所示：

图 8.10 – 登录 PostgreSQL 数据库服务器

以 postgres 用户身份打开 psql 客户端，如下所示：

图 8.11 – 在数据库服务器上打开 psql 客户端

使用 \l 命令列出现有的数据库，并验证 database_demo 是否已创建（根据 vars/postgres.yaml 文件中的变量配置）：

图 8.12 – 在 psql 命令行中列出现有的数据库

使用 \du 命令验证用户列表，如下所示：

图 8.13 – 在 psql 命令行中验证用户

使用 Ctrl + D 键盘快捷键或 \q 命令退出 psql 控制台：

图 8.14 – 退出 psql 控制台

还需要验证pg_hba.conf文件；geerlingguy.postgresql角色将根据变量的内容配置此文件。请检查/var/lib/pgsql/data/pg_hba.conf文件，方法如下：

图 8.15 – 验证/var/lib/pgsql/data/pg_hba.conf 文件

如果您希望从远程节点访问 PostgreSQL，您需要确保pg_hba.conf文件中的条目已正确配置。

使用现有的 Ansible 角色是最佳实践，这样可以节省大量时间和精力来开发自动化内容。同时，您需要确保 Ansible 角色及其方法适合您的环境，而不是盲目使用它们。

在下一节中，您将学习如何更新默认postgres用户的密码。

配置默认 postgres 用户的密码

默认用户postgres没有配置密码，默认的认证方法是postgres用户（或其他管理员用户的密码）。按如下方式设置或更新postgres用户的密码：

切换到postgres用户：

图 8.16 – 切换到 postgres 用户并打开 psql 命令行

更改密码，退出psql控制台，然后按以下方式退出postgres用户：

图 8.17 – 更改密码并退出 postgres 账户

如果需要，这些步骤也可以在您的数据库安装 Playbook 中自动化，尽管这取决于您组织的需求。

也可以使用 Ansible 自动化其他数据库服务器的安装，例如 Microsoft SQL Server。我们将在下一节中讨论这个问题。

在 Linux 上安装 Microsoft SQL Server

2016 年，微软通过其博客（参考以下信息框）宣布 Microsoft SQL Server 将在 Linux 平台上运行。因此，在没有 Windows 服务器的情况下，您可以安装并使用 MSSQL 数据库，且安装将支持最常见的 Linux 平台，如Red Hat 企业 Linux（RHEL）、SUSE 企业 Linux 服务器（SLES）、Ubuntu 等。

在 Linux 上安装 MSSQL 非常简单，但仍然涉及一些配置和服务步骤。当部署中需要安装多个数据库服务器时，除了手动配置每个服务器外，还可以使用 Ansible 角色和 Playbook 来实现这一过程。按照文档中的步骤（参考以下信息框）或使用社区提供的现有贡献；例如，galaxy.ansible.com/microsoft/sql上的角色可以用来在 Linux 上安装 MSSQL：

图 8.18 – 安装 microsoft.sql 集合

community.general.mssql_db 社区模块可用于添加或删除 MSSQL 数据库，方法如下：

图 8.19 – 创建 Microsoft SQL 数据库

在 Ansible Galaxy 中探索更多 MSSQL 自动化内容，并根据环境需求使用它。

公布 SQL Server 在 Linux 上的发布

微软关于 SQL Server 在 Linux 平台上可用性的公告可以在blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/查看。

SQL Server 在 Linux 上的安装指南可以在docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup查看。

一旦数据库服务器安装并配置完成，可以自动化其他任务，例如创建新数据库、创建新表、添加用户或权限。使用现有的 Ansible 集合和模块，例如community.postgresql、community.mysql、community.cockroachdb、community.cassandra等。我们将在下一节中学习如何使用community.postgresql Ansible 集合进行 PostgreSQL 数据库的自动化。

使用 Ansible 创建和管理数据库

PostgreSQL 的社区集合包含 20 多个模块和一些插件。可以使用这些模块和插件自动化 PostgreSQL 数据库操作，包括创建、删除和更新数据库、表格、用户和数据库服务器中的其他资源。

Ansible `community.postgresql` 前提条件

如果你从远程节点（例如 Ansible 控制节点）访问 PostgreSQL，则需要在该机器上安装psycopg2 Python 库，以使用这些 PostgreSQL 模块：

$ pip install psycopg2

在下一节中，我们将使用 Ansible 从数据库节点本身（node1）执行任务。因为数据库服务器已经配置了所需的依赖项，所以此库不是必需的。

在下一节中，你将学习如何使用 Ansible 和community.postgresql 集合来管理数据库操作。

管理数据库生命周期

在本节中，你将学习如何创建数据库、在新数据库中创建表格，然后使用 Ansible 配置用户和权限。按照以下步骤操作：

创建 postgres-manage-database.yaml Playbook，并添加提供关于要创建的数据库、要配置的表格、要添加的用户等详细信息的变量。记得使用 Ansible Vault 加密敏感项，如用户名和密码，方法如下：

图 8.20 – 管理数据库操作的 Playbook

添加一个任务来创建一个新的 PostgreSQL 数据库，如下所示：

图 8.21 – 创建数据库的任务

现在，添加另一个任务来创建包含列的表：

图 8.22 – 在数据库中创建表的任务

添加一个任务，用于创建用户并授予对新创建的数据库的访问权限：

图 8.23 – 创建用户并授予数据库访问权限的任务

执行 playbook 创建数据库和其他资源：

图 8.24 – 执行 playbook 创建数据库、表和用户

一旦 playbook 创建完成，验证数据库和数据库服务器（例如 node1）上的资源。
登录到 node1，切换到 postgres 用户并打开 psql 控制台。列出数据库，你会看到 db_sales 数据库和 devteam 的访问权限：

图 8.25 – 登录数据库服务器并验证详细信息

在 psql 中验证用户信息，如下所示：

图 8.26 – 列出并验证新创建的用户

验证表是否按照 playbook 中的要求已创建。

首先，通过 psql 控制台使用 \c 命令连接到新创建的数据库，然后使用 \dt 命令列出数据库中的表，如下所示：

图 8.27 – 连接到新创建的数据库并列出表

确保你通过 Ansible playbook 创建的列已存在于表中，如下所示：

图 8.28 – 数据库表详细信息

还可以通过使用相应的用户名和密码在 psql 控制台中验证新用户的访问权限，如下所示：

图 8.29 – 验证新用户访问权限和列出表

扩展 playbook，加入更多细节，例如表所需的列、更多用户、权限等。更多细节请参考模块的文档：docs.ansible.com/ansible/latest/collections/community/postgresql/。

在接下来的章节中，你将学习更多关于数据库操作的内容，例如如何通过自动化 pg_hba 配置来管理远程访问、如何进行数据库备份等。

自动化 PostgreSQL 操作

借助 community.postgresql 集合中的模块，可以自动化更多的数据库维护和操作。让我们深入了解一下。

管理 PostgreSQL 远程访问

数据库服务器由远程节点上的应用程序访问，必须适当且安全地配置此访问权限。在测试环境中，允许使用通配符条目（例如 0.0.0.0/0），但这不是生产服务器的推荐做法。您需要配置正确的 IP 地址或主机名以允许或限制对数据库的访问。此操作可以通过使用 community.postgresql.postgresql_pg_hba 模块来自动化，方法如下：

图 8.30 – 授予用户访问数据库的权限

使用 Ansible 管理 pg_hba 条目将使您能够处理数据库及其访问的整个生命周期。

接下来，我们将学习如何进行自动化的数据库备份。

数据库备份和恢复

对于敏感和重要数据，进行数据库备份至关重要。使用 Ansible 自动化此数据库转储，并安排每日、每周或每月的数据库备份：

图 8.31 – 使用 Ansible 进行数据库备份

备份将保存在管理节点上。可以自定义目标位置或自动将备份复制到远程位置，例如 NFS 卷或云存储。

同样，我们可以通过以下方式自动化数据库恢复操作：

图 8.32 – 从备份文件恢复数据库

注意上面示例中的 state: restore。这指示 Ansible 使用 target 参数中提到的文件或归档执行恢复操作。以下截图显示了完整的剧本，可以根据 db_action 值执行备份或恢复操作：

图 8.33 – PostgreSQL 数据库备份和恢复剧本

请参考docs.ansible.com/ansible/latest/collections/community/postgresql/postgresql_db_module.xhtml文档，了解有关 community.postgresql.postgresql_db 模块的更多信息。

Ansible PostgreSQL 和 MySQL 集合

请参考galaxy.ansible.com/community/postgresql了解 PostgreSQL 社区集合，并参考docs.ansible.com/ansible/latest/collections/community/postgresql/查看文档。同时，您可以访问galaxy.ansible.com/community/mysql获取 Ansible MySQL 集合和模块。

在下一部分，您将了解如何处理自动化的数据库密码重置请求，您可以使用 Ansible 和您的 ITSM 工具来实现。

使用 ITSM 和 Ansible 自动化密码重置

借助 ITSM 工具和 Red Hat Ansible 自动化平台（或社区版 Ansible AWX），可以实现零接触自动化用例，例如数据库用户密码重置、数据库预配等。用户将与 ITSM 工具交互，而该工具将与 Ansible 自动化平台交互以实现任务执行，如下图所示：

图 8.34 – ITSM 和 Ansible 自动化平台在数据库操作中的集成

这种程序化自动化是 Ansible 最佳的功能之一，它通过与现有工具和软件的集成，帮助组织扩展其自动化范围。

如下截图所示，在 ITSM 工具中使用自定义表单或工单系统：

图 8.35 – Jira 工单及其详情

ITSM 工具，如 Jira 或 ServiceNow，也可以配置自定义字段来收集信息，例如数据库服务器的名称、数据库名称、用户名等，如下截图所示：

图 8.36 – 带有自定义字段的 Jira 工单

自动化不会跳过你的 ITSM 流程或程序；在任务执行之前，审查和批准将到位，如图 8.34所示。

一旦获得批准，ITSM 工具将发送包含数据（如数据库主机名、数据库名称和用户名）的通知到 Ansible 自动化平台，并触发自动化任务。我们将在下一节中详细讨论这一过程。

重置密码的 Ansible 剧本

Ansible 剧本将根据 Ansible 作业模板和来自 Jira 的输入数据，从 Ansible 自动化平台触发。使用以下截图中显示的自定义字段收集 Jira 的输入数据（有关详细信息，请参见Chapter-08/postgres-password-reset.yaml）：

图 8.37 – 在剧本中收集来自 Jira 的详情

以下任务将为用户设置新密码：

图 8.38 – 设置新密码的任务

一旦密码重置操作成功，以下任务将使用密码重置操作的输出更新 Jira 工单：

图 8.39 – 使用 community.general.jira 模块更新 Jira 工单

扩展 playbook，添加任务，通过 community.general.mail 模块将新密码通过电子邮件发送给用户。更多关于 Ansible Jira 模块的信息，请查阅文档（docs.ansible.com/ansible/latest/collections/community/general/jira_module.xhtml）。

总结

本章中，你了解了 Ansible 如何帮助你安装数据库服务器，并管理如创建数据库、创建表、分配用户权限、进行数据库备份以及配置 pg_hba 等数据库操作。你还了解了 ITSM 工具提供的集成机会，借助 Ansible Automation Platform 实现零接触自动化。

在下一章中，你将学习如何将 Ansible 与 DevOps 实践结合，进行部署、滚动更新、基础设施即代码（IaC）配置等。

进一步阅读

要了解本章所涵盖的更多内容，请访问以下链接：

如何使用 Ansible 和 Gmail 发送邮件： www.techbeatly.com/ansible-gmail
使用 Ansible 在 Red Hat Enterprise Linux 8 上部署 Microsoft SQL Server 2019： www.redhat.com/sysadmin/mssql-linux-easy
Community.Postgresql 集合： docs.ansible.com/ansible/latest/collections/community/postgresql/index.xhtml
Ansible 数据库模块： docs.ansible.com/ansible/2.9/modules/list_of_database_modules.xhtml
使用 ServiceNow 和 Red Hat Ansible Automation Platform 自动化 IT 服务管理： www.ansible.com/integrations/it-service-management/servicenow
Ansible 的 MongoDB 集合： galaxy.ansible.com/community/mongodb

第九章：在 DevOps 工作流中实现自动化

DevOps 是一组实践、工具和理念的结合体，旨在帮助提高软件开发、应用交付和基础设施管理过程的速度、效率和安全性。由于许多优势，如更快和更频繁的部署、质量改善、减少错误以及通过自动化实现高度透明性，DevOps 的实践和方法现在在组织中非常普遍。通过结合自动化、协作和集成，可以开发并实施高效的 DevOps 实践，从而确保 IT 运维团队提供更高质量的输出。

由于有大量的集成、支持的插件和模块，Ansible 是自动化 DevOps 工作流中任务的优秀工具。Ansible 可以帮助你自动化 软件开发生命周期（SDLC）的不同阶段，如构建应用程序、扫描源代码、将工件存储到仓库、部署应用程序、配置应用服务等。自动化这些应用生命周期过程称为 持续集成 和 持续交付（CI/CD）。CI/CD 工具和框架有多种选择，如 Jenkins、CircleCI、GitLab、GitHub Actions、Bamboo 等。

本章将重点介绍在 CI/CD 和 DevOps 工作流中使用 Ansible 来部署和管理应用程序，而不是将 Ansible 作为 CI/CD 工具来使用。

本章将涵盖以下内容：

DevOps 快速介绍
使用负载均衡器提供应用程序
使用 Ansible 进行滚动更新
在 Terraform 中使用 Ansible 作为配置工具

首先，你将学习如何使用 Ansible 将应用程序部署到服务器，包括负载均衡器配置。你还将学习如何使用 Ansible 实现滚动更新，以便在没有停机和中断的情况下部署应用程序。最后，你将学习如何将 Ansible 用作 Terraform 基础设施管理工具的配置和管理工具。

技术要求

本章的技术要求如下：

用于 Ansible 控制节点的 Linux 机器（需要互联网访问）
用于安装和配置应用程序的三台 Linux 机器
DevOps 方法论、CI/CD 工具（Jenkins）以及 Git 工作流的基本知识
Terraform 的基本知识

本章的所有 Ansible 代码、剧本、命令和代码片段可以在本书的 GitHub 仓库中找到，链接如下：github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-09。

DevOps 快速介绍

简单来说，DevOps 是开发（Dev）和运维（Ops）的结合，但实际上，DevOps 是由帮助提高软件开发、交付和基础设施管理流程速度和效率的理念、工具和实践组成的组合。我们可以遵循并纳入 DevOps 工作流程中的一些已知最佳实践，具体如下：

团队协作和透明沟通
CI/CD
基础设施即代码（IaC）和自动化基础设施管理
容器化和微服务
日志记录、监控和反馈循环

DevOps 实践中的一个关键概念是减少应用生命周期管理所需的时间和精力，例如集成、构建、测试、发布和部署。通过使用 DevOps 方法论和工具，可以实现这个过程的自动化，这就是所谓的 CI/CD。

学习 DevOps

请参考以下指南，了解更多关于 DevOps 和 CI/CD 过程的内容：

DevOps 是什么？：aws.amazon.com/devops/what-is-devops/
DevOps 解释：about.gitlab.com/topics/devops/
了解 DevOps：www.redhat.com/en/topics/devops

在典型的 CI/CD 工作流中，开发人员将代码推送到中央代码仓库（例如 Git 服务器），每当仓库内容发生变化时，CI/CD 工具（如 Jenkins、CircleCI、GitHub Actions 等）将收到触发信号。下图展示了典型的 CI/CD 环境：

图 9.1 – CI/CD 环境中的典型工作流

构建、测试、交付和部署过程中涉及多个任务，具体取决于应用类型、应用平台和其他环境因素。

下图展示了 CI、CD 和持续部署过程中的典型手动和自动化任务：

图 9.2 – CI/CD 过程中的典型任务

应用程序可以是一个简单的 JAR 文件、一个压缩镜像、一个容器镜像或其他任何格式（我们将在第十章中学习使用 Ansible 管理容器，使用 Ansible 管理容器）。

CI 帮助开发人员定期合并软件代码更改，并自动快速地完成测试和扫描过程。CI 过程还帮助更快、更有效地发现代码中的缺陷、漏洞和安全问题。

CD 过程涉及自动化软件生命周期操作，例如测试应用程序、扫描以及准备应用程序，使其准备好进入生产环境（发布）。

一旦应用程序构建、扫描并在应用程序仓库（应用程序构件）中可用，它需要按照流程部署到生产环境（或开发环境）。这是下一个CD过程或持续部署任务，根据环境的不同，这可以作为自动化或半自动化部署来实现。

持续交付与持续部署

CD 通过将应用程序部署到生产环境中，帮助应用程序生命周期管理，使得应用程序中的最新变更能够作为 CI/CD 流程的一部分自动到达最终用户，无需任何人工干预。可以根据应用程序的性质、环境和依赖性，使用相同的 CI/CD 工具或专用工具来执行持续部署过程。

部署可以是 CI/CD 流水线的一部分，也可以是部署工具的独立触发器，例如Ansible 自动化平台（AAP）（你将在第十二章《将 Ansible 与工具集成》中学习如何将 Ansible 集成到 CI/CD 流水线中）。

Ansible 在 CI/CD 任务中的应用

Ansible 可以作为 CI/CD 工作流中大多数任务的工具，如下所示：

扫描应用程序
构建应用程序构件
运行单元测试和集成测试
在预生产环境中推广和测试应用程序
将应用程序构件存储在构件仓库中
将应用程序部署到生产环境

在下一节中，你将学习如何使用 Ansible 将应用程序作为持续部署工具部署到生产服务器。

AAP 作为 CI/CD 工具

可以将 AAP 作为 CI/CD 工具，并使用 Ansible 剧本和作业模板来管理应用程序的完整生命周期。你将会在第十二章《将 Ansible 与工具集成》中了解更多内容。

使用 Ansible 可以减少软件部署时间。由于 Ansible 可以高效、有效地管理应用程序部署，因此在 CI/CD 流水线中，Ansible 可以作为主要工具来部署应用程序。下图展示了 Ansible 如何在 Jenkins 流水线作业中用于部署目的（持续部署）：

图 9.3 – Jenkins 流水线作业中的 Ansible

软件构建和 CI/CD 工作流可以通过多种 Jenkins 原生方法触发，也可以通过使用附加插件来触发。例如，要基于 Git 仓库的变化激活构建触发器，并从 Jenkins 执行 Ansible 剧本，你需要按照以下步骤执行一些强制性操作：

首先，您必须安装并配置 Jenkins 的 Ansible 插件，以便在 Jenkins 流水线作业中使用 Ansible。请参阅文档 www.jenkins.io/doc/pipeline/steps/ansible/ 以了解有关 Jenkins Ansible 插件的更多信息。

Jenkins 中的 Ansible

请参阅 plugins.jenkins.io/ansible 以了解有关 Jenkins Ansible 插件的更多信息。

然后，您必须在 Jenkins 服务器（或 Jenkins 代理机器）上安装和配置 Ansible 及其所需的软件包，因为 Ansible playbook 将从 Jenkins 机器执行。（稍后在 第十二章，将 Ansible 与您的工具集成 中，您将学习如何使用 Jenkins 调用 AAP 中的自动化作业。）
要触发 Jenkins 流水线作业，必须在 Jenkins 作业上配置构建触发器，如下截图所示。复制 URL (JENKINS_URL/job/ansible-demo/build?token=TOKEN_NAME) 和 TOKEN 值，并在 Git 服务器中的 webhook 配置中使用它们：

图 9.4 – Jenkins 流水线作业上配置的构建触发器

每当应用程序代码发生变化时，您需要触发 Jenkins 流水线作业。为此，我们在 GitHub 应用程序存储库中配置了一个 webhook，如下截图所示：

图 9.5 – GitHub 存储库中的 webhook 配置

在 GitHub webhook 配置中，还提供了额外的配置选项，帮助您决定何时调用 webhook。请参阅 GitHub webhook 文档 (docs.github.com/en/developers/webhooks-and-events/webhooks/about-webhooks) 以了解更多关于 webhook 的信息。

使用简单 webhook 触发作业

要了解有关 Jenkins 和 webhook 的更多信息，请阅读 docs.cloudbees.com/docs/admin-resources/latest/triggering-jobs-simple-webhook

在 Jenkins 流水线中使用 Ansible

安装并配置了 Ansible 插件后，可以通过在流水线阶段内调用它来从 Jenkins 服务器（或代理）执行 Ansible playbook。以下截图显示了使用 Jenkins 流水线阶段的示例来利用 Ansible 部署应用程序：

图 9.6 – Jenkins 流水线作业阶段，包含用于部署应用的 Ansible 任务

在接下来的练习中，我将解释如何使用 Ansible 从源存储库部署网站内容，用于持续部署任务。

我将使用简单的网站内容（静态网站），以避免任何复杂性，帮助您理解使用 Ansible 部署应用程序的概念。该剧本可以集成到 Jenkins 管道中（或您使用的任何 CI/CD 工具中），以实现持续部署任务。请按照以下步骤进行：

更新Chapter-09/hosts清单文件，将node1和node2作为 Web 主机组的一部分，如下所示：

图 9.7 – 清单中的 Web 主机

创建一个名为Chapter-09/deploy-web.yaml的剧本，并添加以下内容：

图 9.8 – 部署 Web 应用程序的剧本

变量可以保存在单独的文件中，也可以作为参数从您的 CI/CD 工具传递。

添加一个任务来清理应用程序目录并重新创建它（这样可以确保从应用程序路径中删除任何旧版本的文件），如下所示：

图 9.9 – 清理应用程序目录的任务

向同一个剧本中添加任务，以安装所需的包和依赖项。即使您在同一服务器上部署应用程序，最佳实践是在每次部署时安装并配置依赖项。这可能包括服务、包、系统库、Python 包或其他文件，具体取决于应用程序的类型和框架。
也可以提到包的特定版本，如下图所示。还可以添加任务以启动firewalld，打开 Web 服务的防火墙端口，并启动 Web 服务，如下所示：

图 9.10 – 安装包并启动必要的服务

下一步是将网站内容部署到应用程序路径中。（在本练习中，我们使用的是静态网站内容，而不是动态应用程序。）为了识别服务器，请按照以下方式更新index.xhtml文件（我们将在以下任务中用包含节点信息的自定义文本替换SERVER_DETAILS）：

图 9.11 – 部署应用程序并更新其内容

根据需要添加更多任务，例如为 Web 服务器配置更多的限制或自定义 SSL 证书。
将验证步骤作为自动化的一部分非常重要。我们将在这里添加自动化的网站验证。在这种情况下，这是一个简单的健康检查，用来验证网站是否正常工作。在同一个剧本中添加一个新的任务（而不是任务），如下所示：

图 9.12 – 添加一个任务来验证 Web 服务

请注意，我们没有硬编码服务器名称，而是将详细信息作为 Ansible 额外变量 传递，这将帮助您在执行 Ansible playbook 时从 CI/CD 工具传递服务器详细信息。

每当我们在应用程序仓库中进行更改时（github.com/ginigangadharan/website-demo-one-page），GitHub 将触发 Jenkins 服务器中的构建任务，并且 playbook 将作为流水线任务的一部分执行。（我们将在第十二章，将 Ansible 与您的工具集成中探索 Jenkins 作业和流水线。）为了演示和测试的目的，我们从控制台手动执行 playbook，如下所示：

执行 playbook 并验证任务的成功（当您通过 CI/CD 流水线执行 playbook 时，您将在 CI/CD 控制台中看到类似的结果）：

图 9.13 – 带健康检查的 Ansible playbook 输出

Verify application health 任务成功，这意味着网站正在运行并提供内容。

从网页浏览器中验证网站内容，如下所示：

图 9.14 – 使用 Ansible 部署的网站

为进一步练习，请扩展部署用例，如下所示：

部署其他 Web 应用程序、API 应用程序或来自仓库的其他压缩应用程序文件。
根据需要包括更多验证、测试用例、扫描任务等，作为健康检查的一部分。
使用角色部署 Web 服务、负载均衡器、数据库等。

您将在第十二章，将 Ansible 与您的工具集成中学习一些这些场景。在下一节中，您将学习如何使用负载均衡器处理多节点 Web 服务器流量。

使用负载均衡器服务应用程序

到目前为止，您已经学习了如何使用 Ansible 将应用程序部署到多个服务器上，并且具备了所有必要的前提条件、依赖关系和基本健康检查。但是，如果应用程序或网站运行在多个服务器上，您需要告诉最终用户多个服务器的信息，以便他们能够访问网站。将应用程序从单一实体（如负载均衡器）提供服务是一个最佳实践，如下图所示，这样最终用户就不需要了解实际的 Web 或应用服务器 IP 地址。这还将帮助您实现高可用性和应用程序的滚动更新：

图 9.15 – 使用负载均衡器托管在多个服务器上的网站

由于我们在 CI/CD 工作流中使用 Ansible 处理应用程序部署，因此可以将负载均衡器的安装和配置任务包含在管道中，如下图所示：

图 9.16 – Jenkins 管道与 HA Proxy 安装

由于你已经在node1和node2上部署了网站内容，在接下来的练习中，你将学习如何使用haproxy部署一个简单的负载均衡器，并将node1和node2配置为后端服务器：

更新Chapter-09/hosts库存文件，将node3添加到loadbalancer主机组下：

图 9.17 – 库存中的负载均衡器条目

不必从头创建 Playbook，而是使用来自Ansible Galaxy的haproxy角色，由Jeff Geerling提供（galaxy.ansible.com/geerlingguy/haproxy），如下所示：

图 9.18 – 从 Ansible Galaxy 安装 haproxy 角色

创建Chapter-09/deploy-haproxy.yaml Playbook，并包括你在上一步安装的geerlingguy.haproxy角色。下图显示了用于安装 HAProxy 负载均衡器的示例 Playbook：

图 9.19 – 安装 HAProxy 负载均衡器的 Playbook

包括geerlingguy.haproxy角色所需的变量，如前面的截图所示。你可以通过参考角色文档（galaxy.ansible.com/geerlingguy/haproxy）来自定义角色的执行，但在本演示中，你只需添加负载均衡器后端和一些其他细节。（更改 IP 地址，使其与在库存中配置的node1和node2的 IP 地址匹配。）该角色将处理haproxy的安装、配置等。此外，记得添加一个任务以允许防火墙开放端口80（如果你使用的是其他防火墙，例如ufw，则需要修改 Playbook，使用相应的防火墙模块）。
最后，在相同的 Playbook（Chapter-09/deploy-haproxy.yaml）中添加一个新的 Play，用于自动验证负载均衡器的访问：

图 9.20 – 添加 Ansible Play 以验证负载均衡器

执行 Playbook 并验证输出：

图 9.21 – 含健康检查成功的 HAProxy Playbook

验证负载均衡器健康任务成功，这意味着负载均衡器（haproxy）正在工作，并从后端 Web 服务器（即node1和node2）提供内容。

使用负载均衡器 IP 地址（例如，http://192.168.56.45）在 Web 浏览器中验证网站的内容，如下图所示：

图 9.22 – 使用负载均衡器 IP 访问的网站

一旦负载均衡器准备好，可以启用负载均衡器的 DNS 并与最终用户共享（例如，website.example.com）。用户无需担心记住网站或 Web 服务器的 IP 地址。当你有新版本的网站或应用程序时，可以在没有停机的情况下更新内容，因为负载均衡器会从后台可用的 Web 服务器提供网站。

在下一部分中，你将学习如何使用 Ansible 处理没有停机的滚动更新，适用于网站和应用程序。

使用 Ansible 进行滚动更新

持续部署是一种适用于频繁应用程序部署（结合 CI/CD）和频繁更新应用程序或网站的方法，而不是等待计划的停机和部署周期。但是，你还需要确保应用程序在更新过程中能够保持可用。到目前为止，你已经了解到，可以使用负载均衡器实现应用程序的高可用性。在本节中，你将学习如何在 Web 服务器上进行应用程序更新而无需停机。

应用程序更新过程中涉及的步骤

根据应用程序的类型和涉及的组件，更新过程可能包含不同的步骤和程序。下图展示了应用程序更新过程中的通用步骤，该过程运行在负载均衡器后端：

图 9.23 – 应用程序更新过程中涉及的步骤

可以使用 Ansible 自动化所有这些任务，包括验证和检查服务、监控任务等。

在一批托管节点中部署更新

如果你在所有 Web 服务器上（例如，node1 和 node2）并行运行更新任务，则没有服务器来处理来自负载均衡器的请求，网站将会停机。这不是理想的行为，因此你需要将 Web 服务器分批更新，而不是一次性更新所有服务器。可以通过传递特定的远程节点名称（例如，extra-variable）来实现，但这不是最佳做法或方法，因为你需要多次执行剧本才能完成整个网站的更新。

使用 Ansible 进行 CD 和滚动升级

Ansible 编排功能对于管理多层应用程序非常有用。请参考文档 docs.ansible.com/ansible/latest/user_guide/guide_rolling_upgrade.xhtml 了解更多信息。

在 Ansible 中使用 serial 关键字来指定每次执行时管理节点的数量：

图 9.24 – 在 Ansible playbook 中使用 serial

这里，serial: 25% 表示该任务将在每次执行时只在 25% 的总管理节点上运行。

下图显示了滚动更新流程，其中只有一个节点会执行更新任务，负载均衡器将继续为其他节点提供流量：

图 9.25 – 使用 Ansible 进行滚动更新

也可以通过使用 serial: 2 或 serial: 5 关键字来指定批次中的确切节点数量。serial 关键字非常灵活，你甚至可以使用不同数量的节点来控制不同的批次，如下所示：

图 9.26 – 对主机批次使用不同的 serial 值

在下一部分，你将学习如何使用 serial 关键字在 Web 服务器上部署更新而不会导致应用程序停机。

在多个服务器上部署更新而不造成服务中断

现在 CI/CD 流水线包含更多任务，我们将如以下图所示替换应用程序部署的 playbook 为滚动更新 playbook：

图 9.27 – CI/CD 流水线执行应用程序的滚动更新

在本练习中，你将使用 serial: 1，这意味着操作将仅在一个管理节点上执行一次。根据管理节点或后端服务器的数量，根据需要控制此批次大小：

通过在仓库中创建一个新分支来更新网站的内容。（使用 github.com/ginigangadharan/website-demo-one-page 仓库并进行复制以进行测试。）
克隆仓库到本地机器并切换到生产分支，如下所示。还要 checkout 一个新分支 v2：

图 9.28 – 克隆仓库，切换到生产分支，并创建一个新分支

使用以下方式更新 index.xhtml 文件进行一些修改（例如，在主页上添加 v2 来标识更改）：

图 9.29 – 更新应用程序仓库中的 index.xhtml

做完这些更改后，保存文件。

提交所有更改并将新分支 v2 推送到仓库：

图 9.30 – 提交更改并将 v2 分支推送到原始仓库

现在，包含应用程序新版本的新分支已在 GitHub 仓库中可用。这意味着我们可以使用 Chapter-09/deploy-web.yaml playbook 将其部署到 Web 服务器。但对于滚动更新，您需要创建另一个名为 Chapter-09/rolling-update.yaml 的 playbook，并在其中添加滚动更新任务。

创建一个新的 playbook，命名为 Chapter-09/rolling-update.yaml，并添加 serial 关键字，格式如下：

图 9.31 – 滚动更新 playbook

在更新期间，节点将无法提供网页服务。因此，您需要通知负载均衡器这一点。添加一个任务以禁用您之前配置的 haproxy 后端中的主机。还需要添加一个任务来停止服务器上的 Web 服务（httpd）：

图 9.32 – 从负载均衡器中移除主机条目

请注意 delegate_to: ‘{{ item }}’ 这一行，因为该任务将在负载均衡器节点上执行。任务将通过 with_items: ‘{{ groups.loadbalancer }}’ 循环遍历负载均衡器节点。在我们的案例中，只有一个负载均衡器节点。

现在，您的部署 playbook 中有类似的任务，如下图所示：

图 9.33 – 清理目录并部署应用程序

默认分支在 playbook 中设置为生产（application_branch: production）；稍后我们将使用 extra-variable 覆盖该分支名称。

一旦获得最新的应用程序内容，启动 Web 服务并将主机重新添加到负载均衡器后端，如下所示：

图 9.34 – 部署后的配置

最后，在同一个 playbook 中添加另一个任务来验证通过负载均衡器访问 Web 服务器：

图 9.35 – 验证 play 的执行

执行 playbook 并检查其输出。记得将新的分支信息作为 application_branch=v2 传递：

图 9.36 – 在 node1 上执行 Ansible 滚动更新

在前面的截图中，执行过程每次只会在一个节点上进行（即 node1），并完成该批次节点的所有任务。稍后，playbook 将开始为新的批次（即 node2）执行任务，如下所示：

图 9.37 – 在 node2 上执行 Ansible 滚动更新

如前面的输出所示，更新正在以 rolling 方式进行。这意味着在任何时候，负载均衡器后端的 Web 服务器都会有一个可用来提供网站服务。通过这种方式，您可以在应用更新过程中实现零停机时间。

现在，让我们使用负载均衡器的 IP 地址来验证网站访问并查看更改（注意 v2 分支）：

图 9.38 – 滚动更新后的网页（v2）

对于静态网站和动态 Web 应用程序，过程是相同的。在滚动更新过程中，包含你希望执行的确切步骤。

CD 和滚动更新

参考docs.ansible.com/ansible/latest/user_guide/guide_rolling_upgrade.xhtml，了解更多关于使用 Ansible 进行滚动更新的详细信息。还可以查看应用程序部署（www.ansible.com/use-cases/application-deployment）和 Ansible CD（www.ansible.com/use-cases/continuous-delivery）的使用案例。

Ansible 的灵活性使其适用于在大多数 DevOps 工作流中实现自动化。除了单独使用 Ansible，始终可以将 Ansible 与其他工具集成。通过 AAP 和 Ansible API，可以在 CI/CD 工作流中使用 webhooks、作业模板和回调实现更强大的集成。你将会在第十二章，将 Ansible 与工具集成中了解 AAP 和集成的相关内容。在下一节中，你将学习如何将 Ansible 与 Terraform 作为配置工具一起使用。

在 Terraform 中使用 Ansible 作为配置工具

Ansible 可以作为 IaC 工具使用，正如你在第七章，管理你的虚拟化和云平台中学到的那样。同时，在行业中有一个常见的做法，就是为不同的任务选择合适的工具——例如，使用 Terraform 进行 IaC，使用 Ansible 进行 IT 自动化，使用 Jenkins 进行 CI/CD 管道，等等。与其比较类似的工具，不如在合适的地方将它们集成，进而实现更好的结果。

Terraform 是 HashiCorp 提供的开源工具，用于实现 IaC 实践。Terraform 可以用于部署和管理基于云的基础设施和应用程序，使用一种称为 HashiCorp 配置语言（HCL）的声明式配置语言编写基础设施代码。根据云平台和组件的不同，使用可用的提供商模块和资源。参阅registry.terraform.io/browse/providers以探索可用和受支持的提供商。

例如，以下 Terraform 代码将为 AWS 平台提供具有指定的 Amazon 机器镜像（AMIs）和其他细节的 EC2 实例：

图 9.39 – EC2 配置的 Terraform 代码

Terraform 擅长处理基础设施变更，并通过其状态管理机制跟踪更新。但如果你想配置操作系统级别的组件，你需要使用 Terraform 配置器（www.terraform.io/language/resources/provisioners/syntax），因为此类配置无法通过声明性代码表示。Terraform 支持许多配置器，如 file、local-exec、remote-exec 等。使用 local-exec 或 remote-exec 配置器，并使用 Ansible 配置通过 Terraform 配置的系统。根据你的环境和其他工具集成选项，选择其中一种方法。

使用 Terraform 的 local-exec 配置器与 Ansible

要使用 local-exec 配置器与 Ansible，运行 Terraform 的机器应已安装并配置 Ansible，因为 ansible-playbook 命令将在本地机器上执行，如下图所示：

图 9.40 – 在 Terraform 中使用 Ansible 作为 local-exec

你还需要在命令中传递凭证详细信息，如用户名和 SSH 私钥，具体如下：

图 9.41 – 使用 Ansible 自动化的 EC2 配置 Terraform 代码

ec2-user 在前面的代码片段中是 AWS Linux AMI 中的默认用户账户。这个用户名或凭证可以根据你的 EC2 AMI 或其他源镜像进行更改。例如，在 AWS、GCP、Azure 或其他云平台中创建自定义基础镜像，然后使用该镜像通过 Terraform 创建实例，并使用 Ansible 配置它们。

使用 Terraform 的 remote-exec 配置器与 Ansible

如果你的本地机器不支持安装 Ansible（例如，在 Windows 机器上运行 Terraform），则可以使用 remote-exec 配置器，但你需要确保 Ansible 已安装在 Terraform 配置的远程机器上。你还需要确保在调用 ansible-playbook 命令之前，相关的 playbook 和必需文件已经复制到目标机器。以下图示展示了使用 Terraform 配合 Ansible remote-exec 配置的高级工作流：

图 9.42 – Terraform 中的 Ansible remote-exec 配置

请参考 Chapter-09/terraform-aws-ansible-lab 获取以下说明中使用的 Terraform 代码。按照以下步骤操作：

使用 user_data 参数将基本命令传递给 EC2 实例初始化和 Ansible 安装过程中要执行的命令。这些命令可以包含在 user_data 脚本中。一个典型的用户数据脚本可以写成如下：

图 9.43 – 用于在 EC2 实例中安装 Ansible 的用户数据脚本

如您在前面的示例中所见，EC2 实例创建代码现在将包含更多组件，如下所示：

图 9.44 – 带有 user_data 脚本的 EC2 资源

user-data-dbnodes.sh脚本将在新 EC2 实例创建时执行。所有组件，包括 Ansible，都将在其中安装。

下一步是将所需的 playbooks 复制到远程 EC2 实例。在这里，我们使用了 Terraform 的file配置器。之后，使用remote-exec配置器执行 playbook：

图 9.45 – 使用 remote-exec 方法在 EC2 实例内复制并执行 playbook

为了进一步实践和学习，将系统配置任务包含在dbnode-config.yaml文件中，如创建新用户、安装数据库包、启动服务、挂载磁盘卷等。

参见使用 Ansible 与 Terraform（www.techbeatly.com/using-ansible-with-terraform-ansible-real-life-series）以深入了解并理解 Terraform 与 Ansible 的集成。

总结

本章中，您探讨了围绕 DevOps 的基本概念、过程和技术术语，如 CI/CD 和持续部署。您还了解了 Ansible 在 DevOps 工作流中的一些集成可能性。然后，您学习了如何在持续部署工作流中使用 Jenkins 中的 Ansible。接下来，您了解了如何在不中断服务的情况下执行滚动更新，并将 Ansible 作为持续应用程序部署的一部分。最后，您了解了如何将 Ansible 与 Terraform 集成，以实现基础设施即代码（IaC）配置。

在下一章中，您将学习如何使用 Ansible 构建、运行和管理容器。

进一步阅读

若要了解本章涵盖的更多内容，请查看以下资源：

使用 Terraform 在 AWS 中创建免费的 Ansible 实验室：www.techbeatly.com/use-terraform-to-create-a-free-ansible-lab-in-aws
深入了解 – 自动化 NetOps – 用于网络 GitOps 的 Ansible：www.youtube.com/watch?v=JqE13sP2sq8（视频）
持续集成与交付与部署：www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment
Ansible 和 HashiCorp: 更强组合: www.hashicorp.com/resources/ansible-terraform-better-together
管理 Terraform 部署: docs.ansible.com/ansible/latest/collections/community/general/terraform_module.xhtml

第十章：使用 Ansible 管理容器

自从容器化技术引入以来，组织可以更快速地部署应用，并通过频繁的更新和部署加速发布周期。然而，容器化应用相较于传统的服务器部署需要更多步骤。例如，你需要确保打包好的容器镜像按预期工作、安全标准已就位、卷挂载正常、机密信息安全存储等等。当应用发布频率更高时，自动化容器构建和部署任务将有助于实现更好的 CI/CD 工作流，并节省手动操作的时间。

使用 Ansible 容器管理的集合，我们可以管理容器的整个生命周期。这包括构建容器、将其推送到注册表、扫描其漏洞并进行部署。

在本章中，我们将涵盖以下主题：

管理容器主机
Ansible、容器与 CI/CD
使用 Ansible 管理容器
使用 Ansible 构建容器镜像
使用 Ansible 管理多容器应用

首先，你将学习如何使用 Ansible 部署容器引擎到主机上并在其中运行容器。接下来，你将学习如何管理容器镜像构建，并将其管理到容器注册表中。

技术要求

本章需要以下技术要求：

一台用于 Ansible 控制节点的 Linux 机器（需要连接互联网）
一台用于安装和配置 Docker 的 Linux 机器
访问 Docker 容器注册表（hub.docker.com）
关于容器和容器注册表（Docker 或 Podman）的基础知识

本章所有的 Ansible 代码和剧本，以及命令和代码片段，都可以在本书的 GitHub 仓库中找到，网址为：github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-10。

管理容器主机

市面上有各种类型的容器软件，例如 Docker 和 Podman。在本章中，我们将使用 Docker 来解释和演示如何使用 Ansible 管理容器。我们将使用 Docker 社区版（CE），这是免费的，但如果需要，你也可以使用 Docker 企业版（EE）。

Ansible Docker 先决条件

要使用 docker 库，你可以通过 Python pip 或者标准的包管理工具（例如 yum（yum install python-docker-py）或 dnf）来安装。如果你使用的是旧版本的 Python（2.6），那么你应该安装并使用旧版库 docker-py。

使用 Ansible 在主机上安装 Docker

在主机上安装 Docker 软件涉及多个步骤和配置。这些步骤可以手动完成，或者我们可以使用 Ansible Galaxy 中的 Ansible 角色。我们将使用由著名 Ansible 贡献者 Jeff Geerling 创建的社区 Ansible 角色 geerlingguy.docker（github.com/geerlingguy/ansible-role-docker）。

我们还将使用 geerlingguy.pip 来使用 Ansible 安装 Docker 库（例如，docker）。

按照以下步骤在 Linux 机器上安装 Docker 软件：

在清单中将 node1 更新到 dockerhost 主机组（chapter-10/hosts）：

图 10.1 – 在清单中配置 Docker 主机

在 roles 目录中安装 geerlingguy.docker，如下所示：

图 10.2 – 安装 Docker 角色

创建一个名为 Chapter-10/deploy-docker.yaml 的 playbook 来安装角色和库：

图 10.3 – 使用 deploy-docker.yaml 在主机上安装 Docker

pip_install_packages 变量将由 geerlingguy.pip 角色使用，以通过 pip 安装列出的包。

执行 playbook 在主机上部署 Docker：

图 10.4 – 执行 playbook 在主机上部署 Docker

验证它是否已安装。登录到 node1 并检查详细信息：

图 10.5 – 验证 Docker 安装

这样，Docker 就已在主机上安装并配置完成，这意味着我们可以开始运行容器。

接下来，你将了解 Ansible 在管理容器化应用方面的能力。

Ansible、容器和 CI/CD

将应用容器化将为你提供更多的集成、交付和部署选项，因为大多数工具都支持自动化构建、测试和执行。典型的容器化应用工作流程如下图所示：

图 10.6 – 基于 Docker 的部署中的典型 CI/CD 任务

上图中的大部分任务都可以使用 Ansible 自动化，因为 Ansible 的 Docker 和 Podman 集合包含了多个模块，用于支持在容器主机上构建、运行和管理容器。你可以使用 Ansible 实现整个工作流程，或者将 Ansible 与我们喜爱的 CI/CD 工具结合使用，更灵活地执行任务。你将学习如何在第十二章，将 Ansible 与工具集成中将 Ansible 与 Jenkins 集成。

在接下来的部分，你将学习如何使用 Ansible 管理容器并管理容器生命周期。

使用 Ansible 管理容器

Ansible 集合 community.docker (galaxy.ansible.com/community/docker) 包含 25 个以上的 Ansible 模块和大约 10 个用于连接、清单等的插件。这些模块将帮助你管理容器、容器镜像、容器注册表中的镜像、Docker 网络、Docker 卷、Docker 集群以及其他基于容器的操作。

如果你使用的是 Podman，可以在 Ansible Galaxy 中查看 containers.podman 集合 (galaxy.ansible.com/containers/podman)。

在接下来的章节中，你将学习如何使用 Ansible 构建、启动和管理容器。

安装 Ansible Docker 集合

安装集合非常简单，正如你在前面的章节中所学的那样：

更新你的 ansible.cfg 配置文件，添加集合路径：

图 10.7 – ansible.cfg 配置文件，包含集合和角色路径

安装 community.docker Ansible 集合：

图 10.8 – 安装 community.docker 集合

验证集合是否已安装在集合路径中，如下所示的截图所示：

图 10.9 – 安装在集合路径中的 Docker 集合

如果你使用的是 Ansible 社区包，则默认路径中可能有一个旧版本的 community.docker 集合。这就是我们在项目路径（COLLECTIONS_PATHS =）中安装最新版本集合的原因：

图 10.10 – 来自默认 Ansible 安装的 Docker 集合

一旦集合可用，开始使用已安装的 Docker 模块。

在断开网络的 Ansible 控制节点上安装 Ansible 集合

如果你处于受限环境中（如断网或没有互联网），可以按照替代方法安装 Ansible 集合和角色：如何在断开网络的 Ansible 控制节点上安装 Ansible 集合 (www.techbeatly.com/how-to-install-an-ansible-collection-on-a-disconnected-ansible-control-node)。

使用 Ansible 启动 Docker 容器

使用你自己的容器镜像，或者使用来自公共 Docker 注册中心的现有容器镜像，例如 Docker Hub（https://hub.docker.com）、Quay.io（quay.io/repository）和 GitHub 容器注册中心（ghcr.io）。也可以使用私有仓库中的容器镜像，但你需要通过用户名、密码或令牌进行认证，才能拉取或推送容器镜像。在使用 Ansible 构建容器镜像章节中，你将学习如何进行注册中心认证。

在本节中，你将学习如何使用 Ansible 运行 Docker 容器。为了简化演示，我们将使用默认的nginx（hub.docker.com/_/nginx）容器镜像，但之后可以探索使用其他容器镜像：

创建一个名为Chapter-10/container-manage.yaml的 playbook，如下所示：

图 10.11 – container-manage.yaml

注意

变量可以在不同的变量文件中动态配置，例如host_vars或group_vars，也可以通过外部变量进行配置。已在 playbook 中使用的变量已提供，以展示用例的执行过程。

添加一个任务，通过变量详情启动容器，如下所示：

图 10.12 – container-manage.yaml – 第二部分

我们稍后将使用container_action变量来控制容器的其他操作。

在仓库中添加另一个Chapter-10/container-manage.yaml以包含完整的 playbook：

图 10.13 – container-manage.yaml – 使用第二个 play 验证容器内运行的应用

（参见第一章，Ansible 自动化 – 入门，以查看包含多个 play 的 playbook。）

执行 playbook 时将NODES设置为dockerhost：

图 10.14 – 在 Docker 主机上执行 playbook

一旦 playbook 成功执行，验证来自 Docker 主机（node1）的容器，如下所示：

图 10.15 – 在 Docker 主机上运行的 nginx 容器

在这里，nginx容器被命名为web，并在 Docker 主机的端口8080上暴露服务。

访问运行在nginx容器内的网站。你需要记得使用端口8080，因为 Docker 端口已暴露在8080上：

图 10.16 – 使用 curl 命令后可用的 nginx 应用

从浏览器访问网站，如下图所示：

图 10.17 – 使用 Ansible 部署的 Docker 容器内运行的 nginx Web 服务器

向容器添加更复杂的配置，如不同的 Docker 网络、挂载卷等。请参考docs.ansible.com/ansible/latest/collections/community/docker/docker_container_module.xhtml文档，了解各种参数和选项。

使用 Ansible 停止 Docker 容器

在 CI/CD 过程中，当您构建容器进行测试时，也需要处理清理任务。测试完成后，您需要停止容器并删除它作为后续维护的一部分。使用相同的 Ansible 模块 community.docker.docker_container 来处理整个容器生命周期，如停止、删除等操作。

在本节中，您将学习如何停止并移除我们在上一练习中创建的容器。请按照以下步骤操作：

更新之前的 playbook Chapter-10/container-manage.yaml，并向第一个 play 管理 Docker 容器 中添加任务，如下图所示：

图 10.18 – 添加停止和移除容器的任务

执行 playbook 并传递 container_action=stop 作为额外变量：

图 10.19 - 执行 container-manage.yaml 文件以停止容器

在容器主机（node1）上，验证是否有任何容器正在运行：

图 10.20 – nginx 容器已被停止并移除

根据需要向 playbook 添加更多任务，例如验证端口、备份容器卷中的某些配置文件、进行 API 调用等作为测试的一部分。

在本节中，您使用 Docker Registry 的公共容器镜像进行了简单的容器执行测试。在下一节中，您将学习如何使用 Ansible 构建一个包含所有必要依赖项的自定义容器镜像，并使用自定义镜像运行容器。

使用 Ansible 管理容器镜像

如我们从图 10.6中学到的，当开发人员将代码推送或合并分支到 Git 仓库时，您的集成阶段将开始。直接从您的 CI/CD 工具（如Jenkins或GitHub Actions）调用容器构建命令。然而，命令和管道任务是不确定的，因此您对输出和结果的控制较少。这时，您可以利用 Ansible playbook，因为它能提供更多灵活性和对构建过程及输出的控制。

在接下来的几节中，您将学习如何创建 Docker 容器注册表访问、使用 Ansible 构建容器镜像，并将容器镜像保存到容器注册表中。

配置 Docker 注册表访问

在将最新的镜像推送到容器注册表之前，您需要使用凭据登录到注册表。使用用户名和密码访问 Docker 注册表，但最佳实践是使用访问令牌而不是密码。下图显示了 Ansible 如何访问容器注册表以管理容器镜像：

图 10.21 – Ansible 到容器注册表访问

在本示范中，您将使用 Docker 注册表。有关其他注册表的信息，请查看文档（参考容器注册表访问令牌信息框）。请按照以下步骤操作：

登录到 Docker Hub：hub.docker.com。
在右上角，点击您的个人资料名称并从菜单中选择账户设置。
选择安全性选项卡。
点击新建访问令牌按钮并为您的令牌输入名称。之后，在访问权限下选择读取、写入、删除权限并点击生成：

图 10.22 – 在 Docker Hub 中创建新的访问令牌

您将在下一屏幕上看到说明和令牌文本。记得复制并妥善保管该令牌，因为之后将无法再看到该令牌文本。

容器注册表访问令牌

要了解更多关于访问令牌的信息，请参考docs.docker.com/docker-hub/access-tokens/（Docker Hub）和docs.quay.io/glossary/access-token.xhtml（Quay）。

创建一个 Ansible Vault 文件来存储 Docker 注册表凭据，具体如下：

图 10.23 – 使用 Ansible Vault 文件管理您的 Docker 注册表凭据

将您的 Docker 用户名和访问令牌值添加到文件中并保存：

图 10.24 – 将您的 Docker 用户名和密码添加到 Ansible Vault 文件

这些变量将在接下来的章节中用于访问 Docker Registry。你可以将这些敏感信息保存在环境变量中，或使用 CI/CD 软件的内置秘密管理功能（例如 Jenkins 中的凭证）。

使用 Ansible 构建容器镜像

如你所知，你可以使用公共注册表（如 Docker Hub 或 Quay）中的现有 Docker 容器镜像。但对于我们的应用程序，我们需要构建容器镜像并使用它们来部署应用程序。

在 community.docker.docker_image 和其他模块的帮助下，我们可以轻松构建容器镜像，并将这些镜像推送到容器注册表。

创建应用程序或在互联网上查找示例应用程序，并利用它们进行进一步练习。以下是一些选项：

在本节中，你将使用 Dockerfile 将一个简单的 Node.js 应用程序（github.com/ginigangadharan/nodejs-todo-demo-app）容器化。Dockerfile（docs.docker.com/engine/reference/builder）是一个简单的文本文件，其中包含构建容器镜像的指令。之后，你将使用 Ansible 来构建容器镜像并将其推送到 Docker Registry。以下图示展示了涉及的步骤：

图 10.25 – 使用 Ansible 构建和管理容器镜像

Podman 和 Containerfiles

如果你使用的是不同的容器引擎，例如 Podman，那么请查看相应的模块文档并根据需要使用它。Podman 的 Ansible 模块可以在 docs.ansible.com/ansible/latest/collections/containers/podman/index.xhtml 找到，而 Podman 的构建文档可在 docs.podman.io/en/latest/markdown/podman-build.1.xhtml 查阅。这将帮助你了解更多关于 Containerfiles 的信息。

访问仓库并执行以下步骤：

验证应用程序仓库中的 Dockerfile（github.com/ginigangadharan/nodejs-todo-demo-app）：

图 10.26 – 验证 Dockerfile 以构建容器镜像

Dockerfile 包含构建容器镜像的指令，并将应用程序暴露在端口 3000 上。

仓库还包含一个用 Node.js 编写的简单 ToDo 应用程序，包含支持的文件和目录：

图 10.27 – 应用程序仓库内容

Fork 此仓库并根据需要进行更改。
创建一个名为 Chapter-10/container-build.yaml 的 Playbook，并添加所需的变量以构建容器镜像，如下所示：

图 10.28 – 构建容器镜像的 Playbook

使用变量将帮助你动态地将值传递给同一个 Playbook，用于不同的镜像构建任务。

Docker 注册表 URL

请注意，index.docker.io/v1/ 是 Docker Hub 注册表的默认 URL。如果你使用的是其他注册表或私人容器注册表，请找到正确的注册表 URL 并将其用作 container_registry_url。

还需要检查包含的变量文件 vars/docker-credential.yaml，该文件包含 Docker 注册表的用户名和访问令牌（详细内容请参见本章的 配置 Docker 注册表访问 部分）。

添加一个任务，用于在主机上创建临时工作目录并签出应用程序仓库。这是为了避免使用默认的目录名称并在同一 Playbook 并行执行时出现覆盖问题。你还需要在 Playbook 结束时删除该目录，作为清理的一部分：

图 10.29 – 构建容器镜像的任务

添加一个任务，在创建新容器镜像之前，如果已有相同名称和标签的镜像，则删除该镜像。同时添加构建容器镜像的任务，提供工作目录路径，即 temp_location.path：

图 10.30 – 删除并创建新的容器镜像

如果你想包括像扫描镜像、测试漏洞等任务，可以在此阶段添加（或者将其作为 CI/CD 管道中的 post-build 阶段的一部分）：

图 10.31 – 包含扫描或测试任务

现在，我们需要在将镜像推送到仓库之前对 Docker 注册表进行身份验证。验证通过后，将镜像推送到 Docker 注册表，如下所示：

图 10.32 – 认证 Docker Hub 并将镜像推送到容器注册表

可选地，向镜像添加 latest 标签，这样在拉取镜像时如果没有提到标签就会使用该标签：

图 10.33 – 为镜像添加最新标签并从 Docker Hub 注销

另外，注意最后一个任务是从容器注册表退出。出于安全原因，一旦镜像推送（或拉取）完成，务必从 Docker Registry 注销。

最后，作为清理过程的一部分，删除临时工作目录：

图 10.34 – 删除临时工作目录

执行 playbook 并验证结果。记得在命令中加上 --ask-vault-password，因为你已使用 Ansible Vault 包含了 Docker 凭证：

图 10.35 – 执行 playbook 来构建并推送容器镜像

现在，从多个地方验证镜像，例如从 Docker 主机和 Docker 注册表 GUI（Docker Hub: hub.docker.com/repositories）。
在 Docker 主机（node1）上检查镜像：

图 10.36 – 使用 Ansible 构建的容器镜像

另外，按照以下截图的显示，验证 Docker Hub GUI 上的镜像 (hub.docker.com/repositories)：

图 10.37 – Docker Hub 中的 Docker 镜像

点击容器镜像条目查看更多镜像详细信息：

图 10.38 – Docker 镜像详细信息

为镜像添加更多细节，如容器镜像的 README 信息、支持的标签、文档链接等。

这样，我们就有了最新的容器镜像，并且应用已存储在容器注册表中。我们可以使用相同的 Chapter-10/container-manage.yaml playbook 来进行测试。

按照以下步骤运行容器并使用新镜像：

使用 Chapter-10/container-manage.yaml playbook 启动新容器，但传递适当的额外变量，如 container_image、container_name、container_port 和 container_expose_port，如下所示：

图 10.39 – 使用不同镜像运行容器

容器创建完成后，按照以下步骤在 Docker 主机（node1）上进行验证：

图 10.40 – 使用 Ansible 部署的 ToDo 应用容器

从网页浏览器验证应用。记得添加端口 8081，如下所示，因为我们在运行容器时使用了端口 8081：

图 10.41 – 从网页浏览器访问 ToDo 应用

添加一些条目并测试应用程序，如下截图所示：

图 10.42 – 使用示例条目测试 ToDo 应用程序

使用相同的 playbook 停止容器作为日常管理的一部分，但传递 container_action=stop 动作：

图 10.43 – 使用 playbook 停止容器

注意

当您停止并销毁容器时，由于没有为数据持久性挂载任何卷，您存储的数据将会丢失。向 Chapter-10/container-manage.yaml 添加更多配置和卷的细节，增强您的 playbook。

在本节中，您学习了如何处理单个容器和容器镜像。但是，您可以根据应用程序堆栈使用 Ansible 来处理任意数量的镜像和容器。在下一节中，您将学习如何使用 Ansible 处理多个容器。

使用 Ansible 管理多容器应用程序

在本节中，您将使用著名的 内容管理系统 (CMS) 应用堆栈 WordPress (wordpress.org)。WordPress 应用基于多个应用堆栈，包括 PHP、Web 服务器和数据库。WordPress 应用有一个容器镜像 (hub.docker.com/_/wordpress)。对于数据库，我们将使用 MariaDB 部署另一个容器 (hub.docker.com/_/mariadb)。

请参考 Chapter-10/deploy-wordpress-on-docker.yaml 文件，查看使用 Ansible 部署 WordPress CMS 的 Ansible playbook。请按照以下步骤操作：

我们在 playbook 顶部声明了必要的参数，如下截图所示。请记住，使用 Ansible Vault（或在 Ansible 自动化控制器中使用凭证）或其他秘密管理服务存储敏感数据，如数据库用户名和密码。然后，这些变量会作为环境变量传递给容器，同时创建 Docker 卷，如下截图所示：

图 10.44 – 使用 Ansible 部署 WordPress

有两个任务，如下截图所示。第一个任务将部署 MariaDB 容器，第二个任务将部署 WordPress 容器：

图 10.45 – 部署 WordPress 和 MariaDB 容器的 Ansible 任务

执行 playbook 在 node1 上部署 WordPress 堆栈及 MariaDB 数据库：

图 10.46 – 使用 Ansible 部署 WordPress

在 node1 上，验证 Docker 容器和 Docker 卷，如下截图所示：

图 10.47 – 在 Docker 主机上运行的 WordPress 和 MariaDB 容器

通过浏览器使用我们已经配置的 8082 端口验证 WordPress 应用。初始的 WordPress 配置界面将可见，如下图所示。现在，我们可以配置 WordPress CMS 应用（wordpress.org/support/article/how-to-install-wordpress/#setup-configuration-file）：

图 10.48 – 初始的 WordPress 配置界面

通过配置额外的卷和配置，可以增强 playbook；请参考 WordPress 安装文档，以便为此类用例实施更多自动化步骤（wordpress.org/support/article/how-to-install-wordpress/#setup-configuration-file）。

通过本章，你已经学会了如何在 CI/CD 管道的不同阶段使用 Ansible 自动化整个容器镜像生命周期。与使用现有 CI/CD 工具中的原生容器管理功能相比，这将使你对构建和测试过程拥有更多的控制权。

摘要

本章中，你学习了如何使用 Ansible 在 Linux 机器上安装和配置 Docker。接着，你学习了如何从容器注册表拉取镜像，然后使用 Ansible 模块启动和停止该容器。最后，你学习了如何使用 Ansible 根据 Dockerfile 构建容器镜像，以及如何构建应用内容并将容器镜像推送到容器注册表。你还通过使用 Ansible 模块运行容器，测试了新构建的容器镜像。掌握了如何使用 Ansible 管理容器和容器镜像，将帮助你实现更好、更高效的 CI/CD 工作流和管道。与其在 CI/CD 工具中挣扎于有限的功能，不如利用 Ansible 的灵活性，向容器构建过程添加更多的验证、测试和集成。

在下一章中，你将学习如何在 Kubernetes 中管理容器化应用，并使用 Ansible 管理其他 Kubernetes 资源和应用。

进一步阅读

若想进一步了解本章所涵盖的主题，请查看以下资源：

Docker Hub 的容器注册表访问令牌：docs.docker.com/docker-hub/access-tokens
Ansible docker-compose 模块：docs.ansible.com/ansible/latest/collections/community/docker/docker_compose_module.xhtml
Docker RUN 和环境变量: docs.docker.com/engine/reference/commandline/run/#set-environment-variables--e---env---env-file
Dockerfile 文档: docs.docker.com/engine/reference/builder/
学习 Docker 的 5 大免费资源: www.techbeatly.com/top-5-free-resources-to-learn-docker/

第十一章：使用 Ansible 管理 Kubernetes

由于应用程序的容器化和微服务革命，基于 Kubernetes 的平台变得越来越流行。应用程序的容器化和使用 Kubernetes 进行容器编排，为基础设施增加了额外的层次和复杂性，这需要自动化解决方案来管理大量组件。

在前一章中，你了解了 Ansible 构建和管理容器镜像与容器的功能。当涉及到容器编排工具时，如 Kubernetes 或 Red Hat OpenShift，有 Ansible 集合可用，包含模块和插件，用于支持和管理你的 Kubernetes 和 Red Hat OpenShift 集群及资源。

使用 Ansible 进行 Kubernetes 资源管理将帮助你在 DevOps 工作流和持续集成/持续部署（CI/CD）管道中实现更多的集成，从而灵活地部署应用程序。

在本章中，我们将覆盖以下主题：

Kubernetes 简介
使用 Ansible 管理 Kubernetes 集群
配置 Ansible 以支持 Kubernetes
使用 Ansible 将应用程序部署到 Kubernetes
扩展 Kubernetes 应用程序
在 Kubernetes Pod 内部执行命令

我们将学习如何使用 Ansible 集合来管理 Kubernetes，并通过它自动化 Kubernetes 集群操作和资源管理。

技术要求

以下是继续本章所需的技术要求：

一台用于 Ansible 控制节点的 Linux 机器
一个具有 API 访问权限的工作 Kubernetes 集群（参考minikube.sigs.k8s.io/docs/start来启动一个本地 Kubernetes 集群）
关于容器和 Kubernetes 的基础知识

本章的所有 Ansible 代码、Ansible 剧本、命令和片段可以在 GitHub 仓库中找到：github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-11。

Kubernetes 简介

Kubernetes是一个开源容器编排平台，在这里我们可以部署和管理我们的容器化应用程序，而无需担心底层层次结构。这种服务模型被称为平台即服务（PaaS），开发人员可以自由地部署他们的应用程序及其他必要的资源，如存储、网络和密钥，而无需平台团队的帮助。

Kubernetes 平台包含多个组件，用于管理容器的部署和协调，如图 11.1所示：

图 11.1 – Kubernetes 集群的组件（来源：kubernetes.io/docs/concepts/overview/components/）

让我们在接下来的部分简要了解这些组件。

Kubernetes 控制平面

控制平面负责代表集群和应用程序做出决策，例如调度应用程序 Pods、检测和响应 Pod 故障，以及管理集群节点。控制平面有多个组件来处理这些操作，如下所示：

kube-apiserver – 提供 Kubernetes 集群 API，负责所有的中央管理和通信。Kubernetes 集群中的每个任务都是通过 Kubernetes API 服务器操作的。
kube-controller-manager – 包含多个控制器进程，如节点控制器、任务控制器、服务账户控制器和端点控制器。
etcd – 一个 高可用性（HA）键值存储，用于存储 Kubernetes 集群数据。
kube-scheduler – 帮助选择节点以部署 Pods。

节点上的组件

这些是运行在集群中每个节点上的 Kubernetes 组件，管理应用程序 Pods 及其网络：

容器运行时 – 实际在后台运行容器的软件，例如 containerd 和 CRI-O。
kubelet – 按照规范管理运行中的容器。
kube-proxy – 通过维护节点上的网络规则，帮助实现 Kubernetes 服务。

和其他开源项目一样，Kubernetes 也是免费的，且得到 Kubernetes 用户和开发者社区的支持 (kubernetes.io/community)。如果一个组织正在寻找企业级的 Kubernetes 发行版和支持，市场上有多种 Kubernetes 发行版作为交钥匙解决方案，例如 Red Hat OpenShift、Rancher 和 VMware Tanzu。

解释 Kubernetes 平台、概念和架构超出了本书的范围。你可以在本章末的 进一步阅读 部分找到更多详细信息。

要在 Kubernetes 中使用 Ansible，我们可以使用 minikube，它是一个本地的 Kubernetes 集群，用于学习和开发 Kubernetes 部署。请参考 minikube.sigs.k8s.io/docs/start 上的文档，那里你可以找到适用于 Linux、Windows 和 macOS 平台的安装说明。

Kubernetes 文档

请参考 Kubernetes 文档 kubernetes.io/docs/home 以了解更多关于 Kubernetes 的信息。也可以参考 前 15 个免费 Kubernetes 课程 (www.techbeatly.com/kubernetes-free-courses) 了解 Kubernetes 的基础知识。

在接下来的部分，我们将学习用于管理 Kubernetes 集群的 Ansible 方法。

使用 Ansible 管理 Kubernetes 集群

部署 Kubernetes 集群涉及许多步骤，包括准备节点、安装容器运行时包和配置网络。我们可以使用多种方法在测试或生产环境中部署 Kubernetes 集群。Kubernetes 集群的安装方法还取决于您的需求，例如，您是使用单节点集群还是使用具有 HA 的多节点集群，或者是否需要随时扩展集群。

Kubespray 是一种生产级的 Kubernetes 集群部署方法，基于 Ansible 进行配置和编排。使用 Kubespray，可以在裸金属服务器、虚拟机以及私有云或公有云平台（例如，AWS、GCE、Azure 和 OpenStack）上部署 Kubernetes 集群。

Kubespray 高度可定制，您可以根据需要选择不同的 Kubernetes 组件配置集群，如下所示：

支持的 容器网络接口（CNI） – Calico、Flannel、Kube-router、Kube-OVN、Weave 或 Multus
支持的 容器运行时接口（CRI） – containerd、Docker、CRI-O、Kata Containers 或 gVisor
支持的云服务提供商 – AWS、Azure、OpenStack 或 vSphere
支持的 Ingress – Kube-vip、ALB Ingress、MetalLB 或 Nginx
支持的操作系统 – Debian、Fedora CoreOS、Flatcar Container Linux、openSUSE、Red Hat Enterprise Linux、CentOS 或 Amazon Linux 2

使用 Kubespray 部署 Kubernetes 的详细说明可以在文档 (kubespray.io) 和其他在线指南中找到。

一旦完成配置，Kubernetes 集群可以根据需要进行扩展（通过添加或删除节点），使用 Kubespray 无需担心新节点的手动配置和集群加入步骤。请参考以下信息框和本章末尾的 进一步阅读 部分，获取关于 Kubespray 更多信息的链接。

Kubespray

请参考文档 (kubespray.io) 和项目仓库 (github.com/kubernetes-sigs/kubespray) 了解有关 Kubespray 的更多选项。还可以查看 www.techbeatly.com/deploying-kubernetes-with-kubespray，以获取关于如何使用 Kubespray 部署多节点 Kubernetes 集群的详细指南。

为了演示 Ansible 用例，我们使用了一个 minikube Kubernetes 环境，如下所示：

图 11.2 – minikube Kubernetes 集群详情

请参考文档 (minikube.sigs.k8s.io/docs/start) 了解如何创建 minikube 环境的更多细节。

在下一节中，我们将学习如何配置 Ansible 以访问 Kubernetes 集群并检查集群资源。

配置 Ansible 以支持 Kubernetes

Ansible 可以使用 Kubernetes Python 库或直接通过 Kubernetes API 与 Kubernetes 集群进行通信，如图 11.3所示：

图 11.3 - Ansible 与 Kubernetes 的通信

用于管理 Kubernetes 的 Ansible 模块和插件可以在 kubernetes.core Ansible 集合中找到。（在 kubernetes.core 1.1 版本发布之前，Ansible Kubernetes 集合以 community.kubernetes 发布。）我们将在接下来的章节中安装、配置并使用 kubernetes.core 集合。

Python 要求

要与 Kubernetes 或 OpenShift API 通信，可以使用 OpenShift API 的 Python 客户端（github.com/openshift/openshift-restclient-python）Python 库。在使用任何 Kubernetes 模块之前，你需要安装以下所需的 Python 库：

$ pip install openshift
$ pip install PyYAML

如果你在 Python 虚拟环境中使用 Ansible，请记得激活该环境并在其中安装库。

Kubernetes 的 Python 库

OpenShift REST 客户端依赖于 Kubernetes Python 客户端（github.com/kubernetes-client/python），该 Kubernetes Python 客户端将作为依赖项安装。同时，请查看 Ansible 为 Red Hat OpenShift 提供的内容集合（Ansible 博客）– www.ansible.com/blog/introducing-the-ansible-content-collection-for-red-hat-openshift

安装 Ansible Kubernetes 集合

从 Ansible Galaxy 安装 Ansible Kubernetes 集合（galaxy.ansible.com/kubernetes/core），步骤如下：

如果你希望将集合安装到项目目录中，可以在 ansible.cfg 文件中配置集合路径的对象类型：

图 11.4 - 在 ansible.cfg 中配置集合路径

安装 kubernetes.core 集合：

图 11.5 - 安装 kubernetes.core 集合

kubernetes.core 集合将根据你在 ansible.cfg 文件中提到的路径安装到集合目录内（COLLECTIONS_PATHS = ./collections）。

将 Ansible 连接到 Kubernetes

Ansible 将尝试使用$HOME/.kube/config文件，这是默认的 Kubernetes 配置文件（kubeconfig），包含 Kubernetes 集群的详细信息、凭证详细信息和连接上下文。如果你的kubeconfig文件位于其他路径或具有不同的文件名，请在 Ansible 剧本中的 Kubernetes module参数中指定此路径。

如前所述，我们有一个在 minikube 上运行的 Kubernetes 集群。kubeconfig文件和证书凭证已复制到 Ansible 控制节点，如下图所示：

图 11.6 – kubeconfig 文件和证书

如果你使用基本身份验证（用户名和密码）来访问集群，请在 Kubernetes 模块中指定这些详细信息。

对于生产环境，请记得遵循最佳实践来存储凭证、证书和访问密钥，使用 Ansible Vault 或任何其他秘密管理系统。

安装 kubectl CLI 工具

由于我们从控制节点进行操作，请在机器上安装kubectl CLI 工具，并执行kubectl命令以验证我们将通过 Ansible 创建的资源。

如果你的机器上已安装kubectl并能够访问 Kubernetes 集群，则跳过此步骤。

请参阅kubectl安装文档（kubernetes.io/docs/tasks/tools/install-kubectl-linux），并使用适合您环境的正确方法（由于我们在 Red Hat Enterprise Linux 机器上运行 Ansible 控制节点，以下命令基于 Red Hat Enterprise Linux/Fedora 发行版）：

添加kubectl包的仓库。

图 11.7 – 添加 kubectl 包的仓库

安装kubectl包：

图 11.8 – 安装 kubectl 工具

配置KUBECONFIG环境变量，因为我们的kubeconfig文件名不同（/home/ansible/.kube/minikube-config），与默认文件名（/home/ansible/.kube/config）不同：

图 11.9 – 配置 KUBECONFIG 环境变量

验证kubectl CLI 版本和集群详细信息。

图 11.10 – kubectl 版本信息

kubectl CLI 可以访问集群，我们将在接下来的章节中使用它来验证 Kubernetes 集群中的资源。

使用 Ansible 验证 Kubernetes 集群详细信息

收集集群详细信息和资源信息是一个重要步骤。Kubernetes 集群的详细信息可以通过kubectl CLI 收集，如图 11.11所示：

图 11.11 – 使用 kubectl CLI 收集的 Kubernetes 集群详细信息

使用kubernetes.core.k8s_info模块通过 Ansible 收集 Kubernetes 集群的类似详细信息（在 Ansible 2.9 之前，该模块被称为k8s_facts）。

按照以下步骤创建我们的第一个 Ansible playbook 与 Kubernetes 集群交互：

创建Chapter-11/k8s-details.yaml，如下所示：

图 11.12 – 从 kube-system 命名空间获取 Pod 详细信息的任务

我们正在从 Kubernetes 集群的kube-system命名空间中获取 Pod 的详细信息。注意hosts: localhost这一行，因为执行需要在localhost上进行。Python 库将处理 Kubernetes 操作。

执行 playbook 并验证输出。你将看到很多关于运行在kube-system命名空间内的 Pods 的详细信息，如图 11.13所示：

图 11.13 – 来自 Kubernetes 命名空间的 Pod 详细信息

在同一个 playbook 中添加一个任务，以收集 Kubernetes 集群节点的详细信息。

图 11.14 – 获取 Kubernetes 节点详细信息的任务

再次执行 playbook 并验证结果。

查看节点名称（在此示例中为minikube），如图 11.15中的输出所示。如果你有多个节点，你将在这里看到多个条目。

图 11.15 – 获取 Kubernetes 集群节点详细信息

通过使用不同的kubeconfig文件或在模块本身中提供凭证信息，如api_key、client_cert和client_key，来自定义不同集群的 playbook。有关更多详细信息，请参考kubernetes.core.k8s_info模块（docs.ansible.com/ansible/latest/collections/kubernetes/core/k8s_info_module.xhtml）。

现在，你已经学会了如何使用 Ansible 模块与 Kubernetes 集群进行通信，以及如何获取集群的详细信息。在下一节中，我们将通过在 Kubernetes 集群中创建资源和对象，进一步学习 Kubernetes 自动化的 Ansible 应用。

使用 Ansible 将应用部署到 Kubernetes

可以通过 Kubernetes 仪表板（Web UI）或使用 kubectl CLI (kubernetes.io/docs/reference/kubectl) 在 Kubernetes 内部部署容器化应用程序。通过使用 Ansible，我们可以自动化在 Kubernetes 集群内部发生的大多数部署操作。由于 Ansible 可以轻松集成到 CI/CD 流水线中，因此可以在像 Kubernetes 这样的容器化环境中对应用程序部署进行更多控制。

应用程序部署在称为 Kubernetes 命名空间 的逻辑隔离组内。可以有默认命名空间和与 Kubernetes 集群相关的命名空间，我们还可以根据需要创建额外的命名空间来部署应用程序。图 11.16 展示了 Kubernetes 集群中部署、Pod、服务和命名空间之间的关系：

图 11.16 – Kubernetes 部署和命名空间

在以下练习中，我们将通过创建专用的命名空间、部署配置和服务来部署一个应用程序：

准备 Chapter-11/todo-app-deploy.yaml 部署定义文件，接下来的步骤中将使用该文件创建 Kubernetes 部署资源。我们可以创建在 第十章《使用 Ansible 管理容器》中创建的 ginigangadharan/todo-app:latest 镜像。

图 11.17 – 待办事项应用的 Kubernetes 定义文件

准备一个 Chapter-11/todo-app-service.yaml Kubernetes 服务定义文件，以使用 NodePort 300080 暴露应用程序。根据所使用的 Kubernetes 集群，可以选择不同的 NodePort、ClusterIP 或 LoadBalancer 类型的服务。

图 11.18 – 待办事项应用的 Kubernetes 服务定义文件

创建 Chapter-11/k8s-app-deploy.yaml playbook，并添加如下内容：

图 11.19 – 用于在 Kubernetes 中部署应用的 playbook

执行 playbook：

图 11.20 – 执行 playbook 部署 todo-app

使用 kubectl CLI 验证命名空间是否创建，如 图 11.21 所示：

图 11.21 – 使用 Ansible 创建的 Kubernetes 命名空间

在同一个 playbook 中添加一个任务，用于使用 todo-app-deploy.yaml 部署定义文件创建部署，并使用 todo-app-service.yaml 文件创建 Kubernetes 服务资源，内容如下：

图 11.22 – 在 Kubernetes 中创建 Deployment 和 Service 资源的任务

再次执行 playbook 来创建 Deployment。
验证 Deployment、Pods、ReplicaSet 和 Service 资源是否已创建，如 图 11.23 所示：

图 11.23 – 由 Ansible 创建的 Deployment、Pod 和 Service

由于我们使用的是 minikube 集群，我们可以通过运行 minikube 集群的机器（而不是 Ansible 控制节点）使用 minikube service list 命令获取暴露的服务详情，如 图 11.24 所示：

图 11.24 – 在 minikube 集群中暴露的服务详情

根据名称查找 todo-app 应用的 URL（在此案例中为 http://192.168.64.10:30080），并在下一步中使用它。

通过 URL http://192.168.64.10:30080 在网页浏览器中访问应用，如 图 11.25 所示：

图 11.25 – 访问部署在 Kubernetes 集群中的待办应用

在你的应用部署中扩展 playbook，加入更多资源和配置。例如，我们可以通过 Ingress 定义创建一个 Ingress 资源，如下所示：

图 11.26 – 待办应用的 Ingress 资源定义

使用 Ansible 任务中的 Ingress 定义来创建 Ingress 资源，如下所示：

图 11.27 – 使用 Ansible 创建 Ingress 资源

我们还可以以变量的形式传递 Deployment 信息，并将其集成到我们的 CD 工作流中。

你已经学会了如何使用 Ansible 在 Kubernetes 中部署应用和服务资源。大多数 Kubernetes 资源可以通过 kubernetes.core.k8s 模块和资源定义文件来创建。然而，在 kubernetes.core 集合中还有其他有用的模块，我们将继续学习如何使用其中的一些模块，比如扩展应用和在 Pod 中运行命令。

扩展 Kubernetes 应用

Kubernetes 中的 ReplicaSet 资源确保指定数量的应用 Pod 副本作为 Deployment 的一部分运行。这个机制有助于在需要时横向扩展应用，而无需额外的资源配置。当你在 Kubernetes 中创建 Deployment 资源时，将会创建一个 ReplicaSet 资源，如 图 11.28 所示：

图 11.28 – 作为 Deployment 一部分创建的 ReplicaSet 资源

在部署定义文件中指定初始副本数为replicas: 1。ReplicaSet 将根据副本数量扩展 Pod 的数量。

当应用 Pod 上有额外流量时，使用kubectl scale命令扩展应用，如下所示（修改部署，而不是 ReplicaSet）：

图 11.29 – 使用 kubectl 扩展应用

等待复制更改生效并再次检查资源详细信息。你将发现现在有多个 Pod（三个）在运行，如图 11.30所示：

图 11.30 – 使用 ReplicaSet 资源扩展的应用

流量将通过service/todoapp-svc模块作为负载均衡器，分配给所有 Pods。请参考图 11.31，其中突出显示了多个端点，即 Pod 的 IP 地址：

图 11.31 – 一个具有多个 Pod 副本作为端点的 Kubernetes 服务

我们可以使用 Ansible 自动根据流量和条件管理 Kubernetes 应用的扩展。我们将在下一节中进一步了解kubernetes.core.k8s_scale模块，并进行实践。

使用 Ansible 扩展 Kubernetes 部署

k8s_scale模块是kubernetes.core集合的一部分，我们可以使用它来扩展或缩小 Kubernetes 部署。

在开始练习之前，记得将应用缩小为一个副本（--replicas=1），如下所示：

图 11.32 – 缩小 todo-app 副本

按照以下步骤创建用于扩展 Kubernetes 应用的 Ansible 工件：

创建一个Chapter-11/k8s-app-scale.yaml剧本，并添加以下内容：

图 11.33 – 扩展 Kubernetes 部署的 Ansible 剧本

根据工作流中的下一个任务，调整wait_timeout: 30。例如，增加该值，以确保 Pod 副本在继续执行下一任务之前已经创建并成功运行。

执行剧本：

图 11.34 – 执行 Kubernetes 部署扩展剧本

使用kubectl命令验证 Pod 副本，如图 11.35所示：

图 11.35 – 扩展后的 Pod 副本

根据以下条件定制扩展：

current_replicas: x：只有当前副本数量与current_replicas值匹配时，才会更改副本。
src: deployment.yml：这将从文件中读取部署和副本定义。
wait: no：这将不会等待缩放完成。

参阅 k8s_scale 模块文档获取更多细节（docs.ansible.com/ansible/latest/collections/kubernetes/core/k8s_scale_module.xhtml）。

在下一节中，我们将学习 k8s_exec 模块，并了解如何使用它来排查 Pod 问题。

在 Kubernetes Pod 中执行命令

在正常情况下，我们不需要登录到 Pod 或容器中，因为应用程序通过一些端口暴露，服务会通过这些暴露的端口进行通信。然而，当出现问题时，我们需要访问容器并检查内部情况，通过查看日志、访问其他 Pod 或运行必要的故障排除命令。

如果你正在手动排查问题或收集信息，请使用 kubectl exec 命令：

图 11.36 – 使用 kubectl 工具在 Pod 中执行命令

然而，当我们使用 Ansible 自动化 Kubernetes 操作时，应使用 k8s_exec 模块，并同时自动化验证任务或验证过程。

对于这种场景，我们可以使用合适的镜像（例如，包含所需工具的镜像，如ping、curl或netstat）部署调试 Pod，并从这些 Pod 执行验证命令。一个典型的部署场景是使用测试 Pod（curl-pod），如图 11.37所示：

图 11.37 – 用于验证和确认应用程序的调试 Pod

在以下场景中，我们将创建一个 playbook，使用 busyboxplus 镜像（hub.docker.com/r/radial/busyboxplus）部署一个 curl-pod Pod，并验证 curl-pod Pod 中的 todoapp-svc 服务：

创建 curl-app-pod.yaml 定义文件用于定义 curl-pod Pod，如下所示：

图 11.38 – curl-pod Pod 的 Kubernetes Deployment 定义

我们添加了一个 sleep 50000 命令；否则，Pod 会在没有运行任何进程的情况下退出。

创建一个 Chapter-11/curl-app-deploy.yaml playbook，并添加如下内容：

图 11.39 – 用于部署 curl-pod 的 Ansible playbook

添加一个任务，在 curl-pod Pod 中执行 curl 命令，以验证 todoapp-svc 服务是否可以访问。然后，添加任务以显示 curl 命令的输出，并验证成功与失败状态（curl_output.failed == true），如下所示：

图 11.40 – 在 curl-pod Pod 内执行 curl 命令并显示其状态的任务

最后一个任务是可选的，但添加更多的验证和消息将有助于实现更好的工作流程。

一旦验证完成，删除 curl-pod Pod，因为我们不再需要它。

图 11.41 – 测试完成后删除 curl-pod Pod

执行 playbook 并验证输出。如果 todoapp-svc 服务可以从 curl-pod Pod 访问，我们可以看到如 图 11.42 所示的 curl 输出：

图 11.42 – todoapp-svc 的 curl 命令输出

kubernetes.core.k8s_exec 模块在使用 Ansible 进行 Kubernetes 应用程序和集群管理的验证和确认中非常有用。该命令可以在调试 Pod 内执行，正如我们在前面的练习中所学的那样，甚至可以在应用程序 Pod 内执行以验证信息。

探索 kubernetes.core 集合，查找其他有用的模块和插件，以自动化您的 Kubernetes 部署和资源。

总结

在本章中，我们学习了用于 Kubernetes 集群和资源管理的 Ansible 集合。我们从 Kubernetes 组件的基础知识开始，讨论了如何使用 Kubespray 部署和管理 Kubernetes 集群及其支持的功能。

之后，我们学习了将 Kubernetes 集群连接到 Ansible 以自动化集群操作的方法。我们使用 Kubernetes Ansible 集合部署应用程序并扩展 Deployments。我们还学习了如何使用 Ansible 在运行中的 Kubernetes Pod 内执行命令，这可以用于验证和故障排除。本章简要介绍了使用 Ansible 自动化 Kubernetes 及其他重要信息，如 Kubernetes 内容集合以及将 Ansible 连接到 Kubernetes 的方法。

在下一章中，您将学习如何使用 Ansible 集成 CI/CD 和通信工具的不同方法。我们将进一步了解 Ansible 的企业版，名为 Ansible Automation Platform，以及其灵活的集成功能。

进一步阅读

欲了解更多本章内容的相关信息，请参考以下链接：

Kubernetes Ansible 入门指南 – docs.ansible.com/ansible/latest/collections/kubernetes/core/docsite/scenario_guide.xhtml
Play with Kubernetes – 免费的动手实验室 – labs.play-with-k8s.com/
CRI-O – cri-o.io
containerd – containerd.io/
前 15 名免费 Kubernetes 课程 – www.techbeatly.com/kubernetes-free-courses/
什么是 Kubernetes？ – www.redhat.com/en/topics/containers/what-is-kubernetes
免费的 OpenShift 实验室 – learn.openshift.com
Ansible kubernetes.core 集合 – galaxy.ansible.com/kubernetes/core 或 console.redhat.com/ansible/automation-hub/repo/published/kubernetes/core
Ansible community.kubernetes 集合 – galaxy.ansible.com/community/kubernetes
模板化（Jinja2） – docs.ansible.com/ansible/latest/user_guide/playbooks_templating.xhtml
什么是 PaaS？ – www.redhat.com/en/topics/cloud-computing/what-is-paas
Microk8s – microk8s.io
Red Hat OpenShift – www.redhat.com/en/technologies/cloud-computing/openshift
Kubespray – kubespray.io, github.com/kubernetes-sigs/kubespray

第十二章：将 Ansible 与你的工具集成

随着组织 IT 基础设施的不断发展，通常需要越来越多的工具来解决技术难题。与其让这些工具独立工作在孤岛中，不如实现它们之间的集成，以提高效率和可扩展性。例如，IT 服务管理 (ITSM) 工具可以向审批人发送警报，或者当团队开发出新版本时，容器平台可以触发应用程序的新部署。将多个孤立的 IT 基础设施工具进行集成，带来了无数的机会。

自动化同样适用；Ansible 可以作为实施多个基础设施和应用支持工具之间集成的关键自动化工具。在前几章中，你学习了基础设施（公有云和私有云）、DevOps、网络、应用程序等领域的 Ansible 自动化和集成机会。在本章中，你将了解更多有关企业自动化解决方案 Ansible Automation Platform (AAP) 以及如何在 IT 基础设施环境中与其他工具进行集成的方法。

我们将从介绍 Red Hat AAP 及其组件、功能和优势开始。然后，你将学习如何通过在自动化控制器中创建各种自动化资源（如项目、作业模板和凭证）来使用 AAP。

在本章中，我们将涵盖以下主题：

Red Hat AAP 简介
Red Hat AAP 组件
使用 Red Hat AAP 进行数据库管理
将 Jenkins 与 AAP 集成
将自动化控制器与 Slack 和通知服务集成

让我们开始学习 AAP，这一企业 IT 自动化工具。

技术要求

本章需要以下技术要求：

一台或多台配置了 Red Hat 仓库的 Linux 机器。如果你使用的是其他 Linux 操作系统而非 Red Hat Enterprise Linux (RHEL) 机器，请确保已配置相应的仓库，以便获取软件包和更新。
访问 Red Hat AAP。
一个 GitHub 帐户。
一个 Jenkins 服务器和有关 Jenkins 流水线的基本知识。
一个 Slack 应用帐户和有关 Slack 使用的基本知识。

一个 60 天的自助试用订阅可以用于测试 AAP 及其功能。请参阅 www.redhat.com/en/technologies/management/ansible/trial 了解有关 AAP 试用订阅的更多信息。

本章的所有 Ansible 工件、命令和代码片段可以在本书的 GitHub 仓库中找到，地址为 github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-12。

Red Hat AAP 简介

到目前为止，您已经学习了如何使用 Ansible，开发剧本，创建角色，使用内容集合等来处理您的用例。任何人都可以在他们的工作站或环境中的任意服务器上安装并使用 Ansible，用于自动化用例。然而，由于每个人采用自己的方法和实践，这将导致没有标准化、痕迹或问责。因此，组织中会出现以下挑战：

个人工作各自为营，导致工作场所没有协作。
自动化工件（剧本、角色和集合）未在个人或团队之间共享。
由于自动化在个人工作站或任意服务器上运行，因此没有可用的日志记录或审计选项。
对谁可以执行剧本或自动化作业的控制较少。
隐私和凭证管理困难。
缺乏作业调度和监控功能。
管理托管节点信息的复杂性。

在企业自动化中，解决方案必须能够实施治理、标准化、协作、问责和审计。

Red Hat AAP 通过实施企业自动化解决方案，帮助组织应对之前提到的大部分挑战，从而可以扩展自动化并协调基础设施和应用程序。AAP 包括所有企业自动化所需的工具和功能，如图形用户界面（GUI）和文本用户界面（TUI）基础工具、分析、仪表板、审计等。

请注意，与 Ansible（ansible-core 或 ansible 包）不同，Red Hat AAP 不是免费的，并且以订阅模式提供（www.ansible.com/products/pricing），就像其他 Red Hat 产品一样。对于测试和概念验证（POC）目的，可以申请 60 天的试用订阅，并访问 https://www.redhat.com/en/technologies/management/ansible/try-it 了解更多信息。有关如何安装和配置 Red Hat AAP 的详细信息，请参阅 access.redhat.com/documentation/en-us/red_hat_ansible_automation_platform/2.1/html/red_hat_ansible_automation_platform_installation_guide/index。

也可以获得免费的 RHEL 个人开发者订阅，用于测试和开发目的。请参阅developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux了解有关此免费 RHEL 订阅的更多信息。

微软 Azure 中的 Red Hat AAP 托管服务

Red Hat 将 AAP 作为 Microsoft Azure 上的托管服务提供，组织可以像使用其他 Microsoft Azure 云服务一样使用 AAP 解决方案。这是由 Red Hat 完全支持的，计费将包含在同一个云服务账单中。有关此托管服务的更多信息，请参阅www.redhat.com/en/technologies/management/ansible/azure。

现在，让我们探索 Red Hat AAP 的各种功能。

Red Hat AAP 的功能

以下是 Red Hat AAP 包含的重要功能：

WebUI：基于 Web 的 GUI 可以帮助管理员和开发人员通过 Web 浏览器管理整个自动化解决方案。AAP 中的大多数配置都可以直接从 WebUI 执行，如下所示的截图所示：

图 12.1 – Red Hat AAP 仪表板

基于角色的访问控制（RBAC）：管理员可以在 AAP 中创建团队和角色，并将适当的权限分配给用户或团队。这些权限可以针对 AAP 中的每个组件进行配置，例如项目、作业模板、清单或凭据。
日志记录和审计：AAP 将存储活动日志，包括作业执行历史记录，并且可以随时通过 WebUI 访问旧的作业详情。AAP 还包括与日志聚合工具（如 Logstash、Splunk、Loggly、Sumo Logic 等）集成的选项，以便我们可以将日志保存在中央系统中。
REST API（也称为 RESTful API）：强大且文档完善的 REST API 将帮助您将 AAP 与您环境中现有的工具和应用程序集成。

自动化控制器 API 指南

自动化控制器的 REST API 还帮助您管理自动化控制器操作，如作业模板创建、凭据管理或配置身份验证。有关详细信息，请参阅 API 指南 docs.ansible.com/automation-controller/latest/html/controllerapi/index.xhtml。

作业模板和工作流：可以预定义和配置作业模板和工作流模板，以便快速执行复杂的自动化作业（docs.ansible.com/automation-controller/latest/html/userguide/workflows.xhtml）。
凭据管理：使用凭据，您可以存储密码、API 密钥、令牌等敏感信息。AAP 提供了几种预定义的凭据类型，如果需要，还可以创建自定义凭据类型（docs.ansible.com/automation-controller/latest/html/userguide/credential_types.xhtml）：

图 12.2 – 自动化控制器凭证

作业调度：自动化作业可以自动调度和执行，无需用户干预，如下截图所示。这对于许多需要在特定时间段执行且不需要手动干预的自动化作业非常有用。例如，我们可以使用自动化控制器调度每周或每月的重启作业（如我们在第三章《自动化日常作业》中所学到的）：

图 12.3 – 自动化控制器中的作业调度

通知：AAP 支持多种类型的通知，如电子邮件、IRC 和 Webhook，以及 Grafana、Slack、Mattermost 等工具的集成。
与 Red Hat Insights 的集成：启用此集成后，可以分析您环境中自动化平台（AAP 集群）的自动化状态和数据。
与第三方认证系统的集成：无需在 AAP 中管理本地用户账户，而是与现有的认证提供商集成，例如 Active Directory、Google OAuth2、LDAP、RADIUS、SAMPLE 或 TACACS。

Red Hat AAP 特性与优势

请访问www.redhat.com/en/technologies/management/ansible/features了解有关 AAP 的更多功能及其优势。

在下一节中，您将深入了解 Red Hat AAP 的组件。

Red Hat AAP 组件

Red Hat AAP 是一个包含多个组件的自动化套件，如下图所示：

图 12.4 – Red Hat AAP 2.1 组件的高级图示（来源：https://www.ansible.com/blog/introducing-red-hat-ansible-automation-platform-2.1）

在接下来的章节中，您将了解 AAP 的不同组件，如自动化控制器、执行环境和自动化网格。

Ansible 自动化控制器

自动化控制器之前被称为Ansible Tower。它是 AAP 的控制平面和核心组件。随着 Ansible 自动化控制器的引入，控制平面组件（WebUI 和 API）与执行环境（EE）解耦，这也帮助解决方案增加了额外的执行节点。

使用自动化控制器，我们可以通过 WebUI 管理 AAP 操作，例如管理远程节点（库存）、凭证、项目、作业模板和其他操作。自动化控制器包含多个组件，如下所示：

用于库存、凭证和作业管理的 REST API
用于存储资源详情的数据库，包括自动化任务的历史记录
自动化网格连接器和接收器
消息队列和缓存
任务调度器

根据 RBAC 配置，用户在自动化控制器界面上将拥有不同的权限。

什么是 Red Hat Ansible 自动化平台的自动化控制器？

要了解更多关于自动化控制器的信息，请查看 什么是 Red Hat Ansible 自动化平台的自动化控制器？（www.redhat.com/en/technologies/management/ansible/automation-controller）。

Ansible Tower 和 AAP 生命周期

Ansible 自动化控制器 3.8（Ansible Tower）自版本 1.2 起已成为 AAP 的一部分。请参考 Ansible Tower 生命周期（access.redhat.com/support/policy/updates/ansible-tower）和 AAP 生命周期（access.redhat.com/support/policy/updates/ansible-automation-platform）以了解更多关于这些版本的信息。

ansible-navigator 是一个 TUI 工具，用于与自动化执行环境交互。在以下截图中可以看到。ansible-navigator 对于开发和测试自动化内容也很有帮助：

图 12.5 – ansible-navigator TUI

我们可以使用 ansible-navigator 来管理 Ansible 的所有命令行操作，如执行 playbook、管理集合、执行环境等，而不需要使用 ansible-playbook 和其他 ansible-* 命令。

请参考 Ansible navigator 文档（ansible-navigator.readthedocs.io）和 Ansible navigator 快捷操作表（www.techbeatly.com/ansible-navigator-cheat-sheet）以了解更多信息。

自动化执行环境

自动化执行环境提供了一种标准和可移植的机制，用于执行 Ansible playbook。执行环境在设计上是一致的，并提供包含以下组件的容器镜像：

Ansible
Ansible Runner
所需的 Ansible 集合
playbook 执行所需的其他依赖项（例如，Python 库、系统包）

之前，使用 Python 虚拟环境（例如，/var/lib/awx/venv/ansible）来实现此功能。在一致性方面，管理和维护这项功能并不容易，因为需要在 AAP 或 Ansible Tower 集群的所有节点上管理 Python 虚拟环境。通过容器化可执行文件和依赖项，可以将相同的镜像一致地分发到多个集群节点：

图 12.6 – 自动化执行环境中的组件

ansible-builder 是一个命令行工具，可以用来构建和管理自动化执行环境的容器镜像。有关构建和分发自动化执行环境的更多信息，请参考自动化执行环境文档（docs.ansible.com/automation-controller/latest/html/userguide/execution_environments.xhtml）。

自动化网格

自动化网格是 Ansible 自动化的服务网格概念，并在 AAP 2.1 中引入。自动化网格替代了 AAP 旧版本（1.2 及以下）中的孤立节点概念，并提供了扩展自动化生态系统的灵活性。自动化网格消除了跳板服务器（或堡垒主机）的需求，并且可以将执行节点放置在靠近被管理节点的位置，如下图所示：

图 12.7 – AAP 与自动化网格（来源： www.ansible.com/blog/whats-new-in-ansible-automation-platform-2.1-automation-mesh）

有关自动化网格的更多信息，请参考文档（www.ansible.com/products/automation-mesh）。

自动化中心

Ansible 自动化中心是下载受支持和认证的 Ansible 集合的官方位置。托管的自动化中心可通过 console.redhat.com/ansible/automation-hub 访问，如下图所示：

图 12.8 – Ansible 自动化中心

为了管理您的内容集合和其他受支持的集合，可以使用 私有自动化中心（PAH）。这一概念是在 AAP 1.2 中引入的。来自其他来源（例如 Red Hat Ansible 自动化中心或 Ansible Galaxy）的内容可以同步到私有自动化中心，如下图所示：

图 12.9 – 带 AAP 的私有自动化中心

有关自动化中心的更多信息，请参考文档（docs.ansible.com/ansible/latest/reference_appendices/automationhub.xhtml）和产品页面（www.ansible.com/products/automation-hub）。

Ansible AWX 和 Ansible 自动化控制器

Ansible AWX 是由 Red Hat 赞助的开源社区项目。它是 Red Hat AAP 中自动化控制器组件的上游项目。（Red Hat Ansible Tower 3.2 是基于 Ansible AWX 项目的第一个版本。）Ansible AWX 是一个快速发展的项目（github.com/ansible/awx），主要通过 IRC（web.libera.chat/#ansible-awx）和 AWX 邮件列表（groups.google.com/forum/#!forum/awx-project）由社区支持。请参阅项目页面（www.ansible.com/community/awx-project）和常见问题（www.ansible.com/products/awx-project/faq）以了解更多关于 Ansible AWX 的信息。

在接下来的章节中，您将学习如何开始使用 Red Hat AAP 来实现自动化用例。

使用 Red Hat AAP 进行数据库管理

在第八章中，帮助数据库团队实现自动化，您学习了如何使用 Ansible 来自动化数据库创建和用户管理操作。本节将重复使用相同的 Ansible 工件，但在不同的仓库中，并从 Red Hat AAP 执行该作业。

以下是本节的前提条件：

访问 Red Hat Ansible 自动化控制器 WebUI
访问包含必要 Ansible 工件的 GitHub 仓库（github.com/ginigangadharan/ansible-database-demo）
访问目标节点（数据库节点）

作业模板是自动化控制器中的核心资源，但作业模板需要一些其他资源作为依赖项。

图 12.10 – Ansible 自动化平台中的组件和依赖关系

您将学习在 Ansible 自动化控制器中进行基本操作，并创建各种资源，如下所示：

组织
项目
清单、管理节点和组
凭证
带有调查表单和额外变量的作业模板

在接下来的章节中，我们将学习如何访问 Ansible 自动化控制器并创建其中的资源。

访问 Ansible 自动化控制器

从支持的网页浏览器访问自动化控制器的 IP 地址或主机名，并使用用户名和密码登录，如下图所示：

图 12.11 – Ansible 自动化控制器 WebUI 登录页面

根据 RBAC 配置和权限，您将在仪表盘上找到允许的菜单和配置项：

图 12.12 – Ansible 自动化控制器仪表盘

要管理不同的项目、用户和其他资源，请创建一个新的组织；请参见以下截图中显示的示例。组织是项目、库存、团队和用户的逻辑集合（这是一个可选步骤；可以使用自动化控制器中已经存在的默认组织）：

图 12.13 – 创建新组织

一旦创建了新组织，就创建一个新项目。

在自动化控制器中创建项目

点击项目菜单，然后点击添加以创建一个新的项目，如下图所示。对于源代码控制 URL，使用 github.com/ginigangadharan/ansible-database-demo：

图 12.14 – 在自动化控制器中创建新项目

由于 GitHub 仓库是公开的，我们不需要凭证来访问它。对于私有 GitHub 仓库，您需要提供凭证；您将在下一节学习如何创建凭证，当我们添加库存和管理节点时。

验证项目的同步状态，如下图所示：

图 12.15 – 项目详情和任务状态

如您所见，自动化控制器已完成从 GitHub 仓库同步内容到本地目录（Playbook Directory: _15__database_management）。

如果在同步内容时遇到任何问题，请检查您的互联网连接或与 Git 服务器（对于私有仓库）的连接，并确保必要的访问权限已经到位。

创建库存和管理节点

在前面的章节中，您使用静态文件（和动态库存插件）创建了 Ansible 库存，如下图所示：

图 12.16 – 使用静态文件创建 Ansible 库存

现在，让我们在自动化控制器中使用 WebUI 创建一个新的库存、管理节点和主机组：

打开左侧的库存选项卡，并添加一个新库存，如下图所示：

图 12.17 – 在自动化控制器中创建 Ansible 库存

将创建一个新的库存，并显示其状态：

图 12.18 – 自动化控制器中的 Ansible 库存

现在，选择顶部的组选项卡，然后点击添加以创建一个新的主机组：

图 12.19 – 创建新主机组

新主机组的详细信息将显示，如下图所示：

图 12.20 – 新主机组详情

点击顶部的主机选项卡，然后点击添加并选择添加新主机，如下一截图所示：

图 12.21 – 将新主机添加到主机组

如果您已经直接添加了主机，则通过选择添加现有主机将主机添加到此主机组中。

创建一个新的主机，并提供主机名和ansible_host信息，如下所示：

图 12.22 – 创建新主机

可以为主机组在变量部分添加更多变量，作为主机，如图 12.22和图 12.20所示。

将您的库存导入自动化控制器

除了逐一添加管理节点外，您还可以从项目源、公共云或其他库存管理系统导入库存。请参阅文档docs.ansible.com/automation-controller/latest/html/administration/scm-inv-source.xhtml了解更多信息。

在自动化控制器中创建凭证

在前几章中，我们使用 SSH 密钥访问管理节点。SSH 私钥存储在 Ansible 控制节点（/home/ansible/.ssh/id_rsa）中，但在这种情况下，我们必须通过凭证传递私钥。

打开devops和 SSH 私钥（您也可以使用password作为凭证）：

图 12.23 – 添加机器凭证

由于我们已为sudo访问启用了NOPASSWD（参见第一章，Ansible 自动化 – 介绍，配置您的管理节点部分），因此我们不需要在权限提升字段中输入任何数据：

图 12.24 – 机器凭证权限提升字段

保存凭证并验证其详细信息。密码和 SSH 私钥内容将被加密，且任何人都无法查看。您只能重置凭证中的 SSH 私钥内容或密码，如下图所示：

图 12.25 – 加密的 SSH 私钥内容

通过这些设置，您已经创建了一个项目，一个包含管理节点（dbnode1）的库存，并且已经创建了访问该节点的凭证。现在，您必须使用Chapter-08/postgres-manage-database.yaml剧本创建一个作业模板，如下一节所述。

Ansible 自动化控制器 – 凭证

了解更多关于自动化控制器凭据的信息，请访问docs.ansible.com/automation-controller/latest/html/userguide/credentials.xhtml。要了解更多关于自定义凭据的信息，请访问docs.ansible.com/automation-controller/latest/html/userguide/credential_types.xhtml。

创建新的作业模板

自动化控制器中的作业模板是一个预配置的定义，包含一组参数和用于执行 Ansible 自动化作业的剧本。要多次执行相同的作业，使用作业模板并根据需要传递参数。请按以下步骤操作：

打开仪表板左侧的模板标签。然后，点击添加并选择添加作业模板，如图所示：

图 12.26 – 创建作业模板

输入作业模板的详细信息：

图 12.27 – 作业模板详情

自动化控制器中的作业模板

请参考文档docs.ansible.com/automation-controller/latest/html/userguide/job_templates.xhtml，了解如何通过附加选项自定义作业模板。

我们在剧本中使用了变量（图 12.28）来展示操作，避免了复杂性。在实际环境中，这些变量可以从额外的变量文件、组变量、主机变量或额外变量中获取。现在，我们必须将变量和值传递给作业模板，而不是在 Ansible 剧本中使用硬编码的变量：

图 12.28 – Ansible 剧本中的硬编码变量

可以通过自动传递参数给剧本的extra_vars来覆盖这些值。

点击作业模板的调查标签，如下所示：

图 12.29 – 作业模板调查

通过点击添加按钮并填写详细信息来创建新的调查问题：

图 12.30 – 用于收集 NODES 信息的作业模板调查表单

在前面的截图中，我们可以看到以下详细信息：

答案变量的名称是NODES，我们将其传递给剧本的hosts（hosts: "{{ NODES }}"）。
将显示一个多选菜单，供选择选项。

根据需要继续为其他变量创建调查问题。同时，记得启用调查，如下截图所示：

图 12.31 – Ansible 作业模板的调查变量

记得对于包含敏感信息（如密码或机密信息）的变量使用password类型。

自动化控制器中的调查表单

调查表单可以用来通过用户友好的表单和验证设置作业的额外变量。请参阅文档docs.ansible.com/automation-controller/latest/html/userguide/job_templates.xhtml#surveys，了解更多关于调查表单的信息。

我们假设以下变量在每次执行时不会更改，因此不需要放入调查表单中：

ansible_become_user: postgres 
postgres_host: localhost

相反，将它们作为额外变量添加，并保存作业模板：

图 12.32 – Ansible 作业模板中的额外变量

还可以将像ansible_become_user这样的变量传递到主机变量或组变量部分，但这会影响该节点上的所有作业，这在此情况下不是所需的配置。

在下一节中，你将学习如何执行我们之前配置的自动化作业。

从自动化控制器执行自动化作业

在前面的章节中，你已经在自动化控制器中配置了许多资源，例如组织、项目、库存、受管节点、凭证、作业模板等。现在，让我们通过启动自动化作业来测试作业模板。

Ansible 集合和执行环境

使用来自执行环境或项目库的集合（COLLECTIONS_PATHS = ./collections）。并非所有的 Ansible 集合（或最新版本）都会在执行环境中可用，并且可以创建一个自定义的执行环境，包含所需的集合和库。请参阅docs.ansible.com/automation-controller/latest/html/userguide/execution_environments.xhtml中的文档，了解更多关于创建执行环境的信息。在这个演示中，我们将使用community.postgresql Ansible 集合，该集合已在项目库中可用（请参见第八章，帮助数据库团队实现自动化）。

从自动化控制器仪表盘中打开模板标签，找到我们在前一章节中创建的 PostgreSQL 作业模板。点击启动模板按钮（小火箭图标），等待调查表单弹出：

图 12.33 – 从自动化控制器启动作业模板

在调查表单中输入详细信息，然后点击下一步：

图 12.34 – 在调查表中输入详细信息

详细信息将在预览屏幕上显示。请注意，调查变量作为额外变量传递。点击启动按钮，等待作业屏幕加载：

图 12.35 – 作业预览详情

该作业将在目标节点上执行。关于该作业的每个细节将显示在输出选项卡上，包括 playbook 执行的输出，如下图所示：

图 12.36 – 自动化控制器上的作业执行输出

根据需要在数据库节点（dbnode1）上验证数据库和用户的创建。

相同的作业模板可以用于在不同的数据库节点或数据库上执行操作，因为变量是动态的，不需要在 playbook 中修改。

在本节中，您学习了如何创建基本资源并在自动化控制器中启动自动化作业。在下一节中，您将学习如何将其他应用程序（如 Jenkins CI/CD 服务器）与自动化控制器集成并触发自动化执行。

与 AAP 集成 Jenkins

Jenkins（www.jenkins.io）是一个广为人知的开源工具（用 Java 编程语言编写），可用于实现持续集成/持续交付（CI/CD）和部署解决方案。自动化构建和部署是有效 DevOps 实践的关键。如以下图所示，开发人员和测试人员可以将这些任务委托给 CI/CD 工具，如 Jenkins：

图 12.37 – 使用 Jenkins 的 CI/CD 工作流

Jenkins 可以原生执行许多任务或使用插件，但对于复杂任务，Jenkins 可以利用适当的工具。例如，可以将特定作业卸载到 Ansible 自动化控制器，而不是在 Jenkins 管道中调用复杂的脚本或命令，如下图所示：

图 12.38 – Jenkins 与 AAP 集成进行数据库操作

自动化控制器将根据传递的参数执行作业，并将结果作为反馈（成功/失败及其他消息）返回给 Jenkins。

GitOps 和 CI/CD 课程

请参考 www.techbeatly.com/gitops-cicd/ 查找免费的 GitOps 和 CI/CD 课程及认证，包括 Jenkins 课程。

在以下演示中，您将重新使用数据库创建作业模板，作为部署 ToDo 应用程序的一部分。

以下是先决条件：

Jenkins 服务器必须安装了 Ansible Tower 插件（plugins.jenkins.io/ansible-tower）。
了解 Jenkins 的操作和配置。
PostgreSQL - 创建数据库和用户访问 作业模板必须已在自动化控制器上配置。
应用程序代码库（github.com/ginigangadharan/nodejs-todo-demo-app）。

Jenkins 的 Ansible Tower 插件

Jenkins 中的 Ansible Tower 插件帮助你通过传递适当的参数，在 Ansible Tower（或自动化控制器）上执行自动化作业：

图 12.39 – Jenkins 的 Ansible Tower 插件

如果尚未安装插件，请安装该插件并在 管理 Jenkins | 配置系统 下创建 Ansible Tower（自动化控制器）连接（添加所需的凭据）：

图 12.40 – Jenkins 中 Ansible Tower 插件的自动化控制器配置

通过点击 测试连接 按钮验证 Jenkins 与 Ansible 自动化控制器之间的连接，如前面的截图所示。

在接下来的部分中，你将学习如何在 Jenkins 中创建和配置多分支流水线。

Jenkins 中的多分支流水线

使用 ToDo 应用代码库（github.com/ginigangadharan/nodejs-todo-demo-app）在 Jenkins 中创建多分支流水线，如下图所示：

图 12.41 – Jenkins 中的多分支流水线

此外，通过每分钟扫描源代码库来配置自动化流水线触发器。启用此功能后，Jenkins 会每分钟扫描一次代码库中的更改，并自动触发构建过程：

图 12.42 – 扫描多分支流水线触发器

创建 Jenkinsfile

Jenkinsfile 就是一个 Jenkinsfile。以下截图显示了 todo 应用程序源代码库中可用的 Jenkinsfile：

图 12.43 – 带有环境变量的 Jenkinsfile

在生产环境中，存储保险库服务或凭据时，需要考虑敏感变量。

以下截图显示了在自动化控制器中调用数据库创建作业：

图 12.44 – Jenkinsfile 中的数据库创建阶段

ansible_controller_job() 写在 Jenkinsfile 的底部，如下所示：

图 12.45 – Jenkinsfile 中的 ansible_controller_job

注意我们传递的extraVars参数，因为这些变量是强制性的，需要通过额外的变量或调查表单传递（在本例中不适用）。

在下一部分中，您将探索通过 Ansible 自动化控制器可以执行的自动化构建触发和自动化数据库配置。

在 Jenkins 管道中触发构建

每当仓库中有变更（新的提交）或手动启动构建时，都会自动触发新的构建。以下截图显示了作业中的构建历史；请注意，创建数据库阶段已被高亮显示：

图 12.46 – Jenkins 管道中的构建作业

检查构建控制台日志，找到 Ansible 自动化控制器作业执行的详细输出，如以下截图所示：

图 12.47 – Jenkins 构建控制台与 Ansible 作业执行详情

到此为止，您已经学会了如何从 Jenkins 管道中调用自动化控制器作业，并自动化复杂的构建步骤。

Jenkins 管道的进一步增强

通过向管道中添加更多 Ansible 作业，探索 Jenkins 与 Ansible 自动化控制器之间的集成，具体如下：

在自动化控制器中创建一个作业模板，用于构建容器镜像并将其推送到容器注册表。（参考第十章《使用 Ansible 管理容器》中的 Ansible 工件。）
在Jenkinsfile中添加一个构建步骤，调用自动化控制器作业，构建应用程序的容器镜像。
在自动化控制器中创建另一个作业模板，通过使用在前一个阶段创建的容器镜像，在 Kubernetes 集群中部署应用程序。（参考第十一章《使用 Ansible 管理 Kubernetes》中的 Ansible 工件。）
在Jenkinsfile中添加一个部署步骤，调用自动化控制器作业，以使用最新的容器镜像部署更新的应用程序。

在下一部分中，您将学习如何在自动化控制器中启用通知并将其与 Slack 消息服务集成。

将自动化控制器与 Slack 及通知服务集成

在第三章《自动化您的日常工作》中，您学习了如何使用mail模块通过 Ansible 发送自定义电子邮件。在 Ansible 自动化控制器中，可以配置通知，根据作业的开始、成功或失败状态发送电子邮件和消息。自动化控制器支持以下通知类型：

Email
IRC
Webhook
Grafana
Slack
Mattermost
PagerDuty
Rocket.Chat
Twilio

可以创建多个通知，并可以为作业模板启用所需的通知。

在自动化控制器中创建电子邮件通知

要创建电子邮件通知，请从仪表盘打开通知标签并点击添加。选择类型为电子邮件并填写详细信息，如以下截图所示：

如果电子邮件服务器是开放的（无需身份验证），则将用户名和密码字段留空。
如果邮件服务器支持，启用 TLS 或 SSL。
输入一个已批准的发件人电子邮件（电子邮件白名单）。

保存表单并创建通知：

图 12.48 – 在自动化控制器中创建电子邮件通知

创建通知后，打开您想为其启用此通知的作业模板并选择通知标签。根据需要切换开始、成功和失败的开关：

图 12.49 – 在作业模板中启用通知

在上述示例中，只有在作业成功时，通知才会被触发。

执行作业模板并验证是否可以在作业成功时收到电子邮件。以下截图显示了一个示例电子邮件：

图 12.50 – 来自自动化控制器的电子邮件通知示例

通过编辑通知条目自定义通知消息及其内容，如下所示：

图 12.51 – 在自动化控制器中自定义电子邮件通知

在下一部分，您将学习如何将自动化控制与 Slack 集成，以便在 Slack 渠道中启用通知。

从自动化控制器发送 Slack 通知

Slack 是一个工作场所消息平台（app.slack.com），用户可以发送即时消息并创建通话、视频会议等。Slack 对话以 Slack 渠道的形式组织，并且可以在工作场所创建多个频道。

Slack 因其与 IT 和应用程序基础设施的集成灵活性而闻名。这是因为它支持与约 2,400 个应用程序的集成（slack.com/apps）：

图 12.52 – Slack 集成（来源：https://slack.com/integrations）

在以下演示中，您将学习如何创建 Slack 认证令牌，以便从自动化控制器发送通知。请按照以下步骤操作：

注册/登录 Slack，并访问你现有的工作区。（如果你没有工作区，可以按照slack.com/help/articles/206845317-Create-a-Slack-workspace的文档创建一个新的工作区。）
使用工作区中的现有频道（或者按照slack.com/help/articles/201402297-Create-a-channel的文档创建一个新的频道用于测试）。在本示例中，我们创建了一个名为#database-operations的新频道。
在浏览器中打开api.slack.com，点击右上角的教程菜单，并选择发布互动通知，如下图所示：

图 12.53 – 发布互动通知教程

本教程将在api.slack.com/tutorials/tracks/actionable-notifications打开。从创建预配置的应用部分选择创建应用。
Slack 会要求你选择你的工作区。在这里，配置应用的详细信息，如名称、重定向 URL 和其他项目。
完成教程中的指示来创建应用。
一旦应用创建完成，打开应用配置并复制 OAuth 令牌，如下图所示：

图 12.54 – 复制 Slack 应用 OAuth 令牌

图 12.55 – 在自动化控制器中创建 Slack 通知

打开作业模板的通知设置，并启用新创建的 Slack 通知，如下图所示：

图 12.56 – 启用作业模板的 Slack 通知

再次执行该作业，并验证 Slack 频道中的消息：

图 12.57 – 来自自动化控制器的作业通知

探索与其他应用程序的通知选项，以为你的团队和工作区实现有效的通知。

Slack 教程

访问api.slack.com/tutorials以了解更多关于 Slack 及其可用教程的信息。

到此，你已经学会了如何将 Ansible 与 Slack 集成，以启用通知。你可以对其他通知和消息服务（如 Mattermost、Rocket.Chat 等）执行相同操作。

摘要

在本章中，你了解了名为 Red Hat AAP 的企业自动化解决方案。首先，你了解了使用 AAP 的好处及其特点。你还学习了 AAP 的不同组件，如执行环境、自动化控制器、自动化网络和自动化中心。

接下来，你通过创建不同的资源（如组织、项目、清单、受管节点和组、凭证作业模板及调查表和额外变量等）进一步了解了自动化控制器。你还学习了如何将 Jenkins CI/CD 工具与 Red Hat AAP 集成，以便作为构建和部署管道的一部分，自动触发作业。

最后，你探索了自动化控制器中的通知选项，并通过电子邮件和 Slack 等不同类型的通知进行了测试。所有这些知识将帮助你使用 AAP 实现和管理自动化，并将 AAP 与环境中的不同工具集成。

在下一章中，你将学习如何使用 Ansible Vault 管理 Ansible 工件的机密和敏感信息。

进一步阅读

要了解本章涵盖的更多主题，请查看以下资源：

为什么选择 Red Hat 进行自动化？: www.redhat.com/en/topics/automation/why-choose-red-hat-for-automation
部署 Ansible 自动化平台 2.1: access.redhat.com/documentation/en-us/reference_architectures/2021/html-single/deploying_ansible_automation_platform_2.1/index
Red Hat Ansible 自动化平台数据表: www.redhat.com/en/resources/ansible-automation-platform-datasheet
通过私人自动化中心控制你的内容 – Ansible 博客: www.ansible.com/blog/control-your-content-with-private-automation-hub
什么是 Red Hat AAP 自动化执行环境？: www.redhat.com/en/technologies/management/ansible/automation-execution-environments

第十三章：使用 Ansible 进行秘密管理

在我们自动化任务时，我们需要尽量减少用户交互。然而，我们也知道，在某些阶段，Ansible 需要输入信息，如用户名、密码、API 密钥和密钥。大多数这些细节可以保存在变量文件中，并且可以传递给 playbook，而无需用户提示或交互，但将这类敏感信息作为变量保存在明文格式中并不是最佳实践。虽然有一些外部密钥保管服务可以使用，但大多数都需要额外的设置和配置，而且你还需要将它们与 Ansible 集成。

Ansible Vault 是 Ansible 内置的功能，使用它我们可以通过加密自己的 Vault 密码来保护 Ansible 工件中的敏感部分。Ansible Vault 和 Ansible 一起安装，你可以在 Ansible 临时命令、playbook 或 Red Hat Ansible Automation Platform 中使用它。

在本章中，你将学习以下主要内容：

在 Ansible 中处理敏感数据
使用 Ansible Vault 管理秘密
在 Ansible playbook 中使用秘密
在自动化控制器中使用 Vault 凭证

我们将从基本的 Vault 操作开始，学习如何借助 Vault 在 playbook 中使用敏感数据。

技术要求

以下是继续本章所需的技术要求：

一台 RHEL8/Fedora 机器作为 Ansible 控制节点
一台或多台配置了 Red Hat 仓库的 Linux 机器。如果你使用的是 Red Hat Enterprise Linux（RHEL）以外的其他 Linux 操作系统，请确保已配置适当的仓库，以便获取软件包和更新。

本章的所有 Ansible 代码、playbook、命令和代码片段都可以在 GitHub 仓库中找到：github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-13。

在 Ansible 中处理敏感数据

业界普遍认为，敏感数据不应以明文格式存储。这个规则同样适用于 Ansible，因为在使用 Ansible 时，你会处理不同类型的敏感数据。敏感数据可以是任何内容，如下所示：

系统密码
API 密钥
应用程序的端口信息
数据库密码
SSL 证书或密钥
云凭证

我们已经了解到，Ansible 使用明文格式存储 playbook、变量和其他配置。因此，将敏感数据存储在普通的变量文件中并不理想，我们需要使用更安全的方式来存储这类信息。

在深入了解 Ansible Vault 之前，让我们先了解以下章节中一些替代的秘密管理方法。

与 Vault 服务集成

存储敏感信息的最常见方法之一是使用密钥 Vault 软件和服务，在这些服务中，我们可以通过 GUI、API 或 CLI 访问密钥和机密。我们需要在 Ansible 中添加任务，以联系 Vault 存储、进行身份验证，并根据需要检索机密。图 13.1 演示了一个集成示例：

图 13.1 – Ansible 与外部 Vault 的集成

有可用的托管和自托管的外部机密管理解决方案，如 HashiCorp Vault (www.vaultproject.io)、AWS Secrets Manager (aws.amazon.com/secrets-manager/) 或 Azure Key Vault (azure.microsoft.com/en-us/services/key-vault/)。为了检索密钥或机密，我们可以使用 API 调用、Ansible 模块或 Ansible lookup 插件，如下图所示：

图 13.2 – 使用 lookup 插件检索 Vault 密钥

外部密钥 Vault 服务很好用且有用，但我们也需要处理管理和定价方面的开销。有关外部密钥 Vault 服务的更多文档和参考资料，请参考 进一步阅读 部分。

使用提示进行交互式输入

在 Ansible 中处理敏感数据的替代方法之一是，在 playbook 执行过程中动态收集数据。可以使用 vars_prompt 接受敏感和非敏感输入，如下所示：

图 13.3 – Ansible playbook 使用提示接受密码

当你执行 playbook 时，Ansible 会要求输入，并且根据 private 值，输入将在提示中显示或隐藏，如图 13.4所示：

图 13.4 – 使用 vars_prompt 接受用户输入

然而，正如你在前面的图中看到的那样，这种方法是交互式的，执行 playbook 时需要有人输入详细信息。这意味着你将无法在完全自动化的工作流中使用这些 playbook，因为在这种工作流中无法进行用户交互。同样，vars_prompt 不适用于 Ansible 自动化控制器，因为控制器不允许交互式地提出 vars_prompt 问题。

使用 Ansible Vault 加密数据

如本章开头所述，Ansible Vault 是 Ansible 的内建功能，通过它我们可以加密数据，确保 Ansible 工件的敏感部分安全。我们可以使用自己的密码作为 Vault 密码来加密内容。可以在 Ansible 临时命令、Playbook 或 Ansible 自动化平台中使用 Ansible Vault。

最佳实践是将敏感工件与非敏感工件分开，并保存在不同的文件中。过程的第一步是将敏感数据与常规变量文件分开，并将其存储在单独的变量文件中，如图 13.5所示。

图 13.5 – 带有加密变量的 Ansible 工件

通过这种做法，你将能够以加密格式存储敏感数据，并且可以灵活地随时修改常规变量。当 Ansible 需要读取这些加密文件的内容时，Ansible 将使用 Vault 密码，我们可以通过提示（--ask-vault-password）输入或使用特殊的 Vault 密码文件来输入。对于 Ansible 自动化平台，Vault 密码可以作为凭据存储并分配给作业模板。

在接下来的章节中，我们将学习如何使用 Ansible Vault 来加密变量文件，并在 Ansible Playbook 中访问加密的数据。

使用 Ansible Vault 管理机密

Ansible Vault 非常灵活，我们可以根据需要随时加密、查看、解密或更改 Vault 密码（即重新设置密码）。Vault 密码必须安全存储，因为没有 Vault 密码你将无法恢复加密的 Vault 内容。

创建 Vault 文件

在以下练习中，我们将学习如何使用 Ansible Vault 创建加密文件：

要从头开始创建 Vault 文件，请使用 ansible-vault create 命令，如图 13.6所示：

图 13.6 – 创建 Vault 文件

在输入 Vault 密码后，默认文本编辑器（例如 vim 或 nano）将打开一个新文件（我们可以通过更新 $EDITOR 环境变量来更改默认编辑器）。根据需要输入变量和值，和普通变量文件一样：
```
cloud_username: myusername 
cloud_password: mysecretpassword
```

请参阅图 13.7以获取更多详情：

图 13.7 – 向 Vault 文件添加内容

按照文本编辑器的操作保存文件（例如，：wq）并退出编辑器。

我们可以查看 Vault 文件，但内容将被加密（参见图 13.8），没有 Vault 密码，你将无法恢复数据。

图 13.8 – Vault 文件中的加密内容

在前面的练习中，我们已经学习了如何使用 Ansible Vault 创建加密文件。在接下来的部分中，我们将学习如何使用 Ansible Vault 加密现有文件和内容。

加密现有文件

如果你有一个变量文件或包含敏感内容的文件，并且想要使用 Ansible Vault 对其进行加密，那么可以使用 encrypt 命令，具体步骤见以下练习：

验证文件的当前内容如下所示：

图 13.9 – 以纯文本格式显示的数据库详情

使用 ansible-vault encrypt 命令加密内容：

图 13.10 – 使用 Ansible Vault 加密现有文件

现在，验证文件的加密情况如下所示：

图 13.11 – 加密后的纯文本文件

现在我们知道如何加密文件，接下来我们将学习如何使用 Vault ID 处理多个 Vault 密码。

向加密中添加 Vault ID

当我们有许多 Vault 文件和多个 Vault 密码时，可以使用 Vault ID 来识别 Vault 内容。Vault ID 是一个标识符，用于标识一个或多个加密的密钥和内容。让我们跟随一个示例：

使用 --vault-id 选项创建并加密秘密文件，如下所示。Vault ID 会在提示符中显示，如 图 13.12 所示。

图 13.12 – 使用 Vault ID 创建 Vault 文件

相同的 Vault ID 可以通过以下方式从 Vault 文件的内容中查看：

图 13.13 – 带有 Vault ID 的 Vault 文件

Vault ID 的密码可以通过提示符获取（如前面的示例所示），也可以从 ansible.cfg 中配置的路径获取，如下所示：

图 13.14 – 在 ansible.cfg 中配置的 Vault ID

使用 Vault ID 可以帮助你在大型环境中管理多个 Vault 文件，并识别被加密的文件和密钥。

查看 Vault 文件的内容

一旦内容被加密，就可以使用 ansible-vault view 命令显示 Vault 内容，如 图 13.15 所示。Ansible 将提示输入现有的 Vault 密码，你将看到纯文本格式的内容：

图 13.15 – 显示 Vault 内容

请注意，Vault 文件内容仍然处于加密状态，因此没有 Vault 密码，你将无法访问它。

编辑 Vault 文件

要编辑加密后的 Vault 文件，请使用 ansible-vault edit 命令，如下所示：

图 13.16 – 使用 Ansible Vault 编辑加密文件

Vault 文件将在文本编辑器中以纯文本格式打开。编辑完成后，保存文件（例如，：wq）并退出编辑器，如图 13.17所示：

图 13.17 – 在文本编辑器中编辑 Vault 文件

编辑完成后，Vault 文件将以加密格式保存，无需额外操作。

解密 Vault 文件

有些情况下，我们需要将文件解密为纯文本，可能是暂时的也可能是永久的。在这种情况下，ansible-vault decrypt 命令可以帮助将 Vault 文件解密为纯文本格式，如下所示：

图 13.18 – 解密 Vault 文件

解密后验证文件内容，如图 13.19所示：

图 13.19 – 解密后的 Vault 文件

当你再次加密文件时，可以使用相同的或不同的 Vault 密码，这没有关系。

Vault 密码轮换通过重新设置密码进行

定期更换密码、密钥和 SSL 证书是一种常见做法，以确保凭证不被泄露，并遵循组织的密码政策。ansible-vault rekey 命令可帮助更改或轮换 Vault 密码，保护敏感内容。Ansible Vault 会要求输入现有的 Vault 密码，如果成功，将显示提示以设置新 Vault 密码，如图 13.20所示：

图 13.20 – 更换 Vault 密码

记得在适用的地方更新新的 Vault 密码，例如在本地 Vault 密码文件或 Ansible 自动化控制器的 Vault 凭证中。

加密特定变量

如果你不想加密整个变量文件，那么使用 ansible-vault encrypt_string 命令加密特定的变量，如下所示：

图 13.21 – 使用 Ansible Vault 加密字符串

输入可以来自内联，如前面的示例中所示（图 13.21），也可以来自标准输入，如图 13.22所示：

图 13.22 – Ansible Vault 使用输入值加密字符串

使用这个加密字符串作为 Ansible playbook 或变量文件中的变量，如下所示：

图 13.23 – Playbook 中的加密字符串

使用 Ansible Vault 加密内容

使用 Ansible Vault，你还有更多选择，比如编辑、加密、解密和重新生成密钥等。例如，请参考文档以了解更多详情：docs.ansible.com/ansible/latest/user_guide/vault.xhtml。

在接下来的部分中，我们将学习如何在 Ansible 剧本中使用加密的 Vault 文件并检索密钥信息。

在 Ansible 剧本中使用机密信息

你已经在第三章的自动化通知部分学习了在 Ansible 剧本中使用机密的基本方法。在本节中，我们将进一步学习其用法和不同的传递 Vault 密码的方法。

在以下练习中，我们将开发 Ansible 内容，用于在 Linux 中创建用户，并从 Ansible Vault 文件中检索他们的密码：

创建一个Chapter-13/vars/users.yaml Ansible Vault 文件，并输入 Vault 密码，如下所示：
```
[ansible@ansible Chapter-13]$ ansible-vault create vars/users.yaml 
```

请记住密码，因为执行剧本时我们需要这些信息。

将内容添加到变量文件中，如下所示：

图 13.24 – Ansible Vault 文件中的用户详情

保存文件并退出编辑器。userlist变量包含多个用户及其密码的详细信息。

验证文件内容，如图 13.25所示：

图 13.25 – 用户的加密信息

创建一个Chapter-13/manage-user.yaml剧本，内容如下：

图 13.26 – 一个用于添加用户的剧本

查看vars_files部分，因为我们已经在剧本中包含了加密的变量文件。

图 13.27 – 创建组和用户

在 Ansible 中生成加密密码

password_hash(‘sha256’)过滤器已被用来加密密码，以避免发送明文密码。请参考docs.ansible.com/ansible/latest/reference_appendices/faq.xhtml#how-do-i-generate-encrypted-passwords-for-the-user-module 了解更多关于 Ansible 中密码加密的内容。

现在，使用以下命令执行剧本：ansible-playbook。

图 13.28 – 由于没有 Vault 密钥，Ansible 错误

由于我们在剧本中包含了 Ansible Vault 文件，Ansible 期望 Vault 密钥可用，如果没有合适的密钥，它将失败。

通过添加--ask-vault-password参数执行剧本：

图 13.29 – 执行带有 Vault 密码提示的剧本

使用以下临时命令验证node1上用户创建成功：

图 13.30展示了命令的示例输出：

图 13.30 – 用于检查用户是否成功创建的 Ansible 临时命令

在前面的示例中，您使用 Ansible Vault 加密了一个变量文件，并通过提示 Vault 密码从 Ansible 剧本中检索信息。但是，对于自动化操作，我们需要跳过此提示。Vault 密码应该能够在命令行中直接传递。在这种情况下，使用--vault-password-file参数，并将 Vault 密码放入一个文件中。

创建一个文件来存储您的 Vault 密码。Vault 密码应该是一个纯文本文件，但保存在安全位置，例如您主目录中的一个隐藏文件，如图 13.31所示：

图 13.31 – 您主目录中的隐藏文件中的 Vault 密码

执行相同的剧本，但使用--vault-password-file参数传递 Vault 密码文件。这时，Ansible 将不会询问密码，如图 13.32所示：

图 13.32 – 来自密码文件的 Ansible Vault 密码

Vault 文件可以包含任何类型的数据，无论是单一变量、字符串、复杂的字典变量，还是任何其他文本内容。

Ansible Vault 将帮助我们加密 Ansible 工件中的敏感数据，但我们需要防止这些数据在日志中被捕获，我们将在下一节学习如何做到这一点。

使用 no_log 从日志中隐藏秘密

您已经学会了如何使用 Ansible Vault 保护敏感内容，但我们在这里遇到了一个问题，因为 Ansible 在执行日志记录时会以纯文本格式包含敏感数据内容。有时，默认的详细模式中看不到这些内容，但在更高级的详细模式下（如-vvv或-vvvv）会显示出来。有关详细信息，请参见图 13.33：

图 13.33 – 显示敏感数据的 Ansible 剧本输出

在这种情况下，使用no_log: True，如图 13.34所示，该任务中的任何输出都会因安全原因被屏蔽：

图 13.34 – 使用 no_log 禁用任务的日志记录

如果现在执行剧本，您会注意到如下更改：

图 13.35 – 应用 no_log 到敏感数据的 Ansible 输出

即使启用了高详细模式-vvv，Ansible 仍会隐藏信息，如图 13.36所示：

图 13.36 – 应用 no_log 的高详细 Ansible 日志

这是保护系统日志和作业历史中捕获的敏感数据的最佳实践之一。

在接下来的部分，我们将学习如何将敏感数据保存在其他变量位置，如group_vars和host_vars。

Ansible Vault 用于`group_vars`和`host_vars`

正如我们在本章之前讨论的那样，最佳实践是根据需要将变量和敏感信息分开。

在以下练习中，我们将重用在第八章中开发的 PostgreSQL Ansible 工件，帮助数据库团队进行自动化。PostgreSQL 已安装并配置在node2上。我们将为访问db_sales数据库创建一个额外的数据库用户帐户（请参考第八章的内容了解更多详情）。我们将执行以下操作：

更新库存文件（Chapter-13/hosts），通过将node2添加为postgres主机组的一部分：
```
[postgres]
node2 ansible_host=192.168.56.24
```
创建group_vars和另一个子目录，如下所示：

图 13.37 – 创建group_vars目录和 Vault 文件

为新用户添加数据库用户名和密码：

postgres_app_user_name: appteam
postgres_app_user_password: ‘AppPassword’

保存并验证 Vault 文件，如图 13.38所示：

图 13.38 – Vault 文件中的数据库用户信息

创建另一个 Vault 文件用于存储 PostgreSQL 管理员密码：

[ansible@ansible Chapter-13]$ ansible-vault create group_vars/postgres/vault/dbadmin.yaml

在其中添加postgres_password并保存文件：
```
postgres_password: ‘PassWord’
```
创建一个Chapter-13/postgres-create-dbuser.yaml剧本，如下所示：

图 13.39 – 用于管理 PostgreSQL 用户信息的 Ansible 剧本

添加一个任务以创建 PostgreSQL 数据库用户，如下所示：

图 13.40 – 创建 PostgreSQL 用户的任务

所有敏感变量现在都在group_vars Vault 文件中，例如postgres_password、postgres_password和postgres_app_user_password。

在postgres主机组（我们在第一步中创建的）上执行剧本，剧本将读取变量并安全地创建新用户，如图 13.41所示：

图 13.41 – 创建 PostgreSQL 数据库用户

最佳实践是将所有敏感信息保存在 Vault 文件中，并将其放在适当的位置，这样即使你的 Ansible 内容保存在 Git 仓库中，它们也会保持安全。

在接下来的部分中，我们将学习如何在 Ansible 自动化平台中使用 Vault 文件和凭证。

在 Ansible 自动化平台中使用 Vault 凭证

当你从自动化控制器的 Web UI 运行你的 playbook 时，你将有类似的选项来提供 Vault 密码。我们可以将 Vault 密码保存在 Vault 凭证中，或者在 Ansible 命令行执行中选择 --ask-vault-password，并在从自动化控制器的 WebUI 执行作业模板时提示输入 Vault 密码。

Ansible 自动化控制器

Ansible 自动化控制器是 Ansible 自动化平台（AAP）的控制平面。当你迁移到 AAP 2 时，自动化控制器将升级为包含 Ansible Tower。有关更多详细信息，请参阅 第十二章，将 Ansible 与您的工具集成。

在接下来的部分中，我们将学习如何在 Ansible 自动化控制器 GUI 中创建 Vault 凭证，并将其附加到作业模板中以检索加密内容。

创建 Vault 凭证

要存储 Vault 密码，请按照以下步骤创建一个新凭证：

打开 创建新凭证 面板，并将 凭证类型 设置为 Vault，如 图 13.42 所示。输入 Vault 密码（秘密），并在需要时添加 Vault ID：

图 13.42 – 在自动化控制器中创建新的 Vault 凭证

创建后，更新你的作业模板，并将新的 Vault 凭证添加到其中。导航到 作业模板 | 编辑，然后点击凭证旁边的搜索按钮。
在弹出屏幕中，将 选择的类别 设置为 Vault，然后你将看到 Vault 凭证，如 图 13.43 所示。选择所需的 Vault 凭证并点击选择按钮。

图 13.43 – 为作业模板选择 Vault 凭证

验证凭证，如 图 13.44 所示：

图 13.44 – 在作业模板中添加的凭证

如果你有多个 Vault 文件和不同的 Vault 密码，则根据需要添加多个 Vault 凭证并添加 Vault ID。

摘要

在本章中，我们学习了在 Ansible 自动化工件中保持敏感数据安全的重要性以及可用的不同方法，例如外部 Vault 服务、vars_prompt 和 Ansible Vault。之后，我们学习了在 Ansible Vault 中的不同操作，如创建、修改、查看、解密和重新设置 Vault 文件和变量。

我们还使用 Vault 文件开发了 Ansible 工件，用于存储用户信息和数据库用户凭证。我们还讨论了在自动化控制器 GUI 中的 Vault 凭证，以及如何在作业模板中使用它们。

在下一章中，我们将学习不同的方法和途径，用于开发 Ansible 自动化工件，并探讨在整个 Ansible 自动化过程中需要考虑的因素。

深入阅读

若要了解更多本章涉及的主题，请访问以下链接：

教程：使用 Azure Key Vault 存储 VM 机密信息与 Ansible – docs.microsoft.com/en-us/azure/developer/ansible/key-vault-configure-secrets?tabs=ansible
如何使用 Ansible 和 Gmail 发送电子邮件 – www.techbeatly.com/ansible-gmail
记录 Ansible 输出 – docs.ansible.com/ansible/latest/reference_appendices/logging.xhtml
安全地可见化 Vault 变量 – docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.xhtml#keep-vaulted-variables-safely-visible
在 Ansible 中加密密码 – docs.ansible.com/ansible/latest/reference_appendices/faq.xhtml#how-do-i-generate-encrypted-passwords-for-the-user-module
Red Hat Ansible 和 Red Hat Ansible Tower 中的 Vault ID –developers.redhat.com/blog/2020/01/30/vault-ids-in-red-hat-ansible-and-red-hat-ansible-tower

第三部分：使用最佳实践管理您的自动化开发流程

本部分将描述持续评估、监控和安全操作的重要性。您将了解可以用于检测和保护环境的不同监控技术，以及如何从中获取洞察。

本书的这一部分包括以下章节：

第十四章**，保持自动化简单高效
第十五章**，自动化非标准平台和操作
第十六章**，Ansible 生产环境自动化最佳实践

第十四章：保持自动化简单高效

Ansible 是一个简单而强大的自动化工具。我们可以使用 Ansible 自动化任何类型的工作流，但如果我们增加自动化的复杂度，就会降低效率，从而影响生产力。当你设计自动化解决方案或使用案例时，必须考虑多个因素，例如工具的能力以及在调整自动化流程或扩展性时的灵活性。

例如，可以编写简单的 playbook 来监控系统中的服务状态或检查应用程序的健康状况。但这样做效率不高，因为你还需要其他安排，例如作业调度程序来定期执行任务并监控执行情况。我们可以利用 Ansible 自动化控制器和其他系统的集成功能，而不是仅仅使用 Ansible 来处理复杂的自动化任务。我们可以使用现有的监控、日志记录和安全控制工具，并利用 Ansible 执行补救操作，如启动服务、阻止端口和 IP 地址。

本章将涵盖以下主题：

利用调查和自动化输入
将 Ansible 与监控工具集成
用于安全自动化的 Ansible
Ansible 工作流模板

我们将从查看自动化控制器中的各种调查功能开始，并继续讲解 Ansible 集成相关的内容。

技术要求

本章的技术要求如下：

监控和日志平台的基础知识
一般的安全平台知识
关于IT 服务管理（ITSM）工具（Jira 和 ServiceNow）的基础知识
访问Ansible 自动化平台（AAP）环境

本章所有的 Ansible 文档、命令和片段都可以在本书的 GitHub 仓库中找到，网址是github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-14。

利用调查和自动化输入

在第八章，帮助数据库团队进行自动化，你了解了将 Jira 服务管理与 Ansible 集成以自动化数据库操作的优势。你学会了如何与 Jira 集成并自动传递变量，而不是手动将 Jira 工单中的输入详情复制到 Ansible 自动化控制器中。这使得零接触集成成为可能，无需输入自动化任务的细节，如数据库名称、服务器名称、数据库用户名或数据库表。

你在第十二章，将 Jenkins 与 Ansible 自动化平台集成中了解了类似的示例，Jenkins 调用 Ansible 自动化控制器 API 来执行作业模板。在 Ansible 自动化控制器中，你使用了调查字段和优雅的表单来传递这些信息：

图 14.1 – PostgreSQL – 创建数据库和用户访问任务模板的调查表

当我们将这个任务模板与 Jenkins 等外部工具集成时，我们需要以非交互方式提供输入（数据库用户、数据库或表）。这时，我们使用 Jenkins（或者在前面的例子中使用 Jira）来调用带有所有必要信息的任务模板，包括数据库用户、数据库名称、表格和用户详细信息作为额外变量。

此外，通过与现有的 ITSM 和请求管理工具集成，可以增强自动化系统，并将输入表单创建（调查表）负载从 Ansible 自动化控制器中卸载。

以下图表展示了工具、AAP 和管理节点或平台之间的高级通信。外部工具可以将所有所需信息作为额外变量传递给 AAP API，并实现非交互式工作流：

图 14.2 – 从其他平台触发带有额外变量的 AAP 任务模板

通过这一点，你已经了解了 Ansible 中的最佳实践之一，称为软编码（与硬编码相对）。这意味着在执行自动化任务时接受参数。

在接下来的章节中，你将了解将 Ansible 与其他安全和监控工具集成的优势，而不是仅仅使用 Ansible 本身来执行这些目的。

将 Ansible 与监控工具集成

由于 Ansible 具有灵活性，并且可以自动化大多数日常工作，因此自动化所有可能的用例是常见的做法，即使它效率不高。我们从社区学到的一个所谓的非标准用例是将 Ansible 用于监控目的，如下所示：

在系统中监控服务或应用程序状态
对端点（应用程序、Web 服务或集群）运行健康检查
监控网络和安全设备规则或状态

以下图表展示了一个典型场景，其中 Ansible 自动化任务被安排定期运行健康检查，以监控管理节点或应用程序。这些任务可以作为 Ansible 控制节点上的cron任务运行，或者作为 Ansible 自动化控制器中的计划任务运行：

图 14.3 – 使用计划自动化任务进行监控

这种方法是可行且易于实现的，但效率不高。它有很多缺点，如下所示：

你对监控频率的控制较少。
在 Ansible 控制节点或自动化控制器上存在计算开销。监控目标的数量将增加这种开销。
由于某些作业可能需要更多时间，您对执行时间的控制较少，队列中的下一个作业也可能会被延迟。
根据要监控的目标项，你需要创建许多 Ansible 剧本。

我们可以使用已经到位并高效执行的标准监控工具，而不是使用 Ansible 剧本来执行频繁的监控作业。下图展示了监控和日志工具、ITSM 软件与 Ansible 之间的高级集成：

图 14.4 – Ansible 与日志和监控工具的集成

监控和日志代理可以有效地完成其工作，并将警报、事件和问题报告到中央数据库系统。根据组织的需求和基础设施布局，监控堆栈可能包含不同的组件和多个活动部分。监控和日志工具可以与 ITSM 工具集成，将事件和警报记录到 ITSM 事件管理系统中。此外，ITSM 工具还可以与 Red Hat AAP 集成，实现自动化修复。你将在下一节了解更多信息。

Ansible 在监控中的作用

在监控和警报领域有几个使用案例，我们可以利用 Ansible 来自动化操作：

通过 API 调用在自动化控制器上实现自动作业触发。
基于监控工具或 ITSM 工具的 API 调用，实现自动化修复和部署。
在受管节点上部署监控代理和配置。
根据警报和 API 调用实施配置强化。

下图展示了基于 AAP 和自动化作业执行的典型集成和工作流：

图 14.5 – Ansible 中的监控和警报工作流

在上面的图示中，发生以下操作：

通过监控主机或服务上的代理，可以检测到事件和警报，如系统问题、安全事件或应用程序健康问题。
监控和日志工具在 ITSM 和安全监控工具中创建事件。
监控和日志工具还可以直接通过自动化控制器 API 触发警报（或 API 调用），从而触发作业。
ITSM 工具根据规则、工作流和脚本触发 API 调用。
基于 API 调用，自动化控制器执行配置好的作业模板并修复事件。
自动化控制器还会自动更新事件票证，包含修复作业的状态和票证状态（例如，关闭票证或更新审查状态）。

Ansible 与 ServiceNow 的集成

想要了解更多关于 Ansible 与 ServiceNow 集成的信息，请阅读 Ansible + ServiceNow 第三部分：向 Red Hat Ansible Tower 发起外部 RESTful API 调用（www.ansible.com/blog/ansible-servicenow-howto-part-3-making-outbound-restful-api-calls-to-ansible-tower）。同时，查看 www.ansible.com/integrations/it-service-management/servicenow 获取更多相关参考资料。

你将在下一节中通过一个用例来探索这种集成。

ServiceNow、Ansible 与零接触事件修复

在本节中，你将了解零接触事件修复与ServiceNow（也称为SNOW）和 Ansible 之间的重要集成和连接点。典型的工作流可以在以下图示中看到：

图 14.6 – 典型的事件自动化工作流

配置监控代理和 ServiceNow 实例超出了本书的范围，因此我们将只关注 Ansible 部分。只要该工具能够触发 API 调用至 AAP 进行自动化作业，就可以将 ServiceNow 替换为其他 ITSM 工具，如 Jira 服务管理或 BMC Remedy。

ServiceNow 工作流

请参考 ServiceNow 文档 www.servicenow.com/products/workflow.xhtml 了解更多有关其工作流自动化的信息。

一旦在服务管理系统中创建了事件，Ansible 自动化控制器将根据工作流的配置接收 API 调用。例如，我们在自动化控制器中配置了一个名为PostgreSQL - 服务启动的作业模板，如下所示：

图 14.7 – PostgreSQL – 服务启动作业模板

Ansible 剧本包含了一些任务，用于更新事件工单以及重启 PostgreSQL 服务。第一步是将事件工单的状态更新为进行中，如下所示：

图 14.8 – 更新 ServiceNow 工单的任务

现在，添加一个任务，启动 PostgreSQL 服务：

图 14.9 – 启动 PostgreSQL 服务的任务

现在，添加一个任务，将工单的状态更新为已解决：

图 14.10 – 更新工单状态为已解决

扩展剧本，增加更多验证和工单状态更新，以满足你所在组织的 ITSM 过程和需求。如果需要，你甚至可以添加更新工单为已关闭的任务。

ServiceNow 中事件的生命周期

请参阅 ServiceNow 文档 (docs.servicenow.com/en-US/bundle/sandiego-it-service-management/page/product/incident-management/concept/c_IncidentManagementStateModel.xhtml) 了解更多关于事件生命周期的信息。同时，参阅 Ansible 博客文章 www.ansible.com/blog/ansible-servicenow-opening-and-closing-tickets 了解更多关于 ServiceNow 与 Ansible 集成的内容。

有时可能会有人因某些活动而停止 PostgreSQL 服务；Ansible 应该能够意识到这一点。可以使用 ITSM 工具或第三方解决方案创建一个维护跟踪系统，在其中可以更新系统维护详情并指定时间段，以便高效处理事件工单，如下所示：

ITSM 工具检测到系统维护窗口并将工单更新为误报。
在 Ansible playbook 中添加任务，以检查是否处于此维护窗口，如果系统在该维护窗口内，则将警报更新为误报。

通过这一步，你已经探索了将 Ansible 与各种监控和日志系统集成的一些可能性。在下一节中，你将学习如何将 Ansible 用于安全自动化解决方案。

Ansible 与安全自动化

安全加固是通过减少攻击面来保护主机、网络设备和应用程序的做法。实现安全加固的方式有多种，例如适当配置系统、安装最新版本的软件（或固件）或禁用不必要的配置。根据需求，组织采用不同的安全基准方法和标准。互联网安全中心（CIS）是一个提供必要企业标准基准和 CIS 控制的知名机构 (www.cisecurity.org/about-us)。

登录并免费下载操作系统或平台的基准文档，如下图所示：

图 14.11 – Kubernetes 的 CIS 基准下载页面

根据这些基准来配置系统并不容易，因为必须执行数百条规则和配置项以确保系统安全。组织采用不同的方法来实现这些配置，例如 shell 脚本、PowerShell 脚本和 Ansible 自动化。由于 Ansible playbooks 的灵活性和模块化特性，它们比其他方法更高效且更易于维护。

可以通过 Ansible 或自动化控制器（定时任务）频繁执行 CIS 硬化剧本，以确保系统具有良好的安全状态。然而，这种方法无法及时检测和修复威胁及事件。

如您在上一节中所学，也可以利用安全工具和解决方案的强大功能，并将其与 Ansible 集成，以自动化各种安全操作，具体如下：

安全信息与事件管理 (SIEM)
入侵检测与防御系统 (IDPS) 任务
特权访问管理 (PAM) 操作
端点保护平台 (EPP) 任务
防火墙操作

以下图示展示了一个典型的威胁检测与自动化工作流：

图 14.12 – 威胁检测与自动化修复

通过使用现有的安全解决方案，可以将检测和响应的开销从 Ansible 中卸载，但仍然可以利用 Ansible 的强大功能来修复安全问题。

Ansible 拥有大量的社区模块和集合，可以支持安全设备和解决方案的自动化，具体如下：

Cisco ASA
FortiGate
Palo Alto
F5
CheckPoint
CyberArk
Trend Micro

Ansible 安全自动化集合

请参考 Ansible 集合索引 (docs.ansible.com/ansible/latest/collections/index.xhtml) 查找与安全相关的集合。同时，查看 Red Hat Ansible 自动化平台的安全自动化 (access.redhat.com/articles/4001711) 以了解该平台的兼容性矩阵。最后，请阅读博客文章 使用 Ansible 安全自动化入门：调查丰富 (www.ansible.com/blog/getting-started-with-ansible-security-automation-investigation-enrichment) 以了解 Ansible 安全自动化及与 AAP 的集成。

自动化 IP 地址封锁的过程可见于以下图示：

图 14.13 – 自动化 IP 地址封锁

借助 Ansible 模块，大多数与安全相关的操作可以高效自动化。

例如，添加 cisco.asa.asa_acls 模块，如下图所示：

图 14.14 – 向 Cisco ASA 设备添加访问控制规则

以下截图显示了一个简单的 Ansible 任务，使用 fortinet.fortios.fortios_firewall_address 模块来封锁 FortiGate 设备中的 IP 地址：

图 14.15 – 在 FortiGate 设备中屏蔽 IP 地址

同样，以下截图展示了如何使用 paloaltonetworks.panos.panos_security_rule 模块向 Palo Alto 设备添加安全规则：

图 14.16 – 向 Palo Alto 设备添加安全规则

请参阅进一步阅读部分，获取有关 Ansible 中安全自动化模块的更多资源。

在下一节中，你将学习自动化控制器中的工作流模板。

Ansible 工作流模板

在单个 playbook 中可以创建任意数量的任务，并将其变成一个长工作流。例如，一个 Linux 操作系统作业模板可以包含以下任务：

在开始打补丁之前创建虚拟机快照。
保存配置文件备份。
停止系统中的服务。
执行各种 Linux 操作系统补丁任务。
重启系统。
等待系统启动并启动必要的服务。
如果虚拟机重启不成功，在同一作业中处理虚拟机快照恢复操作。

请注意，大多数任务可以作为单独的作业重用，例如创建快照、停止服务或配置备份。

不要开发冗长、复杂的作业模板，利用自动化控制器中的工作流模板创建模块化的作业工作流，并根据成功/失败状态处理任务。工作流模板是通过将多个作业模板拼接在一起创建的，以实现更大或更复杂的工作流。

以下图表展示了 Ansible 自动化控制器中作业模板和工作流模板之间的高层次区别。

图 14.17 – 作业模板与工作流模板

以下截图展示了一个简单的 Linux 操作系统补丁工作流模板。在这里，我们有多个任务，如下：

在打补丁前创建快照作业。
创建一个作业模板，停止系统中的重要和依赖服务。
执行操作系统补丁任务。
重启。
如果重启成功，所有必需的服务将启动。
如果重启失败，将执行恢复快照的作业模板：

图 14.18 – 操作系统补丁的工作流模板

这种模块化的方法通过重用作业模板帮助你实现复杂的自动化工作流。以下截图展示了一个类似的工作流，其中操作系统特定的作业模板已被替换，其他作业模板正在被重用：

图 14.19 – Windows 补丁工作流

Ansible 工作流作业模板

请参阅 docs.ansible.com/automation-controller/4.1.2/html/userguide/workflow_templates.xhtml 了解更多关于工作流模板的功能，如 webhook 和集成选项。

总结

在这一章中，你了解了简化 Ansible 自动化的重要性。你探索了自动化控制器中调查功能的优势和软编码机会，以动态接受参数。这种方法帮助你复用相同的 playbook 和作业模板，适用于不同的设备和场景。

然后，你了解了 Ansible 与其他监控和告警工具之间的集成选项，以实现零接触事件修复。可以利用现有的 ITSM 工具和工作流，根据规则和条件触发 Ansible 自动化控制器作业。通过利用监控工具的强大功能和 Ansible 的自动化能力，可以实现高效的监控和修复系统。

之后，你探索了在安全领域内进行集成的机会，以实现威胁检测和自动修复的自动化，利用自动化控制器。Ansible 自动化的安全模块和集合帮助你实施复杂且增强的安全自动化解决方案。

最后，你学习了自动化控制器中的工作流模板、创建工作流的模块化方法，以及复用作业模板的优势。

在下一章中，你将学习如何使用 Ansible 自动化非标准和不支持的平台。你还将探索一些有用的模块以及 Ansible 自定义模块创建的基础知识。

进一步阅读

要了解更多本章所涵盖的主题，请查看以下资源：

Ansible 安全自动化： www.ansible.com/use-cases/security-automation
Ansible 关于安全自动化的博客： www.ansible.com/blog/topic/security-automation
使用 Ansible 的安全性与合规性： www.ansible.com/use-cases/security-and-compliance
Ansible 集合： docs.ansible.com/ansible/latest/collections/index.xhtml#list-of-collections
Ansible 自动化控制器中的应用程序： docs.ansible.com/automation-controller/latest/html/userguide/applications_auth.xhtml
Ansible 网络自动化： docs.ansible.com/ansible/latest/network/index.xhtml

第十五章：自动化非标准平台和操作

到目前为止，您已经了解了不同的系统和平台（管理节点），例如 Linux 系统、Microsoft Windows 系统、网络设备和云平台，这些都可以通过 Ansible 进行自动化。您已经使用了不同的方法和协议来连接目标系统或平台，执行自动化操作。您无需了解这些系统内部如何运行复杂操作，因为 Ansible 会理解并对目标系统采取适当的行动，以达到所需的状态。

如果没有标准的 Ansible 模块或连接方法可用于管理节点上的特定操作怎么办？或者，如果模块缺少您需要的某个功能呢？例如，假设您想要自动化一台没有安装支持的 Python 版本的机器，并且您想使用 Ansible 来自动化 Python 安装，或在没有合适模块的防火墙设备上运行原始命令。

由于 Ansible 灵活且模块化，您有多种方式来克服这些挑战。在本章中，您将学习如何使用 Ansible 自动化这些非标准操作。

在本章中，我们将覆盖以下主题：

执行低级原始命令
使用原始命令进行网络操作
使用 API 调用进行自动化
为 Ansible 创建自定义模块

我们将从 Ansible 的raw模块开始，并探讨raw模块帮助自动化非标准用例的救命场景。然后，您将学习如何在 Ansible 模块或基于 SSH 的连接不可用时，使用 API 调用来自动化操作。您还将探索自定义 Ansible 模块，以及如何使用 Python 开发简单的自定义模块。

技术要求

您需要以下技术要求来完成本章内容：

用于 Ansible 控制节点的 Linux 机器
网络设备命令的基础知识（例如，FortiOS 和 Cisco ASA）
REST API 端点及其用法的基础知识
Bash 脚本编写和 Python 编程语言的基础知识

本章的所有 Ansible 工件、命令和代码片段都可以在本书的 GitHub 仓库中找到，地址为 github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-15。

执行低级原始命令

到目前为止，你已经了解了不同的 Ansible 模块和集合，用于开发自动化内容。大多数这些模块要求在目标节点上有支持的 Python 版本（或 Microsoft Windows 的 PowerShell）来执行后端的自动化脚本（有关更多详细信息，请参考 Ansible 的管理节点要求文档：docs.ansible.com/ansible/latest/installation_guide/intro_installation.xhtml#managed-node-requirements）。当没有所需的 Python 版本或软件包时，你需要手动安装它（或使用某些脚本）到每个节点，才能让 Ansible 在这些节点上自动化任务。当多个管理节点需要加入到 Ansible 时，逐一登录每个节点并手动安装这些依赖项将是一项繁琐的任务。在这种情况下，可以执行原始命令（如你在 bash 脚本或 PowerShell 脚本中使用的命令）来安装和配置系统，具体如下：

sudo yum install python36

在使用低级原始命令之前，请注意以下几点：

低级原始命令与在系统中手动处理操作时使用的命令相同。
这些低级原始命令不会通过 Ansible 模块系统，而是通过配置的远程 shell 执行。
你必须假设命令的输出、成功和错误条件。

通过执行低级原始命令，可以通过 Ansible 自动化这些操作，使用 ansible.builtin.raw 模块。

Ansible 网络自动化的区别

我们无法在网络设备上安装 Python。正因如此，网络自动化在后端是不同的。请参阅 第六章，自动化 Microsoft Windows 和网络设备，了解更多信息。

ansible.builtin.raw 模块有助于在目标节点上通过 SSH 连接执行原始命令。由于命令的结果不可预测，因此在目标节点上使用原始命令并不是最佳实践；因此，Ansible 将无法像其他标准模块一样处理验证和错误。然而，ansible.builtin.raw 模块在一些特殊情况下是有用的，正如你将在接下来的章节中学习到的那样。

使用 raw 模块安装 Python

正如我在本章介绍中提到的，如果你的管理节点没有安装 Python，而你又想使用 Ansible 自动化 Python 安装该怎么办呢？让我们来学习如何创建一个 Playbook，使用 Ansible 安装 Python。

我们假设所需的包仓库已经按照标准系统配置在目标节点上进行了配置。

以下截图显示了用于安装和验证 Python 版本的示例 Playbook：

图 15.1 – 使用原始模块安装并验证 Python 的 Playbook

请注意前面截图中的gather_facts: false行；这是一个依赖于 Python 的收集事实任务。否则，playbook 将无法正常工作。

Playbook 的安装输出可以在以下截图中看到：

图 15.2 – Python 安装 Playbook 的输出

一旦您在目标节点上安装了 Python，可以像往常一样使用任何其他 Ansible 模块。ansible.builtin.raw模块还支持 Windows、网络和防火墙设备，用于执行底层原始命令。

Ansible 原始模块

原始模块是ansible-core的一部分，并且在您的安装中默认包含。请参考文档 docs.ansible.com/ansible/latest/collections/ansible/builtin/raw_module.xhtml 了解更多信息。如前所述，raw模块仅在特殊情况下使用；否则，请使用ansible.builtin.shell或ansible.builtin.command模块来执行 Shell 命令（对于 Windows 机器，可以查看替代的ansible.windows.win_command和ansible.windows.win_shell模块）。

在下一节中，您将学习如何在没有适当模块可用的情况下，使用ansible.builtin.raw模块进行网络自动化。

使用原始命令进行网络操作

Ansible 拥有大量的模块和插件，支持大多数知名的网络和防火墙设备。下图显示了支持的部分网络设备和品牌，用于网络自动化：

图 15.3 – 支持的品牌用于 Ansible 网络自动化（来源：https://www.ansible.com/integrations/networks）

然而，也会有一些情况，您必须克服以下挑战：

没有支持的 Ansible 模块可用于执行特定的网络或防火墙操作。
有一个可用的模块进行操作，但您所寻找的特定功能或参数在当前模块版本中不存在。
与设备上的 CLI 命令相比，支持的模块使用的是一种较慢的方法。

Ansible 集合索引中的网络集合

请参考文档页面 docs.ansible.com/ansible/latest/collections/index.xhtml 查看 Ansible 集合索引中的网络集合。

为了克服这种情况，请使用相同的ansible.builtin.raw模块，并通过 SSH 连接在目标网络设备上执行原始命令。

在下一部分中，您将学习如何使用 ansible.builtin.raw 模块在 FortiOS 和 Cisco 设备中执行必要的操作，例如进行配置备份、升级软件等。

备份 FortiOS 配置

fortinet.fortios Ansible 集合包含超过 600 个用于管理和操作带有 FortiOS 的设备或设备的模块。我们来看看一个简单的操作，例如从 FortiOS 设备进行配置备份。

下图显示了 FortiOS 设备连接的清单变量：

图 15.4 – FortiOS 连接的清单变量

我们可以使用 fortinet.fortios.fortios_monitor_fact 来收集并将备份保存到系统中，如此处所示：

图 15.5 – 使用 fortios_monitor_fact 模块备份 FortiOS

Ansible fortinet.fortios 集合

在 galaxy.ansible.com/fortinet/fortios 上找到 fortinet.fortios Ansible 集合中的模块和插件容器。

然而，配置备份需要通过 Ansible 中的另一个任务安全地传输到文件服务器（例如 TFTP 服务器）。一些组织可能希望遵循标准和传统的备份方式，这种方式是从设备本身进行备份，而不是复制到 Ansible 控制节点（或自动化控制器）。在这种情况下，使用 raw 模块执行原始命令，如此处所示：

图 15.6 – 使用原始命令备份 FortiOS

在前面的例子中，我们使用了原始 CLI 命令将配置直接复制到 TFTP 服务器。

记得修改清单变量，使用默认的 SSH 连接，而不是 ansible.netcommon.httpapi：

图 15.7 – 没有 httpapi 的 FortiOS 连接清单变量

Ansible 将使用默认的 SSH 连接，并在目标 FortiOS 设备上执行原始命令。

FortiOS 软件升级

让我们来看另一个 FortiOS 软件升级或修补的例子。我们有一个名为 fortios_system_federated_upgrade 的模块来按照标准的 Ansible 方式执行此任务。然而，这个模块需要将新的软件镜像从本地主机（即 Ansible 控制节点或 Ansible 执行环境）上传，因此首先，您需要将这个镜像从某个位置复制到本地主机。此外，如果网络有限制，无法复制较大的镜像文件（如固件文件），那么唯一的选择就是在 FortiOS 设备内部执行传统的原始命令，如下图所示：

图 15.8 – 使用 raw 模块运行 FortiOS 软件升级

execute restore image命令将要求你确认镜像升级；第二行的Y是对该确认问题的输入。

fortios_system_federated_upgrade模块将处理所有此类确认和程序化升级。请记住，raw 命令方法应仅在特殊情况下使用。

Cisco 设备上的 raw 命令

同样，也可以在任何支持 SSH 连接的设备上使用 raw 命令。让我们来看另一个关于 Cisco ASA 设备备份的例子。

cisco.asa.asa_config模块是cisco.asa Ansible 集合的一部分（galaxy.ansible.com/cisco/asa）。使用该模块可以按照标准 Ansible 方式配置 Cisco ASA 设备并进行配置备份。备份将下载到你的localmachine（Ansible 控制节点或 Ansible 执行环境），因此需要将其传输到目标文件服务器（例如，TFTP 服务器）。备份可能包含敏感信息，因此组织可能更愿意直接将备份复制到 TFTP 服务器（或其他支持的目标文件服务器）。

在这种情况下，使用相同的ansible.builtin.raw模块在目标 Cisco 设备上执行 Cisco ASA 命令。但在使用ansible.builtin.raw模块之前，你需要检查相应的 Ansible 集合（例如，这里的cisco.asa集合），以查看是否有任何模块可以以 Ansible 的方式执行原始网络命令。在这种情况下，可以使用cisco.asa.asa_command模块来执行 Cisco ASA 的原始命令，如下所示：

图 15.9 – 使用 raw 命令进行 Cisco ASA 备份

同样，你可以在 Cisco IOS 和 Cisco Nexus OS 设备上分别使用cisco.ios.ios_command和cisco.nxos.nxos_command模块。如果没有特定设备的模块来执行原始命令，那么请使用ansible.builtin.raw，正如你之前所学的那样。

raw 模块可以用于任何支持 SSH 和命令行执行的设备。但对于不支持 SSH 连接的设备或没有此类命令的设备，可以使用 API 调用。在下一节中，你将学习如何使用 API 调用从 Ansible 自动化操作。

使用 API 调用进行自动化

在 第六章，自动化 Microsoft Windows 和网络设备 中，你学习了 Ansible 与受管节点、平台或应用程序进行通信的不同方式。所以，只要有受支持的方法可以访问目标系统，就可以使用 Ansible 自动化这些任务。在前几章中，你学习了 Ansible 与 Jira、ServiceNow、Kubernetes、公共或私有云平台等工具的集成。对于这些平台，大多数模块使用 HTTP/HTTPS API 调用来执行操作。这意味着，如果没有可用的模块来自动化操作，但有 API 方法，你可以在 Ansible 剧本中直接使用这些原始 API 调用。

Python SDK 和 API 调用

请记住，并非所有模块都使用直接或原生的 API 调用来执行操作；一些模块使用 Python 库和 fortiosapi Python 库，但现在，httpapi 是执行剧本的首选方式。阅读更多关于 httpapi 插件的信息，访问 https://docs.ansible.com/ansible/latest/plugins/httpapi.xhtml。

例如，amazon.aws.ec2_instance_info 模块（Ansible amazon.aws 集合的一部分）有助于收集 AWS 中 EC2 实例的信息。它的使用方法很简单，如下图所示，你无需担心复杂的 AWS EC2 端点 API 调用：

图 15.10 – 使用 amazon.aws.ec2_instance_info 模块收集 AWS EC2 信息

假设你有一个需求，需要收集一些模块输出中没有的附加要求。在这种情况下，也可以使用 AWS EC2 API 端点（docs.aws.amazon.com/AWSEC2/latest/APIReference/Welcome.xhtml）来利用 API 调用的全部功能。

在接下来的章节中，你将学习如何从 Ansible 使用 API 调用来自动化平台或应用程序。

使用 Ansible 自动化 ToDo 应用程序

在本节中，你将使用提供的 API 自动化一个简单的 ToDo 应用程序。这个示范将帮助你了解如何使用 Ansible 发起 API 调用，并如何适当处理 API 调用的输出。本节将帮助你了解如何处理任何其他服务（例如云服务、网络设备、软件应用程序等）的 API 调用，方法是遵循产品的 API 文档。

介绍 Ansible 的 uri 模块

ansible.builtin.uri模块用于与 HTTP 和 HTTPS 端点进行交互，并使用 Ansible 实现与 Web 相关的操作。ansible.builtin.uri模块支持多种身份验证机制，如 Digest、Basic 和 WSSE HTTP（docs.ansible.com/ansible/latest/collections/ansible/builtin/uri_module.xhtml）。ansible.builtin.uri模块可以用于多种用例，如下所示：

调用 AWS API 服务以获取 EC2 实例详细信息
调用 Jira API 以更新票据
从 Web 服务器获取详细信息
验证 Web 服务健康检查

现在，让我们学习如何使用ansible.builtin.uri模块与 ToDo 应用程序的 API 进行交互。

假设你有一个正在运行的 ToDo 应用程序，API 可以通过todo-app.example.com:8081/api进行访问，并且不需要身份验证。使用默认的curl命令测试 API，如下所示：

图 15.11 – 测试 ToDo API 的访问

让我们使用 Ansible 和ansible.builtin.uri模块（docs.ansible.com/ansible/latest/collections/ansible/builtin/uri_module.xhtml）来处理 ToDo 应用程序。

这里是你有的Chapter-15/todo-app.yaml（请参阅 GitHub 仓库），其内容如下：

图 15.12 – ToDo 应用程序 playbook 详细信息

在上面的截图中，我们可以看到以下内容：

hosts: localhost：这是因为我们是从本地主机运行此 API 调用。
gather_facts: false：这是因为我们不需要来自localhost的任何事实（如果需要使用 Ansible 事实，请启用此选项）。
become: false：这是因为 API 调用不需要特权访问。

method参数使用GET作为uri模块的默认值。由于我们是从 URL 获取数据，因此在以下示例中将使用默认的 GET HTTP 方法。第一个任务是获取 API 的健康状态，然后使用调试模块打印输出，如下截图所示：

图 15.13 – API 健康检查任务

status_code: 200参数有助于验证 API 调用和任务的成功，因为你期望OK 成功状态；你不需要添加额外的验证任务。如果状态码不是200，任务将失败。

以下截图显示了执行 playbook 时的示例输出：

图 15.14 – API 健康检查示例输出

如果您只需要 API 调用返回的内容（结果），则通过将 msg 参数设置为 msg: “{{ health_status.content }}” 来修改 msg。这样，您将获得更准确的结果，如下所示：

图 15.15 – API 调用返回的内容

uri 调用将返回详细的 JSON 输出。根据需要筛选出内容。

HTTP 请求方法

根据 API 或 Web 端点，可能会提供不同的 HTTP 方法，例如 GET、POST、PUT 或 DELETE。请参阅 www.w3schools.com/tags/ref_httpmethods.asp 了解更多有关 HTTP 方法的信息。

下一步是获取 ToDo 列表中的项目，如下所示：

图 15.16 – 使用 API 获取 ToDo 应用中的项目

执行剧本时，您将获得如下所示的 ToDo 项目列表：

图 15.17 – 使用 API 调用获取的 ToDo 项目

通过筛选 JSON 输出，可以处理单独的项目。这样，您就可以根据需要检索精确的内容。

对于创建或更新新项目，使用 POST HTTP 方法，并根据需要附带内容和其他细节。让我们通过使用 POST 方法和 body 内容将新项目添加到 ToDo 列表。第一步是准备要发布的数据。在这种情况下，您有一个名为 new_item 的字典变量，其中包含项目详情，如下图所示：

图 15.18 – 新 ToDo 项目的变量

向 ToDo 列表 POST 内容的任务需要更多的参数，如下所示：

图 15.19 – 通过 API 调用向 ToDo 应用添加新任务

在上面的截图中，我们可以看到以下内容：

status_code: 201 - 201 是 created 的状态码。如果您未提及 status_code，Ansible 将使用默认值 200，并且任务将显示为失败（例如，"msg": "Status code was 201 and not [200]: OK (unknown bytes)"）。
body_format: json：默认值是 raw。这是您传递 JSON 格式输入的地方。

以下截图显示了执行剧本时任务的示例输出：

图 15.20 – 任务输出

这个简单的演示解释了使用 Ansible 与 API 端点交互的不同方式。根据您要管理的 API 端点，您可以探索更多的自动化用例和工作流。

一些 API 调用可能需要您准备复杂的 body 内容，在这种情况下，可以使用 Ansible Jinja2 模板；这将在下一部分中介绍。

Ansible uri 模块与 REST APIs

uri模块是一个多功能模块，提供了大多数 API 操作所需的参数，包括凭证、证书、代理配置等。查看模块文档，了解更多信息：docs.ansible.com/ansible/latest/collections/ansible/builtin/uri_module.xhtml。

与 Akamai API 交互

假设你有一个场景，需要自动化像 Akamai 这样的 DNS 管理设备，但没有支持的 Ansible 模块。幸运的是，Akamai 设备提供了一个简单的 API 端点，用于管理 DNS 条目。可以在 Ansible 中使用该端点来自动化所需的操作。

API 需要以复杂的主体格式输入。为此，可以使用一个名为akamai-url-block-format.j2的 Jinja2 模板，如下所示：

图 15.21 – 用于准备 Akamai API 调用主体的 Jinja2 模板

akamai-dns-block.yaml剧本包含一些变量，如下截图所示：

图 15.22 – 用于 Akamai DNS 屏蔽的变量

记住，要使用 Ansible Vault（或凭证在 Ansible 自动化控制器中）以加密格式保存敏感项目（如凭证）。

dns_list（DNS 条目列表）可以通过template查找插件转换为所需格式，并传递给uri模块（body: “{{ dns_list_templated }}”），如下所示：

图 15.23 – 使用 uri 模块的 Akamai API 调用

在执行 API POST 调用之前，你需要添加所有必需的验证和核实任务。参考 Akamai 文档（techdocs.akamai.com/home/page/products-tools-a-z）了解更多关于产品的信息。

在本节中，你学习了如何使用原始命令和 API 调用自动化不支持的操作。在下一节中，你将探索 Ansible 模块以及为 Ansible 创建自定义模块的基本步骤。

为 Ansible 创建自定义模块

在前面的章节中，你学习了如何在标准模块不可用的情况下自动化操作。模块是实现自动化的标准方式，帮助你编写 Ansible 剧本，而无需担心后台复杂的操作。如果你了解后台操作以及如何执行任务，可以为 Ansible 创建一个模块来执行特定操作。最后，通过 Ansible collections 将其贡献回社区。这就是开源社区成长的方式。

创建自定义 Ansible 模块前需要检查的事实

你可以使用任何编程语言（可以通过 Ansible API、ansible 命令或 ansible-playbook 命令调用的语言）、库和方法来开发你的新 Ansible 模块。你现在使用的大多数 Ansible 模块都是用 Python 编程语言编写的。在开发新模块之前，请确认以下事项：

如果可以使用 Ansible 角色完成特定任务，则应开发角色，而不是 Ansible 模块。
如果实际执行发生在控制节点（而不是管理节点）上，则应创建一个动作插件而不是模块（阅读 开发插件，详见 docs.ansible.com/ansible/latest/dev_guide/developing_plugins.xhtml）。
如果有类似的模块可用，则可以修改该模块，增加新功能，并将其贡献回社区。
如果你计划开发的模块依赖项较多，请尝试将其作为 Ansible 集合进行开发，并包含所有必要的依赖项、自定义库和插件。

你应该开发 Ansible 模块吗？

请参考 Ansible 文档 docs.ansible.com/ansible/latest/dev_guide/developing_modules.xhtml 了解更多信息。

如果你没有使用 Ansible 集合（或作为独立模块使用自定义模块），请确保模块脚本已被复制到正确的位置。以下是存放自定义模块的常见位置和方法：

在 Ansible 配置中使用 DEFAULT_MODULE_UTILS_PATH，并指定所有查找模块的目录。
将模块添加到用户目录：~/.ansible/plugins/modules/。
将模块添加到系统目录：/usr/share/ansible/plugins/modules/。
可以配置 ANSIBLE_LIBRARY 环境变量来设置自定义模块目录。

以下截图展示了 Ansible 配置的模块路径：

图 15.24 – Ansible 模块路径

如果该模块是为特定的 Ansible 角色使用的，则将模块存放在该角色的 library 目录中。Ansible 会自动检测该模块。
如果该模块被 playbook 和不同角色使用，则将其存放在项目目录的 library 目录中。以下截图展示了 ansible.cfg 中配置了 library 的示例：

图 15.25 – ansible.cfg 中的库路径

Ansible 模块目录配置

阅读 docs.ansible.com/ansible/latest/dev_guide/developing_locally.xhtml 中的文档，了解更多有关本地添加模块和插件的内容。

在下一节中，您将学习如何使用简单的 bash 脚本为 Ansible 模块，并通过基于 Python 的 Ansible 模块进行更深入的探索。

使用 bash 脚本开发 Ansible 模块

模块仅仅是用于执行特定任务的可重用脚本。在继续之前，您需要创建一个简单的 bash 脚本并将其用作 Ansible 模块。

library/customhello.sh是一个简单的 Bash 脚本，它显示操作系统、主机名和自定义消息，如下截图所示：

图 15.26 – 用于 Ansible 模块的 Bash 脚本

注意 echo 行，其中输出格式为 JSON。模块应提供一个定义的接口（也接受参数），并应通过将 JSON 字符串打印到stdout来返回结果或信息给 Ansible，然后再退出。

我们有一个 playbook，包含一个调用此自定义模块的任务，如下截图所示：

图 15.27 – 带有自定义 hello 模块任务的 Ansible playbook

当您执行此 playbook 时，bash 脚本将在后台执行，Ansible 会从脚本中获取信息，如下所示：

图 15.28 – 自定义模块的 Ansible playbook 输出

这是 Ansible 模块及其参数和变量的一个非常基础的概念。根据需要进行扩展。

开发 Ansible 模块

遵循最佳实践将帮助您创建高质量的 Ansible 模块，这些模块可以根据需要进行增强。请参考文档（docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.xhtml）和 Ansible 模块架构（docs.ansible.com/ansible/latest/dev_guide/developing_program_flow_modules.xhtml）以了解更多关于开发 Ansible 模块的内容。

在下一节中，您将通过遵循 Ansible 模块开发指南进一步了解自定义模块。

使用 Python 开发 Ansible 模块

创建模块时，请尽量遵循最佳实践，并通过添加适当的文档、示例或预期结果来提高模块的可重用性。

查看本书 GitHub 仓库中Chapter-15目录下的library/hello_message.py文件，并探索 Python 脚本中的标准模块组件：

脚本以ansible_python_interpreter开头，以便运行。
之后根据需要添加版权和其他联系方式。
DOCUMENTATION 块是模块中非常重要的一部分，它帮助用户了解该模块的使用方法，例如可用的参数、使用的选项、字段类型等。以下截图展示了我们自定义的 hello_message.py 模块的文档部分：

图 15.29 – 模块文档

EXAMPLES 块包含模块的示例用法：

图 15.30 – 模块的 EXAMPLE 部分

RETURN 块应包含模块执行成功后返回的示例输出或结果：

图 15.31 – 模块的 RETURN 块

最后是实际的脚本。这包含了所有必需的库和依赖，就像一个普通的 Python 脚本：

图 15.32 – Ansible 模块的脚本部分

模块格式与文档

遵循最佳实践将帮助使用该模块的人理解如何使用它。请访问 https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_documenting.xhtml#developing-modules-documenting 了解更多关于模块格式和文档的信息。

使用 ansible-doc 命令验证模块，如下所示：

图 15.33 – 使用 ansible-doc 命令后，自定义模块的详细信息

当使用键盘向下滚动时，你将看到模块文档中的 EXAMPLES 和 RETURN VALUES 部分，如下所示：

图 15.34 – 使用 ansible-doc 命令后，Ansible 自定义模块文档的详细信息

让我们在 hello-python.yaml playbook 中使用该模块，并传递 message 和 name 模块参数：

图 15.35 – 在 playbook 中使用 hello_message 模块

执行 playbook 并验证其输出，如下所示：

图 15.36 – 验证 playbook 执行情况及 hello_message 模块

检查本书 GitHub 仓库中的 Chapter-15 目录，了解更多关于 Ansible 自定义模块的信息。同时，请参考本章末尾的 进一步阅读 部分，获取更多关于 Ansible 自定义模块开发的资源。

使用 Ansible 集合并进行贡献

如前所述，将模块、角色和库作为 Ansible 集合存储和分发。这个集合可以通过 Ansible Galaxy (galaxy.ansible.com/) 公共发布，或者通过 Red Hat Ansible 私人自动化中心 (PAH) 内部发布。

在本节中，你将学习如何将集合导出到 Ansible Galaxy。

准备集合目录

以下截图显示了一个典型的 Ansible 集合目录结构：

图 15.37 – Ansible 集合目录结构

在我们的示例中，我们将进行各种调整，而不移动原始的 playbook 和模块目录。（这仅仅是为了演示目的；也可以将集合目录和文件保存在 GitHub 仓库的根目录中。）

类似于 ansible-galaxy role init 命令，使用 ansible-galaxy collection init 命令来初始化集合，包括基础目录和结构。在这个示例中，我们将手动创建集合及其子目录，以演示集合所需的目录结构和文件。这还将使我们能够重用现有的 playbook 和模块：

创建 collection 目录。
创建 collection/playbook 目录并将 playbook 复制到该目录。
创建 collection/plugins/modules 目录并将自定义模块复制到其中。
创建 collection/meta/runtime.yml。
创建 collection/galaxy.yml，如以下截图所示：

图 15.38 – Ansible 集合的 galaxy.yml 文件

创建 collection/README.md，并包含必要的文档和详细信息。添加/更新 .gitignore 文件（位于 GitHub 仓库根目录），并添加以下内容（用于在同步内容到 GitHub 服务器时忽略不需要的文件）：
```
*.tar.gz
test/results
```

一旦准备好集合的内容，你必须构建并将其发布到 Ansible Galaxy。下一节将详细介绍这一过程。

将 Ansible 集合发布到 Ansible Galaxy

通过 GUI 或 CLI 将集合发布到 Ansible Galaxy。按照以下步骤使用 CLI 发布集合：

将令牌导出到环境变量：

$ export ANSIBLE_GALAXY_TOKEN='YOUR_ANSIBLE_GALAXY_API_TOKEN'

使用 ansible-galaxy collection build 命令构建集合归档文件：

图 15.39 – 构建 Ansible 集合归档文件

使用 --force 来覆盖已有的集合归档文件，如果存在同版本的归档文件。

现在，使用 ansible-galaxy collection publish 命令将集合发布到 Ansible Galaxy：

图 15.40 – 将集合发布到 Ansible Galaxy

在 Ansible Galaxy 门户中验证发布的集合（galaxy.ansible.com/my-content/namespaces），如下所示的截图：

图 15.41 – 在 Ansible Galaxy 中发布的新集合

打开集合并查看其内容：

图 15.42 – Ansible 集合内容

在本节中，你创建了一个子目录（collection），用来存放集合内容并构建归档文件。如前所述，将集合内容保存在 GitHub 仓库的根目录中。请参考 github.com/ginigangadharan/ansible-collection-custom-modules 查看示例集合仓库。

总结

在本章中，你学习了如何使用 Ansible 自动化非支持和非标准操作，使用 Ansible raw 模块。你探讨了 raw 命令在服务器、网络设备、防火墙设备等上的执行。

然后，你学习了如何与提供 API 操作的设备进行交互。使用 Ansible uri 模块与一个待办应用进行交互；你探索了通过 API 获取和添加应用项目的选项。你还了解了设备的基于 API 的操作，并通过 Akamai DNS API 探索了一些示例用法。

除了 raw 命令和基于 API 的操作外，你还学习了 Ansible 自定义模块以及如何使用 bash 和 Python 创建自定义模块。最后，你将自定义模块作为 Ansible 内容集合分发到 Ansible Galaxy。

到此，你已经探索了一个常见的生产用例，可以使用 Ansible 作为完美的自动化工具，并将 Red Hat Ansible Automation Platform 作为企业自动化解决方案。

在下一章中，你将学习 Ansible 的最佳实践，例如存储 playbook 及其内容、组织清单、YAML 风格指南等。

进一步阅读

要了解本章涉及的主题，可以查看以下资源：

使用 Ansible 进行网络自动化: www.ansible.com/integrations/networks
开发 Ansible 模块: docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.xhtml
Ansible 模块最佳实践 – 约定、提示和陷阱: docs.ansible.com/ansible/latest/dev_guide/developing_modules_best_practices.xhtml
使用私有自动化中心（Ansible 博客）: www.ansible.com/blog/control-your-content-with-private-automation-hub

第十六章：适用于生产环境的 Ansible 自动化最佳实践

Ansible 可以用于自动化 IT 基础设施和 DevOps 任务。由于其灵活和模块化的架构，我们可以使用 Ansible 实现大型复杂的自动化用例。但同时，我们需要保持自动化工件和方法的简单性和可重用性。

本章中，你将学习实现高效自动化解决方案的关键和知名最佳实践。

首先，你将学习如何在 Ansible 项目中组织 playbooks、角色、集合和清单。之后，我们将讨论在清单中存储管理节点信息的最佳实践以及存储和维护多个清单的不同方法。你可以根据远程节点的功能、重要性或位置将其单独存储；这些细节将在接下来的章节中进行解释。

你还将学习在动态方法中存储变量的最有效方式，以及如何存储主机变量和组变量，以便适当地维护它们。

另一个在 Ansible 自动化中至关重要的组件是处理凭据，如用户名和密码、API 密钥以及机密信息。因此，你将探索 Ansible 凭据管理的最佳实践，例如如何为 Ansible playbook 存储敏感数据。

最后，你将学习开发和执行 Ansible playbook 的最佳实践、方法和优化技巧。

本章将覆盖以下主题：

组织 Ansible 自动化内容
存储远程主机信息 – 清单最佳实践
Ansible 主机变量和组变量
Ansible 凭据最佳实践
Ansible playbook 最佳实践

本章将从介绍各种 Ansible 内容组织方法和不同的清单组织方法开始。

技术要求

完成本章内容，你需要以下技术要求：

一台用于 Ansible 控制节点的 Linux 机器。
一台或多台配置了 Red Hat 仓库的 Linux 机器作为管理节点（如果你使用的是非 RHEL 机器，请确保已配置适当的仓库以获取软件包和更新）。

本章所有的 Ansible 工件、Ansible playbooks、命令和片段可以在本书的 GitHub 仓库中找到，地址是 github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-16。

组织 Ansible 自动化内容

在 第四章，探索自动化开发中的协作，你学习了版本控制系统（VCS）和源代码管理（SCM），以及如何使用 GitHub 服务存储 Ansible 工件。

最佳实践是创建特定于项目的目录（即存储库），将所有相关项保存在一个位置，例如特定于项目的ansible.cfg文件、剧本、角色、集合或库。如果有外部角色或集合依赖项，请在requirements.yaml（或requirements.yml）文件中提及详细信息。

使用 Linux 中的tree命令递归列出目录和文件，并了解目录内容的结构。一个示例项目目录可以按如下方式组织：

图 16.1 – 典型的 Ansible 项目目录

您的角色将位于roles目录下，如下图所示：

图 16.2 – Ansible 角色目录

根据项目和使用案例，您可能会有更多或更少的目录和文件。我们将在下一节中探讨存储清单的最佳实践。

存储远程主机信息 – 清单最佳实践

在 Ansible 自动化中，托管节点或远程主机信息是关键数据，因为没有正确的主机详细信息，Ansible 将无法执行自动化任务。您在第一章中了解了 Ansible 清单及其基本细节，Ansible 自动化 – 介绍。在第四章中，您了解了将清单存储在 GitHub 存储库中的重要性，以便进行版本控制和更好的管理。如果您的托管节点托管在云平台中，那么使用 Ansible 动态清单是最佳实践，正如您在第五章中学习的那样，扩展您的自动化视野。

使用有意义的主机名

在创建 Ansible 静态清单文件时，请使用有意义且用户友好的名称来表示托管节点，而不是复杂的完全限定域名（FQDNs）或 IP 地址。这将在执行 Ansible 剧本和故障排除时提供帮助。

例如，以下是一个通用的 Ansible 静态清单文件：

图 16.3 – 示例静态清单文件

相同的静态清单可以用用户友好的名称和ansible_host信息重写，如下图所示：

图 16.4 – 带有用户友好名称的 Ansible 清单

使用ansible_host意味着您不必依赖 DNS 名称（FQDN），可以通过 IP 地址访问托管节点。

这种做法不仅有助于您排除输出和日志中的故障，还能帮助您通过简单且有意义的名称管理清单。

如何构建您的清单

有关更多详情，请参考官方文档：docs.ansible.com/ansible/latest/user_guide/intro_inventory.xhtml。

在下一节中，你将学习如何根据生产、预发布和开发等环境来分离库存。

将生产、预发布和开发主机分开存储

你需要在项目级别或整体库存级别组织你的库存。如果你在多个 Ansible 项目中使用相同的管理节点（相同的节点但不同的自动化和用例），那么将库存存储在一个中央的 GitHub 仓库中作为单一的事实来源。这将帮助你更好地组织管理节点信息，以便用于不同的自动化 playbook。以下图示展示了库存存储在专用 GitHub 仓库中的场景：

图 16.5 – 存储在专用库中的 Ansible 库存

在以下示例中，我们为库存创建了一个单独的目录，并将生产、开发和预发布的管理节点分别放入不同的目录（参见本书 GitHub 仓库中的Chapter-16目录）：

图 16.6 – 基于环境组织的 Ansible 库存

执行 playbook 时，必须指定使用的库存文件，如下所示：

[ansible@ansible Chapter-16]$ ansible-playbook site.yml -i inventories/prod/host

库存还可以根据位置、重要性、服务器类型等进行分类。也可以通过在库存文件中使用主机组来进行相同的分类，如下图所示：

图 16.7 – 用于管理节点的主机组和组变量

使用ansible-inventory命令验证管理节点的分组，如下图所示：

图 16.8 – 使用 ansible-inventory 命令列出主机和主机组

在前面的示例中，我们在相同或不同的文件夹中创建了多个库存文件，并根据功能或位置对管理节点进行分组。在下一节中，你将学习如何分别使用group_vars和host_vars变量来维护主机特定和组特定的变量。

Ansible 主机变量和组变量

正如您之前学到的，像许多其他自动化工具一样，Ansible 允许您使用变量动态执行 Playbooks。可以配置相同的 Playbook，使其能够根据不同的期望状态通过变量和值执行。我们可以将变量保存在 Playbooks 内部、外部变量文件、库存文件和许多其他地方。您在第六章《自动化 Microsoft Windows 和网络设备》中学习了更多关于变量的内容。

相同的变量可以在多个位置指定，但根据变量的位置和变量优先级，Ansible 将应用适当的变量值。

Ansible 使用适当的变量值并根据它们执行 Playbooks；下图展示了 Ansible 如何将变量值与 Playbook 结合的典型流程：

图 16.9 – Ansible 结合 Playbooks 和变量进行最终执行

理解变量优先级

请参考docs.ansible.com/ansible/latest/user_guide/playbooks_variables.xhtml#understanding-variable-precedence以了解更多关于变量优先级的信息。

最佳实践是分别在host_vars和group_vars目录中使用特定于主机和特定于组的变量，如下图所示：

图 16.10 – Ansible 库存中的 host_vars 和 group_vars

现在，让我们来学习如何创建host_vars和group_vars。

Ansible group_vars

组的变量应在类似group_vars/INVENTORY_GROUP_NAME.yaml的文件或类似group_vars/INVENTORY_GROUP_NAME/VAR_FILE的子目录中提及。

例如：

group_vars/web.yaml
group_vars/web/vars.yaml
group_vars/web/credential.yaml

Ansible host_vars

主机的变量应在类似host_vars/INVENTORY_HOSTNAME的文件或类似host_vars/INVENTORY_HOSTNAME/VAR_FILE的子目录中提及。

例如：

host_vars/node1.yaml
host_vars/node1/vars.yaml
host_vars/node2.yaml

可以为同一托管节点创建多个变量文件，以便您可以分别管理相关的变量。

将您的机密变量保存在安全的位置

如果您的主机变量中包含凭据或机密信息，请将这些变量保存在单独的变量文件中，并使用 Ansible Vault 对其进行加密。以下是一些示例：

host_vars/node1/vars.yaml
host_vars/node1/credentials.yaml
group_vars/web/vault.yaml

也可以使用其他保管服务，如 HashiCorp Vault 或 CyberArk，来替代 Ansible Vault。请参考 第十三章，使用 Ansible 进行密钥管理，以了解有关 Ansible Vault 的更多信息。

管理 Ansible 中的 group_vars 和 host_vars

在此练习中，您将使用主机变量和组变量来控制多个 Web 服务器的值。请按照以下步骤操作：

在暂存清单目录（Chapter-16/inventories/stg）中创建一个 hosts 清单文件，内容如下（不用担心 node1、node2 或 node3，因为我们不会连接到这些机器）：

图 16.11 – 带有 web 组的 Ansible 清单

为了存储组变量和主机变量，创建 group_vars 和 host_vars 目录：

图 16.12 – 创建组变量和主机变量的目录

创建一个名为 inventories/stg/group_vars/web.yaml 的组变量文件，内容如下：

图 16.13 – 创建一个组变量文件

为 node1 配置不同的 web_server_port 值（8080）。创建一个名为 inventories/stg/host_vars/node1.yaml 的主机变量文件，内容如下：

图 16.14 – 创建主机变量文件

为 node2 配置不同的 web_server_port 值（8081）。然后，在 inventories/stg/host_vars/node2.yaml 中创建一个名为 node2 的主机变量文件，内容如下：

图 16.15 – 为 node2 创建主机变量文件

现在，所有变量文件已创建，您必须验证它们，如下图所示：

图 16.16 – 带有组变量和主机变量的项目目录结构

现在，使用 ansible-inventory 命令验证每个主机的变量值：

图 16.17 – 使用 ansible-inventory 命令验证清单和变量

现在，您必须验证并理解已分配的主机变量，如下所示：
- node1 已分配了 web_server_port: 8080，该值来自 host_vars/node1.yaml。
- node2 已分配了 web_server_port: 8081，该值来自 host_vars/node2.yaml。
- node3 已分配了 web_server_port: 80，该值来自 group_vars/web.yaml。

根据变量优先级，节点将为相同的变量获取不同的值，如下图所示：

图 16.18 – 目标节点上的 Ansible 组变量和主机变量

配置 host_vars 或 group_vars 中的主机特定变量非常重要，这样你就不会在 playbook 级别丢失重要的值。如果多个主机共享相同的变量和值，那么应在 group_vars 中进行配置。

在下一节中，你将学习如何在 Ansible 中存储凭据的最佳实践。

Ansible 凭据最佳实践

Ansible 支持多种凭据和认证方法，如用户名和密码、SSH 密钥、API 令牌、Webhooks，甚至可以创建自定义凭据。你应该使用一个简单的认证机制作为起点，但你需要考虑最佳实践，以确保安全性和防护措施到位。

避免使用默认的管理员用户帐户

工程师通常会将默认的管理员帐户配置为 Linux 中的 root 或 Microsoft Windows 中的 administrator 作为 remote_user。这不是最佳实践；你应该为 Ansible 创建专用帐户并为管理节点进行配置。

将环境和节点的登录凭据分开

在之前的示例中，你为 Ansible 创建了 Linux 和 Microsoft Windows 用户帐户，用于登录和执行任务。你可以为所有节点创建相同的用户帐户，但这不是必须的，也不推荐。你可以为不同的管理节点创建不同的用户帐户，因为你可以为每个管理节点或主机组指定 remote_user 或 ansible_user，如下面所示：

图 16.19 – 远程节点的不同用户帐户

在上面的库存输出中，可以看到不同的 ansible_user 实例已为不同的节点配置，例如 node1 使用 ansibleadmin，node2 使用 user1，node3 使用 devops 等。

避免使用明文密码

如果你使用基于密码的认证方式，则密码应加密并单独保存。请参考 第三章**的，使用 Ansible Vault 加密敏感数据 部分，了解更多关于 Ansible Vault 和秘密管理的内容。通过 Ansible Vault 加密后，密码文件将安全且无法被其他人读取，如下图所示：

图 16.20 – 使用 Ansible Vault 加密敏感文件

当你执行 playbook 时，也可以指示 Ansible 使用 --ask-pass 开关提示输入密码：

图 16.21 – Ansible Vault 密码提示

根据你组织的最佳实践和合规要求，为 Ansible 中的敏感数据处理添加更多的限制和最佳实践。

在下一部分中，你将学习一些 Ansible playbook 的最佳实践。

Ansible playbook 最佳实践

在编写 Ansible playbook 时，考虑到可读性和可重用性是很重要的。由于 YAML 格式是人类可读的，因此很容易为你的 Ansible playbook 制定并遵循一些样式指南。

在 第十五章，《使用原始命令进行网络操作》中，你学习了何时使用 raw 模块和命令。始终查看文档，看看是否有适合任务的模块。如果没有合适的模块，可以使用 command、shell、raw 和 script 模块。但请始终记住，command、shell、raw 和 script 模块不是幂等的，每次执行时都会报告为 changed。

始终为你的任务命名

即使name参数是可选的，最佳实践是为你的 plays、tasks、blocks 及其他组件提供适当且有意义的名称。参见图 16.22，其中可以看到为任务使用的示例名称。

使用适当的注释

在你的 playbook 中添加注释将帮助你在出现问题时进行故障排除。注释在需要进一步开发或增强时也非常有用，这样原作者和其他开发人员就能轻松理解 Ansible playbook 中需要的任务或步骤。

以下截图显示了在任务之前添加了注释：

图 16.22 – 带有注释、额外行和标签的 Ansible playbook

额外的行和空格

在 playbook 中添加空格和额外的行将增加其可读性。如前面截图所示，在每个任务后添加一个额外的行可以帮助你更容易地识别各个任务。

实现你自己的样式指南，并遵循 YAML 编写的最佳实践，以提高 Ansible 制品的可读性和可重用性。

为任务添加标签

当你拥有大型或复杂的 playbook 时，可能需要单独运行某些任务，而不是执行 playbook 和角色中的每个任务。可以通过使用--tags参数来实现，方法如下：

$ ansible-playbook site.yml --tags=pretasks

可以通过使用--skip-tags参数来跳过这些任务，方法如下：

$ ansible-playbook site.yml --skip-tags=email

请参考 Ansible 标签文档（docs.ansible.com/ansible/latest/user_guide/playbooks_tags.xhtml），了解更多关于 Ansible playbook 中标签的使用和方法。

使用显式声明

模块可能具有默认的参数值，如果我们在 playbook 中没有提到这些值，它们可能会自动应用。但在 playbook 中显式声明这些参数将帮助你明确任务的期望结果。例如，在 ansible.posix.firewalld 模块中，immediate 的默认值是 no，如文档中所示：docs.ansible.com/ansible/latest/collections/ansible/posix/firewalld_module.xhtml：

图 16.23 – firewalld 模块显示立即参数详情

保持原样，或在需要立即应用防火墙条目时显式声明为 immediate: yes。以下截图展示了一个示例 firewalld 任务：

图 16.24 – 带有显式声明的 firewalld 任务

始终在 Ansible playbook 中声明期望的结果，以便在出现问题时可以进行故障排除和修复。

使用本地 YAML 格式编写 playbook

可以使用任何可接受的 YAML 格式编写任务，只要 Ansible 能够读取并理解它。以下截图展示了在 Ansible playbook 中的一些示例任务：

图 16.25 – 非本地 YAML 格式的 Ansible 任务

相同的 playbook 可以用本地 YAML 编写，这样更整洁且更具可读性。可以在以下截图中看到：

图 16.26 – 使用本地 YAML 格式编写的 Ansible 任务

参阅 Ansible YAML 语法（docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.xhtml）和高级语法（docs.ansible.com/ansible/latest/user_guide/playbooks_advanced_syntax.xhtml）文档，了解更多有关 Ansible 的 YAML 知识。

避免硬编码变量和细节

以下截图展示了一个在 playbook 中提到（硬编码）目标节点和软件包详情的 play：

图 16.27 – 带有硬编码值的 Ansible playbook

如果你需要在其他目标节点上执行 playbook，那么你必须修改 playbook 文件并更新其值。相同的 playbook 可以这样编写：

图 16.28 – 带有动态变量的 Ansible playbook

现在，在执行 playbook 时传递变量，如下所示：

$ ansible-playbook site.yaml --extra-vars “nodes=webservers web_package=httpd”

通过避免硬编码，可以动态地使用相同的 playbook 针对不同的目标节点，使用不同的值。

在 Ansible playbook 中使用块

块是 Ansible playbook 中任务的逻辑分组，有助于处理执行过程中的错误。与其验证任务的成功率，不如在 playbook 中使用block，如下所示：

图 16.29 – 在 Ansible playbook 中使用块

如果 block 中的任何任务失败，Ansible 会执行 rescue 块中的任务。无论 block 和 rescue 任务成功或失败，always 块中的任务都会执行。

请参考块文档（docs.ansible.com/ansible/latest/user_guide/playbooks_blocks.xhtml），了解如何在 Ansible 中使用块。

使用角色和子任务

当你开发大型复杂的自动化用例时，应该将 playbook 拆分成小的子任务文件和角色。这样做有助于提高 Ansible 工件的模块化和灵活性，同时也有助于更轻松地排除故障：

图 16.30 – 一个 Ansible playbook 调用角色和子任务文件

上图展示了一个 Ansible playbook，它调用了 linux-patching 角色以及来自该角色的一些特定任务文件。

为变量使用有意义的名称

在前几章中，你学习了 Ansible 变量及其不同的用法。在你的 playbook 和角色中使用多个变量是可能的，因此为变量使用有意义的名称非常重要。下图展示了命名变量的好例子和坏例子：

图 16.31 – 使用简洁且有意义名称的 Ansible 变量

适当地命名变量有助于避免在 playbook 开发中重复使用变量名称和复杂性。

学习 playbook 优化

有多种方法可以优化 Ansible playbook 并加速其执行。以下是其中的一些方法：

使用并行执行。
根据需要使用适当的执行策略。
根据需要使用适当的 forks 值。
使用 serial 批量执行。
使用 order 根据清单控制执行顺序。
使用 throttle 处理高 CPU 密集型任务。

阅读 加速 Ansible playbook 的 8 种方法 (www.redhat.com/sysadmin/faster-ansible-playbook-execution) 和 让 Ansible 模块更快工作的 5 种方法 (www.redhat.com/sysadmin/faster-ansible-modules)，以了解更多关于 Ansible 优化技巧的内容。为了拓展你对 Ansible 最佳实践的学习，请参考官方的 Red Hat 课程 高级自动化：Red Hat Ansible 最佳实践 (www.redhat.com/en/services/training/do447-advanced-automation-ansible-best-practices)。

总结

在本章中，你学习了一些可以在 Ansible 开发工作流中实现的最佳实践。你探讨了组织 Ansible 工件（包括 playbook、角色、变量、清单和其他 Ansible 内容）的最佳实践。接着，你了解了根据受管理节点环境、重要性和其他因素分别存储清单的重要性。你还学习了如何使用主机变量和组变量来组织变量。

之后，你学习了关于在 Ansible 中存储和管理凭据的一些最佳实践，如避免使用明文密码和将密钥与常规变量文件分开存储。最后，你学习了改善 Ansible playbook 效率的不同最佳实践和优化技巧。请参考 进一步阅读 部分，了解更多关于 Ansible 最佳实践的内容。

恭喜你！通过本章内容，你已经完成了关于 Ansible 在实际使用案例中自动化的学习。

首先，你了解了 Ansible 并学习了如何安装和部署它。在此基础上，你学习了 Ansible 命令、模块和管理节点。之后，你学习了 Ansible playbook，并开发了基本的自动化用例，如收集系统信息、每周系统重启和系统报告生成。你还学习了版本控制系统的重要性，并练习了如何使用它们存储 Ansible 工件。

此后，你通过理解如何寻找 Ansible 自动化用例来扩展了学习内容。你学习了如何使用 Ansible 自动化 Microsoft Windows 和网络设备（如 VyOS 和 Cisco ASA）。你还学习了如何使用 Ansible 管理虚拟化平台、云平台（AWS、GCP 和 VMware）以及数据库操作。

后来，你学习了如何在 DevOps 实践和工作流中使用 Ansible，并通过 Ansible 进行容器管理。你还学习了如何通过在 Kubernetes 上部署和扩展应用程序来使用 Ansible 进行 Kubernetes 管理。为了扩展你的知识，你了解了 Ansible 自动化平台及其各种集成方法。之后，你学习了如何使用 Ansible Vault 管理敏感信息。

在最后几章中，你学习了如何使用原始命令、API 调用和模块来管理非标准平台和操作。你还学习了开发和存储 Ansible 工件的最佳实践。

在继续之前，记得加入 Ansible 社区、实时聊天群组和邮件列表。参考 Ansible 社区页面（www.ansible.com/community）以查找聚会活动的详细信息。如果你对本书的内容有任何问题或反馈，欢迎通过 LinkedIn 与我联系（www.linkedin.com/in/gineesh）。

如果你正在寻找官方的 Ansible 培训，查看来自 Red Hat 的课程（www.ansible.com/products/training-certification）。

如果在练习本书中的内容时遇到问题，请在书籍仓库中提出问题（github.com/PacktPublishing/Ansible-for-Real-life-Automation/issues）。

感谢你对本书的关注以及致力于完成本书的努力！

进一步阅读

要了解更多关于本章涵盖的主题，请查看以下资源：

重用 Ansible 工件（Include 和 Import）： docs.ansible.com/ansible/latest/user_guide/playbooks_reuse.xhtml#playbooks-reuse
Ansible 小技巧： docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.xhtml
Ansible 最佳实践（演示文稿归档）： aap2.demoredhat.com/decks/ansible_best_practices.pdf
伟大的 Ansible 用户的 10 个习惯： www.redhat.com/sysadmin/10-great-ansible-practices

posted @ 2025-07-02 17:45 绝不原创的飞龙阅读(24) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

Ansible-真实世界的自动化指南-全-

Ansible 真实世界的自动化指南（全）

前言

本书适合的人群

本书内容

为了充分利用本书

下载示例代码文件

下载彩色图片

使用的规范

联系我们

分享您的想法

第一部分：将 Ansible 作为您的自动化工具

第一章：Ansible 自动化 – 介绍

技术要求

你好，工程师们！

什么是 Ansible？我应该在哪里使用这个工具？

前提条件

Ansible 控制节点要求

Ansible 管理节点要求

Ansible 是无代理的

Ansible 架构

Ansible 库存

Ansible 插件

Ansible 模块

Ansible 内容集合

Ansible playbook

Ansible 用例

安装 Ansible

验证依赖关系

使用包管理器安装 Ansible

使用 Python pip 安装 Ansible

部署 Ansible

创建 Ansible 库存

配置你的管理节点

设置基于 SSH 密钥的认证

多个用户和凭据

Ansible 即时命令

使用 Ansible 安装软件包

概要

进一步阅读

第二章：从简单自动化开始

技术要求

识别需要自动化的手动任务

查找要使用的 Ansible 模块

配置你的文本编辑器以支持 Ansible

连接到远程节点

总结

进一步阅读

第三章：自动化您的日常工作

技术要求

使用 Ansible 收集服务器详细信息

Ansible 角色

角色目录结构

Ansible Jinja2 模板

收集系统信息

使用 Ansible 进行系统扫描和修复

Ansible --extra-vars

使用 Ansible 自动化每周系统重启

自动化通知

使用 Ansible Vault 加密敏感数据

总结

进一步阅读

第四章：探索自动化开发中的协作

技术要求

版本控制在 IT 自动化中的重要性

选择 Git 服务器

GitHub

GitLab

我应该将自动化工件存储在哪里？

Ansible 和 Git 仓库的最佳实践

Ansible 角色的仓库

Ansible 集合仓库

为团队创建专用仓库

为清单创建专用仓库

在 Git 服务器中管理自动化内容

设置 GitHub 账户

创建您的第一个 Git 仓库

在本地机器上安装 Git