使用 OSPFV2 资源模块入门
使用 OSPFV2 资源模块入门
随着现代企业网络规模和复杂性的不断增长，简化网络管理的需求变得更加迫切。Ansible 2.9 中引入了资源模块，为用户提供了一种简化网络管理的方法，特别是在跨多个不同产品供应商的情况下。
过去，我们已经介绍了用于 VLAN 管理和 ACLs 的资源模块。然而，简化网络管理并不局限于比较局部的网络设置：开放最短路径优先 (OSPFv2) 是一种用于在单个自治系统 (AS) 中分发 IP 路由信息的协议。它用于较大的网络设置，正如 维基百科页面所述
OSPF 是大型企业网络中广泛使用的 IGP。IS-IS 是另一种基于 LSR 的协议，在大型服务提供商网络中更为常见。
手动管理网络设备的 OSPFv2 可能是一项非常困难且乏味的任务，而且更常见的是需要谨慎执行，因为手动过程更容易出现人为错误。
这篇博文将介绍 VyOS 网络平台的 OSPFV2 资源模块。我们将介绍几个示例，并描述每个状态参数的用例以及我们如何在现实场景中使用它们。
OSPFv2 资源模块示例：Vyos
OSPFv2 资源模块的目标是确保配置在整个基础架构中以更少的精力一致地应用。它简化了管理，并使扩展变得更快、更容易，而无需担心幕后运行的网络平台的实际实施细节。
2019 年 10 月，作为 Red Hat Ansible Engine 2.9 的一部分，Ansible 网络自动化团队引入了资源模块的概念，以使那些在生产环境中自动化各种网络平台的人更容易、更一致地进行网络自动化。
Ansible 内容是指 Ansible 剧本、模块、模块实用程序和插件。基本上所有用户用来创建 Ansible 的 Ansible 工具，以及 OSPFv2 资源模块都是 Ansible 内容集合的一部分。
让我们更详细地了解 OSPFv2 资源模块的工作原理。例如，我们选择 vyos_ ospfv2 资源模块。在本博文中，我们将使用版本 1.1.8（氦）的 VyOS 路由器来执行所有特定于配置管理的操作。此外，为了更好地展示模块的效果，我们将从一些 已配置的 OSPF 版本 2 特定属性 开始。有关详细信息，请查看链接的列表。
访问和使用 VyOS 集合
要下载 VyOS 集合，请参考自动化中心（完全支持，需要 Red Hat Ansible Automation Platform 订阅）或 Ansible Galaxy（上游社区支持）
-
自动化中心集合:
vyos.vyos -
Ansible Galaxy 集合:
vyos.vyos
在我们开始之前，让我们快速解释一下命名网络资源模块背后的原理。注意，对于配置 OSPFV2 路由的资源模块，新添加的模块将根据 IP 地址类型命名。这样做是为了使那些使用现有网络模块的人不会让他们的 Ansible 剧本停止工作，并有足够的时间迁移到新的网络自动化模块。
以下支持的平台也提供了用于配置 OSPFv2 的模块
- Arista EOS (arista.eos.eos_ospfv2)
- Cisco IOS (cisco.ios.ios_ospfv2)
- Cisco IOSXR (cisco.ios.iosxr_ospfv2)
- Cisco NXOS (cisco.nxos.nxos_ospfv2)
- Juniper junos (junipernetwork.junos.junos_ospfv2)
- Vyos (vyos.vyos.vyos_ospfv2)
OSPFV2 资源模块提供了与用户在 VyOS 设备上手动配置时相同的级别功能，并具有 Ansible 的所有优势，以及 Ansible 事实收集和资源模块方法的额外优势，该方法与网络专业人员的日常工作更加一致。
用例：OSPFv2 配置更改
使用收集的状态 - 构建 Ansible 库存
资源模块允许用户读取现有网络配置并将其转换为结构化数据模型。state: gathered 等同于为此特定资源收集 Ansible 事实。此示例将读取现有网络配置并将其存储为平面文件。
以下是一个使用 state: gathered 并将结果存储为 YAML 到 host_vars 的 Ansible 剧本示例。如果您不熟悉 Ansible 库存并想了解 group_vars 和 host_vars，请参考 此处的文档。
--- - name: convert configured OSPFV2 resource to structured data hosts: vyos vars: inventory_dir: "lab_inventory" inventory_hostname: "vyos" gather_facts: false tasks: - name: Use the OSPFV2 resource module to gather the current config vyos.vyos.vyos_ospfv2: state: gathered register: ospfv2 - name: Create inventory directory file: path: "{{ inventory_dir }}/host_vars/{{ inventory_hostname }}" state: directory - name: Write the OSPFV2 configuration to a file copy: content: "{{ {'ospfv2': ospfv2['gathered']} | to_nice_yaml }}" dest: "{{ inventory_dir }}/host_vars/{{ inventory_hostname }}/ospfv2.yaml"
使用 ansible-playbook 命令执行 Ansible 剧本
$ ansible-playbook example.yml
这是从棕色字段配置中的读取/收集操作创建的数据结构
$ cat nw_inventory/host_vars/vyos/ospfv2.yaml ospfv2: areas: - area_id: '2' area_type: normal: true authentication: plaintext-password shortcut: enable - area_id: '4' area_type: stub: default_cost: 20 set: true
您可以在 state: gathered 参考 gist 中查看此示例的完整详细输出列表。
使用合并状态 - 推送配置更改
合并状态将获取您的 Ansible 配置数据（即 Ansible 变量）并将它们合并到网络设备的运行配置中。这不会影响 Ansible 配置数据中未指定的现有配置。让我们通过一个示例来演示。
我们将修改在第一个示例中创建的平面文件，其中包含 要合并的配置。
以下是最重要的部分
areas: - area_id: '2' area_type: normal: true authentication: "plaintext-password" shortcut: 'enable' - area_id: '3' area_type: nssa: set: true
现在让我们创建一个 Ansible 剧本，将此新配置合并到网络设备的运行配置中
--- - name: Merged state play hosts: vyos gather_facts: false tasks: - name: Merge OSPFV2 config with device existing OSPFV2 config vyos.vyos.vyos_ospfv2: state: merged config: "{{ ospfv2 }}"
使用 ansible-playbook 命令执行 Ansible 剧本
$ ansible-playbook merged.yml
并且，一旦我们运行相应的合并操作，所有提供的参数都将在 VyOS 路由器上配置，Ansible changed=True.
请注意合并操作后的网络配置
vyos@vyos:~$ show configuration commands | grep ospf set protocols ospf area 2 area-type 'normal' set protocols ospf area 2 authentication 'plaintext-password' set protocols ospf area 2 shortcut 'enable' set protocols ospf area 3 area-type 'nssa' set protocols ospf area 4 area-type stub default-cost '20'
请注意，此列表仅显示了一些重点内容；完整的列表在 合并的 gist 中提供。
让我们看看通过此操作发生了哪些变化：如果我们查看设备输出，有一些观察结果
- 具有 area_id '3' 的属性区域已添加到 OSPF 区域列表中。
- 为 OSPF 配置了 redistribute 和参数属性。
- 如果已配置了具有区域的 OSPF，并且用户想要更新该特定区域的任何参数，那么用户还可以使用合并状态来更新 OSPFv2 下的区域。
在第二次运行时，相应的合并操作将再次运行，Ansible 的幂等性特性就会发挥作用。如果没有变化，操作运行结果为 changed=False，这向用户确认操作中提供的配置已经在 IOS 设备上配置好了。
使用替换状态 - 替换配置
如果用户想要使用提供的 OSPFv2 配置完全重新配置 VyOS 设备的预配置 OSPFv2，那么资源模块的 replaced 状态就会发挥作用。
替换操作的范围取决于各个进程。在 VyOS 的情况下，只支持一个进程。因此，替换状态的行为类似于覆盖状态。因此，在 VyOS 模块中不需要专门的覆盖状态。其他支持多个 OSPFv2 进程的网络平台确实具有覆盖状态操作。
使用覆盖状态，用户可以使用用户提供的 OSPFv2 配置覆盖所有 OSPFv2 资源属性。由于此资源模块状态会覆盖资源模块的所有预先存在的属性，因此应谨慎使用覆盖状态，因为 OSPFv2 配置非常重要；如果所有配置被错误地替换为操作输入配置，可能会给网络管理员造成不必要的麻烦。
在这种情况下，已经在 VyOS 设备上配置了具有 'n' 个区域的 OSPF，现在用户想要用一组新的区域更新区域列表，并丢弃所有已配置的 OSPF 区域。在这种情况下，资源模块的替换状态将是一个理想的选择，顾名思义，替换状态将用用户作为输入提供的新的区域集替换现有的 OSPF 区域列表。
如果用户尝试配置任何不在设备上预先配置的新的 OSPFv2 区域/属性，它将作为合并状态起作用，并且 vyos_ospfv2 模块将尝试在替换操作中配置用户作为输入提供的 OSPF 区域。
我们将修改在第一个示例中创建的平面文件
areas: - area_id: '2' area_type: normal: true authentication: "plaintext-password" shortcut: 'enable' - area_id: '4' area_type: stub: default_cost: 20
如果您想了解更多详细信息，请查看 完整的输入配置结构。
同样，我们创建一个 Ansible 剧本，将此新配置合并到网络设备的运行配置中
--- - name: Replaced state play hosts: vyos gather_facts: false tasks: - name: Replace OSPFV2 config with device existing OSPFV2 config vyos.vyos.vyos_ospfv2: state: replaced config: "{{ ospfv2 }}"
一旦我们运行相应的替换操作，所有提供的参数都将覆盖 VyOS 路由器上所有现有的 OSPFv2 资源特定配置，Ansible changed=True。
替换操作后的网络设备配置
vyos@vyos:~$ show configuration commands | grep ospf set protocols ospf area 2 area-type 'normal' set protocols ospf area 2 authentication 'plaintext-password' set protocols ospf area 2 shortcut 'enable' set protocols ospf area 4 area-type stub default-cost '20' set protocols ospf area 4 network '192.0.2.0/24'
查看 相应的 gist 以了解更多详细信息。
如果我们深入研究上面的输出，我们会注意到以下变化
- 替换会否定所有预先存在的 OSPFv2 资源特定属性，并删除不在替换操作中的配置。在上面的示例中，ospfv2 区域 ID 3 已被删除。
- 对于预先存在且也在操作中的 OSPFv2 配置，vyos_ospfv2 替换状态将尝试删除/否定所有预先存在的 OSPFv2 配置，然后配置操作中提到的新 OSPFv2 配置。
- 对于任何不存在的 OSPFv2 特定属性，替换状态将以与合并状态相同的方式配置 OSPFv2。在上面的示例中，为 OSPFv2 区域 ID 4 配置了一个新的网络地址。
使用上述操作的第二次运行，没有报告任何更改，这满足了 Ansible 的幂等性。
使用删除状态 - 删除配置
既然我们已经讨论了如何使用 vyos_ospfv2 资源模块的合并状态和替换状态在 VyOS 设备上配置 OSPFv2 特定属性，现在该讨论如何删除预配置的 OSPFv2 属性以及删除操作状态对用户提供的粒度级别了。
一次性删除所有 OSPFV2 配置会导致从 VyOS 设备中删除所有预先配置的 OSPFV2 特定属性。但话说回来，这是一个非常关键的删除操作，如果没有谨慎使用，它有能力删除所有预先配置的 OSPFV2，并可能导致生产环境中的路由器没有任何预先配置的 OSPFV2 属性。
让我们创建一个 Ansible Playbook 将此新配置合并到网络设备的运行配置中
--- - name: Deleted state play hosts: vyos gather_facts: false tasks: - name: Delete ALL OSPFV2 config vyos.vyos.vyos_ospfv2: state: deleted
执行 playbook 后，网络设备配置发生了变化
vyos@vyos:~$ show configuration commands | grep ospf vyos@vyos:~$
请务必查看 更改值的完整列表。如果我们简要分析上面的输出，我们可以看到所有 ospfv2 资源特定的配置都已从网络配置中删除。
使用 state rendered - 开发和离线工作
Ansible 将任务中提供的配置渲染成设备原生格式（例如，VyOS CLI）。Ansible 在结果中的 rendered 键中返回此渲染后的配置。请注意，此状态不会与网络设备通信，可以在离线情况下使用。
要渲染配置，请修改在第一个场景中创建的 YAML 文件。例如，如果这是 vyos_ospfv2 模块，您只需添加几个属性来表明我们再次更改了数据模型。
areas: - area_id: '2' area_type: normal: true authentication: "plaintext-password"
查看 相应渲染后的 gist 中的完整列表。
我们创建一个 playbook 来执行此操作
--- - name: Rendered state play hosts: vyos gather_facts: false tasks: - name: Render the provided configuration vyos.vyos.vyos_ospfv2: config: "{{ ospfv2 }}" state: rendered
这会产生以下输出
"rendered": [ "set protocols ospf log-adjacency-changes 'detail'", "set protocols ospf max-metric router-lsa administrative", "set protocols ospf max-metric router-lsa on-shutdown 10",
查看 相应 gist 以获取更多详细信息。
如果我们深入分析上面的输出，我们可以看到没有任何变化；渲染甚至不需要与实际网络设备建立连接。
使用 state parsed - 开发和离线工作
Ansible 将运行配置选项中的配置解析成 Ansible 结构化数据，并将结果放在 parsed 键中。请注意，此操作不会从网络设备收集配置，因此此状态可以在离线情况下使用。
作为要解析的配置，我们使用设备原生格式的配置
set protocols ospf area 2 area-type 'normal' set protocols ospf area 2 authentication 'plaintext-password' set protocols ospf area 2 shortcut 'enable' set protocols ospf area 4 area-type stub default-cost '20' set protocols ospf area 4 network '192.0.2.0/24' set protocols ospf area 4 range 192.0.3.0/24 cost '10'
应用此配置的 playbook 是
--- - name: Parsed state play hosts: vyos gather_facts: false tasks: - name: Parse the provided OSPFV2 configuration vyos.vyos.vyos_ospfv2: running_config: "set protocols ospf area 2 area-type 'normal' set protocols ospf area 2 authentication 'plaintext-password' set protocols ospf area 2 shortcut 'enable' state: parsed
执行 playbook 会生成以下输出
"parsed": { "areas": [ { "area_id": "2", "area_type": { "normal": true }, "authentication": "plaintext-password", "shortcut": "enable" } ] } ...
如果我们深入分析上面的输出，我们可以看到没有任何变化，解析操作甚至不需要与实际网络设备建立连接。
注意：解析的输入将作为 running_config 键的值提供。
结论和后续步骤
如上所示，借助 OSPFV2 资源模块，可以极大地简化资源特定配置。用户无需过多关注每个平台的 OSPFV2 实现细节，只需输入实际数据即可。通过使用合并、替换和覆盖参数，我们为网络工程师提供了更大的灵活性，以便他们能够逐步采用自动化。其他操作（如收集、渲染和解析）使事实和这些任务中管理的数据能够得到更好的、更友好的处理。
