Ansible Handlers

什么是 Ansible？

Ansible 是一个基本的开源 IT 引擎，可自动化应用程序部署、服务内协调、云配置以及许多其他 IT 工具。

Ansible 是一个允许我们创建和控制我们环境中三个关键区域的工具。

首先是 IT 自动化，因此我们可以编写指令来自动化我们以前通常手动执行的 IT 部署。

第二个是配置管理，并保持基础设施中所有系统的稳定配置。

最后，我们有自动化部署，因此我们需要扩展我们的环境；我们可以推送指令，这些指令可以自动部署到不同的服务器。基本上，我们需要加速并提高我们的运营团队的效率。

为什么选择 Ansible？

我们需要将 Ansible 视为我们 DevOps 环境中的另一个工具，以帮助管理职责，这些职责属于 DevOps 环境的运营方面。因此，如果我们看到这里，我们有一张系统管理员的图片。该人员负责维护其网络中所有不同服务器的基础设施，因此该人员可能需要维护的某些服务器可以是运行 Apache 的 Web 服务器或运行 MySql 的数据库服务器。

如果我们只有几台服务器，那么管理起来会相对容易，如果我们有三台 Web 服务器和两台数据库服务器。

Ansible-pull 配置工具

有多种方法可以为服务器场设置不同的环境。

一种方法是拥有一台主服务器，该服务器上保存所有指令，然后连接到该主服务器的所有服务器上，我们会安装一个名为客户端的软件，它会与主服务器通信，然后定期更新或更改从服务器的配置，这被称为拉式配置。

另一种是推送式配置，这有点不同。主要区别在于，与拉式配置一样，我们有一个主服务器，我们在其中设置指令，与我们在每个服务上安装了客户端的拉式配置不同。对于推送式配置，我们在远程服务器上没有安装客户端。我们只是将配置推送到这些服务器，并强制重新构建或在新环境中安装。因此，Ansible 是第二个条件之一，它是一个推送式配置服务器，这与 Chef 和 Puppet 等其他流行产品不同，后两者具有主从架构，主服务器连接到远程从服务器环境中的客户端，然后我们将推送更新，而使用 Ansible，我们正在将服务器的服务和结构推送到远程硬件。我们将其安装在硬件上，而与配置无关。

因此，Ansible 是上述第二个条件之一，它是一个推送式配置服务器，这与 Chef 和 Puppet 等其他流行产品不同，后两者具有主从架构，主服务器连接到远程从服务器环境中的客户端，然后我们将推送更新，而使用 Ansible，我们正在将服务器的服务和结构推送到远程硬件。我们将其安装在硬件上，而与配置无关。

Ansible 架构

在设置 Ansible 环境时，我们首先需要一台本地机器，我们将在其中拥有所有指令以及我们将推送到远程服务器的控制能力。因此，本地机器是我们开始并完成所有工作的地方；从本地机器连接的是不同的节点，推送我们将在本地机器上设置的各种配置。我们将编写的配置是代码中的或模块中的。因此，我们在本地机器上进行这些模块的创建，每个模块都是一个可重复使用的 playbook。

本地机器还有第二个工作：管理我们环境中节点的清单。本地机器可以通过 SSH 客户端连接到我们硬件网络中的每个节点。

Playbook

首先，我们研究 playbook，我们将为 ansible 环境编写和安装。因此，Ansible 的核心是 playbook；这是我们编写指令来定义硬件配置的地方。因此，playbook 是一组指令，用于配置我们的各种节点。每组指令都用一种称为 YAML 的语言编写，YAML 是一种用于配置服务器环境的标准语言。

Ansible 的工作原理

让我们来看看 Ansible 在现实世界中是如何工作的。在实际环境中，我们将在本地机器上安装 Ansible 软件，然后连接到我们网络中的不同节点。在本地机器上，我们将首先拿出 playbook，它是用于设置远程节点的指令集，然后确定我们将如何连接到这些节点。我们将有一个清单；我们使用安全 SSH 连接到每个服务器。因此，我们对到这些服务器的通信进行加密。我们可以获取每个服务器的一些基本事实，以了解如何将 playbook 推送到每个服务器并远程配置该服务器。最终目标是拥有一个一致的环境。

Ansible Tower

Ansible Tower 是 Red Hat 开发的一个附加产品，它为我们的冰淇淋锦上添花，或为我们的蛋糕增添了糖霜。

Ansible 是一个命令行工具，而 Tower 是一个用于访问 Ansible 的框架。通过 Ansible Tower 框架，我们现在拥有了一个易于使用的图形用户界面；这使得非开发人员能够轻松创建他们想要在其 DevOps 计划中管理的解决方案，而无需不断使用命令行提示窗口。与其打开终端或命令行窗口并仅用文本写出复杂的指令，不如现在可以使用拖放和鼠标点击操作来为我们的节点创建合适的 playbook、清单和推送。

Hootsuite 的用例

让我们来看看今天正在使用 Ansible 的一家特定公司，在这个例子中，我们将看看 Hootsuite。它是一个社交媒体管理系统。它们可以帮助我们管理跨所有流行社交媒体平台的社交媒体内容的推送，这些平台可以提供分析；它们可以提供营销和销售团队可以使用的工具来访问对正在推送的消息的情感分析。这是一个很棒且非常受欢迎的工具。但它们的可行性的一部分直接给 Hootsuite 带来了一个特定的问题。Hootsuite 面临的挑战是，他们必须不断地重新构建服务器环境，并且需要更持续、更一致地这样做。没有标准的文档，他们必须依靠记忆来一致地做到这一点。所以，Ansible 出现了，并帮助了 Hootsuite 的人们。如今，Hootsuite 的 DevOps 团队编写了具有特定指令的 playbook，这些指令定义了他们的硬件节点和环境的架构和结构。他们可以将其作为一个标准产品来完成。与其说扩展其环境是一个问题，不如现在可以在几秒钟内重建和创建新服务器。

底线是，Ansible 为 Hootsuite 提供了 IT 自动化和一致的配置，并从运营团队解放了时间，这样他们就可以提供额外的、对公司有价值的新功能，而不是管理服务器。

Ansible 的好处

让我们来看看 Ansible 带来的各种好处，它赋予了这种地位。

Ansible 是无代理、高效、灵活、简单、幂等且具有自动化报告功能。

1. 无代理：在我们的节点或客户端系统上无需安装支持软件或插件。因此，主控端拥有完全的控制权。
2. 自动化，这意味着 Ansible 更高效，因为现在我们的客户端和节点系统有更多空间用于其他资源，并且我们可以快速启动和运行 Ansible。
3. Ansible 也灵活，因此基础设施容易频繁变化，而 Ansible 可以迅速适应。
4. Ansible 只能变得更简单，因为我们的 playbook 是用 YAML 这样的语言编写的，它尽可能接近英语。
5. 幂等：这意味着如果我们要在一“n”个系统上运行一个 playbook，它会对所有这些系统产生相同的影响，而没有任何副作用。
6. 最后，我们有自动化报告，因此在 Ansible 的情况下，我们的 playbook 有多个任务，所有这些任务都有名称。因此，每当我们运行或执行我们的 playbook 时，它都会报告哪些任务成功运行，哪些任务失败，哪些客户端无法访问等等。所有这些信息在处理大型基础设施时都至关重要。

Ansible Handlers

Handler 与普通任务相同，但在另一个任务调用时运行。Handler 会在听到它正在监听的事件时执行。Handler 用于在任务更改托管主机时执行额外的操作，并且不应作为常规任务的替代品。

Handler 是仅在被通知时运行的任务。它们用于我们希望在机器上进行更改时才运行任务的情况。

Handler 始终按照 play 的 handler 部分指定的顺序运行，并且它们不会按照任务中 notify 语句的列出顺序或任务通知它们的顺序运行。Handler 通常在 play 中的所有其他任务完成后运行。由 playbook 的 tasks 部分中的任务调用的 Handler 不会运行，直到 tasks 下的所有任务都已处理完毕。Handler 名称存在于全局命名空间中；如果两个 Handler 被错误地赋予相同的名称，则只会运行一个。即使多个任务通知一个 Handler，该 Handler 也只运行一次。如果没有任何任务通知它，Handler 将不会运行。

如果带有通知语句的任务未报告更改结果，则不会通知 Handler。Handler 将被跳过，除非另一个任务通知它。

在 Ansible 中，Handler 通常用于启动、重新加载、重启和停止服务。如果我们的 playbook 涉及更改配置文件，我们可能需要重启服务才能使更改生效。在这种情况下，我们需要为该服务定义一个 Handler，并在任何需要该服务 Handler 的任务中包含 notify 指令。

处理 Handler 时还有其他一些注意事项

1. Handler 只有在任务通知 Handler 时才会运行；如果一个任务由于 when 条件或其他原因而被跳过，那么 Handler 将不会运行。
2. Handler 将只运行一次，并且在 play 结束时运行一次。如果您需要覆盖此行为并在 playbook 中间运行 Handler，您可以使用 meta 模块来实现（例如，meta: flush_handlers）。
3. 如果 play 在 Handler 被通知之前在一个特定主机（或所有主机）上失败，Handler 将永远不会运行。如果希望始终运行 Handler，即使在 playbook 失败后，您也可以使用上面描述的 meta 模块作为 playbook 中的单独任务，或者在运行 playbook 时使用命令行标志 --force-handlers。Handler 不会在 playbook 运行期间变得不可达的主机上运行。

处理程序（Handlers）

- name: 重启 Apache

service: name=apache2 state=restarted

tasks

- name: 启用 Apache 重写模块。

apache2_module: name=rewrite state=present

notify: restart Apache

在某些情况下，我们可能希望通知多个 Handler，甚至让 Handler 通知其他 Handler。使用 Ansible 可以轻松实现这两者。要从一个任务通知多个 Handler，请为 notify 选项使用列表

- name: 重建应用程序配置。

command: /opt/app/rebuild.sh

notify

- restart Apache

- restart memcached

在 Handler 上添加 notify 选项以使一个 Handler 通知另一个 Handler。Handler 是被 notify 选项调用的、经过美化的任务，但由于它们本身充当任务，因此它们可以将自己链接到其他 Handler

处理程序（Handlers）

- name: 重启 Apache

service: name=apache2 state=restarted

notify: restart memcached

- name: 重启 memcached

service: name=memcached state=restarted

Ansible Roles

1. Ansible Role 是一个处理概念而不是事件的概念。它是用于组织 playbook 的另一个抽象级别。
2. 它们为变量、任务、模板、文件和模块的独立且可重用的集合提供了骨架，这些集合可以自动加载到 playbook 中。

Role 是 Ansible 的一个核心概念，它们执行如此核心的功能，以至于它们甚至拥有自己的存储库和配套的命令行工具。Ansible Galaxy 是一个人们可以上传他们开发的 Role 以供他人使用的网站。

安装 Role 时，我们可以将其全局安装在我们的机器上，也可以本地安装到项目中。与任何依赖项一样，我们希望它在本地项目中使用，以防多个项目需要同一依赖项的不同版本。要下载 Role，我们调用 ansible-galaxy 命令，提供 -p（表示路径）标志，使其在名为 roles 的文件夹中安装 Role。我们应该在 playbook.yml 所在的同一个目录中运行 ansible-galaxy 命令。