即将发布的Red Hat Ansible Engine 2.9版本正等待您进行令人印象深刻的改进，本文中对其中一些进行了描述。 与往常一样，我们在社区支持下公开开发了Ansible Network改进。 加入- 在GitHub上查看任务板，并在Ansible Network的Wiki页面上研究Red Hat Ansible Engine 2.9发行版的开发计划。
正如我们最近宣布的那样， 红帽Ansible自动化平台现在包括Ansible Tower，Ansible Engine和所有Ansible Network内容。 现在，大多数流行的网络平台都是通过Ansible模块实现的。 例如：
- Arista Eos
- 思科IOS
- 思科IOS XR
- 思科NX-OS
- 杜松朱诺斯
- 维约斯
此处提供了Red Hat通过Ansible Automation完全支持的平台的完整列表。
我们学到了什么
在过去的四年中，我们学到了很多有关开发网络自动化平台的知识。 我们还学习了最终用户如何在Ansible剧本和角色中扮演平台工件。 这是我们发现的：
- 组织不仅使设备自动化，而且使许多供应商自动化。
- 自动化不仅是一种技术现象，而且是一种文化现象。
- 由于自动化设计的基本体系结构原理，网络的大规模自动化比看起来要复杂得多。
当我们在一年多前讨论我们的长期发展计划时，我们的公司客户提出以下要求：
- 事实收集需要更好地标准化，并与任何设备的自动化工作流程保持一致。
- 设备上的更新配置也需要进行标准化和协调，以便Ansible模块在收集事实后处理周期的后半部分。
- 我们需要严格且受支持的方法来将设备配置转换为结构化数据。 在此基础上，可以从网络设备中转移真相的来源。
事实增强
使用Ansible从网络设备收集事实通常是随机的。 网络平台在不同程度上具有收集事实的能力，但是它们几乎没有（甚至根本没有）用于解析和标准化键值对中数据表示的功能。 阅读Ken Celenza的文章 ，了解分析和标准化事实数据有多么困难和痛苦。
您可能已经注意到我们是如何处理Ansible Network Engine角色的。 自然地，在24,000次下载之后，网络引擎角色迅速成为Ansible在Ansible Galaxy中用于网络自动化方案的最受欢迎角色之一。 在将大部分内容移至Ansible 2.8之前，为了准备Ansible 2.9所需的功能，这个Ansible角色提供了第一套工具来协助网络设备的命令解析，命令管理和数据收集。
如果您擅长使用Network Engine，这是一种收集，解析和标准化事实数据以供Ansible使用的非常有效的方法。 该角色的缺点是您需要为每个平台和所有网络活动创建一堆解析器。 要了解创建， 交付和维护解析器有多困难，请查看Cisco的1200多个解析器 。
简而言之，对于大规模自动化而言，从设备接收事实并将其标准化为键值对非常重要，但这在拥有许多供应商和网络平台的情况下很难实现。
现在，Ansible 2.9中的每个网络事实模块都可以分析网络设备的配置并返回结构化数据-无需其他库，Ansible角色或自定义解析器。
从Ansible 2.9开始，在更新的网络模块的每个发行版中，事实模块均得到了改进，以提供有关此配置部分的信息。 也就是说，事实和模块的开发正在以相同的速度进行，并且它们将始终具有相同的数据结构。
可以通过两种方式提取网络设备上的资源配置并将其转换为结构化数据。 两种方式都可以使用新的gather_network_resources编译和转换特定的资源列表。 资源名称与模块名称相对应，这非常方便。
在收集事实时：
使用gather_facts可以在剧本的开头提取当前的设备配置，然后在整个剧本中使用它。 指定要从设备检索的单个资源。
- 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资源eos_interfaces输入，而无需进行其他处理或转换。
资源模块
因此，我们提取了事实，对数据进行了归一化，将其输入到数据结构的标准化内部架构中，从而获得了现成的事实来源。 万岁！ 当然，这很棒，但是我们仍然需要以某种方式将键值对转换回特定设备平台期望的特定配置。 现在，我们需要用于特定平台的模块，以满足这些新的事实收集和规范化要求。
什么是资源模块？ 设备配置部分可以被认为是此设备提供的资源。 网络资源模块被有意地限制为一种资源，并且可以像积木一样堆叠以配置复杂的网络服务。 结果，由于资源模块可以读取和配置网络设备上的特定网络服务，因此自然简化了对资源模块的要求和规格。
为了解释资源模块的功能，让我们看一个剧本示例，该示例使用来自网络资源和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 2.9中的资源模块与以前的版本之间存在3个主要区别。
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来自Extreme Networks。nxos_bfd_interfaces来自思科nxos_telemetry来自思科
如您所见，资源模块的概念适合我们的平台导向策略。 也就是说，我们在Ansible本身中包含了必要的特性和功能，以支持网络模块开发中的标准化，并在Ansible角色和剧本级别简化用户的工作。 为了扩展资源模块的开发，Ansible团队发布了Module Builder工具。
从Ansible 2.10起的计划
在Ansible 2.9发布之后，我们将处理以下用于Ansible 2.10的资源模块集，这些资源模块可用于进一步配置拓扑和网络策略，例如ACL，OSPF和BGP 。 开发计划仍然可以调整，因此，如果您有意见，请向Ansible Network社区报告。
资源和入门
Ansible自动化平台新闻稿
Ansible自动化平台博客
Ansible内容交付的未来
关于改变Ansible项目结构的思考