如何用Ansible实现网络自动化

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

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

- nxos_vlan: vlan_id=100 name=web_vlan

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

注意：

这个报告的下半部分涉到 Ansible 术语（剧本playbook、剧集play、任务task、模块module等等）的细节。在我们使用 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。

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!