自动化和 Ansible 简介
随着数据中心从物理本地部署演变为数字化云基础设施,传统网络也在不断发展,需要根据业务需求进行扩展。 这给网络运营团队带来了更大的负担,他们需要管理、维护并不断适应不断变化的环境,其中包含复杂而精确的配置。 为了克服手动管理网络运营带来的局限性,数据中心必须实现自动化,以提高其敏捷性。
自动化
如今,企业以高速率运营,数据量呈爆炸式增长,这使得手动监控、故障排除和修复速度过慢,可能会使企业面临风险。 自动化可以简化 Day-0 和 Day-1 的设置,并使 Day-2 的运营几乎实现自主化。 自动化将数据中心基础设施整合在一起,从而可以集中访问大多数数据中心资源。 这种访问支持存储、服务器、网络和其他数据中心管理任务的自动化。
NVIDIA 用户体验
NVIDIA 用户体验 (NVUE) 是一个面向对象的、模式驱动的 Cumulus Linux 系统(硬件和软件)模型,它提供了一个强大的 API,允许多个接口查看(show)和配置(set 和 unset)运行 NVUE 软件的系统中的任何元素。 NVUE 遵循声明式模型,消除了特定于上下文的命令和设置。 它的结构是一棵大树,代表 Cumulus Linux 实例的整个状态。 树的根部是代表对象的高级分支,例如路由器和接口。 在每个分支下都有额外的分支。 当您浏览树时,您会获得更具体的上下文。 树的叶子是实际属性,表示为键值对。 树的路径类似于文件系统路径。 您可以通过以下方式使用 NVUE 对象模型
- 使用 **NVUE CLI**,您可以在其中配置、监控和管理 Cumulus Linux 网络元素。 CLI 命令转换为等效的 REST API,Cumulus Linux 随后在 NVUE 对象模型上运行这些 API。
- 使用 **NVUE REST API**,您可以在其中在 NVUE 对象模型端点上运行 GET、PATCH、DELETE 和其他 REST API,以配置、监控和管理交换机。 由于 NVUE 基于开放 API 规范 (OAS) 的庞大用户社区和成熟度,您可以使用多种流行的工具和库来创建客户端绑定以使用 NVUE REST API。 NVUE REST API 的文档使用 Swagger; 您可以在此处找到它。 CLI 和 REST API 在功能上是等效的; 您可以从 REST API 或 CLI 运行所有管理操作。 NVUE 对象模型驱动 REST API 和 CLI 管理操作。 所有操作都是一致的; 例如,CLI nv show 命令反映您通过 REST API 运行的任何 PATCH 操作(创建)。
Ansible
Ansible® 是一款开源 IT 自动化工具,可自动化配置、配置管理、应用程序部署、编排和许多其他手动 IT 流程。 Ansible 的工作原理是连接到您的自动化目标并推送程序,这些程序执行您通常手动执行的指令。 这些程序利用 Ansible 模块,这些模块是根据端点连接、接口和命令的特定期望编写的。 Ansible Playbook 是自动化任务的蓝图,这些任务是无需人工干预即可执行的复杂 IT 操作。 您可以使用人类可读的 YAML 格式编写 Ansible Playbook,并在主机集、组或分类上执行它们,这些主机共同构成 Ansible 清单。
术语
Ansible Galaxy
一个在线分发服务器,用于查找和共享 Ansible 社区内容,有时称为社区 Galaxy。 此外,它还是一个命令行实用程序,可让您安装单个 Ansible 集合,例如 ansible-galaxy collection install nvidia.nvue
。
集合
一种用于捆绑和分发 Ansible 内容的打包格式,包括插件、角色、模块等。 集合在发布时独立于其他集合或 ansible-core,因此可以更快地提供功能。 某些集合与 Ansible(版本 2.10 或更高版本)打包在一起。 您可以使用 ansible-galaxy collection install <namespace.collection>
安装其他集合(或其他版本的集合)。
集合名称
完全限定集合名称的第二部分。 集合名称分隔集合命名空间,通常反映集合内容的功能。 例如,nvidia
命名空间包含 nvidia.nvue
,其内容用于管理 NVIDIA 维护的不同 NVUE 设备。
组
组由分配到池中的多个主机组成,可以方便地一起定位这些主机,并为它们提供共同的变量。
组变量
group_vars
文件与清单文件一起位于目录中,每个组都有一个可选的同名文件名。 这是放置提供给给定组的变量(尤其是复杂数据结构)的便捷位置,这样这些变量就不必嵌入到文件或 playbook 中。
主机
主机是 Ansible 管理的远程计算机。 您可以为主机分配单个变量,也可以将它们组织在组中。 所有主机都有一个名称,可以是 IP 地址或域名,以及可选的端口号(如果默认 SSH 端口不允许访问)。
清单
一个文件(默认情况下,Ansible 使用简单的 INI 格式),用于描述 Ansible 中的 主机 和 组。 您还可以通过 清单脚本(有时称为外部清单脚本)提供清单。
清单脚本
一个非常简单的程序(或复杂的程序),用于从外部资源(SQL 数据库、CMDB 解决方案或类似于 LDAP 的解决方案)查找 主机、组的主机成员资格和变量信息。 此概念改编自 Puppet(在 Puppet 中称为外部节点分类器),工作方式大致相同。
Jinja2
Jinja2 是 Ansible 模板模块首选的模板语言。 它是一种非常简单的 Python 模板语言,通常可读且易于编写。
模块
模块是 Ansible 发送到远程计算机的工作单元。 模块由 /usr/bin/ansible
或 /usr/bin/ansible-playbook
启动(其中多个任务使用许多不同的模块)。 您可以使用任何语言(包括 Perl、Bash 或 Ruby)实现模块。 如果使用 Python 编写,您可以利用一些有用的公共库代码。 模块只需返回 JSON。 在远程计算机上执行模块后,它们将被删除,因此不会使用长时间运行的守护程序。 Ansible 将可用模块的集合称为 库。
Playbook
Playbook 是 Ansible 用来编排、配置、管理或部署系统的语言。 它们之所以被称为 playbook,部分原因是使用了体育运动的比喻,因为使用它们应该很有趣。 它们不是工作簿。
Play
一个 Playbook 是一个 play 列表。 一个 play 至少是主机说明符(通常由 组 选择,但有时由主机名 glob 选择)选择的一组 主机 与在这些主机上运行以定义这些系统执行的角色 任务 之间的映射。 一个 playbook 中可以有一个或多个 play。
角色
角色是 Ansible 中的组织单元。 将角色分配给一组 主机(或一组 组,或 主机模式 等)意味着它们应该实现特定的行为。 角色可能包括应用某些变量值、某些 任务 和某些 处理程序 – 或仅其中一项或多项。 由于与角色关联的文件结构,角色成为可再分发的单元,使您可以在 Playbook 之间甚至与其他用户共享行为。
任务
Playbook 的存在是为了运行任务。 任务将 操作(模块及其参数)与名称以及可选的其他关键字(如 循环关键字)结合在一起。 处理程序 也是任务,但它们是一种特殊类型的任务,除非在任务报告远程系统上的基础更改时按名称通知它们,否则它们不会运行。
模板
Ansible 可以轻松地将文件传输到远程系统,但通常,需要在其他文件中替换变量。 变量可以来自 清单 文件、主机变量、组变量 或 事实。 模板使用 Jinja2 模板引擎,还可以包括循环和 if 语句等逻辑结构。
YAML
Ansible 不希望强迫人们编写编程语言代码来自动化基础设施,因此 Ansible 使用 YAML 来定义 playbook 配置语言以及变量文件。 YAML 具有最少的语法,并且非常简洁,易于浏览。 它是一种适用于配置文件和人类的良好数据格式,并且也是机器可读的。 Ansible 对 YAML 的使用源于 Michael DeHaan 大约在 2006 年首次在 Cobbler 中使用它。 YAML 在动态语言社区中相当流行,并且该格式具有可用于多种语言(Python、Perl、Ruby 等)序列化的库。