什么是 Ansible Rulebook？

Ansible® Rulebook 是一组条件规则，事件驱动的 Ansible 使用这些规则在事件驱动型自动化模型中执行 IT 操作。借助 Rulebook，用户可以告知事件驱动的 Ansible 需监控哪个事件源的特定事件，以及在检测到该事件并满足特定条件的情况下，应执行哪些操作。

Rulebook 以人类可读的 YAML 语言编写，正如 Ansible Playbook 一样，但它使用“如果满足某个条件，就自动触发”（if-this-then-that）条件规则来定义事件何时应触发操作。事件驱动的 Ansible 会按照 Rulebook 的指示，监控目标事件源，识别事件发生的时间，并自动执行相应的操作。 

借助 Ansible Rulebook，IT 团队可以将他们希望做出的决策编写成代码，并设计在满足特定条件时要执行的任何操作，从而确保每次都以相同的方式执行操作。当条件满足时，Rulebook 还可以启动现有的 Ansible Playbook，从而进一步发挥团队长期构建和增强的可信赖 Playbook 的价值。 

通过将知识整理到 Rulebook 中，团队可以使用事件驱动的 Ansible 来最大限度地减少因员工疲于执行重复性任务而导致的错误，并构筑更加高效、一致的 IT 流程。

事件驱动的 Ansible 可提供所需的事件处理能力，能够自动化任何 IT 领域中耗时的任务，并根据不断变化的条件适用和调整。它可以处理包含有关 IT 环境条件中离散智能的事件，判断出最佳的应对措施，然后自动执行操作以解决或修复事件。事件驱动的 Ansible 可用于自动执行 IT 服务管理任务（例如工单增强、修复和用户管理），以及整个 IT 环境中的各种其他任务。

例如，假设您的可观测性工具（即事件源）正在监控网络路由器，它发现路由器没有响应，则将其识别为一个事件。事件驱动的 Ansible 将收到该事件，通过 Rulebook 的条件反馈事件数据，并将事件与您所需的操作相匹配，比如重新应用配置、重置路由器、创建服务工单或重新路由流量。按照 Rulebook 的指示，事件驱动的 Ansible 可以触发重置路由器的操作，使其恢复正常功能。这整个过程可以在任何时候进行，哪怕在凌晨 2 点，网络工程师还在休息时。

事件驱动 Ansible 之所以能如此灵活，Ansible Rulebook 功不可没，它可通过规则将事件源与相应的操作连接起来。

Ansible Rulebook 包含事件源和条件指令（即规则，指定在满足特定条件时要执行的操作）。一条规则包含一个条件和相应的操作。规则集是一组多个规则和操作。Rulebook 可以包括多个规则集。

Rulebook 设计灵活。它们可以：

• 监控一个或多个事件源。 
• 包含一条或多条规则。
• 触发一个或多个操作。 

事件驱动的 Ansible 可以灵活地搭配不同的事件源、规则和动作，因此用户可以设置在出现特定 IT 条件时要执行的任何操作。

Rulebook 的第一部分主要是定义要监控的一个或多个事件源。事件驱动的 Ansible 依靠智能事件源（如外部观测工具和应用）来识别事件并收集相关数据。事件源插件用于将事件驱动的 Ansible 连接到这些源，以监听事件。 

ansible.eda 红帽® Ansible 认证内容集包含了多个预先构建的事件源插件，可以帮助用户轻松上手使用事件驱动的 Ansible。不过，红帽也支持和鼓励合作伙伴和供应商提供根据自己的技术设计定制插件，以简化集成过程，并更轻松地从事件数据中获取更多价值。

Ansible.eda 认证内容插件

通过使用 the ansible.eda collection 中的事件源插件，用户可以快速开始处理事件。这些源插件使事件驱动的 Ansible 能够监听事件，然后根据 Rulebook 的条件逻辑处理这些事件，以确定应执行的操作。如果事件不符合 Rulebook 的条件，事件驱动的 Ansible 将不会触发任何操作，该事件将直接被略过。 

ansible.eda 集合中常见的源插件包括 Webhook、Kafka 和 Prometheus Alertmanager。这些插件可以处理来自多个系统和工具的通用 Webhook、消息队列以及 Prometheus 之类的企业级事件监控系统发出的警报。 

除了这些插件外，红帽合作伙伴还会提供更多针对其技术和解决方案定制的经认证事件源插件。这些插件可能包括事件驱动的 Ansible 的附加功能，以便更好地与这些合作伙伴的技术配合使用。用户还可以针对自制事件源自行构建源插件。

例如，假设您有一个网络交换机，并且只想知道某个端口何时宕机，那么合作伙伴可以创建一个插件，精确指定事件驱动的 Ansible 应该监听交换机上的哪些事件。使用该合作伙伴插件，您就不会全天候收到其他无关信息（有关交换机所发生的情况）。Webhook 之类的通用插件可能会提供发件人名称、URL 或其他与故障排除操作无关的数据等额外详细信息，而经认证的插件可能只提供设备主机名称、问题和事件编号，提高故障排除效率。

一旦源插件检测到事件并提供相关信息，事件驱动的 Ansible 便会通过 Rulebook 的条件规则过滤这些数据，以确定要采取的行动。规则可以灵活地设定 if-this-then-that 条件，定义当事件数据满足特定条件时应执行的步骤。 

例如，如果源插件正在监控网络路由器上的端口，则规则可能会规定：如果端口发生故障并且在 5 分钟内没有响应，则重新启动路由器。如果事件数据经过规则过滤后不符合条件，则不会采取任何操作。 

Rulebook 可以：

• 包含一条或多条规则。 
• 您可以设定一个条件、多个条件且所有条件都要匹配事件状态，或者多个条件且只需要满足其中一个。 
• 支持所有传统的数学运算符，如 =、≠、> 和 <。
• 支持整数、字符串、布尔值（如 and、or 和 not）、浮点数和空值条件数据类型。 

例如，如果您正在评估一个事件并试图匹配多个条件，可以使用布尔值 and，这意味着需要满足其中每个条件才会触发操作。
 

name: Combining ‘and’ operators
condition: event.version == "2.0" and event.name == "test" and event.alert_count > 10
action:
  debug:

如果要监控多个并试图匹配多个条件，则可以使用 all，这意味着需要满足每个条件，才会视为条件匹配。由于这些条件涉及多个事件，因此列于单独的行中。
 

name: Condition using both a fact and an event
condition:
  all:
    - fact.meta.hosts == "localhost"
    - event.target_os == "windows"
action:
  debug:

通过使用 any，如果满足任何条件，则视为条件匹配，并触发操作。正如与上面例子所示，这段代码需监控多个事件，因此条件分别列在不同的行中。
 

name: Any condition can match
condition:
  any:
    - event.target_os == "linux"
    - event.target_os == "windows"
action:
  debug:

注意：在上述示例中，debug 操作将打印事件信息，以便在事件驱动的 Ansible 中查看这些数据。

当事件数据满足 Rulebook 的条件时，事件驱动的 Ansible 就会触发指定的一个或多个操作。 

常见的操作包括：

• Run_playbook 可运行已设计好的现有 Ansible Playbook，以自动执行某些操作，如对服务器进行故障排除。 
• Run_job_template 可通过红帽 Ansible 自动化平台中的自动化控制器来运行作业模板。由于是在 Ansible 自动化平台中运行模板，因此还能利用该平台的其他功能，如库存管理、用户和访问控制，以及对已完成操作的分析。 
• Run_module 可运行一个现有的 Ansible 模块，当您不想运行整个 Playbook 时，该模块可执行更具体、更有针对性的操作。
• Post_event 支持将事件发布到正在运行的规则集中。它通常在 run_playbook 或 run_job_template 操作之后执行，可将操作结果的相关信息反馈到事件驱动的 Ansible 中。
• Set_fact 会记录有关事件或操作的特定数据，以便将其反馈到事件驱动的 Ansible 中，并用于其他操作。事件数据是短暂、临时的数据，通常会很快消失或变化，设置 facts 就可以保存关于事件的特定信息，并使这些数据可以持久存在。
• Debug 类似于 Ansible Playbook 中的调试。如果没有提供参数，它将显示与事件匹配的有效负载和其他相关的关键信息。

本部分包含一些简单的 Ansible Rulebook 示例。即使有些细节不连贯也没关系，这些示例旨在让您对事件源、规则和操作如何在完整的 Rulebook 中协同工作有一个基本了解。 

第一个示例专注于一个相当简单的单一操作。按照下面的代码，如果事件源出现故障，事件驱动的 Ansible 会运行一个修复 Playbook。
 

rules:
  - name: An automatic remediation rule
    condition: event.outage == true
    action:
      run_playbook:
        name: remediate_outage.yml

在下面这个稍微复杂的 Rulebook 示例中，我们将事件源定义为 Dynatrace 认证源插件。规则负责定义我们要监听的条件；在本例中，规则指定了一些应用和硬件使用条件。
 

---
- name: Listen for events on a webhook
  hosts: all
  sources:
    - dynatrace.eda.dt_esa_api:
        dt_api_host: "https://abc.live.dynatrace.com"
        dt_api_token: "asjfsjkfjfjh"
        delay: 60 
  Rules:
    - name: Problem payload Dynatrace for CPU issue
      condition: event.payload.problemTitle contains "CPU saturation"
      action:
        run_job_template:
          name: "Remediate CPU saturation issue"
          organization: "Default"
    - name: Problem payload Dynatrace for App Failure rate increase issue
      condition: event.payload.problemTitle contains "Failure rate increase"
      action:
        run_job_template:
          name: "Remediate Application issue"
          organization: "Default"
    - name: Update comments in Dynatrace
      condition: 
        all: 
          - event.status == "OPEN"
      action:
        run_playbook:
          name: dt-update-comments.yml

系统将检查接收到的事件有效负载中是否包含“CPU saturation”或“Failure rate increase”信息。如果有效负载中包含这些信息，事件驱动的 Ansible 会将这些事件与修复 Playbook 或作业模板相匹配，以解决问题。

红帽 Ansible 自动化平台使用人类可读的 YAML 语言，使用户能够共享、审查和管理自动化内容。它具备实施企业级自动化所需的所有工具，包括事件驱动的 Ansible、Playbook 和分析。另外，它允许团队通过可视化控制面板、基于角色的访问控制等功能来集中管理和控制您的 IT 基础架构，从而帮助降低运维复杂性。

借助红帽订阅，您可以获得认证的内容、可靠的合作伙伴生态系统、托管管理服务的访问权限，以及生命周期技术支持，从而在整个企业或机构中扩展自动化。红帽已成功服务数千客户，积累了能提供专业洞察和指导的宝贵经验。

搭载 IBM watsonx Code Assistant 的红帽 Ansible Lightspeed 的推出，既可让初学者更容易上手 Ansible，也能帮助经验丰富的 Ansible 创建者提高生产力和效率并且避免出错。开发人员可以直接使用简单的英语输入任务请求，Ansible Lightspeed 会与 IBM watsonx 基础模型交互，从而生成代码建议，然后用于创建 Ansible Playbook。