document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-03-06 01:20:12 +08:00
Code Issues Packages Projects Releases Wiki Activity

PRF:20160325 Network automation with Ansible.md

Browse Source 
部分校对
This commit is contained in:
Xingyu.Wang 2018-05-22 08:51:45 +08:00
parent c4ebf40497
commit ec85583945
1 changed files with 9 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
translated/tech/20160325 Network automation with Ansible.md
View File

@ -1,31 +1,33 @@
用 Ansible 实现网络自动化
================
> 了解 Ansible 的功能，这是一个无代理的、可扩展的配置管理系统。
### 网络自动化
随着 IT 行业的技术变化，从服务器虚拟化到公有和私有云，以及自服务能力、容器化应用、平台即服务（Paas）交付，一直以来落后的一个领域是网络。
随着 IT 行业的技术变化，从服务器虚拟化到公有云和私有云，以及自服务能力、容器化应用、平台即服务（PaaS）交付，有一直以来落后的一个领域就是网络。
在过去的五年多，网络行业似乎有很多新的趋势出现，它们中的很多被归入到软件定义网络（SDN）。
>注意
> SDN 是新出现的一种构建、管理、操作和部署网络的方法。SDN 最初的定义是需要将控制层和数据层（包转发）物理分离，并且，解耦合的控制层必须管理好各自的设备。
> SDN 是新出现的一种构建、管理、操作和部署网络的方法。SDN 最初的定义是出于将控制层和数据层（包转发）物理分离的需要，并且，解耦合的控制层必须管理好各自的设备。
> 如今，_在 SDN_ 旗下已经有许多技术，包括基于<ruby>控制器的网络<rt>controller-based networks</rt></ruby>、网络设备上的 API、网络自动化、白盒交换机、策略网络化、网络功能虚拟化（NFV）等等。
> 如今，在 SDN 旗下已经有许多技术，包括基于<ruby>控制器的网络<rt>controller-based networks</rt></ruby>、网络设备上的 API、网络自动化、白盒交换机、策略网络化、网络功能虚拟化（NFV）等等。
> 由于这篇报告的目的，我们参考 SDN 的解决方案作为我们的解决方案，其中包括一个网络控制器作为解决方案的一部分，并且提升了该网络的可管理性，但并不需要从数据层解耦控制层。
这些趋势的之一是，网络设备的 API 作为管理和操作这些设备的一种方法而出现，真正地提供了机器对机器的通讯。当需要自动化和构建网络应用时 API 简化了开发过程，在数据如何建模时提供了更多结构。例如，当启用 API 的设备在 JSON/XML 中返回数据时，它是结构化的，并且比返回原生文本信息、需要手工去解析的仅支持命令行的设备更易于使用。
这些趋势的之一是，网络设备的 API 作为管理和操作这些设备的一种方法而出现，真正地提供了机器对机器的通讯。当需要自动化和构建网络应用时 API 简化了开发过程，在数据如何建模时提供了更多结构。例如，当启用 API 的设备以 JSON/XML 返回数据时，它是结构化的，并且比返回原生文本信息、需要手工去解析的仅支持命令行的设备更易于使用。
在 API 之前，用于配置和管理网络设备的两个主要机制是命令行接口（CLI）和简单网络管理协议（SNMP）。让我们来了解一下它们，CLI 是一个设备的人机界面，而 SNMP 并不是为设备提供的实时编程接口。
幸运的是，因为很多供应商争相为设备增加 API，有时候 _正是因为_ 它被放到需求建议书（RFP）中，就带来了一个非常好的副作用 —— 支持网络自动化。当真正的 API 发布时，访问设备内数据的过程，以及管理配置，就会被极大简化，因此，我们将在本报告中对此进行评估。虽然使用许多传统方法也可以实现自动化，比如，CLI/SNMP。
幸运的是，因为很多供应商争相为设备增加 API，有时候 _只是因为_ 它被放到需求建议书（RFP）中，这就带来了一个非常好的副作用 —— 支持网络自动化。当真正的 API 发布时，访问设备内数据的过程，以及管理配置，就会被极大简化，因此，我们将在本报告中对此进行评估。虽然使用许多传统方法也可以实现自动化，比如，CLI/SNMP。
> 注意
> 随着未来几个月或几年的网络设备更新，供应商的 API 无疑应该被测试，并且要做为采购网络设备（虚拟和物理）的关键决策标准。如果供应商提供一些库或集成到自动化工具中，或者如果被用于一个开放的标准/协议，用户应该知道数据是如何通过设备建模的，API 使用的传输类型是什么。
> 随着未来几个月或几年的网络设备更新，供应商的 API 无疑应该被做为采购网络设备（虚拟和物理）的关键决策标准而测试和使用。如果供应商提供一些库或集成到自动化工具中，或者如果被用于一个开放的标准/协议，用户应该知道数据是如何通过设备建模的，API 使用的传输类型是什么。
总而言之，网络自动化，像大多数的自动化类型一样，是为了更快地工作。工作的更快是好事，降低部署和配置改变的时间并不总是许多 IT 组织需要去解决的问题。
总而言之，网络自动化，像大多数类型的自动化一样，是为了更快地工作。工作的更快是好事，降低部署和配置改变的时间并不总是许多 IT 组织需要去解决的问题。
包括速度，我们现在看看这些各种类型的 IT 组织逐渐采用网络自动化的几种原因。你应该注意到，同样的原则也适用于其它类型的自动化。