mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
PRF:20160325 Network automation with Ansible.md
@qhwdw
This commit is contained in:
Xingyu.Wang
parent
edbeacbb2d
commit
5e64380bbb
@ -75,7 +75,7 @@ Ansible 的其中一个吸引人的属性是，使用它你 **不** 需要特定
|
||||
|
||||
> 注意：
|
||||
|
||||
> 这个报告的下半部分涉到 Ansible 术语（<ruby>剧本<rt>playbook</rt></ruby>、<ruby>行动<rt>play</rt></ruby>、<ruby>任务<rt>task</rt></ruby>、<ruby>模块<rt>module</rt></ruby>等等）的细节。在我们使用 Ansible 进行网络自动化时，提及这些关键概念时我们会有一些简短的示例。
|
||||
> 这个报告的下半部分涉到 Ansible 术语（<ruby>剧本<rt>playbook</rt></ruby>、<ruby>剧集<rt>play</rt></ruby>、<ruby>任务<rt>task</rt></ruby>、<ruby>模块<rt>module</rt></ruby>等等）的细节。在我们使用 Ansible 进行网络自动化时，提及这些关键概念时我们会有一些简短的示例。
|
||||
|
||||
#### 无代理
|
||||
|
||||
@ -165,7 +165,7 @@ leaf3
|
||||
leaf4
|
||||
```
|
||||
|
||||
为了自动化所有的主机，你的剧本中的<ruby>行动<rt>play</rt></ruby>定义的一个片段看起来应该是这样的：
|
||||
为了自动化所有的主机，你的剧本中的<ruby>剧集<rt>play</rt></ruby>定义的一个片段看起来应该是这样的：
|
||||
|
||||
```
|
||||
hosts: all
|
||||
@ -185,7 +185,7 @@ hosts: core-switches
|
||||
|
||||
> 注意
|
||||
|
||||
> 正如前面所说的那样，这个报告的后面部分将详细介绍剧本、行动、和清单。
|
||||
> 正如前面所说的那样，这个报告的后面部分将详细介绍剧本、剧集、和清单。
|
||||
|
||||
因为能够很容易地对一台设备或者 _N_ 台设备进行自动化，所以在需要对这些设备进行一次性变更时，Ansible 成为了最佳的选择。在网络范围内的变更它也做的很好：可以是关闭给定类型的所有接口、配置接口描述、或者是在一个跨企业园区布线的网络中添加 VLAN。
|
||||
|
||||
@ -193,17 +193,17 @@ hosts: core-switches
|
||||
|
||||
这个报告从两个方面逐渐深入地讲解一些技术。第一个方面是围绕 Ansible 架构和它的细节，第二个方面是，从一个网络的角度，讲解使用 Ansible 可以完成什么类型的自动化。在这一章中我们将带你去详细了解第二方面的内容。
|
||||
|
||||
自动化一般被认为是速度快，但是，考虑到一些任务并不要求速度，这就是为什么一些 IT 团队没有认识到自动化的价值所在。VLAN 配置是一个非常好的例子，因为，你可能会想，“创建一个 VLAN 到底有多快？一般情况下每天添加多少个 VLANs？我真的需要自动化吗？”
|
||||
自动化一般被认为是速度快，但是，考虑到一些任务并不要求速度，这就是为什么一些 IT 团队没有认识到自动化的价值所在。VLAN 配置是一个非常好的例子，因为，你可能会想，“创建一个 VLAN 到底有多快？一般情况下每天添加多少个 VLAN？我真的需要自动化吗？”
|
||||
|
||||
在这一节中，我们专注于另外几种有意义的自动化任务，比如，设备准备、数据收集、报告、和遵从情况。但是，需要注意的是，正如我们前面所说的，自动化为你、你的团队、以及你的精确的更可预测的结果和更多的确定性，提供了更快的速度和敏捷性。
|
||||
在这一节中，我们专注于另外几种有意义的自动化任务，比如，设备准备、数据收集、报告和遵从情况。但是，需要注意的是，正如我们前面所说的，自动化为你、你的团队、以及你的精确的更可预测的结果和更多的确定性，提供了更快的速度和敏捷性。
|
||||
|
||||
### 设备准备
|
||||
#### 设备准备
|
||||
|
||||
为网络自动化开始使用 Ansible 的最容易也是最快的方法是，为设备最初投入使用创建设备配置文件，并且将配置文件推送到网络设备中。
|
||||
为网络自动化开始使用 Ansible 的最容易也是最快的方法是，为设备的最初投入使用创建设备配置文件，并且将配置文件推送到网络设备中。
|
||||
|
||||
如果我们去完成这个过程，它将分解为两步，第一步是创建一个配置文件，第二步是推送这个配置到设备中。
|
||||
|
||||
首先，我们需要去从供应商配置文件的底层专用语法（CLI）中解耦 _输入_。这意味着我们需要对配置参数中分离出文件和值，比如，VLANs、域信息、接口、路由、和其它的内容、等等，然后，当然是一个配置的模块文件。在这个示例中，这里有一个标准模板，它可以用于所有设备的初始部署。Ansible 将帮助提供配置模板中需要的输入和值之间的部分。几秒钟之内，Ansible 可以生成数百个可靠的和可预测的配置文件。
|
||||
首先，我们需要去从供应商配置文件的底层专用语法（CLI）中解耦 _输入_。这意味着我们需要对配置参数中分离出文件和值，比如，VLAN、域信息、接口、路由、和其它的内容等等，然后，当然是一个配置的模块文件。在这个示例中，这里有一个标准模板，它可以用于所有设备的初始部署。Ansible 将帮助提供配置模板中需要的输入和值之间的部分。几秒钟之内，Ansible 可以生成数百个可靠的和可预测的配置文件。
|
||||
|
||||
让我们快速的看一个示例，它使用当前的配置，并且分解它到一个模板和单独的一个（作为一个输入源的）变量文件中。
|
||||
|
||||
@ -231,13 +231,13 @@ vlan 50
|
||||
|
||||
如果我们提取输入值，这个文件将被转换成一个模板。
|
||||
|
||||
###### 注意
|
||||
> 注意：
|
||||
|
||||
Ansible 使用基于 Python 的 Jinja2 模板化语言，因此，这个被命名为 _leaf.j2_ 的文件是一个 Jinja2 模板。
|
||||
> Ansible 使用基于 Python 的 Jinja2 模板化语言，因此，这个被命名为 _leaf.j2_ 的文件是一个 Jinja2 模板。
|
||||
|
||||
注意，下列的示例中，_双大括号（{{）_ 代表一个变量。
|
||||
注意，下列的示例中，_双大括号（`{{}}`）_ 代表一个变量。
|
||||
|
||||
模板看起来像这些，并且给它命名为 _leaf.j2_：
|
||||
模板看起来像这些，并且给它命名为 `leaf.j2`：
|
||||
|
||||
```
|
||||
!
|
||||
@ -266,17 +266,17 @@ vlans:
|
||||
- { id: 50, name: misc }
|
||||
```
|
||||
|
||||
这意味着，如果管理 VLANs 的团队希望在网络设备中添加一个 VLAN，很简单，他们只需要在变量文件中改变它，然后，使用 Ansible 中一个叫 `template` 的模块，去重新生成一个新的配置文件。这整个过程也是幂等的；仅仅是在模板或者值发生改变时，它才会去生成一个新的配置文件。
|
||||
这意味着，如果管理 VLAN 的团队希望在网络设备中添加一个 VLAN，很简单，他们只需要在变量文件中改变它，然后，使用 Ansible 中一个叫 `template` 的模块，去重新生成一个新的配置文件。这整个过程也是幂等的；仅仅是在模板或者值发生改变时，它才会去生成一个新的配置文件。
|
||||
|
||||
一旦配置文件生成，它需要去 _推送_ 到网络设备。推送配置文件到网络设备使用一个叫做 `napalm_install_config`的开源的 Ansible 模块。
|
||||
|
||||
接下来的示例是一个简单的 playbook 去 _构建并推送_ 一个配置文件到网络设备。同样地，playbook 使用一个名叫 `template` 的模块去构建配置文件，然后使用一个名叫 `napalm_install_config` 的模块去推送它们，并且激活它作为设备上运行的新的配置文件。
|
||||
接下来的示例是一个 _构建并推送_ 一个配置文件到网络设备的简单剧本。同样地，该剧本使用一个名叫 `template` 的模块去构建配置文件，然后使用一个名叫 `napalm_install_config` 的模块去推送它们，并且激活它作为设备上运行的新的配置文件。
|
||||
|
||||
虽然没有详细解释示例中的每一行，但是，你仍然可以看明白它们实际上做了什么。
|
||||
|
||||
###### 注意
|
||||
> 注意：
|
||||
|
||||
下面的 playbook 介绍了新的概念，比如，内置变量 `inventory_hostname`。这些概念包含在 [Ansible 术语和入门][1] 中。
|
||||
> 下面的剧本介绍了新的概念，比如，内置变量 `inventory_hostname`。这些概念包含在 [Ansible 术语和入门][1] 中。
|
||||
|
||||
```
|
||||
---
|
||||
@ -303,17 +303,17 @@ vlans:
|
||||
replace_config=0
|
||||
```
|
||||
|
||||
这个两步的过程是一个使用 Ansible 进行网络自动化入门的简单方法。通过模板简化了你的配置，构建配置文件，然后，推送它们到网络设备 — 因此，被称为 _BUILD 和 PUSH_ 方法。
|
||||
这个两步的过程是一个使用 Ansible 进行网络自动化入门的简单方法。通过模板简化了你的配置，构建配置文件，然后，推送它们到网络设备 — 因此，被称为 `BUILD` 和 `PUSH` 方法。
|
||||
|
||||
###### 注意
|
||||
> 注意：
|
||||
|
||||
像这样的更详细的例子，请查看 [Ansible 网络集成][2]。
|
||||
> 像这样的更详细的例子，请查看 [Ansible 网络集成][2]。
|
||||
|
||||
### 数据收集和监视
|
||||
#### 数据收集和监视
|
||||
|
||||
监视工具一般使用 SNMP — 这些工具拉某些管理信息库（MIBs），然后给监视工具返回数据。基于返回的数据，它可能多于也可能少于你真正所需要的数据。如果接口基于返回的数据统计你正在拉的内容，你可能会返回在 _show interface_ 命令中显示的计数器。如果你仅需要 _interface resets_ 并且，希望去看到与重置相关的邻接 CDP/LLDP 的接口，那该怎么做呢？当然，这也可以使用当前的技术；可以运行多个显示命令去手动解析输出信息，或者，使用基于 SNMP 的工具，在 GUI 中切换不同的选项卡（Tab）找到真正你所需要的数据。Ansible 怎么能帮助我们去完成这些工作呢？
|
||||
监视工具一般使用 SNMP —— 这些工具拉取某些管理信息库（MIB），然后给监视工具返回数据。基于返回的数据，它可能多于也可能少于你真正所需要的数据。如果接口基于返回的数据统计你正在拉取的内容，你可能会返回在 `show interface` 命令中显示的计数器。如果你仅需要 `interface resets` 并且，希望去看到与重置相关的邻接 CDP/LLDP 的接口，那该怎么做呢？当然，这也可以使用当前的技术；可以运行多个显示命令去手动解析输出信息，或者，使用基于 SNMP 的工具，在 GUI 中切换不同的选项卡（Tab）找到真正你所需要的数据。Ansible 怎么能帮助我们去完成这些工作呢？
|
||||
|
||||
由于 Ansible 是完全开放并且是可扩展的，它可以精确地去收集和监视所需要的计数器或者值。这可能需要一些预先的定制工作，但是，最终这些工作是非常有价值的。因为采集的数据是你所需要的，而不是供应商提供给你的。Ansible 也提供直观的方法去执行某些条件任务，这意味着基于正在返回的数据，你可以执行子任务，它可以收集更多的数据或者产生一个配置改变。
|
||||
由于 Ansible 是完全开源并且是可扩展的，它可以精确地去收集和监视所需要的计数器或者值。这可能需要一些预先的定制工作，但是，最终这些工作是非常有价值的。因为采集的数据是你所需要的，而不是供应商提供给你的。Ansible 也提供了执行某些条件任务的直观方法，这意味着基于正在返回的数据，你可以执行子任务，它可以收集更多的数据或者产生一个配置改变。
|
||||
|
||||
网络设备有 _许多_ 统计和隐藏在里面的临时数据，而 Ansible 可以帮你提取它们。
|
||||
|
||||
@ -335,26 +335,23 @@ vlans:
|
||||
|
||||
你现在可以决定某些事情，而不需要事先知道是什么类型的设备。你所需要知道的仅仅是设备的只读通讯字符串。
|
||||
|
||||
#### 迁移
|
||||
|
||||
### 迁移
|
||||
从一个平台迁移到另外一个平台，可能是从同一个供应商或者是从不同的供应商，迁移从来都不是件容易的事。供应商可能提供一个脚本或者一个工具去帮助你迁移。Ansible 可以被用于去为所有类型的网络设备构建配置模板，然后，操作系统用这个方法去为所有的供应商生成一个配置文件，然后作为一个（通用数据模型的）输入设置。当然，如果有供应商专用的扩展，它也是会被用到的。这种灵活性不仅对迁移有帮助，而且也可以用于<ruby>灾难恢复<rt>disaster recovery</rt></ruby>（DR），它在生产系统中不同的交换机型号之间和灾备数据中心中是经常使用的，即使是在不同的供应商的设备上。
|
||||
|
||||
从一个平台迁移到另外一个平台，可能是从同一个供应商或者是从不同的供应商，迁移从来都不是件容易的事。供应商可能提供一个脚本或者一个工具去帮助你迁移。Ansible 可以被用于去为所有类型的网络设备构建配置模板，然后，操作系统用这个方法去为所有的供应商生成一个配置文件，然后作为一个（通用数据模型的）输入设置。当然，如果有供应商专用的扩展，它也是会被用到的。这种灵活性不仅对迁移有帮助，而且也可以用于灾难恢复（DR），它在生产系统中不同的交换机型号之间和灾备数据中心中是经常使用的，即使是在不同的供应商的设备上。
|
||||
#### 配置管理
|
||||
|
||||
正如前面所说的，配置管理是最常用的自动化类型。Ansible 可以很容易地做到创建<ruby>角色<rt>role</rt></ruby>去简化基于任务的自动化。从更高的层面来看，角色是指针对一个特定设备组的可重用的自动化任务的逻辑分组。关于角色的另一种说法是，认为角色就是相关的<ruby>工作流<rt>workflow</rt></ruby>。首先，在开始自动化添加值之前，需要理解工作流和过程。不论是开始一个小的自动化任务还是扩展它，理解工作流和过程都是非常重要的。
|
||||
|
||||
### 配置管理
|
||||
|
||||
正如前面所说的，配置管理是最常用的自动化类型。Ansible 可以很容易地做到创建 _角色（roles）_ 去简化基于任务的自动化。从更高的层面来看，角色是指针对一个特定设备组的可重用的自动化任务的逻辑分组。关于角色的另一种说法是，认为角色就是相关的工作流（workflows）。首先，在开始自动化添加值之前，需要理解工作流和过程。不论是开始一个小的自动化任务还是扩展它，理解工作流和过程都是非常重要的。
|
||||
|
||||
例如，一组自动化配置路由器和交换机的任务是非常常见的，并且它们也是一个很好的起点。但是，配置在哪台网络设备上？配置的 IP 地址是什么？或许需要一个 IP 地址管理方案？一旦用一个给定的功能分配了 IP 地址并且已经部署，DNS 也更新了吗？DHCP 的范围需要创建吗？
|
||||
例如，一组自动化地配置路由器和交换机的任务是非常常见的，并且它们也是一个很好的起点。但是，配置在哪台网络设备上？配置的 IP 地址是什么？或许需要一个 IP 地址管理方案？一旦用一个给定的功能分配了 IP 地址并且已经部署，DNS 也更新了吗？DHCP 的范围需要创建吗？
|
||||
|
||||
你可以看到工作流是怎么从一个小的任务开始，然后逐渐扩展到跨不同的 IT 系统？因为工作流持续扩展，所以，角色也一样（持续扩展）。
|
||||
|
||||
#### 遵从性
|
||||
|
||||
### 遵从性
|
||||
和其它形式的自动化工具一样，用任何形式的自动化工具产生配置改变都被视为风险。手工去产生改变可能看上去风险更大，正如你看到的和亲身经历过的那样，Ansible 有能力去做自动数据收集、监视、和配置构建，这些都是“只读的”和“低风险”的动作。其中一个 _低风险_ 使用案例是，使用收集的数据进行配置遵从性检查和配置验证。部署的配置是否满足安全要求？是否配置了所需的网络？协议 XYZ 禁用了吗？因为每个模块、或者用 Ansible 返回数据的整合，它只是非常简单地 _声明_ 那些事是 _TRUE_ 还是 _FALSE_。然后接着基于 _它_ 是 _TRUE_ 或者是 _FALSE_， 接着由你决定应该发生什么 —— 或许它只是被记录下来，或者，也可能执行一个复杂操作。
|
||||
|
||||
和其它形式的自动化工具一样，用任何形式的自动化工具产生配置改变都视为风险。手工去产生改变可能看上去风险更大，正如你看到的和亲身经历过的那样，Ansible 有能力去做自动数据收集、监视、和配置构建，这些都是“只读的”和“低风险”的动作。其中一个 _低风险_ 使用案例是，使用收集的数据进行配置遵从性检查和配置验证。部署的配置是否满足安全要求？是否配置了所需的网络？协议 XYZ 禁用了吗？因为每个模块、或者用 Ansible 返回数据的整合，它只是非常简单地 _声明_ 那些事是 _TRUE_ 还是 _FALSE_。然后接着基于 _它_ 是 _TRUE_ 或者是 _FALSE_， 接着由你决定应该发生什么 —— 或许它只是被记录下来，或者，也可能执行一个复杂操作。
|
||||
|
||||
### 报告
|
||||
#### 报告
|
||||
|
||||
我们现在知道，Ansible 也可以用于去收集数据和执行遵从性检查。Ansible 可以根据你想要做的事情去从设备中返回和收集数据。或许返回的数据成为其它的任务的输入，或者你想去用它创建一个报告。从模板中生成报告，并将真实的数据插入到模板中，创建和使用报告模板的过程与创建配置模板的过程是相同的。
|
||||
|
||||
@ -362,22 +359,21 @@ vlans:
|
||||
|
||||
创建报告的用处很多，不仅是为行政管理，也为了运营工程师，因为它们通常有双方都需要的不同指标。
|
||||
|
||||
|
||||
### Ansible 怎么工作
|
||||
|
||||
从一个网络自动化的角度理解了 Ansible 能做什么之后，我们现在看一下 Ansible 是怎么工作的。你将学习到从一个 Ansible 管理主机到一个被自动化的节点的全部通讯流。首先，我们回顾一下，Ansible 是怎么 _开箱即用的（out of the box）_，然后，我们看一下 Ansible 怎么去做到的，具体说就是，当网络设备自动化时，Ansible _模块_是怎么去工作的。
|
||||
从一个网络自动化的角度理解了 Ansible 能做什么之后，我们现在看一下 Ansible 是怎么工作的。你将学习到从一个 Ansible 管理主机到一个被自动化的节点的全部通讯流。首先，我们回顾一下，Ansible 是怎么<ruby>开箱即用<rt>out of the box</rt></ruby>的，然后，我们看一下 Ansible 怎么去做到的，具体说就是，当网络设备自动化时，Ansible _模块_是怎么去工作的。
|
||||
|
||||
### 开箱即用
|
||||
#### 开箱即用
|
||||
|
||||
到目前为止，你已经明白了，Ansible 是一个自动化平台。实际上，它是一个安装在一台单个服务器上或者企业中任何一位管理员的笔记本中的轻量级的自动化平台。当然，（安装在哪里？）这是由你来决定的。在基于 Linux 的机器上，使用一些实用程序（比如 pip、apt、和 yum）安装 Ansible 是非常容易的。
|
||||
|
||||
###### 注意
|
||||
> 注意：
|
||||
|
||||
在本报告的其余部分，安装 Ansible 的机器被称为 _控制主机_。
|
||||
> 在本报告的其余部分，安装 Ansible 的机器被称为<ruby>控制主机<rt>control host</rt></ruby>。
|
||||
|
||||
控制主机将执行在 Ansible 的 playbook （不用担心，稍后我们将讲到 playbook 和其它的 Ansible 术语）中定义的所有自动化任务。现在，我们只需要知道，一个 playbook 是简单的一组自动化任务和在给定数量的主机上执行的指令。
|
||||
控制主机将执行定义在 Ansible 的<ruby>剧本<rt>playbook</rt></ruby> （不用担心，稍后我们将讲到剧本和其它的 Ansible 术语）中的所有自动化任务。现在，我们只需要知道，一个剧本是简单的一组自动化任务和在给定数量的主机上执行的指令。
|
||||
|
||||
当一个 playbook 创建之后，你还需要去定义它要自动化的主机。映射一个 playbook 和要自动化运行的主机，是通过一个被称为 Ansible 清单的文件。这是一个前面展示的示例，但是，这里是同一个清单文件的另外两个组：`cisco` 和 `arista`：
|
||||
当一个剧本创建之后，你还需要去定义它要自动化的主机。映射一个剧本和要自动化运行的主机，是通过一个被称为 Ansible <ruby>清单<rt>inventory</rt></ruby>的文件。这是一个前面展示的示例，但是，这里是同一个清单文件的另外两个组：`cisco` 和 `arista`：
|
||||
|
||||
```
|
||||
[cisco]
|
||||
@ -389,13 +385,13 @@ sfo1.acme.com
|
||||
sfo2.acme.com
|
||||
```
|
||||
|
||||
###### 注意
|
||||
> 注意：
|
||||
|
||||
你也可以在清单文件中使用 IP 地址，而不是主机名。对于这样的示例，主机名将是通过 DNS 可解析的。
|
||||
> 你也可以在清单文件中使用 IP 地址，而不是主机名。对于这样的示例，主机名将是通过 DNS 可解析的。
|
||||
|
||||
正如你所看到的，Ansible 清单文件是一个文本文件，它列出了主机和主机组。然后，你可以在 playbook 中引用一个具体的主机或者组，以此去决定对给定的 play 和 playbook 在哪台主机上进行自动化。下面展示了两个示例。
|
||||
正如你所看到的，Ansible 清单文件是一个文本文件，它列出了主机和主机组。然后，你可以在剧本中引用一个具体的主机或者组，以此去决定对给定的<ruby>剧集<rt>play</rt></ruby>和剧本在哪台主机上进行自动化。下面展示了两个示例。
|
||||
|
||||
展示的第一个示例它看上去像是，你想去自动化 `cisco` 组中所有的主机，而展示的第二个示例只对 _nyc1.acme.com_ 主机进行自动化：
|
||||
展示的第一个示例它看上去像是，你想去自动化 `cisco` 组中所有的主机，而展示的第二个示例只对 `nyc1.acme.com` 主机进行自动化：
|
||||
|
||||
```
|
||||
---
|
||||
@ -417,7 +413,7 @@ sfo2.acme.com
|
||||
- TASKS YOU WANT TO AUTOMATE
|
||||
```
|
||||
|
||||
现在，我们已经理解了基本的清单文件，我们可以看一下（在控制主机上的）Ansible 是怎么与 _开箱即用_ 的设备通讯的，和在 Linux 终端上自动化的任务。这里需要明白一个重要的观点就是，需要去自动化的网络设备通常是不一样的。（译者注：指的是设备的类型、品牌、型号等等）
|
||||
现在，我们已经理解了基本的清单文件，我们可以看一下（在控制主机上的）Ansible 是怎么与 _开箱即用_ 的设备通讯的，和在 Linux 终端上自动化的任务。这里需要明白一个重要的观点就是，需要去自动化的网络设备通常是不一样的。（LCTT 译注：指的是设备的类型、品牌、型号等等）
|
||||
|
||||
Ansible 对基于 Linux 的系统去开箱即用自动化工作有两个要求。它们是 SSH 和 Python。
|
||||
|
||||
@ -427,31 +423,26 @@ Ansible 对基于 Linux 的系统去开箱即用自动化工作有两个要求
|
||||
|
||||
如果我们详细解释这个开箱即用工作流，它将分解成如下的步骤：
|
||||
|
||||
1. 当一个 Ansible play 被执行，控制主机使用 SSH 连接到基于 Linux 的目标节点。
|
||||
|
||||
2. 对于每个任务，也就是说，Ansible 模块将在这个 play 中被执行，通过 SSH 发送 Python 代码并直接在远程系统中执行。
|
||||
|
||||
1. 当执行一个 Ansible 剧集时，控制主机使用 SSH 连接到基于 Linux 的目标节点。
|
||||
2. 对于每个任务，也就是说，Ansible 模块将在这个剧集中被执行，通过 SSH 发送 Python 代码并直接在远程系统中执行。
|
||||
3. 在远程系统上运行的每个 Ansible 模块将返回 JSON 数据到控制主机。这些数据包含有信息，比如，配置改变、任务成功/失败、以及其它模块特定的数据。
|
||||
|
||||
4. JSON 数据返回给 Ansible，然后被用于去生成报告，或者被用作接下来模块的输入。
|
||||
5. 在剧集中为每个任务重复第 3 步。
|
||||
6. 在剧本中为每个剧集重复第 1 步。
|
||||
|
||||
5. 在 play 中为每个任务重复第 3 步。
|
||||
|
||||
6. 在 playbook 中为每个 play 重复第 1 步。
|
||||
|
||||
是不是意味着每个网络设备都可以被 Ansible 开箱即用？因为它们也都支持 SSH，确实，网络设备都支持 SSH，但是，它是第一个和第二要求的组合限制了网络设备可能的功能。
|
||||
是不是意味着每个网络设备都可以被 Ansible 开箱即用？因为它们也都支持 SSH，确实，网络设备都支持 SSH，但是，第一个和第二要求的组合限制了网络设备可能的功能。
|
||||
|
||||
刚开始时，大多数网络设备并不支持 Python，因此，使用默认的 Ansible 连接机制是无法进行的。换句话说，在过去的几年里，供应商在几个不同的设备平台上增加了 Python 支持。但是，这些平台中的大多数仍然缺乏必要的集成，以允许 Ansible 去直接通过 SSH 访问一个 Linux shell，并以适当的权限去拷贝所需的代码、创建临时目录和文件、以及在设备中执行代码。尽管 Ansible 中所有的这些部分都可以在基于 Linux 的网络设备上使用 SSH/Python 在本地运行，它仍然需要网络设备供应商去更进一步开放他们的系统。
|
||||
|
||||
###### 注意
|
||||
> 注意：
|
||||
|
||||
值的注意的是，Arista 确实也提供了原生的集成，因为它可以放弃 SSH 用户，直接进入到一个 Linux shell 中访问 Python 引擎，它可以允许 Ansible 去使用默认连接机制。因为我们调用了 Arista，我们也需要着重强调与 Ansible 默认连接机制一起工作的 Cumulus。这是因为 Cumulus Linux 是原生 Linux，并且它并不需要为 Cumulus Linux 操作系统使用供应商 API。
|
||||
> 值的注意的是，Arista 确实也提供了原生的集成，因为它可以无需 SSH 用户，直接进入到一个 Linux shell 中访问 Python 引擎，它可以允许 Ansible 去使用其默认连接机制。因为我们调用了 Arista，我们也需要着重强调与 Ansible 默认连接机制一起工作的 Cumulus。这是因为 Cumulus Linux 是原生 Linux，并且它并不需要为 Cumulus Linux 操作系统使用供应商 API。
|
||||
|
||||
### Ansible 网络集成
|
||||
#### Ansible 网络集成
|
||||
|
||||
前面的节讲到过 Ansible 默认的工作方式。我们看一下，在开始一个 _play_ 之后，Ansible 是怎么去设置一个到设备的连接、通过执行拷贝 Python 代码到设备去运行任务、运行代码、和返回结果给 Ansible 控制主机。
|
||||
前面的节讲到过 Ansible 默认的工作方式。我们看一下，在开始一个 _剧集_ 之后，Ansible 是怎么去设置一个到设备的连接、通过拷贝 Python 代码到设备、运行代码、和返回结果给 Ansible 控制主机来执行任务。
|
||||
|
||||
在这一节中，我们将看一看，当使用 Ansible 进行自动化网络设备时都做了什么。正如前面讲过的，Ansible 是一个可拔插的连接架构。对于 _大多数_ 的网络集成， `connection` 参数设置为 `local`。在 playbook 中大多数的连接类型都设置为 `local`，如下面的示例所展示的：
|
||||
在这一节中，我们将看一看，当使用 Ansible 进行自动化网络设备时都做了什么。正如前面讲过的，Ansible 是一个可拔插的连接架构。对于 _大多数_ 的网络集成， `connection` 参数设置为 `local`。在剧本中大多数的连接类型都设置为 `local`，如下面的示例所展示的：
|
||||
|
||||
```
|
||||
---
|
||||
@ -464,15 +455,15 @@ Ansible 对基于 Linux 的系统去开箱即用自动化工作有两个要求
|
||||
- TASKS YOU WANT TO AUTOMATE
|
||||
```
|
||||
|
||||
注意在 play 中是怎么定义的，这个示例增加 `connection` 参数去和前面节中的示例进行比较。
|
||||
注意在剧集中是怎么定义的，这个示例增加 `connection` 参数去和前面节中的示例进行比较。
|
||||
|
||||
这告诉 Ansible 不要通过 SSH 去连接到目标设备，而是连接到本地机器运行这个 playbook。基本上，这是把连接职责委托给 playbook 中 _任务_ 节中使用的真实的 Ansible 模块。每个模块类型的委托权利允许这个模块在必要时以各种形式去连接到设备。这可能是 Juniper 和 HP Comware7 的 NETCONF、Arista 的 eAPI、Cisco Nexus 的 NX-API、或者甚至是基于传统系统的 SNMP，它们没有可编程的 API。
|
||||
这告诉 Ansible 不要通过 SSH 去连接到目标设备，而是连接到本地机器运行这个剧本。基本上，这是把连接职责委托给剧本中<ruby>任务<rt>task</rt></ruby> 节中使用的真实的 Ansible 模块。每个模块类型的委托权利允许这个模块在必要时以各种形式去连接到设备。这可能是 Juniper 和 HP Comware7 的 NETCONF、Arista 的 eAPI、Cisco Nexus 的 NX-API、或者甚至是基于传统系统的 SNMP，它们没有可编程的 API。
|
||||
|
||||
###### 注意
|
||||
> 注意：
|
||||
|
||||
网络集成在 Ansible 中是以 Ansible 模块的形式带来的。尽管我们持续使用术语来吊你的胃口，比如，playbooks、plays、任务、和讲到的关键概念 `模块`，这些术语中的每一个都会在 [Ansible 术语和入门][3] 和 [动手实践使用 Ansible 去进行网络自动化][4] 中详细解释。
|
||||
> 网络集成在 Ansible 中是以 Ansible 模块的形式带来的。尽管我们持续使用术语来吊你的胃口，比如，剧本、剧集、任务、和讲到的关键概念模块，这些术语中的每一个都会在 [Ansible 术语和入门][3] 和 [动手实践使用 Ansible 去进行网络自动化][4] 中详细解释。
|
||||
|
||||
让我们看一看另外一个 playbook 的示例：
|
||||
让我们看一看另外一个剧本的示例：
|
||||
|
||||
```
|
||||
---
|
||||
@ -485,22 +476,21 @@ Ansible 对基于 Linux 的系统去开箱即用自动化工作有两个要求
|
||||
- nxos_vlan: vlan_id=10 name=WEB_VLAN
|
||||
```
|
||||
|
||||
你注意到了吗，这个 playbook 现在包含一个任务，并且这个任务使用了 `nxos_vlan` 模块。`nxos_vlan` 模块是一个 Python 文件，并且，在这个文件中它是使用 NX-API 连接到 Cisco 的 NX-OS 设备。可是，这个连接可能是使用其它设备 API 设置的，这就是为什么供应商和用户像我们这样能够去建立自己的集成的原因。集成（模块）通常是以每特性（per-feature）为基础完成的，虽然，你已经看到了像 `napalm_install_config` 这样的模块，它们也可以被用来 _推送_ 一个完整的配置文件。
|
||||
你注意到了吗，这个剧本现在包含一个任务，并且这个任务使用了 `nxos_vlan` 模块。`nxos_vlan` 模块是一个 Python 文件，并且，在这个文件中它是使用 NX-API 连接到 Cisco 的 NX-OS 设备。可是，这个连接可能是使用其它设备 API 设置的，这就是为什么供应商和用户像我们这样能够去建立自己的集成的原因。集成（模块）通常是以<ruby>每特性<rt>per-feature</rt></ruby>为基础完成的，虽然，你已经看到了像 `napalm_install_config` 这样的模块，它们也可以被用来 _推送_ 一个完整的配置文件。
|
||||
|
||||
主要区别之一是使用的默认连接机制，Ansible 启动一个持久的 SSH 连接到设备，并且这个连接为一个给定的 play 持续。当在一个模块中发生连接设置和拆除时，与许多使用 `connection=local` 的网络模块一样，对发生在 play 级别上的 _每个_ 任务，Ansible 将登入/登出设备。
|
||||
主要区别之一是使用的默认连接机制，Ansible 启动一个持久的 SSH 连接到设备，并且对于一个给定的剧集而已该连接将持续存在。当在一个模块中发生连接设置和拆除时，与许多使用 `connection=local` 的网络模块一样，对发生在剧集级别上的 _每个_ 任务，Ansible 将登入/登出设备。
|
||||
|
||||
而在传统的 Ansible 形式下，每个网络模块返回 JSON 数据。仅有的区别是相对于目标节点，数据的推取发生在本地的 Ansible 控制主机上。相对于每供应商（per vendor）和模块类型，数据返回到 playbook，但是作为一个示例，许多的 Cisco NX-OS 模块返回已存在的状态、建议状态、和最终状态，以及发送到设备的命令（如果有的话）。
|
||||
而在传统的 Ansible 形式下，每个网络模块返回 JSON 数据。仅有的区别是相对于目标节点，数据的推取发生在本地的 Ansible 控制主机上。相对于<ruby>每供应商<rt>per vendor</rt></ruby>和模块类型，数据返回到剧本，但是作为一个示例，许多的 Cisco NX-OS 模块返回已存在的状态、建议状态、和最终状态，以及发送到设备的命令（如果有的话）。
|
||||
|
||||
作为使用 Ansible 进行网络自动化的开始，最重要的是，为 Ansible 的连接设备/拆除过程，记着去设置连接参数为 `local`，并且将它留在模块中。这就是为什么模块支持不同类型的供应商平台，它将与设备使用不同的方式进行通讯。
|
||||
|
||||
|
||||
### Ansible 术语和入门
|
||||
|
||||
这一章我们将介绍许多 Ansible 的术语和报告中前面部分出现过的关键概念。比如， _清单文件_、_playbook_、_play_、_任务_、和 _模块_。我们也会去回顾一些其它的概念，这些术语和概念对我们学习使用 Ansible 去进行网络自动化非常有帮助。
|
||||
这一章我们将介绍许多 Ansible 的术语和报告中前面部分出现过的关键概念。比如， <ruby>清单文件<rt>inventory file</rt></ruby>、<ruby>剧本<rt>playbook</rt></ruby>、<ruby>剧集<rt>play</rt></ruby>、<ruby>任务<rt>task</rt></ruby>和<ruby>模块<rt>module</rt></ruby>。我们也会去回顾一些其它的概念，这些术语和概念对我们学习使用 Ansible 去进行网络自动化非常有帮助。
|
||||
|
||||
在这一节中，我们将引用如下的一个简单的清单文件和 playbook 的示例，它们将在后面的章节中持续出现。
|
||||
在这一节中，我们将引用如下的一个简单的清单文件和剧本的示例，它们将在后面的章节中持续出现。
|
||||
|
||||
_清单示例_:
|
||||
_清单示例_ ：
|
||||
|
||||
```
|
||||
# sample inventory file
|
||||
@ -521,7 +511,7 @@ core1
|
||||
core2
|
||||
```
|
||||
|
||||
_playbook 示例_:
|
||||
_剧本示例_ ：
|
||||
|
||||
```
|
||||
---
|
||||
@ -570,54 +560,50 @@ _playbook 示例_:
|
||||
- 50
|
||||
```
|
||||
|
||||
### 清单文件
|
||||
#### 清单文件
|
||||
|
||||
使用一个清单文件，比如前面提到的那个，允许我们去为自动化任务指定主机、和使用每个 play 顶部节中（如果存在）的参数 `hosts` 所引用的主机/组指定的主机组。
|
||||
使用一个清单文件，比如前面提到的那个，允许我们去为自动化任务指定主机、和使用每个剧集顶部节中（如果存在）的参数 `hosts` 所引用的主机/组指定的主机组。
|
||||
|
||||
它也可能在一个清单文件中存储变量。如这个示例中展示的那样。如果变量在同一行视为一台主机，它是一个具体主机变量。如果变量定义在方括号中（“[ ]”），比如，`[all:vars]`，它的意思是指变量在组中的范围 `all`，它是一个默认组，包含了清单文件中的 _所有_ 主机。
|
||||
它也可能在一个清单文件中存储变量。如这个示例中展示的那样。如果变量在同一行视为一台主机，它是一个具体主机变量。如果变量定义在方括号中（`[ ]`），比如，`[all:vars]`，它的意思是指变量在组中的范围 `all`，它是一个默认组，包含了清单文件中的 _所有_ 主机。
|
||||
|
||||
###### 注意
|
||||
> 注意：
|
||||
|
||||
清单文件是使用 Ansible 开始自动化的快速方法，但是，你应该已经有一个真实的网络设备源，比如一个网络管理工具或者 CMDB，它可以去创建和使用一个动态的清单脚本，而不是一个静态的清单文件。
|
||||
> 清单文件是使用 Ansible 开始自动化的快速方法，但是，你应该已经有一个真实的网络设备源，比如一个网络管理工具或者 CMDB，它可以去创建和使用一个动态的清单脚本，而不是一个静态的清单文件。
|
||||
|
||||
### Playbook
|
||||
#### 剧本
|
||||
|
||||
playbook 是去运行自动化网络设备的顶级对象。在我们的示例中，它是一个 _site.yml_ 文件，如前面的示例所展示的。一个 playbook 使用 YAML 去定义一组自动化任务，并且，每个 playbook 由一个或多个 plays 组成。这类似于一个橄榄球的剧本。就像在橄榄球赛中，团队有剧集组成的剧本，Ansible 的 playbooks 也是由 play 组成的。
|
||||
剧本是去运行自动化网络设备的顶级对象。在我们的示例中，它是 `site.yml` 文件，如前面的示例所展示的。一个剧本使用 YAML 去定义一组自动化任务，并且，每个剧本由一个或多个剧集组成。这类似于一个橄榄球的剧本。就像在橄榄球赛中，团队有剧集组成的剧本，Ansible 的剧本也是由剧集组成的。
|
||||
|
||||
###### 注意
|
||||
> 注意：
|
||||
|
||||
YAML 是一种被所有编程语言支持的数据格式。YAML 本身就是 JSON 的超集，并且，YAML 文件非常易于识别，因为它总是三个破折号（连字符）开始，比如，`---`。
|
||||
> YAML 是一种被所有编程语言支持的数据格式。YAML 本身就是 JSON 的超集，并且，YAML 文件非常易于识别，因为它总是三个破折号（连字符）开始，比如，`---`。
|
||||
|
||||
|
||||
### Play
|
||||
#### 剧集
|
||||
|
||||
一个 Ansible playbook 可以存在一个或多个 plays。在前面的示例中，它在 playbook 中有两个 plays。每个 play 开始的地方都有一个 _header_ 节，它定义了具体的参数。
|
||||
一个 Ansible 剧本可以存在一个或多个剧集。在前面的示例中，它在剧本中有两个剧集。每个剧集开始的地方都有一个 _头部_，它定义了具体的参数。
|
||||
|
||||
示例中两个 plays 都定义了下面的参数：
|
||||
示例中两个剧集都定义了下面的参数：
|
||||
|
||||
`name`
|
||||
|
||||
文件 `PLAY 1 - Top of Rack (TOR) Switches` 是任意内容的，它在 playbook 运行的时候，去改善 playbook 运行和报告期间的可读性。这是一个可选参数。
|
||||
文件 `PLAY 1 - Top of Rack (TOR) Switches` 是任意内容的，它在剧本运行的时候，去改善剧本运行和报告期间的可读性。这是一个可选参数。
|
||||
|
||||
`hosts`
|
||||
|
||||
正如前面讲过的，这是在特定的 play 中要去进行自动化的主机或主机组。这是一个必需参数。
|
||||
正如前面讲过的，这是在特定的剧集中要去进行自动化的主机或主机组。这是一个必需参数。
|
||||
|
||||
`connection`
|
||||
|
||||
正如前面讲过的，这是 play 连接机制的类型。这是个可选参数，但是，对于网络自动化 plays，一般设置为 `local`。
|
||||
正如前面讲过的，这是剧集连接机制的类型。这是个可选参数，但是，对于网络自动化剧集，一般设置为 `local`。
|
||||
|
||||
每个剧集都是由一个或多个任务组成。
|
||||
|
||||
|
||||
每个 play 都是由一个或多个任务组成。
|
||||
|
||||
|
||||
|
||||
### 任务
|
||||
#### 任务
|
||||
|
||||
任务是以声明的方式去表示自动化的内容，而不用担心底层的语法或者操作是怎么执行的。
|
||||
|
||||
在我们的示例中，第一个 play 有两个任务。每个任务确保存在 10 个 VLAN。第一个任务是为 Cisco Nexus 设备的，而第二个任务是为 Arista 设备的：
|
||||
在我们的示例中，第一个剧集有两个任务。每个任务确保存在 10 个 VLAN。第一个任务是为 Cisco Nexus 设备的，而第二个任务是为 Arista 设备的：
|
||||
|
||||
```
|
||||
tasks:
|
||||
@ -631,19 +617,17 @@ tasks:
|
||||
when: vendor == "nxos"
|
||||
```
|
||||
|
||||
任务也可以使用 `name` 参数，就像 plays 一样。和 plays 一样，文本内容是任意的，并且当 playbook 运行时显示，去改善 playbook 运行和报告期间的可读性。它对每个任务都是可选参数。
|
||||
任务也可以使用 `name` 参数，就像剧集一样。和剧集一样，文本内容是任意的，并且当剧本运行时显示，去改善剧本运行和报告期间的可读性。它对每个任务都是可选参数。
|
||||
|
||||
示例任务中的下一行是以 `nxos_vlan` 开始的。它告诉我们这个任务将运行一个叫 `nxos_vlan` 的 Ansible 模块。
|
||||
|
||||
现在，我们将进入到模块中。
|
||||
|
||||
#### 模块
|
||||
|
||||
在 Ansible 中理解模块的概念是至关重要的。虽然任何编辑语言都可以用来写 Ansible 模块，只要它们能够返回 JSON 键/值对即可，但是，几乎所有的模块都是用 Python 写的。在我们示例中，我们看到有两个模块被运行： `nxos_vlan` 和 `eos_vlan`。这两个模块都是 Python 文件；而事实上，在你不能看到剧本的时候，真实的文件名分别是 `eos_vlan.py` 和 `nxos_vlan.py`。
|
||||
|
||||
### 模块
|
||||
|
||||
在 Ansible 中理解模块的概念是至关重要的。虽然任何编辑语言都可以用来写 Ansible 模块，只要它们能够返回 JSON 键 — 值对即可，但是，几乎所有的模块都是用 Python 写的。在我们示例中，我们看到有两个模块被运行： `nxos_vlan` 和 `eos_vlan`。这两个模块都是 Python 文件；而事实上，在你不能看到 playbook 的时候，真实的文件名分别是 _eos_vlan.py_ 和 _nxos_vlan.py_。
|
||||
|
||||
让我们看一下前面的示例中第一个 play 中的第一个 任务：
|
||||
让我们看一下前面的示例中第一个剧集中的第一个任务：
|
||||
|
||||
```
|
||||
- name: ENSURE VLAN 10 EXISTS ON CISCO TOR SWITCHES
|
||||
@ -671,48 +655,39 @@ tasks:
|
||||
|
||||
用于登入到交换机的密码。
|
||||
|
||||
示例中最后的片断部分使用了一个 `when` 语句。这是在一个剧集中使用的 Ansible 的执行条件任务。正如我们所了解的，在这个剧集的 `tor` 组中有多个设备和设备类型。使用 `when` 基于任意标准去提供更多的选择。这里我们仅自动化 Cisco 设备，因为，我们在这个任务中使用了 `nxos_vlan` 模块，在下一个任务中，我们仅自动化 Arista 设备，因为，我们使用了 `eos_vlan` 模块。
|
||||
|
||||
示例中最后的片断部分使用了一个 `when` 语句。这是在一个 play 中使用的 Ansible 的执行条件任务。正如我们所了解的，在这个 play 的 `tor` 组中有多个设备和设备类型。使用 `when` 基于任意标准去提供更多的选择。这里我们仅自动化 Cisco 设备，因为，我们在这个任务中使用了 `nxos_vlan` 模块，在下一个任务中，我们仅自动化 Arista 设备，因为，我们使用了 `eos_vlan` 模块。
|
||||
> 注意：
|
||||
|
||||
###### 注意
|
||||
|
||||
这并不是区分设备的唯一方法。这里仅是演示如何使用 `when`，并且可以在清单文件中定义变量。
|
||||
> 这并不是区分设备的唯一方法。这里仅是演示如何使用 `when`，并且可以在清单文件中定义变量。
|
||||
|
||||
在清单文件中定义变量是一个很好的开端，但是，如果你继续使用 Ansible，你将会为了扩展性、版本控制、对给定文件的改变最小化而去使用基于 YAML 的变量。这也将简化和改善清单文件和每个使用的变量的可读性。在设备准备的构建/推送方法中讲过一个变量文件的示例。
|
||||
|
||||
在最后的示例中，关于任务有几点需要去搞清楚：
|
||||
|
||||
* Play 1 任务 1 展示了硬编码了 `username` 和 `password` 作为参数进入到具体的模块中（`nxos_vlan`）。
|
||||
|
||||
* Play 1 任务 1 和 play 2 在模块中使用了变量，而不是硬编码它们。这掩饰了 `username` 和 `password` 参数，但是，需要值得注意的是，（在这个示例中）这些变量是从清单文件中提取出现的。
|
||||
|
||||
* Play 1 中为进入到模块中的参数使用了一个 _水平的（horizontal）_ 的 key=value 语法，虽然 play 2 使用了垂直的（vertical） key=value 语法。它们都工作的非常好。你也可以使用垂直的 YAML “key: value” 语法。
|
||||
|
||||
* 最后的任务也介绍了在 Ansible 中怎么去使用一个 _loop_ 循环。它通过使用 `with_items` 来完成，并且它类似于一个 for 循环。那个特定的任务是循环进入五个 VLANs 中去确保在交换机中它们都存在。注意：它也可能被保存在一个外部的 YAML 变量文件中。还需要注意的一点是，不使用 `with_items` 的替代方案是，每个 VLAN 都有一个任务 —— 如果这样做，它就失去了弹性！
|
||||
|
||||
* 剧集 1 任务 1 展示了硬编码了 `username` 和 `password` 作为参数进入到具体的模块中（`nxos_vlan`）。
|
||||
* 剧集 1 任务 1 和 剧集 2 在模块中使用了变量，而不是硬编码它们。这掩饰了 `username` 和 `password` 参数，但是，需要值得注意的是，（在这个示例中）这些变量是从清单文件中提取出现的。
|
||||
* 剧集 1 中为进入到模块中的参数使用了一个 _水平的_ 的 key=value 语法，虽然剧集 2 使用了垂直的 key=value 语法。它们都工作的非常好。你也可以使用垂直的 YAML “key: value” 语法。
|
||||
* 最后的任务也介绍了在 Ansible 中怎么去使用一个循环。它通过使用 `with_items` 来完成，并且它类似于一个 for 循环。那个特定的任务是循环进入五个 VLAN 中去确保在交换机中它们都存在。注意：它也可能被保存在一个外部的 YAML 变量文件中。还需要注意的一点是，不使用 `with_items` 的替代方案是，每个 VLAN 都有一个任务 —— 如果这样做，它就失去了弹性！
|
||||
|
||||
### 动手实践使用 Ansible 去进行网络自动化
|
||||
|
||||
在前面的章节中，提供了 Ansible 术语的一个概述。它已经覆盖了大多数具体的 Ansible 术语，比如 playbooks、plays、任务、模块、和清单文件。这一节将继续提供示例去讲解使用 Ansible 实现网络自动化，而且将提供在不同类型的设备中自动化工作的模块的更多细节。示例中的将要进行自动化设备由多个供应商提供，包括 Cisco、Arista、Cumulus、和 Juniper。
|
||||
在前面的章节中，提供了 Ansible 术语的一个概述。它已经覆盖了大多数具体的 Ansible 术语，比如剧本、剧集、任务、模块和清单文件。这一节将继续提供示例去讲解使用 Ansible 实现网络自动化，而且将提供在不同类型的设备中自动化工作的模块的更多细节。示例中的将要进行自动化设备由多个供应商提供，包括 Cisco、Arista、Cumulus、和 Juniper。
|
||||
|
||||
在本节中的示例，假设的前提条件如下：
|
||||
|
||||
* Ansible 已经安装。
|
||||
|
||||
* 在设备中（NX-API、eAPI、NETCONF）适合的 APIs 已经启用。
|
||||
|
||||
* 用户在系统上有通过 API 去产生改变的适当权限。
|
||||
|
||||
* 所有的 Ansible 模块已经在系统中存在，并且也在库的路径变量中。
|
||||
|
||||
###### 注意
|
||||
> 注意：
|
||||
|
||||
可以在 _ansible.cfg_ 文件中设置模块和库路径。在你运行一个 playbook 时，你也可以使用 `-M` 标志从命令行中去改变它。
|
||||
> 可以在 `ansible.cfg` 文件中设置模块和库路径。在你运行一个剧本时，你也可以使用 `-M` 标志从命令行中去改变它。
|
||||
|
||||
在本节中示例使用的清单如下。（删除了密码，IP 地址也发生了变化）。在这个示例中，（和前面的示例一样）某些主机名并不是完全合格域名（FQDNs）。
|
||||
在本节中示例使用的清单如下。（删除了密码，IP 地址也发生了变化）。在这个示例中，（和前面的示例一样）某些主机名并不是完全合格域名（FQDN）。
|
||||
|
||||
|
||||
### 清单文件
|
||||
#### 清单文件
|
||||
|
||||
```
|
||||
[cumulus]
|
||||
@ -728,19 +703,19 @@ nx1 hostip=5.6.7.8 un=USERNAME pwd=PASSWORD
|
||||
vsrx hostip=9.10.11.12 un=USERNAME pwd=PASSWORD
|
||||
```
|
||||
|
||||
###### 注意
|
||||
> 注意：
|
||||
|
||||
正如你所知道的，Ansible 支持将密码存储在一个加密文件中的功能。如果你想学习关于这个特性的更多内容，请查看在 Ansible 网站上的文档中的 [Ansible Vault][5] 部分。
|
||||
> 正如你所知道的，Ansible 支持将密码存储在一个加密文件中的功能。如果你想学习关于这个特性的更多内容，请查看在 Ansible 网站上的文档中的 [Ansible Vault][5] 部分。
|
||||
|
||||
这个清单文件有四个组，每个组定义了一台单个的主机。让我们详细回顾一下每一节：
|
||||
|
||||
Cumulus
|
||||
**Cumulus**
|
||||
|
||||
主机 `cvx` 是一个 Cumulus Linux (CL) 交换机，并且它是 `cumulus` 组中的唯一设备。记住，CL 是原生 Linux，因此，这意味着它是使用默认连接机制（SSH）连到到需要自动化的 CL 交换机。因为 `cvx` 在 DNS 或者 _/etc/hosts_ 文件中没有定义，我们将让 Ansible 知道不要在清单文件中定义主机名，而是在 `ansible_ssh_host` 中定义的名字/IP。登陆到 CL 交换机的用户名被定义在 playbook 中，但是，你可以看到密码使用变量 `ansible_ssh_pass` 定义在清单文件中。
|
||||
主机 `cvx` 是一个 Cumulus Linux (CL) 交换机，并且它是 `cumulus` 组中的唯一设备。记住，CL 是原生 Linux，因此，这意味着它是使用默认连接机制（SSH）连到到需要自动化的 CL 交换机。因为 `cvx` 在 DNS 或者 `/etc/hosts` 文件中没有定义，我们将让 Ansible 知道不要在清单文件中定义主机名，而是在 `ansible_ssh_host` 中定义的名字/IP。登陆到 CL 交换机的用户名被定义在 playbook 中，但是，你可以看到密码使用变量 `ansible_ssh_pass` 定义在清单文件中。
|
||||
|
||||
Arista
|
||||
**Arista**
|
||||
|
||||
被称为 `veos1` 的是一台运行 EOS 的 Arista 交换机。它是在 `arista` 组中唯一的主机。正如你在 Arista 中看到的，在清单文件中并没有其它的参数存在。这是因为 Arista 为它们的设备使用了一个特定的配置文件。在我们的示例中它的名字为 _.eapi.conf_，它存在在 home 目录中。下面是正确使用配置文件的这个功能的示例：
|
||||
被称为 `veos1` 的是一台运行 EOS 的 Arista 交换机。它是在 `arista` 组中唯一的主机。正如你在 Arista 中看到的，在清单文件中并没有其它的参数存在。这是因为 Arista 为它们的设备使用了一个特定的配置文件。在我们的示例中它的名字为 `.eapi.conf`，它存在在 home 目录中。下面是正确使用配置文件的这个功能的示例：
|
||||
|
||||
```
|
||||
[connection:veos1]
|
||||
@ -749,27 +724,26 @@ username: unadmin
|
||||
password: pwadmin
|
||||
```
|
||||
|
||||
这个文件包含了定义在配置文件中的 Ansible 连接到设备（和 Arista 的被称为 _pyeapi_ 的 Python 库）所需要的全部信息。
|
||||
这个文件包含了定义在配置文件中的 Ansible 连接到设备（和 Arista 的被称为 `pyeapi` 的 Python 库）所需要的全部信息。
|
||||
|
||||
Cisco
|
||||
**Cisco**
|
||||
|
||||
和 Cumulus 和 Arista 一样，这里仅有一台主机（`nx1`）存在于 `cisco` 组中。这是一台 NX-OS-based Cisco Nexus 交换机。注意在这里为 `nx1` 定义了三个变量。它们包括 `un` 和 `pwd`，这是为了在 playbook 中访问和为了进入到 Cisco 模块去连接到设备。另外，这里有一个称为 `hostip` 的参数，它是必需的，因为，`nx1` 没有在 DNS 中或者是 _/etc/hosts_ 配置文件中定义。
|
||||
和 Cumulus 和 Arista 一样，这里仅有一台主机（`nx1`）存在于 `cisco` 组中。这是一台 NX-OS-based Cisco Nexus 交换机。注意在这里为 `nx1` 定义了三个变量。它们包括 `un` 和 `pwd`，这是为了在 playbook 中访问和为了进入到 Cisco 模块去连接到设备。另外，这里有一个称为 `hostip` 的参数，它是必需的，因为，`nx1` 没有在 DNS 中或者是 `/etc/hosts` 配置文件中定义。
|
||||
|
||||
> 注意：
|
||||
|
||||
###### 注意
|
||||
> 如果自动化一个原生的 Linux 设备，我们可以将这个参数命名为任何东西。`ansible_ssh_host` 被用于到如我们看到的那个 Cumulus 示例（如果在清单文件中的定义不能被解析）。在这个示例中，我们将一直使用 `ansible_ssh_host`，但是，它并不是必需的，因为我们将这个变量作为一个参数进入到 Cisco 模块，而 `ansible_ssh_host` 是在使用默认的 SSH 连接机制时自动检查的。
|
||||
|
||||
如果自动化一个原生的 Linux 设备，我们可以将这个参数命名为任何东西。`ansible_ssh_host` 被用于到如我们看到的那个 Cumulus 示例（如果在清单文件中的定义不能被解析）。在这个示例中，我们将一直使用 `ansible_ssh_host`，但是，它并不是必需的，因为我们将这个变量作为一个参数进入到 Cisco 模块，而 `ansible_ssh_host` 是在使用默认的 SSH 连接机制时自动检查的。
|
||||
|
||||
Juniper
|
||||
**Juniper**
|
||||
|
||||
和前面的三个组和主机一样，在 `juniper` 组中有一个单个的主机 `vsrx`。它在清单文件中的设置与 Cisco 相同，因为两者在 playbook 中使用了相同的方式。
|
||||
|
||||
|
||||
### Playbook
|
||||
### 剧本
|
||||
|
||||
接下来的 playbook 有四个不同的 plays。每个 play 是基于特定的供应商类型的设备组的自动化构建的。注意，那是在一个单个的 playbook 中执行这些任务的唯一的方法。这里还有其它的方法，它可以使用条件（`when` 语句）或者创建 Ansible 角色（它在这个报告中没有介绍）。
|
||||
接下来的剧本有四个不同的剧集。每个剧集是基于特定的供应商类型的设备组的自动化构建的。注意，那是在一个单个的剧本中执行这些任务的唯一的方法。这里还有其它的方法，它可以使用条件（`when` 语句）或者创建 Ansible 角色（它在这个报告中没有介绍）。
|
||||
|
||||
这里有一个 playbook 的示例：
|
||||
这里有一个剧本的示例：
|
||||
|
||||
```
|
||||
---
|
||||
@ -826,29 +800,29 @@ Juniper
|
||||
diffs_file=junpr.diff
|
||||
```
|
||||
|
||||
你将注意到，前面的两个 plays 是非常类似的，我们已经在最初的 Cisco 和 Arista 示例中讲过了。唯一的区别是每个要自动化的组（`cisco` and `arista`) 定义了它们自己的 play，我们在前面介绍使用 `when` 条件时比较过。
|
||||
你将注意到，前面的两个剧集是非常类似的，我们已经在最初的 Cisco 和 Arista 示例中讲过了。唯一的区别是每个要自动化的组（`cisco` and `arista`) 定义了它们自己的剧集，我们在前面介绍使用 `when` 条件时比较过。
|
||||
|
||||
这里有一个不正确的或者是错误的方式去做这些。这取决于你预先知道的信息是什么和适合你的环境和使用的最佳案例是什么，但我们的目的是为了展示做同一件事的几种不同的方法。
|
||||
|
||||
第三个 play 是在 Cumulus Linux 交换机的 `swp1` 接口上进行自动化配置。在这个 play 中的第一个任务是去确认 `swp1` 是一个三层接口，并且它配置的 IP 地址是 100.10.10.1。因为 Cumulus Linux 是原生的 Linux，网络服务在改变后需要重启才能生效。这也可以使用 Ansible 的操作来达到这个目的（这已经超出了本报告讨论的范围），这里有一个被称为 `service` 的 Ansible 核心模块来做这些，但它会中断交换机上的网络；使用 `ifreload` 重新启动则不会中断。
|
||||
第三个剧集是在 Cumulus Linux 交换机的 `swp1` 接口上进行自动化配置。在这个剧集中的第一个任务是去确认 `swp1` 是一个三层接口，并且它配置的 IP 地址是 100.10.10.1。因为 Cumulus Linux 是原生的 Linux，网络服务在改变后需要重启才能生效。这也可以使用 Ansible 的操作来达到这个目的（这已经超出了本报告讨论的范围），这里有一个被称为 `service` 的 Ansible 核心模块来做这些，但它会中断交换机上的网络；使用 `ifreload` 重新启动则不会中断。
|
||||
|
||||
本节到现在为止，我们已经讲解了专注于特定任务的 Ansible 模块，比如，配置接口和 VLANs。第四个 play 使用了另外的选项。我们将看到一个 _pushes_ 模块，它是一个完整的配置文件并且立即激活它作为正在运行的新的配置。这里将使用 `napalm_install_config`来展示前面的示例，但是，这个示例使用了一个 Juniper 专用的模块。
|
||||
本节到现在为止，我们已经讲解了专注于特定任务的 Ansible 模块，比如，配置接口和 VLAN。第四个剧集使用了另外的选项。我们将看到一个 `pushes` 模块，它是一个完整的配置文件并且立即激活它作为正在运行的新的配置。这里将使用 `napalm_install_config` 来展示前面的示例，但是，这个示例使用了一个 Juniper 专用的模块。
|
||||
|
||||
`junos_install_config` 模块接受几个参数，如下面的示例中所展示的。到现在为止，你应该理解了什么是 `user`、`passwd`、和 `host`。其它的参数定义如下：
|
||||
|
||||
`file`
|
||||
`file`：
|
||||
|
||||
这是一个从 Ansible 控制主机拷贝到 Juniper 设备的配置文件。
|
||||
|
||||
`logfile`
|
||||
`logfile`：
|
||||
|
||||
这是可选的，但是，如果你指定它，它会被用于存储运行这个模块时生成的信息。
|
||||
|
||||
`overwrite`
|
||||
`overwrite`：
|
||||
|
||||
当你设置为 yes/true 时，完整的配置将被发送的配置覆盖。（默认是 false）
|
||||
|
||||
`diffs_file`
|
||||
`diffs_file`：
|
||||
|
||||
这是可选的，但是，如果你指定它，当应用配置时，它将存储生成的差异。当应用配置时将存储一个生成的差异。当正好更改了主机名，但是，仍然发送了一个完整的配置文件时会生成一个差异，如下的示例：
|
||||
|
||||
@ -860,11 +834,11 @@ Juniper
|
||||
```
|
||||
|
||||
|
||||
上面已经介绍了 playbook 概述的细节。现在，让我们看看当 playbook 运行时发生了什么：
|
||||
上面已经介绍了剧本概述的细节。现在，让我们看看当剧本运行时发生了什么：
|
||||
|
||||
###### 注意
|
||||
> 注意：
|
||||
|
||||
注意：`-i` 标志是用于指定使用的清单文件。也可以设置环境变量 `ANSIBLE_HOSTS`，而不用每次运行 playbook 时都去使用一个 `-i` 标志。
|
||||
注意：`-i` 标志是用于指定使用的清单文件。也可以设置环境变量 `ANSIBLE_HOSTS`，而不用每次运行剧本时都去使用一个 `-i` 标志。
|
||||
|
||||
```
|
||||
ntc@ntc:~/ansible/multivendor$ ansible-playbook -i inventory demo.yml
|
||||
@ -942,12 +916,11 @@ veos1 : ok=1 changed=0 unreachable=0 failed=0
|
||||
vsrx : ok=1 changed=0 unreachable=0 failed=0
|
||||
```
|
||||
|
||||
注意：这里有 0 个改变，但是，每次运行任务，正如期望的那样，它们都返回 “ok”。说明在这个 playbook 中的每个模块都是幂等的。
|
||||
|
||||
注意：这里有 0 个改变，但是，每次运行任务，正如期望的那样，它们都返回 “ok”。说明在这个剧本中的每个模块都是幂等的。
|
||||
|
||||
### 总结
|
||||
|
||||
Ansible 是一个超级简单的、无代理和可扩展的自动化平台。网络社区持续不断地围绕 Ansible 去重整它作为一个能够执行一些自动化网络任务的平台，比如，做配置管理、数据收集和报告，等等。你可以使用 Ansible 去推送完整的配置文件，配置具体的使用幂等模块的网络资源，比如，接口、VLANs，或者，简单地自动收集信息，比如，领居、序列号、启动时间、和接口状态，以及按你的需要定制一个报告。
|
||||
Ansible 是一个超级简单的、无代理和可扩展的自动化平台。网络社区持续不断地围绕 Ansible 去重整它作为一个能够执行一些自动化网络任务的平台，比如，做配置管理、数据收集和报告，等等。你可以使用 Ansible 去推送完整的配置文件，配置具体的使用幂等模块的网络资源，比如，接口、VLAN，或者，简单地自动收集信息，比如，领居、序列号、启动时间、和接口状态，以及按你的需要定制一个报告。
|
||||
|
||||
因为它的架构，Ansible 被证明是一个在这里可用的、非常好的工具，它可以帮助你实现从传统的基于 _CLI/SNMP_ 的网络设备到基于 _API 驱动_ 的现代化网络设备的自动化。
|
||||
|
||||
@ -969,7 +942,7 @@ via: https://www.oreilly.com/learning/network-automation-with-ansible
|
||||
|
||||
作者：[Jason Edelman][a]
|
||||
译者：[qhwdw](https://github.com/qhwdw)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user