宣布推出社区 Ansible 3.0.0 软件包

Ansible 社区软件包的 3.0.0 版本标志着 Ansible 生态系统重构工作的结束。这项工作是 2019 年开始重构 Ansible 项目并塑造 Ansible 内容交付方式的成果。从 Ansible 3.0.0 开始，版本控制和命名方式反映了项目的新结构，具体如下：

1. Ansible 社区软件包的版本控制方法现在采用语义化版本控制，并开始与 Ansible Core 软件包（包含 Ansible 语言和运行时）的版本有所区别。
2. 即将发布的 Ansible Core 软件包将在 2.11 版本中从 2.10 版本的 ansible-base 重命名为 ansible-core，以保持一致性。

首先，回顾一下历史。在 Ansible 2.9 及更早版本中，每个插件和模块都位于 Ansible 项目 (https://github.com/ansible/ansible) 本身。安装“ansible”软件包时，您将获得语言、运行时以及所有内容（模块和其他插件）。随着时间的推移，Ansible 的压倒性普及导致了可扩展性问题。用户不得不等待数月才能获得更新的内容。开发人员不得不依赖 Ansible 维护人员来审查和合并他们的内容。这些明显的瓶颈需要解决。

在 Ansible 2.10 开发周期中，Ansible 社区成功地将大多数模块和插件迁移到 集合 中。集合以及其中的模块和插件现在可以独立于 Ansible 本身进行开发、更新和发布。迁移完成后，核心项目中剩余的部分开始作为 ansible-base 发布，Ansible 社区团队创建了一个新的 Ansible 社区软件包。Ansible 2.10 社区软件包包含 ansible-base 2.10 以及所有包含从原始存储库中迁移出的模块和插件的集合。从 Ansible 2.10 开始，社区用户有两个选择：继续使用 Ansible 社区软件包安装所有内容，或者安装 ansible-base，然后单独添加选定的集合。

如今，Ansible 开源世界中有 3 个不同的工件。

• Ansible Core - 最小的 Ansible 语言和运行时（很快将从 ansible-base 重命名）
• Galaxy 上的 Ansible 集合（社区支持）
• Ansible 社区软件包 - 包含 ansible-base/core 以及社区精选集合的 Ansible 安装包

现在这些工件是分开管理的，它们的版本也开始分化。展望未来，Ansible Core 将保持其现有的编号方案（类似于 Linux 内核）。ansible-base 2.10 之后的下一个 Ansible Core 版本将是 ansible-core 2.11。Ansible 社区软件包（Ansible Core + 社区集合）正在采用语义化版本控制。Ansible 2.10 之后的下一个 Ansible 社区软件包版本是 3.0.0。

软件包的维护和创建方式发生了变化，但是当您安装 Ansible 社区软件包时，您仍然可以获得 Ansible 2.9 中存在的功能，以及模块和插件的更新版本。Ansible 3.0.0 包含 85 多个集合，其中包含数千个模块和其他插件。

由于 Ansible 社区同时发生了如此多的变化，我们认为整理一份问答集是一个好主意，您可以在我们的博客上找到它。

Ansible 3.0.0 问答

Ansible 社区团队已 宣布发布 Ansible 3.0.0，以下列出了一些我们从社区成员那里听到的关于此版本的问题。如果您有任何以下未解答的问题，请在 邮件列表或 IRC 上告知我们。

如何及时了解 Ansible 社区的变化？

订阅 ansible-announce 邮件列表 以获取版本发布公告，并订阅 Bullhorn 时事通讯 以获取社区新闻。Bullhorn 每两周发布一次，内容包括关键日期和更新。您还可以考虑在 2021 年 3 月 9 日 注册参加 Ansible 贡献者峰会。

关于 Ansible 社区软件包和 ansible-base/ansible-core

Ansible 3.0.0 中的 Ansible 语言是否有任何更改？

由于 Ansible 3.0.0 软件包依赖于与 Ansible 2.10.x 相同版本的 ansible-base，因此没有重大更改。

为什么 ansible-base/ansible-core 软件包的版本与 Ansible 软件包的版本不同？

当 Ansible 社区团队着手重构 Ansible 项目时，Ansible 被拆分为以下组件：

• 核心引擎、模块和插件
• 社区和合作伙伴支持的 Ansible 模块和插件集合

前者被称为 ansible-base，很快将成为 ansible-core。后者成为核心之上的补充，可以单独使用或作为 Ansible 社区软件包的一部分使用，其中包含一组经过精心挑选和维护的集合。

Ansible 软件包的语义化版本控制将使我们能够独立于核心引擎，分别指示包含的集合中的向后兼容性和重大更改。

由于这些是不同的组件和不同的内容，因此它们各自独立地进行版本控制是合理的。

ansible-base/ansible-core 是否也会采用语义化版本控制？

不会，管理 ansible-core 的团队目前不打算采用语义化版本控制。

Ansible 3.0.0 和 ansible-base 2.10.x 之间有什么关联？

Ansible 3.0.0 是一个包含超过 85 个 Ansible 集合 的软件包。它不包含 ansible-base：它依赖于它并指定一个所需的版本范围，例如ansible-base>=2.10.6,<2.11，以便自动安装相应的核心软件包。对于 Ansible 4.0.0，此依赖关系将改为ansible-core>=2.11,<2.12。

ansible-base 2.10.x（以及不久的将来将推出的 ansible-core）将继续作为独立软件包提供，供那些希望仅安装所需集合的用户使用。

包含的集合版本范围是如何确定的？

发布构建工具查询包含的集合的最新版本，并根据该版本确定上限。

例如，如果集合的版本为 1.5，则范围将为>=1.5,<2.0。如果集合的版本为 2.3，则范围将为>=2.3,<3.0。

总体思路是在单个 Ansible 软件包主版本的生命周期内，将集合保持在单个主版本内。

ansible --version 将返回什么版本？

ansible --version 将返回 ansible-base 的版本，而不是 Ansible 软件包的版本，因为 ansible-base 是提供 ansible 命令的软件包。

安装和升级

如何安装 Ansible 3.0.0？

Ansible 3.0.0 社区软件包已 发布到 PyPI，可以使用 pip install ansible==3.0.0 进行安装。

我可以从 Ansible 的早期版本升级到 Ansible 3.0.0 吗？如果是，哪些版本可以升级？

• 要从 Ansible-2.10 升级到 Ansible-3.0：pip install --upgrade ansible。
• 要从 Ansible-2.9 或更早版本升级到 Ansible-3.0：pip uninstall ansible；pip install ansible。这是由于 pip 的限制。

可以，但是升级命令取决于您当前的版本。

Ansible 3.0.0 基于 ansible-base 2.10，因此 Ansible-2.10 和 Ansible-3.0 之间的 playbook 语法保持不变。但是，某些模块和插件可能存在不兼容性，因为 Ansible-3.0.0 允许在集合中进行向后不兼容的更改。

我能否从 Ansible 3.0.0 升级到 Ansible 4.0.0？

可以，但是由于 ansible-base 重命名为 ansible-core，您需要先卸载再重新安装：pip uninstall ansible；pip install ansible。

Ansible 4.0.0 将基于 ansible-core 2.11，因此 Ansible 4.0.0 中的 playbook 语法可能包含向后不兼容的更改（ansible-core 不使用语义化版本控制，因此次要版本的更新可能包含向后不兼容的更改）。当 Ansible 4.0.0 准备好开始其预发布周期时，将提供移植指南来帮助您完成这些更改。

发布节奏和范围

未来 Ansible 的发布节奏是什么？

Ansible 软件包的次要版本发布（例如 3.1.0、3.2.0）计划每三周进行一次。这些版本将包含新的向后兼容功能、模块和插件以及错误修复。

Ansible 软件包的主版本发布（例如 4.0.0、5.0.0）将在 ansible-core 发布新版本后进行。Ansible 4.0.0 版本计划于 2021 年 5 月发布，紧随 4 月份发布的 ansible-core 2.11 之后。在 4.0.0 之后，主版本的发布周期将变为 6 个月，5.0.0 将于 11 月发布，紧随计划中的 ansible-core 2.12 版本之后。

Ansible 的每个次要版本和主版本将包含多少更改？

Ansible 社区软件包的每个次要版本仅接受包含的集合中的向后兼容更改。集合也必须使用语义化版本控制，因此集合版本号将反映此规则。例如，如果 Ansible 3.0.0 发布时包含 community.general 2.0.0，则 Ansible 3.x 的所有次要版本（例如 Ansible 3.1.0 或 Ansible 3.5.0）都将包含 community.general 的 2.x 版本（例如 2.8.0 或 2.9.5）。

Ansible 社区软件包的每个主版本将接受每个包含的集合的最新发布版本，并且可能包含 ansible-core 的最新发布版本。Ansible 社区软件包的主版本可能包含包含的集合中或核心功能中的模块和其他插件的重大更改。

鉴于此处使用了语义化版本控制，每个修补程序版本将包含哪些更改？

修补程序版本仅在发现需要快速解决的错误时使用。例如，如果在我们发布的 3.1.0 版本中发现了一个打包错误，导致无法构建 Debian 软件包，那么第二天可能会发布 3.1.1 版本来修复此问题。修补程序版本不允许包含新功能。

打包

Ansible 3.0.0 是否将作为上游 RPM 提供？

一段时间以来，基于 RPM 的 Linux 发行版，例如 Fedora，一直在创建更优秀的 Ansible RPM 包。因此，我们决定从 Ansible-2.10 和 ansible-base-2.10 开始，Ansible 项目将不再提供预构建的 RPM 包。

Ansible 3.0.0 是否会在 Ubuntu Launchpad 上可用？

是的。Ansible 社区团队正在赶上 Ansible 内容打包方式的变化，并计划很快在 PPA 中发布版本。团队目前正在测试一个新的 GitHub action 来构建 PPA 的 deb 包。

术语

• ansible 包

一个多合一的软件包（Python、deb、rpm 等），通过包含自那时以来已迁移到 Ansible 集合的模块和插件，为 Ansible 2.9 提供向后兼容性。

ansible 包依赖于 ansible-base（很快将是 ansible-core）。因此，当您执行 pip install ansible 时，pip 会自动安装 ansible-base。

Ansible 3.0.0 包含更多集合，这得益于更广泛的 Ansible 社区根据社区清单审查集合。此清单包含的内容可以在 ansible-build-data 中找到。

• 集合

用于捆绑和分发 Ansible 内容（插件、角色、模块、剧本、文档等）的打包格式。可以独立于其他集合或 ansible-base 发布，以便可以更快地向用户提供功能和错误修复。从源代码存储库安装，从 galaxy.ansible.com 通过 ansible-galaxy collection install <namespace.collection> 安装，或使用 requirements.yml 文件 安装。

• ansible-base

Ansible 2.10 版本中新增的功能，其代码库现包含在 github.com/ansible/ansible 中。它包含最少的模块和插件，并允许安装其他集合。类似于 Ansible 2.9，但没有任何已移动到集合中的内容。

在 Ansible 的 devel 分支中重命名为 ansible-core，并将从 2.11 版开始使用此名称发布。

• Red Hat Ansible Automation Platform

Red Hat 提供的商业化企业级产品，结合了多个以 Ansible 为中心的项目，包括 ansible-core、awx、galaxy_ng、集合和各种专注于集成 Ansible 用户体验的 Red Hat 工具。

使用新的 Ansible 实用程序进行操作状态管理和修复

将您 IT 基础设施的当前操作状态与您的期望状态进行比较是 IT 自动化的常见用例。这允许自动化用户识别漂移或问题场景以采取纠正措施，甚至主动识别和解决问题。这篇博文将逐步介绍验证操作状态甚至自动修复问题的自动化工作流程。

我们将演示如何使用 Red Hat 支持和认证的 Ansible 内容来

• 从远程主机收集当前操作状态并将其转换为标准化的结构化数据。
• 以标准格式定义期望状态标准，该格式可用于整个企业基础设施团队。
• 根据预定义标准验证当前状态数据，以识别是否存在任何偏差。
• 根据需要采取纠正修复措施。
• 根据数据模型架构验证输入数据

从远程主机收集状态数据

最近发布的 ansible.utils 1.0.0 版本集合增加了对 ansible.utils.cli_parse 模块的支持，该模块将文本数据转换为结构化的 JSON 格式。该模块能够在远程端点上执行命令并获取文本响应，或者读取控制节点上文件的文本并将其转换为结构化数据。此模块可以与传统的 Linux 服务器以及供应商设备（例如无法执行 Python 的网络设备）一起使用，并且此模块依赖于众所周知的文本解析器库进行此转换。当前支持的 CLI 解析器子插件引擎如下所示

1. ansible.utils.textfsm 使用 textfsm python 库
2. ansible.utils.ttp 使用 ttp python 库
3. ansible.netcommon.native 使用 netcommon 内置解析器引擎
4. ansible.netcommon.ntc_templates 使用 ntc_templates python 库
5. ansible.netcommon.pyats 使用 pyats python 库
6. ansible.utils.xml 使用 xmltodict python 库
7. ansible.utils.json

本博文中描述的示例使用 Cisco 网络交换机 NXOS 版本 7.3(0)D1(1) 作为远程端点，以及在控制节点上运行的 Ansible 版本 2.9.15，并且需要在控制节点上安装 ansible.utils、ansible.netcommon 和 cisco.nxos 集合。

下面的 Ansible 代码段 获取接口的操作状态，并使用 ansible.netcommon.pyats 解析器将其转换为结构化数据。此解析需要在控制节点上安装 pyats 库。

---
- hosts: nxos
  connection: ansible.netcommon.network_cli
  gather_facts: false
  vars:
    ansible_network_os: cisco.nxos.nxos
    ansible_user: "changeme"
    ansible_password: "changeme"

  tasks:
  - name: "Fetch interface state and parse with pyats"
    ansible.utils.cli_parse:
      command: show interface
      parser:
        name: ansible.netcommon.pyats
    register: nxos_pyats_show_interface

  - name: print structured interface state data
    ansible.builtin.debug:
      msg: "{{ nxos_pyats_show_interface['parsed'] }}"

ansible.utils.cli_parse 任务中 command 选项的值是在远程主机上应执行的命令，或者，任务可以接受一个 text 选项，该选项直接以字符串格式接受值，并且可以在命令的响应已预取的情况下使用。parser 父选项下的 name 选项可以是上述任何一个解析器子插件。

运行 playbook 后，给定主机的 ansible.utils.cli_parse 任务的输出如下所示，供参考

ok: [nxos] => {
   "changed": false,
   "parsed": {
       "Ethernet2/1": {
           "admin_state": "down",
           "auto_mdix": "off",
           "auto_negotiate": false,
           "bandwidth": 1000000,
           "beacon": "off"
           <--snip-->
       },
       "Ethernet2/10": {
           "admin_state": "down",
           "auto_mdix": "off",
           "auto_negotiate": false,
           "bandwidth": 1000000,
           "beacon": "off",
           <--snip-->
       }
   }

请注意，某些接口的 admin_state 密钥的值为 down，有关完整输出，请参考 此处。

定义状态标准和验证

ansible.utils 集合增加了对 ansible.utils.validate 模块的支持，该模块根据验证引擎验证提供的标准的输入 JSON 数据。当前支持的验证引擎是 jsonschema，将来会根据需要添加对其他验证引擎的支持。

在上一节中，我们获取了接口状态并将其转换为结构化的 JSON 数据。假设如果我们希望所有接口的期望 admin 状态始终处于 up 状态，则 jsonschema 的标准 将如下所示

$cat criterias/nxos_show_interface_admin_criteria.json
{
        "type" : "object",
        "patternProperties": {
                "^.*": {
                        "type": "object",
                        "properties": {
                                "admin_state": {
                                        "type": "string",
                                        "pattern": "up"
                                }
                        }
                }
        }

在定义资源期望状态的标准后，它可以与 ansible.utils.validate 模块一起使用，以检查资源的当前状态是否与期望状态匹配，如下面的 任务 中所示。

- name: validate interface for admin state
  ansible.utils.validate:
    data: "{{ nxos_pyats_show_interface['parsed'] }}"
    criteria:
      - "{{ lookup('file',  './criterias/nxos_show_interface_admin_criteria.json') | from_json }}"
    engine: ansible.utils.jsonschema
  ignore_errors: true
  register: result

- name: print the interface names that does not satisfy the desired state
  ansible.builtin.debug:
    msg: "{{ item['data_path'].split('.')[0] }}"
  loop: "{{ result['errors'] }}"
  when: "'errors' in result"

ansible.utils.validate 任务的 data 选项接受一个 JSON 值，在本例中，它是从上面讨论的 ansible.utils.cli_parse 模块解析的输出。engine 选项的值是 validate 模块的子插件名称，即 ansible.utils.jsonschema，它标识要使用的底层验证库；在本例中，我们使用的是 jsonschema 库。criteria 选项的值可以是一个列表，并且应采用所用验证引擎定义的格式。为了使上述内容能够运行 jsonschema，需要在控制节点上安装库。上面任务运行的输出将是一个错误列表，指示 admin 值不为 up 状态的接口。参考输出可以在 此处 查看（注意：输出将根据远程主机上接口的状态而有所不同）。

TASK [validate interface for admin state] ***********************************************************************************************************
fatal: [nxos02]: FAILED! => {"changed": false, "errors": [{"data_path": "Ethernet2/1.admin_state", "expected": "up", "found": "down", "json_path": "$.Ethernet2/1.admin_state", "message": "'down' does not match 'up'", "relative_schema": {"pattern": "up", "type": "string"}, "schema_path": "patternProperties.^.*.properties.admin_state.pattern", "validator": "pattern"}, {"data_path": "Ethernet2/10.admin_state", "expected": "up", "found": "down", "json_path": "$.Ethernet2/10.admin_state", "message": "'down' does not match 'up'", "relative_schema": {"pattern": "up", "type": "string"}, "schema_path": "patternProperties.^.*.properties.admin_state.pattern", "validator": "pattern"}], "msg": "Validation errors were found.\nAt 'patternProperties.^.*.properties.admin_state.pattern' 'down' does not match 'up'. \nAt 'patternProperties.^.*.properties.admin_state.pattern' 'down' does not match 'up'. \nAt 'patternProperties.^.*.properties.admin_state.pattern' 'down' does not match 'up'. "}
...ignoring

TASK [print the interface names that does not satisfy the desired state] ****************************************************************************
Monday 14 December 2020  11:05:38 +0530 (0:00:01.661)       0:00:28.676 *******
ok: [nxos] => {
   "msg": "Ethernet2/1"
}
ok: [nxos] => {
   "msg": "Ethernet2/10"
}

PLAY RECAP ******************************************************************************************************************************************
nxos                       : ok=4    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=1

从上面的输出可以看出，接口 Ethernet2/1 和 Ethernet2/10 不符合定义标准的期望状态。

修复

根据 ansible.utils.validate 任务的输出，可以使用 Ansible 模块进行配置管理和/或报告以采取许多修复措施。在本例中，我们将使用 cisco.nxos.nxos_interfaces 资源模块将给定接口配置为 admin up 状态，如下面的 代码段 中所示。

- name: Configure interface with drift in admin up state
  cisco.nxos.nxos_interfaces:
    config:
    - name: "{{ item['data_path'].split('.')[0] }}"
      enabled: true
  loop: "{{ result['errors'] }}"
  when: "'errors' in result"

此修复任务仅在早期任务的验证失败时执行，并且仅对 admin 状态不为 up 的接口运行。

数据验证

通常需要在将数据作为输入提供给任务之前对其进行验证，以确保输入数据结构符合预期的数据模型。这使我们能够在将配置推送到网络设备之前验证数据模型的一致性。此用例在 Ivan Pepelnjak 的数据验证 博文中进行了说明。

该博文使用命令行工具验证输入数据，但是由于 ansible.utils.validate 模块的支持，此功能现在可以添加到 Ansible Playbook 本身中，如下面的 代码段 中所示。

- name: validate bgp data data with jsonschema bgp model criteria
  ansible.utils.validate:
    data: "{{ hostvars }}"
    criteria:
      - "{{ lookup('file', './bgp_data_model_criteria.json') |  from_json }}"
    engine: ansible.utils.jsonschema
  register: result

本地存储在 bgp_data_model_criteria.json 文件中的标准结构可以在 此处 参考（来自 原始博文 的修改示例），以及下面的示例 host_vars 文件

$cat host_vars/nxos.yaml
---
bgp_as: 0
description: Unexpected

上面任务运行的输出如下所示

TASK [validate bgp data data with jsonschema bgp model criteria] *******************************************************************************************
fatal: [nxos]: FAILED! => {"changed": false, "errors": [{"data_path": "nxos.bgp_as", "expected": 1, "found": 0, "json_path": "$.nxos.bgp_as", "message": "0 is less than the minimum of 1", "relative_schema": {"maximum": 65535, "minimum": 1, "type": "number"}, "schema_path": "patternProperties..*.properties.bgp_as.minimum", "validator": "minimum"}], "msg": "Validation errors were found.\nAt 'patternProperties..*.properties.bgp_as.minimum' 0 is less than the minimum of 1. "}