我们希望听到您的声音!帮助我们了解 Ansible 生态系统的现状。
参加 2024 年 Ansible 项目调查

使用网络自动化的五种方法

使用网络自动化的五种方法

正如许多人所知,Red Hat Ansible 自动化平台是一个高度灵活的 IT 自动化平台,可以自动化您的 Linux 和 Windows 实例、VMware 私有云、AWS、Azure 或 Google 公有云,甚至您的安全基础设施。今天我想写一下我最喜欢的用例之一:使用 Ansible 自动化平台进行网络自动化。它为您的路由器和交换机提供了简单、高度可定制的自动化,因此您可以像自动化任何其他 IT 基础设施一样自动化它们。

然而,尽管网络自动化变得越来越流行,但大多数组织仍然通过 CLI 或 GUI 手动管理其网络基础设施。为什么呢?这种手动 CLI 操作通常意味着网络工程师是被动的,并不断被手动错误配置或无法快速有效地实施变更而导致的故障排除问题所淹没。

由于网络工程师在日常工作中忙于救火,他们没有时间考虑像自动化这样的新活动,即使从长远来看自动化会为他们节省时间和金钱。我从根本上相信网络自动化不是非此即彼的情况。您需要以较小的增量方式采用网络自动化,这样您才能为自己和团队争取更多时间。换句话说,从小处着手,放眼未来。我制作了这个 视频来帮助网络工程师集思广益网络自动化的五个优秀用例。此列表并不详尽;您可以使用网络自动化完成更多用例,但这旨在让网络管理员了解什么是可能的。

如果您想了解有关特定用例的更多信息,可以直接跳转到该用例

  1. 配置备份和恢复
  2. 基础设施感知
  3. 范围配置管理
  4. 运行状态验证
  5. 自动化网络运维
  6. 总结和下一步






从 Python 虚拟环境迁移到 Ansible 自动化平台 2 中的自动化执行环境

从 Python 虚拟环境迁移到 Ansible 自动化平台 2 中的自动化执行环境

Red Hat Ansible Tower(包含在 Ansible 自动化平台 1.x 中)使用 Python 虚拟环境来管理依赖项并在多个 Red Hat Ansible 自动化平台实例中实施一致的自动化执行。这种管理依赖项的方法有其自身的局限性

  • 在多个 Ansible Tower 实例中管理 Python 虚拟环境。
  • 随着更多最终用户与其交互,确认 Ansible Tower 实例中的自定义依赖项变得越来越复杂。
  • Python 虚拟环境与控制平面紧密耦合,导致运营团队承担了大部分维护工作。
  • 没有 Red Hat 支持和维护的工具来管理 Ansible 自动化平台部署中的自定义依赖项。

Ansible 自动化平台 2 引入了自动化执行环境。这些是所有自动化都打包并在其中运行的容器镜像,其中包括 Ansible Core、Ansible 内容集合、Python 版本、Red Hat Enterprise Linux UBI 8 以及任何其他软件包依赖项。

为什么要升级?

Ansible 自动化平台 2,在 AnsibleFest 2021 上宣布,它具有重新设计的架构,完全解耦了自动化控制平面和执行平面。新功能使跨全球更容易扩展自动化,并允许您在尽可能靠近源代码的位置运行自动化,而无需绑定到在单个数据中心中运行自动化。与 Ansible 自动化平台 1.2 相比,它更加动态、可扩展、弹性和安全。

如果您是使用 Ansible 自动化平台 1.2(Ansible Tower 3.8)的现有 Red Hat 客户,一项重要的迁移建议是将集群中的任何自定义 Python 虚拟环境转换为自动化执行环境。这项一次性工作为利用最新的 Ansible 自动化平台 2 功能以及在多个平台上执行一致的自动化以降低长期维护成本打开了大门。

现在我们将解释这种具体的迁移考虑因素,并向您提供有关如何迁移到自动化执行环境的一些最佳实践。

手动升级过程

如这 文档 中所述,升级到自动化执行环境的手动过程将类似于以下步骤

  1. 前提是运行一个 Ansible 自动化平台 1.2 集群,客户除了默认虚拟环境外还在其中配置了一个或多个自定义 Python 虚拟环境。
  2. 使用 Ansible Tower 节点上存在的 awx-manage 命令行实用程序,使用 list_custom_venvs 子命令获取自定义 Python 虚拟环境列表。
  3. 在每个虚拟环境上运行 awx-manage export_custom_venv 命令以获取该虚拟环境中安装的 Python 软件包列表。
  4. 使用 awx-manage custom_venv_associations 命令检查虚拟环境的关联。此关联/信息列表将帮助客户在 Ansible 自动化平台 2.x 集群中建立新执行环境的关联。
  5. 手动过滤上述信息,并将步骤 3 中的要求列表提供给执行环境构建器(ansible-builder)以创建必要的自定义执行环境。

查看上述流程,可以对该流程进行两个改进,这将帮助客户更快地采用自动化执行环境

  1. 可以将步骤 3 中导出的要求与将用作新创建环境的基础层的自动化执行环境中已存在的 Python 软件包列表进行比较。这将很有帮助,因为基础自动化执行环境将解决某些依赖项,如果客户在开始为其集群创建自动化执行环境时能够关注 **需要什么**,这将对他们有所帮助。
  2. 既然我们喜欢 Ansible,为什么不直接将上述过程自动化呢?:)

自动升级过程

本节的目的是解释如何使用 Ansible 自动化此过程。我们有一些示例 Ansible 内容集合和角色可用于实现这种自动化。从高层面上看,剧本将类似于以下步骤

  1. 从 Ansible 自动化平台 1.2 中 Ansible Tower 节点上存在的所有自定义 Python 虚拟环境中提取软件包列表。
  2. 将步骤 1 中的软件包列表与您决定用作基础的自动化执行环境(在本例中为 ansible-2.9)中的软件包列表进行比较,以查找基础环境中不存在的软件包。
  3. 将步骤 2 中的列表提供给一个 Ansible 角色,该角色可以自动化执行环境创建,将基础环境保持为我们在步骤 2 中进行比较的环境。

让我们来看一个现有的 Ansible 自动化平台 1.2 设置,它有两个自定义虚拟环境,分别称为 custom-venv1 和 custom-venv2,它们都有自己的 Python 软件包列表

# awx-manage export_custom_venv /opt/my-envs/custom-venv1/ -q
certifi==2021.10.8
charset-normalizer==2.0.10
enum34==1.1.10
future==0.18.2
idna==3.3
requests==2.27.1
solidfire-sdk-python==12.3.0.203
urllib3==1.26.8

# awx-manage export_custom_venv /opt/my-envs/custom-venv2/ -q
zabbix-api==0.5.4

我们将使用 redhat_cop.ee_utilities 集合 中打包的一个名为 virtualenv_migrate 的角色,该角色专门为此目的而设计,并针对 Ansible Tower 节点运行它。下面分别是示例剧本和清单文件

---
- name: Review custom virtualenvs and diff packages from base EE
  hosts: tower
  become: true
  vars:
    - venv_migrate_ee_python_list: []
  tasks:
    - name: Include venv_migrate role
      include_role:
        name: redhat_cop.ee_utilities.virtualenv_migrate
[tower]
ansibletower.demoredhat.com

[local]
localhost

[all:vars]
venv_migrate_default_ee_url="registry.redhat.io/ansible-automation-platform-21/ee-29-rhel8:latest"
registry_username=myRedHatID
registry_password=mypassword

剧本的输出如下所示。它按预期进行了比较,并向我们提供了自定义 Python 虚拟环境中的软件包列表,这些软件包不在基础自动化执行环境中。

注意:目前不包括 PIP 软件包的基于版本的比较。

TASK [redhat_cop.tower_utilities.virtualenv_migrate : diff | Show the packages that are extra from default EEs in custom venvs.] ******************************************************************************
ok: [3.228.23.40 -> localhost] => {
    "msg": [
        {
            "/opt/my-envs/custom-venv1/": [
                "certifi",
                "charset-normalizer",
                "enum34",
                "future",
                "solidfire-sdk-python"
            ]
        },
        {
            "/opt/my-envs/custom-venv2/": [
                "zabbix-api"
            ]
        }
    ]
}

上述输出可以直接传递给 redhat_cop.ee_utilities 集合 中的另一个 Ansible 角色,名为 ee_builder;它的用例是自动化执行环境创建过程。

简要总结

  • 我们在 Ansible Tower 节点上运行了一个剧本,以收集不在基础自动化执行环境中的 Python 软件包(来自自定义 Python 虚拟环境)。
  • 上述输出可以帮助使用 ee_builder 角色创建自定义自动化执行环境,该角色可以自动化执行环境创建。

关键要点

  • 将此新 Ansible 角色与 ee_builder 角色结合使用可以用来自动化从自定义虚拟环境到自动化执行环境的迁移。
  • 这些角色目前是社区项目的一部分,未得到 Red Hat 的正式支持。但是,它们可以提供有关迁移过程的理解方面的详细信息。