如何用Ansible实现网络自动化

了解 Ansible 的功能，这是一个无代理的、可扩展的配置管理系统。

网络自动化

随着 IT 行业的技术变化，从服务器虚拟化到公有云和私有云，以及自服务能力、容器化应用、平台即服务（PaaS）交付，而一直以来落后的一个领域就是网络。

在过去的五年多，网络行业似乎有很多新的趋势出现，它们中的很多被归入到软件定义网络。

注意：

SDN 是新出现的一种构建、管理、操作和部署网络的方法。SDN 最初的定义是出于将控制层和数据层（包转发）物理分离的需要，并且，解耦合的控制层必须管理好各自的设备。

如今，在 SDN 旗下已经有许多技术，包括基于控制器的网络controller-based networks、网络设备 API、网络自动化、白盒交换机whitebox switche、策略网络化、网络功能虚拟化Network Functions Virtualization（NFV）等等。

出于这篇报告的目的，我们参考 SDN 的解决方案作为我们的解决方案，其中包括一个网络控制器作为解决方案的一部分，并且提升了该网络的可管理性，但并不需要从数据层解耦控制层。

这些趋势的之一是，网络设备的 API 作为管理和操作这些设备的一种方法而出现，真正地提供了机器对机器的通讯。当需要自动化和构建网络应用时 API 简化了开发过程，在数据如何建模时提供了更多结构。例如，当启用 API 的设备以 JSON/XML 返回数据时，它是结构化的，并且比返回原生文本信息 —— 需要手工去解析的仅支持命令行的设备更易于使用。

在 API 之前，用于配置和管理网络设备的两个主要机制是命令行接口（CLI）和简单网络管理协议（SNMP）。让我们来了解一下它们，CLI 是一个设备的人机界面，而 SNMP 并不是为设备提供的实时编程接口。

幸运的是，因为很多供应商争相为设备增加 API，有时候 只是因为 它被放到需求建议书（RFP）中，这就带来了一个非常好的副作用 —— 支持网络自动化。当真正的 API 发布时，访问设备内数据的过程，以及管理配置，就会被极大简化，因此，我们将在本报告中对此进行评估。虽然使用许多传统方法也可以实现自动化，比如，CLI/SNMP。

注意：

随着未来几个月或几年（LCTT 译注：本文发表于 2016 年）的网络设备更新，供应商的 API 无疑应该被做为采购网络设备（虚拟和物理）的关键决策标准而测试和使用。如果供应商提供一些库或集成到自动化工具中，或者如果被用于一个开放的标准或协议，用户应该知道数据是如何通过设备建模的，API 使用的传输类型是什么。

总而言之，网络自动化，像大多数类型的自动化一样，是为了更快地工作。工作的更快是好事，减少部署和配置改变的时间并不总是许多 IT 组织需要去解决的问题。

包括速度在内，我们现在看看这些各种类型的 IT 组织逐渐采用网络自动化的几种原因。你应该注意到，同样的原则也适用于其它类型的自动化。

简化架构

今天，每个网络都是一片独特的“雪花”，并且，网络工程师们为能够通过一次性的网络改变来解决传输和应用问题而感到自豪，而这最终导致网络不仅难以维护和管理，而且也很难去实现自动化。

网络自动化和管理需要从一开始就包含到新的架构和设计中去部署，而不是作为一个二级或三级项目。哪个特性可以跨不同的供应商工作？哪个扩展可以跨不同的平台工作？当使用具体的网络设备平台时，API 类型或者自动化工程是什么？当这些问题在设计过程之前得到答案，最终的架构将变成简单的、可重复的、并且易于维护 和 自动化的，在整个网络中将很少启用供应商专用的扩展。

确定的结果

在一个企业组织中，改变审查会议会评估面临的网络变化、它们对外部系统的影响、以及回滚计划。在人们通过 CLI 来执行这些 面临的变化 的世界上，输入错误的命令造成的影响是灾难性的。想像一下，一个有 3 位、4 位、5位，或者 50 位工程师的团队。每位工程师应对 面临的变化 都有他们自己的独特的方法。并且，在管理这些变化的期间，一个人使用 CLI 或者 GUI 的能力并不会消除和减少出现错误的机率。

使用经过验证的和测试过的网络自动化可以帮助实现更多的可预测行为，并且使执行团队更有可能实现确实性的结果，***在保证任务没有人为错误的情况下正确完成的道路上更进一步。

业务灵活性

不用说，网络自动化不仅为部署变化提供了速度和灵活性，而且使得根据业务需要去从网络设备中检索数据的速度变得更快。自从服务器虚拟化到来以后，服务器和虚拟化使得管理员有能力在瞬间去部署一个新的应用程序。而且，随着应用程序可以更快地部署，随之浮现的问题是为什么还需要花费如此长的时间配置一个 VLAN（虚拟局域网）、路由器、FW ACL（防火墙的访问控制列表）或者负载均衡策略呢？

通过了解在一个组织内最常见的工作流和 为什么 真正需要改变网络，部署如 Ansible 这样的现代的自动化工具将使这些变得非常简单。

这一章介绍了一些关于为什么应该去考虑网络自动化的高级知识点。在下一节，我们将带你去了解 Ansible 是什么，并且继续深入了解各种不同规模的 IT 组织的网络自动化的不同类型。

什么是 Ansible？

Ansible 是存在于开源世界里的一种***的 IT 自动化和配置管理平台。它经常被拿来与其它工具如 Puppet、Chef 和 SaltStack 去比较。Ansible 作为一个由 Michael DeHaan 创建的开源项目出现于 2012 年，Michael DeHaan 也创建了 Cobbler 和 cocreated Func，它们在开源社区都非常流行。在 Ansible 开源项目创建之后不足 18 个月时间， Ansilbe 公司成立，并收到了六百万美金 A 轮投资。该公司成为 Ansible 开源项目***的贡献者和支持者，并一直保持着。在 2015 年 10 月，Red Hat 收购了 Ansible 公司。

但是，Ansible 到底是什么？

Ansible 是一个无需代理和可扩展的超级简单的自动化平台。

让我们更深入地了解它的细节，并且看一看那些使 Ansible 在行业内获得广泛认可的属性。

简单

Ansible 的其中一个吸引人的属性是，使用它你 不 需要特定的编程技能。所有的指令，或者说任务都是自动化的，以一个标准的、任何人都可以理解的人类可读的数据格式的文档化。在 30 分钟之内完成安装和自动化任务的情况并不罕见！

例如，下列来自一个 Ansible 剧本的任务用于去确保在一个 VLAN 存在于一个 Cisco Nexus 交换机中：

1. - nxos_vlan: vlan_id=100 name=web_vlan

你无需熟悉或写任何代码就可以明确地看出它将要做什么！

注意：

这个报告的下半部分涉到 Ansible 术语（剧本等）的细节。在我们使用 Ansible 进行网络自动化时，提及这些关键概念时我们会有一些简短的示例。

无代理

如果你看过市面上的其它工具，比如 Puppet 和 Chef，你会发现，一般情况下，它们要求每个实现自动化的设备必须安装特定的软件。这种情况在 Ansible 上 并不需要，这就是为什么 Ansible 是实现网络自动化的***选择的主要原因。

这很好理解，那些 IT 自动化工具，包括 Puppet、Chef、CFEngine、SaltStack、和 Ansible，它们最初构建是为管理和自动化配置 Linux 主机，以跟得上部署的应用程序增长的步伐。因为 Linux 系统是被配置成自动化的，要安装代理并不是一个技术难题。如果有的话，它也只会延误安装过程，因为，现在有 N 多个（你希望去实现自动化的）主机需要在它们上面部署软件。

再加上，当使用代理时，它们需要的 DNS 和 NTP 配置更加复杂。这些都是大多数环境中已经配置好的服务，但是，当你希望快速地获取一些东西或者只是简单地想去测试一下它能做什么的时候，它将极大地耽误整个设置和安装的过程。

由于本报告只是为介绍利用 Ansible 实现网络自动化，我们希望指出，Ansible 作为一个无代理平台，对于网络管理员来说，其比对系统管理员更具有吸引力。这是为什么呢？

正如前面所说的那样，对网络管理员来说，它是非常有吸引力的，Linux 操作系统是开源的，并且，任何东西都可以安装在它上面。对于网络来说，却并非如此，虽然它正在逐渐改变。如果我们更广泛地部署网络操作系统，如 Cisco IOS，它就是这样的一个例子，并且问一个问题， “第三方软件能否部署在基于 IOS （LCTT 译注：此处的 IOS，指的是思科的网络操作系统 IOS）的平台上吗？”毫无疑问，它的回答是 NO。

在过去的二十多年里，几乎所有的网络操作系统都是闭源的，并且，垂直整合到底层的网络硬件中。没有供应商的支持，在一个网络设备中（路由器、交换机、负载均衡、防火墙、等等）载入一个代理并不那么轻松。有一个像 Ansible 这样的自动化平台，从头开始去构建一个无代理、可扩展的自动化平台，就像是它专门为网络行业订制的一样。我们最终将开始减少并消除与网络的人工交互。

可扩展

Ansible 的可扩展性也非常的好。从开源、代码开始在网络行业中发挥重要的作用时起，有一个可扩展的平台是必需的。这意味着如果供应商或社区不提供一个特定的特性或功能，开源社区、终端用户、消费者、顾问，或者任何的人能够 扩展 Ansible 来启用一个给定的功能集。过去，网络供应商或者工具供应商通过一个 hook 去提供新的插件和集成。想像一下，使用一个像 Ansible 这样的自动化平台，并且，你选择的网络供应商发布了你 真正 需要的一个自动化的新特性。从理论上说，网络供应商或者 Ansible 可以发行一个新的插件去实现自动化这个独特的特性，这是一件非常好的事情，从你的内部工程师到你的增值分销商（VAR）或者你的顾问中的任何一个人，都可以去提供这种集成。

正如前面所说的那样，Ansible 实际上是***扩展性的，Ansible 最初就是为自动化应用程序和系统构建的。这是因为，Ansible 的可扩展性来自于其集成性是为网络供应商编写的，包括但不限于 Cisco、Arista、Juniper、F5、HP、A10、Cumulus 和 Palo Alto Networks。

对于网络自动化，为什么要使用 Ansible？

我们已经简单了解除了 Ansible 是什么，以及一些网络自动化的好处，但是，对于网络自动化，我们为什么要使用 Ansible？

大家很清楚，使得 Ansible 成为如此伟大的一个自动化应用部署平台的许多原因已经被大家所提及了。但是，我们现在要深入一些，更多地关注于网络，并且继续总结一些更需要注意的其它关键点。

无代理

在实现网络自动化的时候，无代理架构的重要性并不是重点强调的，特别是当它适用于现有的自动化设备时。如果，我们看一下当前网络中已经安装的各种设备时，从 DMZ 和园区，到分支机构和数据中心，***份额的设备 并不 具有*** API 的设备。从自动化的角度来看，API 可以使做一些事情变得很简单，像 Ansible 这样的无代理平台有可能去自动化和管理那些 老旧（传统） 的设备。例如，基于 CLI 的设备，它的工具可以被用于任何网络环境中。

注意：

如果仅支持 CLI 的设备已经集成进 Ansible，它的机制就像是，怎么在设备上通过协议如 telnet、SSH 和 SNMP 去进行只读访问和读写操作。

作为一个独立的网络设备，像路由器、交换机、和防火墙正在持续去增加 API 的支持，SDN 解决方案也正在出现。SDN 解决方案的其中一个常见主题是，它们都提供一个单点集成和策略管理，通常是以一个 SDN 控制器的形式出现。这对于 Cisco ACI、VMware NSX、Big Switch Big Cloud Fabric 和 Juniper Contrail，以及其它的 SDN 提供者，比如 Nuage、Plexxi、Plumgrid、Midokura 和 Viptela，是一个真实的解决方案。这甚至包含开源的控制器，比如 OpenDaylight。

所有的这些解决方案都简化了网络管理，就像它们可以让一个管理员开始从“box-by-box”管理（LCTT 译者注：指的是单个设备挨个去操作的意思）迁移到网络范围的管理。这是在正确方向上迈出的很大的一步，这些解决方案并不能消除在变更期间中人类犯错的机率。例如，比起配置 N 个交换机，你可能需要去配置一个单个的 GUI，它需要很长的时间才能实现所需要的配置改变 —— 它甚至可能更复杂，毕竟，相对于一个 CLI，他们更喜欢 GUI！另外，你可能有不同类型的 SDN 解决方案部署在每个应用程序、网络、区域或者数据中心。

在需要自动化的网络中，对于配置管理、监视和数据收集，当行业开始向基于控制器的网络架构中迁移时，这些需求并不会消失。

大量的软件定义网络中都部署有控制器，几乎所有的控制器都提供expose一个***的 REST API。并且，因为 Ansible 是一个无代理架构，它实现自动化是非常简单的，而不仅仅是对那些没有 API 的传统设备，但也有通过 REST API 的软件定义网络解决方案，在所有的终端上不需要有额外的软件（LCTT 译注：指的是代理）。最终的结果是，使用 Ansible，无论有或没有 API，可以使任何类型的设备都能够自动化。

自由开源软件（FOSS)

Ansible 是一个开源软件，它的全部代码在 GitHub 上都是公开可访问的，使用 Ansible 是完全免费的。它可以在几分钟内完成安装并为网络工程师提供有用的价值。Ansible 这个开源项目，或者 Ansible 公司，在它们交付软件之前，你不会遇到任何一个销售代表。那是显而易见的事实，因为它是一个真正的开源项目，但是，作为开源的、社区驱动的软件项目在网络行业中的使用是非常少的，但是，也在逐渐增加，我们想明确指出这一点。

同样需要指出的一点是，Ansible, Inc. 也是一个公司，它也需要去赚钱，对吗？虽然 Ansible 是开源的，它也有一个叫 Ansible Tower 的企业产品，它增加了一些特性，比如，基于规则的访问控制（RBAC）、报告、 web UI、REST API、多租户等等，（相比 Ansible）它更适合于企业去部署。并且，更重要的是，Ansible Tower 甚至可以最多在 10 台设备上 免费 使用，至少，你可以去体验一下，它是否会为你的组织带来好处，而无需花费一分钱，并且，也不需要与无数的销售代表去打交道。

可扩展性

我们在前面说过，Ansible 主要是为部署 Linux 应用程序而构建的自动化平台，虽然从早期开始已经扩展到 Windows。需要指出的是，Ansible 开源项目并没有“自动化网络基础设施”的目标。事实上是，Ansible 社区更明白如何在底层的 Ansible 架构上更具灵活性和可扩展性，对于他们的自动化需要（包括网络）更容易成为一个 扩展 的 Ansible。在过去的两年中，部署有许多的 Ansible 集成，许多是有行业独立人士进行的，比如，Matt Oswalt、Jason Edelman、Kirk Byers、Elisa Jasinska、David Barroso、Michael Ben-Ami、Patrick Ogenstad 和 Gabriele Gerbino，也有网络系统供应商的***，比如，Arista、Juniper、Cumulus、Cisco、F5、和 Palo Alto Networks。

集成到已存在的 DevOps 工作流中

Ansible 在 IT 组织中被用于应用程序部署。它被用于需要管理部署、监视和管理各种类型的应用程序的运维团队中。通过将 Ansible 集成到网络基础设施中，当新应用程序到来或迁移后，它扩展了可能的范围。而不是去等待一个新的顶架交换机（LCTT 译注：TOR，一种数据中心设备接入的方式）的到来、去添加一个 VLAN、或者去检查接口的速度/双工，所有的这些以网络为中心的任务都可以被自动化，并且可以集成到 IT 组织内已经存在的工作流中。

幂等性

术语幂等性（读作 item-potency）经常用于软件开发的领域中，尤其是当使用 REST API 工作的时候，以及在 DevOps 自动化和配置管理框架的领域中，包括 Ansible。Ansible 的其中一个信念是，所有的 Ansible 模块（集成的）应该是幂等的。那么，对于一个模块来说，幂等是什么意思呢？毕竟，对大多数网络工程师来说，这是一个新的术语。

答案很简单。幂等性的本质是允许定义的任务，运行一次或者上千次都不会在目标系统上产生不利影响，仅仅是一种一次性的改变。换句话说，如果有一个要做的改变去使系统进入到它期望的状态，这种改变完成之后，并且，如果这个设备已经达到这种状态，就不会再发生改变。这不像大多数传统的定制脚本和拷贝、黏贴到那些终端窗口中的 CLI 命令。当相同的命令或者脚本在同一个系统上重复运行，（有时候）会出现错误。即使是粘贴一组命令到一个路由器中，也可能会遇到一些使你的其余的配置失效的错误。好玩吧?

另外的例子是，如果你有一个配置 10 个 VLAN 的文件文件或者脚本，那么 每次 运行这个脚本，相同的命令命令会被输入 10 次。如果使用一个幂等的 Ansible 模块，首先会从网络设备中采集已存在的配置，并且，每个新的 VLAN 被配置后会再次检查当前配置。仅仅当这个新的 VLAN 需要被添加（或者，比如说改变 VLAN 名字）是一个变更，命令才会真实地推送到设备。

当一个技术越来越复杂，幂等性的价值就越高，在你修改的时候，你并不能注意到 已存在 的网络设备的状态，而仅仅是从一个网络配置和策略角度去尝试达到 期望的 状态。

网络范围的和临时（Ad Hoc）的改变

用配置管理工具解决的其中一个问题是，配置“飘移”（当设备的期望配置逐渐漂移，或者改变，随着时间的推移，手动改变和/或在一个环境中使用了多个不同的工具），事实上，这也是像 Puppet 和 Chef 所使用的地方。代理商电联到前端服务器，验证它的配置，并且，如果需要变更，则改变它。这个方法是非常简单的。如果有故障了，需要去排除怎么办？你通常需要跳过管理系统，直接连到设备，找到并修复它，然后，马上离开，对不对？果然，在下次当代理电连回来，这个修复问题的改变被覆盖了（基于主/前端服务器是怎么配置的）。在高度自动化的环境中，一次性的改变应该被限制，但是，仍然允许使用它们（LCTT 译注：指的是一次性改变）的工具是非常有价值的。正如你想到的，其中一个这样的工具是 Ansible。

因为 Ansible 是无代理的，这里并没有一个默认的推送或者拉取去防止配置漂移。自动化任务被定义在 Ansible <ruby剧本playbook中，当使用 Ansible 时，它让用户去运行剧本。如果剧本在一个给定的时间间隔内运行，并且你没有用 Ansible Tower，你肯定知道任务的执行频率；如果你只是在终端提示符下使用一个原生的 Ansible 命令行，那么该剧本就运行一次，并且仅运行一次。

缺省运行一次的剧本对网络工程师是很具有吸引力的，让人欣慰的是，在设备上手动进行的改变不会自动被覆盖。另外，当需要的时候，一个剧本所运行的设备范围很容易被改变，即使是对一个单个设备进行自动化的单次变更，Ansible 仍然可以用，设备的 范围 由一个被称为 Ansible 清单inventory的文件决定；这个清单可以是一台设备或者是一千台设备。

下面展示的一个清单文件示例，它定义了两组共六台设备：

1. [core-switches]
2. dc-core-1
3. dc-core-2
5. [leaf-switches]
6. leaf1
7. leaf2
8. leaf3
9. leaf4

为了自动化所有的主机，你的剧本中的剧集play定义的一个片段看起来应该是这样的：

1. hosts: all

并且，要只自动化一个叶子节点交换机，它看起来应该像这样：

1. hosts: leaf1

这是一个核心交换机：

1. hosts: core-switches

注意

正如前面所说的那样，这个报告的后面部分将详细介绍剧本、剧集、和清单。

因为能够很容易地对一台设备或者 N 台设备进行自动化，所以在需要对这些设备进行一次性变更时，Ansible 成为了***的选择。在网络范围内的变更它也做的很好：可以是关闭给定类型的所有接口、配置接口描述、或者是在一个跨企业园区布线的网络中添加 VLAN。