diff --git a/translated/tech/20160325 Network automation with Ansible.md b/translated/tech/20160325 Network automation with Ansible.md index f23824a7bc..2f4ebc9be1 100644 --- a/translated/tech/20160325 Network automation with Ansible.md +++ b/translated/tech/20160325 Network automation with Ansible.md @@ -31,19 +31,19 @@ 包括速度在内，我们现在看看这些各种类型的 IT 组织逐渐采用网络自动化的几种原因。你应该注意到，同样的原则也适用于其它类型的自动化。 -### 简化架构 +#### 简化架构 今天，每个网络都是一片独特的“雪花”，并且，网络工程师们为能够通过一次性的网络改变来解决传输和应用问题而感到自豪，而这最终导致网络不仅难以维护和管理，而且也很难去实现自动化。 网络自动化和管理需要从一开始就包含到新的架构和设计中去部署，而不是作为一个二级或三级项目。哪个特性可以跨不同的供应商工作？哪个扩展可以跨不同的平台工作？当使用具体的网络设备平台时，API 类型或者自动化工程是什么？当这些问题在设计过程之前得到答案，最终的架构将变成简单的、可重复的、并且易于维护 _和_ 自动化的，在整个网络中将很少启用供应商专用的扩展。 -### 确定的结果 +#### 确定的结果 在一个企业组织中，改变审查会议change review meeting会评估面临的网络变化、它们对外部系统的影响、以及回滚计划。在人们通过 CLI 来执行这些 _面临的变化_ 的世界上，输入错误的命令造成的影响是灾难性的。想像一下，一个有 3 位、4 位、5位，或者 50 位工程师的团队。每位工程师应对 _面临的变化_ 都有他们自己的独特的方法。并且，在管理这些变化的期间，一个人使用 CLI 或者 GUI 的能力并不会消除和减少出现错误的机率。 使用经过验证的和测试过的网络自动化可以帮助实现更多的可预测行为，并且使执行团队更有可能实现确实性的结果，首次在保证任务没有人为错误的情况下正确完成的道路上更进一步。 -### 业务灵活性 +#### 业务灵活性 不用说，网络自动化不仅为部署变化提供了速度和灵活性，而且使得根据业务需要去从网络设备中检索数据的速度变得更快。自从服务器虚拟化到来以后，服务器和虚拟化使得管理员有能力在瞬间去部署一个新的应用程序。而且，随着应用程序可以更快地部署，随之浮现的问题是为什么还需要花费如此长的时间配置一个 VLAN（虚拟局域网）、路由器、FW ACL（防火墙的访问控制列表）或者负载均衡策略呢？ @@ -61,7 +61,7 @@ _Ansible 是一个无需代理和可扩展的超级简单的自动化平台。_ 让我们更深入地了解它的细节，并且看一看那些使 Ansible 在行业内获得广泛认可的属性。 -### 简单 +#### 简单 Ansible 的其中一个吸引人的属性是，使用它你 **不** 需要特定的编程技能。所有的指令，或者说任务都是自动化的，以一个标准的、任何人都可以理解的人类可读的数据格式的文档化。在 30 分钟之内完成安装和自动化任务的情况并不罕见！ @@ -77,7 +77,7 @@ Ansible 的其中一个吸引人的属性是，使用它你 **不** 需要特定 > 这个报告的下半部分涉到 Ansible 术语（剧本playbook、行动play、任务task、模块module等等）的细节。在我们使用 Ansible 进行网络自动化时，提及这些关键概念时我们会有一些简短的示例。 -### 无代理 +#### 无代理 如果你看过市面上的其它工具，比如 Puppet 和 Chef，你会发现，一般情况下，它们要求每个实现自动化的设备必须安装特定的软件。这种情况在 Ansible 上 _并不_需要，这就是为什么 Ansible 是实现网络自动化的最佳选择的主要原因。 @@ -91,72 +91,65 @@ Ansible 的其中一个吸引人的属性是，使用它你 **不** 需要特定 在过去的二十多年里，几乎所有的网络操作系统都是闭源的，并且，垂直整合到底层的网络硬件中。没有供应商的支持，在一个网络设备中（路由器、交换机、负载均衡、防火墙、等等）载入一个代理并不那么轻松。有一个像 Ansible 这样的自动化平台，从头开始去构建一个无代理、可扩展的自动化平台，就像是它专门为网络行业订制的一样。我们最终将开始减少并消除与网络的人工交互。 -### 可扩展 +#### 可扩展 -Ansible 的可扩展性也非常的好。作为一个开源的，并且从代码开始将在网络行业中发挥重要的作用，有一个可扩展的平台是必需的。这意味着如果供应商或社区不提供一个特定的特性或功能，开源社区，终端用户，消费者，顾问者，或者，任何可能去 _扩展_ Ansible 的人，去启用一个给定的功能集。过去，网络供应商或者工具供应商通过一个 hook 去提供插件和集成。想像一下，使用一个像 Ansible 这样的自动化平台，并且，你选择的网络供应商发布了你 _真正_ 需要的自动化的一个新特性。从理论上说，网络供应商或者 Ansible 可以发行一个新的插件去实现自动化这个独特的特性，这是一件非常好的事情，从你的内部工程师到你的增值分销商（VARs）或者你的顾问中的任何人，都可以去提供这种集成。 - -正如前面所说的那样，Ansible 实际上是极具扩展性的，Ansible 最初就是为自动化应用程序和系统构建的。这是因为，Ansible 的可扩展性是被网络供应商编写集成的，包括但不限于 Cisco、Arista、Juniper、F5、HP、A10、Cumulus、和 Palo Alto Networks。 +Ansible 的可扩展性也非常的好。从开源、代码开始在网络行业中发挥重要的作用时起，有一个可扩展的平台是必需的。这意味着如果供应商或社区不提供一个特定的特性或功能，开源社区、终端用户、消费者、顾问，或者任何的人能够 _扩展_ Ansible 来启用一个给定的功能集。过去，网络供应商或者工具供应商通过一个 hook 去提供新的插件和集成。想像一下，使用一个像 Ansible 这样的自动化平台，并且，你选择的网络供应商发布了你 _真正_ 需要的一个自动化的新特性。从理论上说，网络供应商或者 Ansible 可以发行一个新的插件去实现自动化这个独特的特性，这是一件非常好的事情，从你的内部工程师到你的增值分销商（VAR）或者你的顾问中的任何一个人，都可以去提供这种集成。 +正如前面所说的那样，Ansible 实际上是极具扩展性的，Ansible 最初就是为自动化应用程序和系统构建的。这是因为，Ansible 的可扩展性来自于其集成性是为网络供应商编写的，包括但不限于 Cisco、Arista、Juniper、F5、HP、A10、Cumulus 和 Palo Alto Networks。 ### 对于网络自动化，为什么要使用 Ansible？ 我们已经简单了解除了 Ansible 是什么，以及一些网络自动化的好处，但是，对于网络自动化，我们为什么要使用 Ansible？ -在一个完全透明的环境下，已经说的很多的理由是 Ansible 可以做什么，比如，作为一个很大的自动化应用程序部署平台，但是，我们现在要深入一些，更多地关注于网络，并且继续总结一些更需要注意的其它关键点。 +大家很清楚，使得 Ansible 成为如此伟大的一个自动化应用部署平台的许多原因已经被大家所提及了。但是，我们现在要深入一些，更多地关注于网络，并且继续总结一些更需要注意的其它关键点。 +#### 无代理 -### 无代理 +在实现网络自动化的时候，无代理架构的重要性并不是重点强调的，特别是当它适用于现有的自动化设备时。如果，我们看一下当前网络中已经安装的各种设备时，从 DMZ 和园区，到分支机构和数据中心，最大份额的设备 _并不_ 具有最新 API 的设备。从自动化的角度来看，API 可以使做一些事情变得很简单，像 Ansible 这样的无代理平台有可能去自动化和管理那些 _老旧（传统）_ 的设备。例如，_基于 CLI 的设备_，它的工具可以被用于任何网络环境中。 + +> 注意： -在实现网络自动化的时候，无代理架构的重要性并不是重点强调的，特别是当它适用于现有的自动化设备时。如果，我们看一下当前网络中已经安装的各种设备时，从 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。 -如果仅 CLI 的设备已经集成进 Ansible，它的机制就像是，怎么在设备上通过协议如 telnet、SSH、和 SNMP，去进行只读访问和读写操作。 +所有的这些解决方案都简化了网络管理，就像它们可以让一个管理员开始从“box-by-box”管理（LCTT 译者注：指的是单个设备挨个去操作的意思）迁移到网络范围的管理。这是在正确方向上迈出的很大的一步，这些解决方案并不能消除在变更期间中人类犯错的机率。例如，比起配置 _N_ 个交换机，你可能需要去配置一个单个的 GUI，它需要很长的时间才能实现所需要的配置改变 —— 它甚至可能更复杂，毕竟，相对于一个 CLI，他们更喜欢 GUI！另外，你可能有不同类型的 SDN 解决方案部署在每个应用程序、网络、区域或者数据中心。 -作为一个独立的网络设备，像路由器、交换机、和防火墙持续去增加 APIs 的支持，SDN 解决方案也正在出现。SDN 解决方案的其中一个主题是，它们都提供一个单点集成和策略管理，通常是以一个 SDN 控制器的形式出现。这是真实的解决方案，比如，Cisco ACI、VMware NSX、Big Switch Big Cloud Fabric、和 Juniper Contrail，同时，其它的 SDN 提供者，比如 Nuage、Plexxi、Plumgrid、Midokura、和 Viptela。甚至包含开源的控制器，比如 OpenDaylight。 +在需要自动化的网络中，对于配置管理、监视和数据收集，当行业开始向基于控制器的网络架构中迁移时，这些需求并不会消失。 -所有的这些解决方案都简化了网络管理，就像他们允许一个管理员去开始从“box-by-box”管理（译者注：指的是单个设备挨个去操作的意思）迁移到网络范围的管理。这是在正确方向上迈出的很大的一步，这些解决方案并不能消除在改变窗口中人类犯错的机率。例如，比起配置 _N_ 个交换机，你可能需要去配置一个单个的 GUI，它需要很长的时间才能实现所需要的配置改变 — 它甚至可能更复杂，毕竟，相对于一个 CLI，他们更喜欢 GUI！另外，你可能有不同类型的 SDN 解决方案部署在每个应用程序、网络、区域、或者数据中心。 +大量的软件定义网络中都部署有控制器，几乎所有的控制器都提供expose一个最新的 REST API。并且，因为 Ansible 是一个无代理架构，它实现自动化是非常简单的，而不仅仅是对那些没有 API 的传统设备，但也有通过 REST API 的软件定义网络解决方案，在所有的终端上不需要有额外的软件（LCTT 译注：指的是代理）。最终的结果是，使用 Ansible，无论有或没有 API，可以使任何类型的设备都能够自动化。 -在需要自动化的网络中，对于配置管理、监视、和数据收集，当行业开始向基于控制器的网络架构中迁移时，这些需求并不会消失。 +#### 自由开源软件（FOSS) -大量的软件定义网络中都部署有控制器，所有最新的控制器都提供（expose）一个最新的 REST API。并且，因为 Ansible 是一个无代理架构，它实现自动化是非常简单的，而不仅仅是没有 API 的传统设备，但也有通过 REST APIs 的软件定义网络解决方案，在所有的终端上不需要有额外的软件（译者注：指的是代理）。最终的结果是，使用 Ansible，无论有或没有 API，可以使任何类型的设备都能够自动化。 +Ansible 是一个开源软件，它的全部代码在 GitHub 上都是公开可访问的，使用 Ansible 是完全免费的。它可以在几分钟内完成安装并为网络工程师提供有用的价值。Ansible 这个开源项目，或者 Ansible 公司，在它们交付软件之前，你不会遇到任何一个销售代表。那是显而易见的事实，因为它是一个真正的开源项目，但是，作为开源的、社区驱动的软件项目在网络行业中的使用是非常少的，但是，也在逐渐增加，我们想明确指出这一点。 +同样需要指出的一点是，Ansible, Inc. 也是一个公司，它也需要去赚钱，对吗？虽然 Ansible 是开源的，它也有一个叫 Ansible Tower 的企业产品，它增加了一些特性，比如，基于规则的访问控制（RBAC）、报告、 web UI、REST API、多租户等等，（相比 Ansible）它更适合于企业去部署。并且，更重要的是，Ansible Tower 甚至可以最多在 10 台设备上 _免费_ 使用，至少，你可以去体验一下，它是否会为你的组织带来好处，而无需花费一分钱，并且，也不需要与无数的销售代表去打交道。 -### 免费和开源软件（FOSS) +#### 可扩展性 -Ansible 是一个开源软件，它的全部代码在 GitHub 上都是公开的、可访问的，使用 Ansible 是完全免费的。它可以在几分钟内完成安装并为网络工程师提供有用的价值。Ansible，这个开源项目，或者 Ansible 公司，在它们交付软件之前，你不会遇到任何一个销售代表。那是显而易见的事实，因为它是一个真正的开源项目，但是，开源项目的使用，在网络行业中社区驱动的软件是非常少的，但是，也在逐渐增加，我们想明确指出这一点。 +我们在前面说过，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。 -同样需要指出的一点是，Ansible, Inc. 也是一个公司，它也需要去赚钱，对吗？虽然 Ansible 是开源的，它也有一个叫 Ansible Tower 的企业产品，它增加了一些特性，比如，基于规则的访问控制（RBAC）、报告、 web UI、REST APIs、多租户、等等，（相比 Ansible）它更适合于企业去部署。并且，更重要的是，Ansible Tower 甚至可以最多在 10 台设备上 _免费_ 使用，至少，你可以去体验一下，它是否会为你的组织带来好处，而无需花费一分钱，并且，也不需要与无数的销售代表去打交道。 +#### 集成到已存在的 DevOps 工作流中 +Ansible 在 IT 组织中被用于应用程序部署。它被用于需要管理部署、监视和管理各种类型的应用程序的运维团队中。通过将 Ansible 集成到网络基础设施中，当新应用程序到来或迁移后，它扩展了可能的范围。而不是去等待一个新的顶架交换机（LCTT 译注：TOR，一种数据中心设备接入的方式）的到来、去添加一个 VLAN、或者去检查接口的速度/双工，所有的这些以网络为中心的任务都可以被自动化，并且可以集成到 IT 组织内已经存在的工作流中。 -### 可扩展性 +#### 幂等性 -我们在前面说过，Ansible 主要是为部署 Linux 应用程序而构建的自动化平台，虽然从早期开始已经扩展到 Windows。需要指出的是，Ansible 开源项目并没有自动化网络基础设施的目标。事实上是，Ansible 社区更多地理解了在底层的 Ansible 架构上怎么更具灵活性和可扩展性，对于他们的自动化需要，它变成了 _扩展_ 的 Ansible，它包含了网络。在过去的两年中，部署有许多的 Ansible 集成，许多行业独立人士（industry independents），比如，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。 +术语幂等性idempotency （读作 item-potency）经常用于软件开发的领域中，尤其是当使用 REST API 工作的时候，以及在 _DevOps_ 自动化和配置管理框架的领域中，包括 Ansible。Ansible 的其中一个信念是，所有的 Ansible 模块（集成的）应该是幂等的。那么，对于一个模块来说，幂等是什么意思呢？毕竟，对大多数网络工程师来说，这是一个新的术语。 +答案很简单。幂等性的本质是允许定义的任务，运行一次或者上千次都不会在目标系统上产生不利影响，仅仅是一种一次性的改变。换句话说，如果有一个要做的改变去使系统进入到它期望的状态，这种改变完成之后，并且，如果这个设备已经达到这种状态，就不会再发生改变。这不像大多数传统的定制脚本和拷贝、黏贴到那些终端窗口中的 CLI 命令。当相同的命令或者脚本在同一个系统上重复运行，（有时候）会出现错误。即使是粘贴一组命令到一个路由器中，也可能会遇到一些使你的其余的配置失效的错误。好玩吧? -### 集成到已存在的 DevOps 工作流中 +另外的例子是，如果你有一个配置 10 个 VLAN 的文件文件或者脚本，那么 _每次_ 运行这个脚本，相同的命令命令会被输入 10 次。如果使用一个幂等的 Ansible 模块，首先会从网络设备中采集已存在的配置，并且，每个新的 VLAN 被配置后会再次检查当前配置。仅仅当这个新的 VLAN 需要被添加（或者，比如说改变 VLAN 名字）是一个变更，命令才会真实地推送到设备。 -Ansible 在 IT 组织中被用于应用程序部署。它被用于需要管理部署、监视、和管理各种类型的应用程序的操作团队中。通过将 Ansible 集成到网络基础设施中，当新应用程序到来或迁移后，它扩展了可能的范围。而不是去等待一个新的顶架交换机（TOR，译者注：一种数据中心设备接入的方式）的到来、去添加一个 VLAN、或者去检查接口的速度/双工，所有的这些以网络为中心的任务都可以被自动化，并且可以集成到 IT 组织内已经存在的工作流中。 +当一个技术越来越复杂，幂等性的价值就越高，在你修改的时候，你并不能注意到 _已存在_ 的网络设备的状态，而仅仅是从一个网络配置和策略角度去尝试达到 _期望的_ 状态。 +#### 网络范围的和临时（Ad Hoc）的改变 -### 幂等性 +用配置管理工具解决的其中一个问题是，配置“飘移”（当设备的期望配置逐渐漂移，或者改变，随着时间的推移，手动改变和/或在一个环境中使用了多个不同的工具），事实上，这也是像 Puppet 和 Chef 所使用的地方。代理商电联phone home到前端服务器，验证它的配置，并且，如果需要变更，则改变它。这个方法是非常简单的。如果有故障了，需要去排除怎么办？你通常需要跳过管理系统，直接连到设备，找到并修复它，然后，马上离开，对不对？果然，在下次当代理电连回来，这个修复问题的改变被覆盖了（基于主/前端服务器是怎么配置的）。在高度自动化的环境中，一次性的改变应该被限制，但是，仍然允许使用它们（LCTT 译注：指的是一次性改变）的工具是非常有价值的。正如你想到的，其中一个这样的工具是 Ansible。 -术语 _幂等性_ （明显能提升项目的效能） 经常用于软件开发的领域中，尤其是当使用 REST APIs工作的时候，以及在 _DevOps_ 自动化和配置管理框架的领域中，包括 Ansible。Ansible 的其中一个信念是，所有的 Ansible 模块（集成的）应该是幂等的。那么，对于一个模块来说，幂等是什么意思呢？毕竟，对大多数网络工程师来说，这是一个新的术语。 +因为 Ansible 是无代理的，这里并没有一个默认的推送或者拉取去防止配置漂移。自动化任务被定义在 Ansible playbook中，当使用 Ansible 时，它让用户去运行剧本。如果剧本在一个给定的时间间隔内运行，并且你没有用 Ansible Tower，你肯定知道任务的执行频率；如果你只是在终端提示符下使用一个原生的 Ansible 命令行，那么该剧本就运行一次，并且仅运行一次。 -答案很简单。幂等性的本质是允许定义的任务，运行一次或者上千次都不会在目标系统上产生不利影响，仅仅是一种一次性的改变。换句话说，如果一个请求的改变去使系统进入到它期望的状态，这种改变完成之后，并且，如果这个设备已经达到这种状态，它不会再发生改变。这不像大多数传统的定制脚本，和拷贝（copy），以及过去的那些终端窗口中的 CLI 命令。当相同的命令或者脚本在同一个系统上重复运行，会出现错误（有时候）。以前，粘贴一组命令到一个路由器中，然后得到一些使你的其余的配置失效的错误类型？好玩吧? - -另外的例子是，如果你有一个配置 10 个 VLANs 的文件文件或者脚本，那么 _每次_ 运行这个脚本，相同的命令命令会被输入 10 次。如果使用一个幂等的 Ansible 模块，首先会从网络设备中采集已存在的配置，并且，每个新的 VLAN 被配置后会再次检查当前配置。仅仅是这个新的 VLAN 需要去被添加（或者，改变 VLAN 名字，作为一个示例）是一个改变，或者命令真实地推送到设备。 - -当一个技术越来越复杂，幂等性的价值就越高，在你修改的时候，你并不能注意到 _已存在_ 的网络设备的状态，仅仅是从一个网络配置和策略角度去尝试达到 _期望的_ 状态。 - - -### 网络范围的和临时（Ad Hoc）的改变 - -用配置管理工具解决的其中一个问题是，配置“飘移”（当设备的期望配置逐渐漂移，或者改变，随着时间的推移手动改变和/或在一个环境中使用了多个不同的工具），事实上，这也是像 Puppet 和 Chef 得到使用的地方。代理商 _phone home_ 到前端服务器，验证它的配置，并且，如果需要一个改变，则改变它。这个方法是非常简单的。如果有故障了，需要去排除怎么办？你通常需要通过管理系统，直接连到设备，找到并修复它，然后，马上离开，对不对？果然，在下次当代理的电话打到家里，修复问题的改变被覆盖了（基于主/前端服务器是怎么配置的）。在高度自动化的环境中，一次性的改变应该被限制，但是，仍然允许它们（译者注：指的是一次性改变）使用的工具是非常有价值的。正如你想到的，其中一个这样的工具是 Ansible。 - -因为 Ansible 是无代理的，这里并没有一个默认的推送或者拉取去防止配置漂移。自动化任务被定义在 Ansible playbook 中，当使用 Ansible 时，它推送到用户去运行 playbook。如果 playbook 在一个给定的时间间隔内运行，并且你没有用 Ansible Tower，你肯定知道任务的执行频率；如果你正好在终端提示符下使用一个原生的 Ansible 命令行，playbook 运行一次，并且仅运行一次。 - -缺省运行的 playbook 对网络工程师是很具有吸引力的，让人欣慰的是，在设备上手动进行的改变不会自动被覆盖。另外，当需要的时候，一个 playbook 运行的设备范围很容易被改变，即使是对一个单个设备进行自动化的单次改变，Ansible 仍然可以用，设备的 _范围_ 由一个被称为 Ansible 清单（inventory）的文件决定；这个清单可以是一台设备或者是一千台设备。 +缺省运行一次的剧本对网络工程师是很具有吸引力的，让人欣慰的是，在设备上手动进行的改变不会自动被覆盖。另外，当需要的时候，一个剧本所运行的设备范围很容易被改变，即使是对一个单个设备进行自动化的单次变更，Ansible 仍然可以用，设备的 _范围_ 由一个被称为 Ansible 清单inventory的文件决定；这个清单可以是一台设备或者是一千台设备。 下面展示的一个清单文件示例，它定义了两组共六台设备： @@ -172,13 +165,13 @@ leaf3 leaf4 ``` -为了自动化所有的主机，你的 play 定义的 playbook 的一个片段看起来应该是这样的： +为了自动化所有的主机，你的剧本中的行动play定义的一个片段看起来应该是这样的： ``` hosts: all ``` -并且，一个自动化的叶子节点交换机，它看起来应该像这样： +并且，要只自动化一个叶子节点交换机，它看起来应该像这样： ``` hosts: leaf1 @@ -190,11 +183,11 @@ hosts: leaf1 hosts: core-switches ``` -###### 注意 +> 注意 -正如前面所说的那样，这个报告的后面部分将详细介绍 playbooks、plays、和清单（inventories）。 +> 正如前面所说的那样，这个报告的后面部分将详细介绍剧本、行动、和清单。 -因为能够很容易地对一台设备或者 _N_ 台设备进行自动化，所以在需要对这些设备进行一次性改变时，Ansible 成为了最佳的选择。在网络范围内的改变它也做的很好：可以是关闭给定类型的所有接口、配置接口描述、或者是在一个跨企业园区布线的网络中添加 VLANs。 +因为能够很容易地对一台设备或者 _N_ 台设备进行自动化，所以在需要对这些设备进行一次性变更时，Ansible 成为了最佳的选择。在网络范围内的变更它也做的很好：可以是关闭给定类型的所有接口、配置接口描述、或者是在一个跨企业园区布线的网络中添加 VLAN。 ### 使用 Ansible 实现网络任务自动化