即将发布的红帽 Ansible Engine 2.9 带来了令人兴奋的改进，本文将讨论其中一些改进。 与往常一样，我们一直在社区的支持下公开开发 Ansible 网络改进。 加入我们——看看 并研究发展规划 在 wiki 页面上 .
正如我们最近宣布的那样， 现在包括 Ansible Tower、Ansible 引擎和所有 Ansible 网络内容。 如今，最流行的网络平台都是通过 Ansible 模块实现的。 例如：
- 阿里斯塔EOS
- 思科IOS
- 思科 IOS XR
- 思科 NX-OS
- 杜松子朱诺斯
- 操作系统
有关红帽通过 Ansible Automation 订阅完全支持的平台的完整列表， .
我们学到了什么
在过去的四年里，我们学到了很多有关开发网络自动化平台的知识。 我们还了解到 如 最终用户在 Ansible 剧本和角色中使用平台工件。 这是我们发现的：
- 组织不仅对来自一家供应商的设备进行自动化，而且还对来自许多供应商的设备进行自动化。
- 自动化不仅是一种技术现象，也是一种文化现象。
- 由于自动化设计的基本架构原则，大规模网络自动化比看起来更困难。
当我们一年多前讨论我们的长期增长计划时，我们的企业客户提出了以下要求：
- 事实收集需要更好地标准化并与所有设备上的自动化工作流程保持一致。
- 更新设备上的配置也需要标准化和一致，以便 Ansible 模块在收集事实后处理周期的后半部分。
- 我们需要严格且受支持的方法来将设备配置转换为结构化数据。 在此基础上，可以将真相来源从网络设备上移走。
事实改进
使用 Ansible 从网络设备收集事实通常是随机发生的。 基于 Web 的平台具有不同程度的事实收集功能，但它们几乎没有或没有解析和标准化键值对中数据表示的功能。 读 Ken Celenza 讲述了分析和标准化事实数据是多么困难和痛苦。
您可能已经注意到我们致力于 Ansible 网络引擎角色。 自然，在下载量达到 24K 后，网络引擎角色迅速成为 Ansible Galaxy 中网络自动化场景中最受欢迎的 Ansible 角色之一。 在我们将其中的大部分内容转移到 Ansible 2.8 中以准备 Ansible 2.9 中的需求之前，这个 Ansible 角色提供了第一组工具来帮助解析命令、管理命令和收集网络设备的数据。
如果您知道如何使用 Network Engine，那么这是收集、解析和标准化事实数据以供 Ansible 使用的非常有效的方法。 该角色的缺点是您需要为每个平台和所有网络活动创建一大堆解析器。 要了解创建、发布和维护解析器有多么困难，请查看 来自思科的人。
简而言之，从设备获取事实并将其标准化为键值对对于大规模自动化至关重要，但当您拥有许多供应商和网络平台时，实现这一点很困难。
Ansible 2.9 中的每个网络事实模块现在都可以分析网络设备的配置并返回结构化数据 - 无需额外的库、Ansible 角色或自定义解析器。
从 Ansible 2.9 开始，每次发布更新的网络模块时，事实模块都会得到改进，以提供有关这部分配置的数据。 也就是说，事实和模块的开发现在以相同的速度进行，并且它们将始终具有共同的数据结构。
网络设备上的资源配置可以通过两种方式检索并转换为结构化数据。 通过这两种方式，您都可以使用新关键字收集和转换特定资源列表 gather_network_resources。 资源名称与模块名称相匹配，非常方便。
在收集事实时：
使用关键字 gather_facts 您可以在 playbook 的开头检索当前的设备配置，然后在整个 playbook 中使用它。 指定要从设备检索的各个资源。
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: True您可能已经注意到这些示例中的一些新内容，即 - gather_facts: true 现在可用于网络设备的本机事实收集。
直接使用网络事实模块：
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces该剧本返回有关界面的以下事实：
ansible_facts:
ansible_network_resources:
interfaces:
- enabled: true
name: Ethernet1
mtu: '1476'
- enabled: true
name: Loopback0
- enabled: true
name: Loopback1
- enabled: true
mtu: '1476'
name: Tunnel0
- enabled: true
name: Ethernet1
- enabled: true
name: Tunnel1
- enabled: true
name: Ethernet1请注意 Ansible 如何从 Arista 设备检索本机配置并将其转换为结构化数据，以用作下游任务和操作的标准键值对。
接口事实可以添加到 Ansible 存储变量中，并立即或稍后用作资源模块的输入 eos_interfaces 无需额外的处理或转换。
资源模块
因此，我们提取事实，规范化数据，将它们拟合到标准化的内部数据结构图中，并获得现成的事实来源。 万岁！ 当然，这很棒，但我们仍然需要以某种方式将键值对转换回特定设备平台期望的特定配置。 我们现在需要特定于平台的模块来满足这些新的事实收集和规范化要求。
什么是资源模块？ 您可以将设备的配置部分视为该设备提供的资源。 网络资源模块有意限制为单一资源，并且可以像构建块一样堆叠以配置复杂的网络服务。 结果，资源模块的要求和规范自然就被简化了，因为资源模块可以读取 и 在网络设备上配置特定的网络服务。
为了解释资源模块的作用，让我们看一个示例 playbook，它显示了使用新网络资源事实和模块的幂等操作 eos_l3_interface.
- name: example of facts being pushed right back to device.
hosts: arista
gather_facts: false
tasks:
- name: grab arista eos facts
eos_facts:
gather_subset: min
gather_network_resources: l3_interfaces
- name: ensure that the IP address information is accurate
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
register: result
- name: ensure config did not change
assert:
that: not result.changed可以看到，从设备采集的数据直接传输到对应的资源模块，没有进行任何转换。 启动后，剧本会从设备检索值并将其与预期值进行比较。 在此示例中，返回的值符合预期（即，它检查配置偏差）并报告配置是否已更改。
检测配置偏差的理想方法是将事实存储在 Ansible 存储变量中，并在检查模式下定期将它们与资源模块一起使用。 这是查看是否有人手动更改值的简单方法。 在大多数情况下，组织允许手动更改和配置，尽管许多操作是通过 Ansible Automation 执行的。
新的资源模块与以前的资源模块有何不同？
对于网络自动化工程师来说，Ansible 3 和之前版本的资源模块主要有 2.9 个区别。
1) 对于给定的网络资源（也可以被认为是配置部分），模块和事实将在所有支持的网络操作系统上同时发展。 我们认为，如果 Ansible 支持在一个网络平台上进行资源配置，那么我们应该在所有地方都支持它。 这简化了资源模块的使用，因为网络自动化工程师现在可以使用本机和受支持的模块在所有网络操作系统上配置资源（例如 LLDP）。
2) 资源模块现在包含状态值。
merged：配置与提供的配置合并（默认）；replaced：资源配置将替换为提供的配置；overridden：资源配置将替换为提供的配置； 不必要的资源实例将被删除；deleted：资源配置将被删除/恢复为默认值。
3) 资源模块现在包含稳定的返回值。 当网络资源模块对网络设备做出（或建议）必要的更改时，它会将相同的键值对返回到剧本。
before：任务前以结构化数据的形式在设备上进行配置；after：如果设备已更改（或者如果使用测试模式则可能会更改），则结果配置将作为结构化数据返回；commands：在设备上运行任何配置命令以使其进入所需状态。
这一切意味着什么？ 它为什么如此重要？
这篇文章涵盖了很多复杂的概念，但我们希望最终您能够更好地理解企业客户对自动化平台的事实收集、数据规范化和循环配置的要求。 但为什么他们需要这些改进呢？ 许多组织现在正在寻求数字化转型，以使其 IT 环境更加敏捷和更具竞争力。 无论好坏，许多网络工程师要么出于自身利益，要么应管理层的要求而成为网络开发人员。
组织正在意识到，自动化单个网络模板并不能解决孤岛问题，只能在一定程度上提高效率。 红帽 Ansible 自动化平台提供严格且规范的资源数据模型，以编程方式管理网络设备上的底层数据。 也就是说，用户正在逐渐放弃单独的配置方法，转而采用更现代的方法，重点关注技术（例如 IP 地址、VLAN、LLDP 等），而不是特定供应商的实现。
这是否意味着可靠且经过验证的命令模块和配置的日子已经屈指可数了？ 不可能。 预期的网络资源模块并不适用于所有情况或适用于每个供应商，因此网络工程师对于某些实施仍然需要命令和配置模块。 资源模块的目的是简化大型 Jinja 模板并将非结构化设备配置规范为结构化 JSON 格式。 通过资源模块，现有网络可以更轻松地将其配置转换为结构化的键值对，这些键值对代表易于阅读的事实来源。 通过使用结构化键值对，您可以从在每个设备上运行配置转向处理独立的结构化数据，并将网络带到基础设施即代码方法的最前沿。
Ansible Engine 2.9 中将包含哪些资源模块？
在我们详细告诉您 Ansible 2.9 中会发生什么之前，让我们记住我们是如何划分整个工作范围的。
我们确定了 7 个类别，并为每个类别分配了特定的网络资源：
注：粗体资源是在 Ansible 2.9 中规划和实施的。
根据企业客户和社区的反馈，首先处理与网络拓扑协议、虚拟化和接口相关的模块是合乎逻辑的。
以下资源模块由 Ansible Network 团队开发，对应 Red Hat 支持的平台：
以下模块由 Ansible 社区开发：
exos_lldp_global- 来自极进网络。nxos_bfd_interfaces- 来自思科nxos_telemetry- 来自思科
正如您所看到的，资源模块的概念符合我们以平台为中心的战略。 也就是说，我们在 Ansible 本身中包含了必要的能力和功能，以支持网络模块开发的标准化，并在 Ansible 角色和剧本级别简化用户的工作。 为了扩展资源模块的开发，Ansible 团队发布了 Module Builder 工具。
Ansible 2.10 及更高版本的计划
Ansible 2.9 发布后，我们将致力于 Ansible 2.10 的下一组资源模块，这些模块可用于进一步配置网络拓扑和策略，例如 。 开发计划仍可调整，如有意见请反馈至 .
资源和入门
来源： habr.com