作者：余欣
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
NetDevOps入门与实践试读：
前言
为什么要写这本书清晨，我们做的第一件事是什么？睁开眼。睁开眼看手机里的朋友圈是否有更新，昨晚下的单是否已经安排送货，今天的天气是否依旧晴朗。而这些信息的更新都是通过互联网传递到你的手机上。在很多人眼里，手机有电而没有网络是一件非常痛苦的事情。互联网在中国的发展也就是20来年的事，但它已经渗透到了我们工作、学习和生活的方方面面。网络是新时代的基础设施，无论上面有多么丰富多彩的应用软件，它们都离不开网络。这些年，应用软件的迭代速度非常快。而网络在这几十年中却没有发生多大的变化（虽然网络带宽一直在指数级增长）。特别是网络工程师们日常的工作似乎还是和10年前甚至20年前一样。虽然，这几年SDN（Software Defined Networks）在快速发展，但是物理网络仍然没有发生多大的变化。大量的网络工程师还是通过Telnet或SSH登录到网络设备上，然后一条一条地敲击各种各样的命令。应用软件越来越多，应用软件生命周期越来越短。这对网络提出了很多的挑战，网络工程师的工作压力也是直线上升。这几年随着上层应用DevOps思想的发展，网络自动化的需求也在不断提升。那些安分守己的传统网络工程师面临着转型的痛苦。
我是一个和网络打交道20来年的传统网络工程师，但我一直是一个不安分守己且会偷懒的人。早在我大学期间，为了和同寝室的同学一起玩一款叫“红色警戒”的游戏而接触了网络。从两台电脑之间使用串口互联进行对战，到使用同轴电缆后8个同学可以在一个地图中互相厮杀，再到1999年通过双绞线接入互联网。那个时候，几个寝室的双绞线都汇聚到了我们寝室，我不知不觉也成了96级化学系的网络管理员。日常的“工作”就是帮同学看看网络怎么不通了；谁的IP地址又和谁冲突了；如何从其他同学的电脑里复制一些电脑游戏等。活脱脱就是一个小型网吧的工作人员。随着1999年学校寝室接入了互联网，出于对“工作”的热情，我开始用Linux自己搭建一些服务，比如DHCP、DNS、FTP、BBS等。慢慢又干起了系统管理员的“工作”。
在千禧年（2000年）的毕业季，我的第一份工作是在一家大型的纺织公司做系统管理员和DBA。这份工作和化学没有任何的关系。而日常的工作就是帮助新员工开账号，每天备份那些数据库的数据到磁带中。为了减少自己日常的工作就开始写一些自动化的脚本。其实，当时就是为了每天能偷点懒。开一个账号，懒得去点那么多次的鼠标。每天的备份任务，懒得去一个个地核对和比较，而是让脚本自己去核对，自己去比较，然后把检查后的结果发送E-mail给我。
2003年考完CCIE后到一家为中国电信服务的系统集成公司。在这家公司有幸参与了中国电信CN2（ChinaNet2）的建设工作。在网络建设的初期有大量的设备配置需要增加和修改。纯手工的操作让我觉得痛苦不堪，此时又萌生了“偷懒”的思想。我开始用Python、Perl等语言写了一些脚本用于设备配置的生成和修改。当时设备并没有丰富的API接口，大部分都是用Telnet模拟登录来操作设备。
2007年我进入了Juniper工作，在这里接触了更多的网络自动化的内容，也写了很多自动化脚本来操作网络设备。比如，2008年考完JNCIE后，有幸做了一年多的中国区JNCIE考官。JNCIE的考官除了要发卷子外，还需要负责给考生判卷。也是为了“偷点懒”写了一些自己用的脚本提高判卷的效率。2009年开始学习JUNOScript（一种可以运行在JUNOS上的脚本语言），用JUNOScript来实现一些特殊的功能或者对命令进行重新格式化的输出。2010年后由于需要经常参加设备的测试，开始使用Python等语言对JUNOS设备基于NETCONF协议进行操作。
2014年到2016年，我先后在两家互联网公司做网络工程师，负责网络的规划与运维工作。由于互联网公司自身的产品迭代速度很快，对网络的适配性也提出了更多的需求。虽然在互联网公司有很多的程序员，但大部分的程序员对网络和网络设备的理解远逊于网络工程师。这就导致了网络自动化的开发工作比较难推进。因此，我结合自己的编程能力和对网络的理解开始用代码去实现网络自动化的任务。
从2016年到现在，我一直在Cisco工作。在这里我接触到了DevNet（https://developer.cisco.com）。在DevNet的网站上我看到和学习了很多关于基础网络设备的编程知识。在2016年，Cisco发布了思科全数字化网络架构（思科DNA），这个平台不仅提供了实现全数字化的路线图，而且为网络工程师提供了网络自动化和网络安全的途径。这个平台的很多理念和架构为我写这本书提供了很多的帮助。
在这20来年的时间里，我积累了一些使用程序来操作网络设备的经验。一方面是想把这些经验分享给大家；另一方面也是想帮助那些想转型的传统网络工程师。这就是我写这本书的初衷。另外，我还想告诉广大的网络工程师们开发一个小工具用来管理设备其实并没有那么难。对于我这样一个非软件专业的人而言并没有觉得吃力，反而在开发中获得了更多的自信，也偷了“懒”。
最后，希望这本书能给广大的网络工程师在转型过程中带来一些帮助，也希望大家能少走弯路。本书特色
首先，本书是专门针对网络工程师而写的。书中关于Bash和Python的基本语法部分使用了网络工程师更加熟悉的内容，并且提供了一些网络设备上的运行情况。
其次，本书的重点是如何编写和网络设备相关的代码。因此，在书中提供了很多关于如何处理网络设备输出的文本的例子，以及处理网络相关的数据。
最后，本书并不是一本纯粹讲解编程的书，而是一本从理论到实践的综合书籍。读者对象
·网络架构师
·网络运维工程师
·网络运维开发人员
·网络与系统管理人员
·网络规划与设计人员
·网络专业在校学生如何阅读本书
本书分为五篇，共计14章内容。
第一篇为概念篇，这一篇主要讲述什么是NetDevOps，以及如何开始NetDevOps实践之路，包括如下2章内容。
第1章 从SDN开始谈起，讲解在SDN的大背景下，传统的网络都发生了什么变化，而这些变化给传统网络工程师带来了哪些影响。最后介绍了什么是NetDevOps，NetDevOps需要我们学习什么样的技能才能胜任。
第2章 在业务快速迭代的推动下，传统IP网络的自动化需求在不断增强。大量的网络工程师面临着新的挑战。这章介绍如何从零开始逐步过渡到NetDevOps。这章将重点讲解4个话题：首先，在NetDevOps开始之前需要做什么；其次，在进行NetDevOps开发时，如何选择开发语言；再次，一些常见的NetDevOps开源工具或平台如何选择；最后，在进行NetDevOps时，对网络设备有哪些要求。
第二篇为基础篇，这一篇主要介绍了如何构建NetDevOps的工作环境以及在这些环境中的常用工具，包括如下4章内容。
第3章 介绍在Linux环境下，如何使用Linux下的工具登录网络设备，以及使用SSH工具建立一些SSH的隧道。
第4章 介绍在Linux环境下，如何使用一些工具获取网络设备的信息，以及获取网络的可达信息，涵盖SNMP、traceroute、ping等工具。
第5章 使用Linux中三大文本处理利器（grep、awk和sed）来处理网络设备输出的文本内容。这些文本内容包括命令行的输出、设备的配置以及设备的日志信息等。这些工具可以帮助网络工程师快速地获取相关的数据和信息。
第6章 在NetDevOps的实践过程中，我们需要搭建一些基础的服务。这些服务包括TFTP、DNS和DHCP等。在微模块流行的时代，网络工程师使用Docker可以快速地构建起这些基础服务。
第三篇为提高篇，这一篇将开始介绍编程相关的内容。这一篇都是编程的一些基础知识，包括如下3章内容。
第7章 这一章主要介绍Linux环境或网络设备上的Bash编程基础知识。通过Bash基本语法并结合一些工具，我们可以和设备进行简单的交互或处理一些数据。
第8章 这一章主要介绍Python的编程知识。本书的大部分编程内容都是基于Python语言的。因此，这一章是后续章节的基础。这一章关于Python的基本语法是专门为网络工程师重新编写的。使用的例子将是网络工程师比较熟悉的内容。
第9章 我们在和网络设备进行交互或者进行网络相关的编程时，经常需要处理一些常用的数据类型，这些数据类型包括JSON、XML、YAML和YANG。熟练掌握这些数据类型的处理是编程的基础。在这章，我们将介绍上述这四种数据类型的常用处理方法。
第四篇为实践篇，这一篇将通过一些实际的例子来介绍，包括如下3章内容。
第10章 NetDevOps必然需要和网络设备进行交互，从而获得我们需要的数据。本章将介绍三种常见的连接网络设备的方法，它们分别是：命令行登录、NETCONF以及REST。
第11章 连接到网络设备后就可以获取很多的信息，其中通过命令行获取的数据大部分是半结构化的数据。这些半结构化的数据需要进行结构化处理。这一章将通过几个Python的模块来处理这些数据。
第12章 我们在处理网络相关数据时，有两种常见且特殊的数据需要处理，它们分别是网络地址和网络拓扑数据。同样，我们将通过几个Python的模块来处理这些数据。
第五部分为案例篇，这一篇将介绍3个常见的案例来帮助大家更好地了解和掌握NetDevOps的相关内容，包括如下两章内容。
第13章 众所周知，绝大多数的网络设备都会有配置文件，获取和管理这些配置文件是NetDevOps工作的基础。通过程序化的方式自动地获取这些配置就打通了程序和网络设备之间的通道，这是后续获取更多信息的基础。另外，网络设备的配置文件也是最需要且被优先管理的内容，这些内容的版本管理也是非常重要的。本章将通过网络设备的配置管理案例来描述如何多厂家、并发地与网络设备进行数据交互。
第14章 网络运维与管理的独特之处是，该工作是基于网络拓扑的。获取和处理网络拓扑是基本功能。该章通过两个小的案例来介绍，它们分别是：基于ISIS协议来获取网络拓扑并进行简单的网络拓扑分析；使用BGP协议进行简单的网络流量调度。
其中，本书的第2章、第8章、第9章、第10章、第11章是重点。如果你有一定的Python编程基础，那么可以参考第9章及之后的章节，这些章节提供了Python用于网络管理与维护常用的一些模块，这些模块可以提高你的工作效率。如果你是一位传统的网络工程师且对编程和Linux环境不是十分了解，请从本书的开头读起。笔者希望通过本书的内容能循序渐进地带领大家走上NetDevOps之路。勘误和支持
由于笔者的水平有限，编写时间仓促，书中难免会出现一些错误或者不准确的地方，恳请读者批评指正。如果读者朋友有更多的宝贵意见，欢迎你发送邮件到netdevops@hotmail.com联系我。本书的大部分代码示例都放在GitHub上，其地址为https://github.com/netdevops-engineer/newbie_book。期待能够得到大家的真挚反馈，在技术之路上互勉共进。特别致谢
这里要特别感谢毛厚君先生，他是这本书的第一位读者，不但给了我很多的宝贵建议，而且帮我润色了全书的文字。如果没有他的帮助我想是很难完成这本书的。致谢
在本书的写作过程中得到了很多同事和朋友的支持与帮助。没有你们的支持与帮助，本书将难以如期完成。
在本书的写作过程中需要实验环境，感谢徐晓东先生为我提供了便利。
感谢思科同事们的支持和鼓励，他们是方芳女士、徐志骏先生、杨骏先生、刘佳女士等。
感谢身在美国的朋友杨文嘉先生提供了关于Arista产品和技术的相关信息。
最后，我要特别感谢我的家人，我为写作这本书，牺牲了很多陪伴他们的时间，但也正因为有了他们的付出与支持，我才能坚持写下去。
谨以此书献给我最亲爱的人，以及众多的网络工程师朋友们！余欣—·第一篇·—概念篇
欢迎来到《NetDevOps入门与实践》。
在第1章，我们将讨论一下NetDevOps的一些基本概念以及NetDevOps与SDN（软件定义网络）相关的一些内容，并且介绍一下为什么需要NetDevOps。
第2章主要涉及如何开始NetDevOps。随着上层业务的推动，传统的IP网络面临着前所未有的挑战，网络的自动化需求在不断增强，如何从零开始逐步向NetDevOps过渡，这是目前大量传统网络工程师的困惑所在。本章将涉及以下几个话题：
·开始NetDevOps之前首先需要做什么；
·关于NetDevOps语言的选择问题；
·一些常见的NetDevOps开源工具的选择；
·网络设备需要具备什么能力以及如何来管理它们。第1章NetDevOps理念与要义
自从20世纪八九十年代Internet（互联网）出现以来，IP网络在全球出现了爆发式发展。近几年来，随着大量计算机网络应用，特别是云计算、大数据以及互联网+在各行各业的渗透，网络变得无处不在。虽然网络不是万能的，但是现代社会没有网络几乎已经变成万万不能了。各种各样纷繁复杂的应用都承载在IP网络之上，网络规模变得越来越大，网络结构也变得越来越复杂。这些变化给网络工程师带来的压力在逐年增加。如何提高网络运维的效率、提升网络操作准确性以及网络业务可用性是网络工程师一直在苦苦探索的方向。
对于NetDevOps，你需要向广大网络工程师、网络规划人员以及大部分运维平台开发工程师解释清楚它到底是什么、它包含哪些内容，以及它和这几年火热的SDN（软件定义网络）有什么关系。1.1 从SDN开始说起
在这几年的IT圈子中，最火的名词有云计算、大数据以及人工智能（AI）。在网络，特别是基础网络圈子里，最火的也许就是SDN与NFV了。我们在全球IT相关的大会中都可以看到它们的身影。在国内，网络厂商的技术交流会，以及互联网公司、运营商、企业的技术分享会都会提到SDN和NFV相关的解决方案。在网络运营与维护工程师聚集的论坛里也经常看到它们的主题。比如，NANOG（北美网络运维论坛https://www.nanog.org）也有SDN与NFV相关的内容。作为在网络行业中工作了近20年的网络工程师，笔者和很多在这个行业中的网络工程师们一样，对于SDN，也许一开始是拒绝的。但是随着SDN的声音越来越大，参与的人也越来越多，很多像笔者一样的网络工程师也开始关注和参与到这个领域。
那么SDN究竟和NetDevOps有什么关系或关联呢？正是SDN的出现和发展，推动了传统网络设备管理维护方式的变革：一方面，SDN让网络工程师不再只依赖CLI命令行（部分Web）方式对设备进行逐台的操作管理，毕竟逐台通过CLI的管理方式是一种非常低效且容易出错的运维方式；另一方面，SDN推动了传统网络设备厂商自身的变革，各厂商开放出更多的API接口，供用户侧进行自动化的编排和调用。自动化这几年的呼声越来越大，自动化上线、自动化部署、自动化运维、自动化修复，甚至还可以和业务进一步结合。实际上，NetDevOps追求的目标就是网络资源的接口化、自动化以及智能化。借助于NetDevOps，我们可以提高运维的工作效率，提升业务部署的准确性，提供网络资源的可编程性。
在正式进入NetDevOps之前，我们先来了解一下SDN的发展状况。无论是SDN具体的技术细节，还是SDN的建设思想，SDN对全球的学术研究机构、标准化组织以及设备厂商都已经产生了深远的影响。了解SDN技术的概貌及其相关的实现架构，有助于我们理解NetDevOps。1.1.1 OpenFlow打开了新的一扇窗
对于OpenFlow，我想大家应该并不陌生。有人认为OpenFlow是SDN的“Hello World”，也有人觉得它给网络带来了新的活力。众所周知，Martin Casado在斯坦福大学读博士期间领导并开发了OpenFlow协议，当时他的博士导师是Nick McKeown。这个协议不仅定义了网络设备数据转发平面的内容，同时也定义了控制平面的内容。简单来说，通过OpenFlow，可以把控制平面从硬件中剥离出来，可以开发出更加智能、更加集中的控制中心。而转发平面把原来网络设备ASIC等芯片进行了更加高级的抽象化处理，让开发人员不用深入了解硬件底层的处理方式，就能够获得硬件带来的性能。《OF-[1]CONFIG 1.2ONF TS-0161》白皮书给出OpenFlow高度抽象的逻辑图（见图1-1）。从这个图中，我们可以清晰地看出：OpenFlow协议是OpenFlow控制器与OpenFlow交换机之间通信的协议，而交换机的其他操作使用了OF-Config这个接口协议。如果我们把这个结构映射到传统的路由器或者交换机中，OpenFlow协议可以类比为传统设备的RIB（Routing Information Base，路由信息表）与FIB（Forwarding Information Base，转发信息表）之间的协议。图1-1 OpenFlow逻辑图
对于传统的网络设备，这里的通信协议往往是私有的，并没有开放给普通的使用者；而OpenFlow协议则定义了这部分内容。除了OpenFlow协议，OF-Config定义的是如何管理和运维网络设备。OF-Config定义了机器与机器之间的交互方式。它和设备之间的通信使用NETCONF作为底层的通信协议，使用了大量的YANG模型对数据结构进行了定义，并且给出了UML（Unified Modeling Language，统一建模语言）的结构。
OpenFlow协议本身并不是一场变革，它所描述的方式、方法不是传统网络工程师所熟悉的领域，反而是软件工程师所熟悉的领域，它从另外一个视角来描述网络的管理与维护工作。它让传统的人机交互命令演变为控制器与机器之间的交互，从而可以实现集中化、统一化和程序化的网络管理维护方式。
NetDevOps的初衷也是希望通过机器与机器之间的交互来实现更加高效、更加准确的网络管理，而不只限于对网络设备的管理；另外，也希望通过对网络资源进行二次封装，从而为上层应用提供简单灵活的编程接口。1.1.2 简单聊聊SDN控制器
接着前面谈到的OpenFlow相关的一些内容。OpenFlow自身并没有定义和解决控制平面的问题。在OpenFlow应用场景中，我们通过SDN控制器来保证运行OpenFlow的网络能正常地运作。SDN控制器完成的是控制平面的工作，它是通过软件来实现的。为了满足不同场景的应用需求，控制器的内容会更加抽象化，在表述控制器功能的时候也更加软件工程化。在SDN网络（包括OpenFlow网络）中，和智能相关的内容大部分由SDN控制器（OpenFlow网络对应的控制器通常称为OpenFlow控制器）完成和实现。“控制平面与转发平面分离”是SDN网络与传统网络的主要区别。转发平面常常被定义为毫无智能可言的“傻终端”，完全根据控制平面的指令来进行转发。
在开源的世界里，目前比较主流的SDN控制器如下：
·OpenDayLight（https://github.com/opendaylight）；
·ONOS（https://github.com/opennetworkinglab/onos）；
·Ryu（https://github.com/osrg/ryu）；
·Floodlight（https://github.com/floodlight/floodlight）。
SDN控制器软件有很多，上面列出的只是其中很少的一部分。SDN并不是本书的重点，因此也不会在这里详细的展开，有兴趣的读者可以找相关的书籍或者文章进行了解。
在这里，我们以OpenDayLight（简称ODL）为例子简单地看一下SDN控制器的框架设计图（https://www.opendaylight.org/odlboron网站提供了更加清晰的图片）。
从OpenDayLight硼版本框架结构图（见图1-2）中，可以清晰地看出以下几点。
首先，最下方是网络设备，既包括具备OpenFlow功能的设备，也包括Open vSwith这样纯软件的设备，还包括了一些其他的硬件物理设备。
其次，ODL的南向接口（即控制器与网元设备通信的接口）不单单只有OpenFlow与OF-Config，还包括NETCONF、BGP、PCEP、SNMP等多种接口。ODL实现了基于南向接口的网络服务抽象层和基于抽象服务的接口转换。通过这一层的转换，能够让网络设备提供的描述方式和能力转化为面向业务的描述方式及接口。这就方便了应用层的开发人员进行网络相关应用程序的开发，他们并不需要深入了解网络底层的内容。
最后，控制器提供了北向API接口（有RESTful、RESTCONF、NETCONF等接口类型），这是应用开发人员编程所使用的接口。其他更加上层的系统或者平台可以通过调用这些接口来完成其开发，完成应用对网络的调度和管理。ODL提供了GUI的开发框架，应用开发人员也可以基于这个开发框架来开发应用程序，并实现对网络的管理和调用。图1-2 OpenDayLight硼版本框架结构图
总之，SDN控制器软件是应用开发人员和网络设备（无论是硬件的还是软件的）之间的桥梁。通过SDN控制器，应用开发人员可以更多地专注于业务逻辑，从而开发与网络相关的应用程序。因此，在SDN控制器设计的时候，无论是南向接口还是北向接口都会更加关注机器与机器之间的接口。这也许是很多的传统网络工程师感觉SDN控制器比较难学习和难以掌握的地方。正像前面提到的，网络工程师擅长的还是人与机器交互的界面，这也导致了网络工程师在接触SDN控制器时，通常也只是关注SDN控制器所提供的Web UI功能的原因。这样的思路需要转变，无论是SDN还是NetDevOps，都应该更加关注机器和机器之间的接口部分。1.1.3 NFV
随着SDN（软件定义网络）的发展，NFV（Network Functions Virtualization，网络功能虚拟化）在SDN领域也越来越多地被提及。NFV是ETSI（European Telecommunications Standards Institute，欧[2]洲电信标准协会）在2012年10月发布的白皮书中定义的。但是，NFV这样的产品形态并不是2012年后才有。例如，2006年春季推出[3]的Vyatta OFR是一个软件的路由器，它可以运行在很多的虚拟化的[4]平台上。又如，2009年，Cisco推出Nexux 1000v的虚拟交换机产品，它可以运行在VMware等虚拟化平台上，提供软件交换机的功能。另外，防火墙、负载均衡等领域都有虚拟化软件的产品，如Juniper的[5][6]vSRX虚拟化和cSRX容器化的软件防火墙产品。ETSI除了概念化了NFV，还定义了NFVI（Network Functions Virtualization Infrastructure，网络功能虚拟化的基础设施）以及NFV-MANO（Network Functions Virtualization Management and Orchestration，网络功能虚拟化的管理与编排）等框架。这些框架为大规模、自动化地部署NFV提供了很好的指导思路与建议。
NFV让网络服务功能的形态发生了不小的变化。现在物理服务器的性能越来越好，单台物理服务器上的虚拟机或容器就可以组成一定规模的小型网络。根据现在服务器的性能及应用的要求，一台物理服务器通常可以虚拟化出10～100台虚拟机。而每台虚拟机又可以有10～100甚至更多的容器。这样，在一台物理服务器上就可以产生100～10000个服务节点。这个规模已经超过了很多小型园区网的规模。物理服务器内部的网络结构也正变得越来越复杂。
在NFV的环境中，为了让服务节点之间的网络更加灵活，引入了VxLAN（Virtual eXtensible Local Area Network）等技术。VxLAN通常应用在Overlay的网络环境中，即在原有的三层网络（IP网络）上又衍生出二层网络，类似传统网络中用GRE隧道方式组成的网络。这里我们不讨论GRE（或NVGRE）和VxLAN两者之间的区别，这并不是本书的重点。Overlay网络中存在着大量非状态的隧道，并且这些隧道的生命周期往往是非常短的。这是因为按需服务的理念使得服务节点虚拟机或容器的生命周期正变得越来越短。
网络功能的软件化与虚拟化使得网络功能部署更加灵活和快捷，这势必会促使NFV软件大规模发展和应用，软件网元数量将会大大超过现在物理网元设备。同时，业务需求的频繁调整和变化，将使得Overlay网络拓扑的生命周期越来越短。管理和维护由软件网元组成的网络将是一个很大的挑战。1.1.4 云和SDN“云”应该是大家再熟悉不过的概念了。现在有很多的公有云平台，如美国亚马逊的AWS云平台、微软的Azure云平台以及谷歌的云平台等；国内有阿里巴巴的阿里云平台、腾讯的云平台、百度的云平台以及青云等。另外，大量企业使用了OpenStack、VMware等搭建企业的私有云或公有云平台。在私有云和公有云之间又存在很多混合云的环境。从网络的视角来看，这些云的通信可以分为两大类：一类是云内部的通信。这通常是在一个DC（Data Center，数据中心）内部的通信。另一类是云与云之间的通信。这里有些是私有云之间的通信，有些是公有云平台之间的通信，有些是公有云与私有云之间的通信。这些云之间的通信有些是专门的线路互联，例如，亚马逊的AWS平台就提供直接网络互联的服务。有些是没有专门的链路进行连接的，它们之间通过现在的互联网进行互联。
当计算、存储等资源云化后，这些资源的弹性变大了。换个角度来看，这些资源池所提供的服务节点虚拟机的生命周期也变短了，需要时启用，不需要时释放。这些资源都是网络中的节点，云越多，可用的资源也会越多，并且所有这些资源都会愈加依赖网络进行通信。散布在各地的云资源需要通过网络进行动态的组合，这势必会迫使网络具备动态的调整能力。连接云节点与云节点之间的网络无论是通过底层的物理网络来实现，还是通过上层的软件网络来实现，都需要具有一个供机器管理调用的接口，才有可能实现对网络的监控、创建、修改以及撤销等操作功能。
在网络中传送的数据最终还是会落到物理连接上。因此，物理网络（有时候也把它称为传统网络）同样需要实现更多机器与机器的通信接口。正是像云业务这样上层应用的不断“推动”，才使得网络的接口和自动化能力需要不断提升，从而达到更高的业务敏捷性。同时，软件定义网络技术的发展“拉动”了网络自身的变革。我们可以清晰地看到，网络的变革体现在以下几个方面。
首先，网络管理接口数据结构化，这里比较有代表性的是NETCONF协议的定义以及YANG模型对网络设备的配置与信息输出结果的结构化定义。关于NETCONF协议与YANG模型这两部分的内容，在后续的章节中会进行比较详细的介绍。
其次，在SDN（软件定义网络）中强调转发与控制分离的架构。这种架构实际上是让硬件与软件进行了分离。软件部分的控制器在设计上提供了非常丰富的北向接口。而这些北向接口的定义，都是为了实现机器与机器（程序与程序）之间的通信。当网络设备的API越来越丰富时，在这样的环境中进行自动化运维就不是难事了。
大家也许注意到，刚才一直在说机器与机器通信的问题。正是类似像“云”这样的业务和SDN这样的技术促进了网络设备接口的升级。无论是商业公司的产品还是开源的项目，均提供了比以前更多的机器与机器交互的接口，而不再只是关注人与机器交互的接口。较典型的人与机器交互的接口是CLI（Command Line Interface，命令行）以及Web界面。而这样的接口是很难与另外一台机器进行交互的。只有让更多的机器参与到业务流程中，才能提供更快的效率。网络提供的服务在业务平台的下层，如果网络能够给上层业务应用提供更多的可供机器使用的接口，网络被使用的效率自然也会得到快速提高。1.1.5 SD-WAN
SDN一直被认为缺少理想的应用场景。而自2014年开始出现的SD-WAN（Software Defined-WAN）正逐渐成为SDN最热门的一种应用场景。截至2017年，业界对SD-WAN的定义还存在着一些分歧，具体可以参考Wikipedia（https://en.wikipedia.org/wiki/SD-WAN）的内容。
在笔者看来，网络从功能、物理规模和特点方面来区分大致可以分为以下三大类。
1）广域网（Wide Area Network，WAN）。Wikipedia给出的定义如下：广域网是指连接不同地区局域网或城域网计算机通信的远程网。广域网通常跨接很大的物理范围，所覆盖的范围从几十千米到几千千米。由于长途链路的成本是这张网络的主要成本，因此这张网络的拓扑结构差异性会比较大。广域网存在链路按需使用的需求，例如早期的ISDN链路就是按时长进行计费的；也存在网络流量调度的需求，即合理地利用现有的链路。Google B4在这个领域做了很多的尝[7]试。
2）园区网络（也称为局域网）。相对于广域网而言，它的覆盖范围通常会比较小，常常仅限于一幢或者几幢楼的内部，并且其带宽相对广域网往往会大很多。园区网的主要功能是提供大量的信息点并管理这些信息点接入的用户，这些信息点可以是一些传感器或者是人机交互的终端。其主要特点是要应对各种各样的接入方式以及安全接入的需求。园区网的网络拓扑相对比较固定，通常是双星形的拓扑结构。
3）数据中心网络（Data Center Network，DCN）。这个网络的物理范围一般会更小，只覆盖一个或数个较近的机房。这个网络的拓[8]扑非常标准化，目前最为流行的设计是SPINE-LEAF的结构，设计完成后几乎不会有大的变动。其主要的特点是为服务器和服务器之间的通信提供高速的带宽，通常也称之为横向流量带宽。
而SD-WAN首先要解决广域网的互联互通，其次需要满足网络的快速开通与灵活部署，另外还要解决一些广域网优化的问题。SD-WAN会大量引入NFV，NFV的灵活性在1.1.3节中有介绍。如何快速部署业务、如何管理网络节点、如何检测广域网的通信质量、如何优化广域网的转发路径、如何运营广域网，这些都是SD-WAN需要解决的问题。作为软件定义的广域网，SD-WAN必然会使用很多编排系统，这些编排系统也必然会大量用到网络设备的API。对于这样的网络，采用DevOps的运维方式和业务部署将是一个不错的选择。[1] https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflowconfig/of-config-1.2.pdf。[2] https://portal.etsi.org/NFV/NFV_White_Paper.pdf。[3] https://wiki.vyos.net/wiki/Vyatta。[4] https://communities.cisco.com/community/technology/datacenter/data-center-networking/nexus1000v/blog/2009/7。[5] https://www.juniper.net/us/en/products-services/security/srx-series/vsrx。[6] https://www.juniper.net/us/en/products-services/security/srx-series/csrx。[7] https://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p3.pdf。[8] 可以参考http://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white-paper-c11-737022.html。1.2 NetDevOps，你需要知道的事1.2.1 什么是NetDevOps
NetDevOps是网络（Networks）、开发（Developments）与运维（Operations）三个单词的复合词。很显然，这个单词已经非常清晰地表达了其所包含的内容：网络的运维工作需要开发者来一起参与进行，通过程序化的代码来完成大量运维的工作。推动这种变化（或称为演进）有来自多方面的因素：网络规模变大带来维护工作量的增加、应用快速上线、快速响应需求、自动化运维思想的驱动等，总之就是需要提高运维效率，给运维人员降低工作负荷，提升网络操作的准确性，降低误操作。从定义来看，NetDevOps包含很多方面的内容，它既包含了技术的一些细节，也涵盖了很多非技术的内容。实际上，NetDevOps代表了一种思路、一种方法论、一种与时俱进符合当前业务发展需要的新型的网络管理和运维手段。
本书主要从技术入手，侧重介绍实践过程中能直接应用的工具与方法，在最后会给出几个常见的应用场景的实际案例。
NetDevOps不一定都要通过编程来实现。毕竟对于绝大多数网络工程师而言，编程属于陌生或跨界的领域，要求传统网络工程师一下子就能编写出大量代码来实现自动化的网管和运维也是比较困难的。学习和实践NetDevOps并不一定需要我们从头开始写每一行代码，我们可以学习和掌握一些已有的工具和现成的程序库来实现我们的想法、达到我们的目的。尤其是对于初学者而言，有现成NetDevOps工具能实现的就尽量不要使用编程，有现成的语言平台库能实现的功能就尽量不要去一行一行地去撰写代码。可以逐步编写更多的代码或基于已有的代码模板进行修改，这是一个循序渐进的过程，只有你一路坚持下来才能体会出这其中美妙的、得心应手的滋味。1.2.2 NetDevOps适用环境
现在得益于IT技术的发展，很多行业自身的自动化程度越来越高。随着人工智能的逐步普及，以后机器将会能做更多的事情。但是目前很多的网络规划与运维工程师们，特别是在国内，大家都还不太善于利用机器来帮助自己做更多的事情。在云计算的大趋势下，无论是网络的自动开通，还是网络的变更运维，都需要非常高的自动化程度。目前不论是传统的网络还是SDN相关的网络，都适合采用NetDevOps的方式进行运维管理。
在传统的网络中，设想某网络工程师管理维护了一套企业园区网，假设这个园区网从接入到汇聚再到核心和网络出口一共拥有100台网络设备。在日常的管理维护方面，网络工程师需要监控这些设备的运行状态，并定期做设备配置的备份或设备版本的升级；当然也会经常有新业务上线，对应网络及安全的策略变更等工作。可想而知，如果没有类似NetDevOps工具的帮助，此网络工程师的工作量将会非常庞大。而如果能够借助NetDevOps来完成此类日常事务，那么此网络工程师的工作量可以缩减为原来的十分之一，甚至更少。由机器完成此类重复类（循环类）的信息统计，其效能将万倍于人的手工操作。
在云服务商自身的SDN网络中，NetDevOps已经得到较为广泛的使用，包括公司层面DevOps的开发（此类NetDevOps通常会跟公司主营业务应用以及服务器虚拟化平台进行融合，打通业务自动化链条上的各个环节）以及网络运维部门自身的维护NetDevOps工具的开发。国外Google公司内部日常运维的网络工程师已经要求必须具备NetDevOps的编程能力。
NetDevOps实际上适合运用在任何存在网络的环境里，包括传统园区网、新型数据中心，以及当下日益火热的SD-WAN市场。1.2.3 为什么我们需要NetDevOps
为什么我们需要NetDevOps？原因有以下几方面。
首先，上层业务的自动化程度越来越高。这些自动化的业务推动了网络管理需适应其业务自身的快速迭代与发展。
其次，网络设备及网络技术的演进。最为典型的就是SDN的发展让网络设备的API越来越丰富，这点拉动了网络管理方式的变革——可以更多地使机器和代码参与到日常的网络管理工作中来。
再次，网络节点数量在急剧增加，导致重复性工作越来越多。只有使用机器和代码才能快速高效地完成此类工作。最后，人工管理网络势必会不可避免地带来大量人为疏忽性错误。网络维护操作中的小失误常常会引起大范围的网络故障，因此网络维护的准确率是非常重要的。就这点而言，使用机器和代码完成自动化将会是更好的选择。
纵观当前的IT发展状况：快速服务是目的，自动化是手段，NetDevOps是方法。NetDevOps是之前游戏规则的改变者，它打破了传统IT各领域的边界，其本质是一种思路、一套方法论。如今许多网络和IT运维人员已经开始寻求和部署自动化的解决方案，并借此来提升用户体验，提升服务质量和效率。当然这些技能也会提升网络运维人员自身的竞争力。
上士闻道，勤而行之。既然已经有了这么强大、这么好用的技术和理念，我们有什么理由仍然拒之门外呢？1.2.4 NetDevOps需要什么样的人
传统的网络工程师需要掌握很多的网络基础知识。例如，OSPF、ISIS、BGP等路由协议，还有相关设备厂家的命令行使用方式等。既然希望借助NetDevOps让机器和代码参与到网络工程师日常的管理与运维工作中，那么必然也需要要掌握一些NetDevOps相关的基础知识，如文本处理工具、网络设备的API、一些简单的编程语言以及一些现成的自动化工具。本书的目的就是帮助传统网络工程师了解和学习这些方面的基础知识。即便是传统网络工程师不愿转向软件开发领域，但了解和掌握一些NetDevOps的基础知识也是很有益处的。当你和软件开发、软件设计人员进行交流时，当你希望公司开发部人员能帮你们部门开发一些系统和工具时，这些知识将会很有帮助。1.3 小结
本章一开始谈了很多关于SDN和云相关的内容，看似和NetDevOps没有太多关系，但正是SDN和云的发展让网络DevOps变成了可行的且相当迫切的需求。如果不是SDN和云这两个技术的双重驱动力，NetDevOps发展也许还会再晚一些。
NetDevOps带着DevOps的理念与文化，在传统的网络运维领域也一样会掀起出新的浪潮。在第2章，我们会和大家聊聊关于如何开始NetDevOps的学习。第2章如何开始NetDevOps
基于第1章的内容，我们可以看到NetDevOps是网络运维的发展趋势。那么，我们如何开始NetDevOps呢？我们需要做哪些准备工作呢？本章会从如下几个方面来帮助大家做好准备工作。
·文档的管理。无论是采用传统的方式运维网络还是采用写程序的方式来维护网络，都会产生大量的文件，有效地管理这些文档和代码以及相应的版本是NetDevOps的开始。
·编程语言的选择。NetDevOps包含了一定的程序开发工作，如何选择一个适合自己或自己所在公司的编程语言是一件比较重要的事情。目前编程语言多达5000多种，我们怎样才能选择更适合当下的语言呢？
·自动化平台的选择。对大多数中小企业而言，开发一套相对完整的自动化工具是一项工作量很大的工程。特别是在初期，使用现成的工具将会是一个不错的选择。但这些自动化的平台该如何选择呢？
·我们需要什么样的编程接口。既然要面向网络设备进行编程开发，那么网络设备需要具备什么样的编程接口才会更容易实现NetDevops呢？
我们在开始编程之前先关注一下上述的几个问题，这对后续的学习会更有帮助。2.1 文档内容与版本管理
首先需要声明的是，版本管理并不限于网络工程师们常说的“设备软件版本的管理”。这里提到的版本管理包括网络规划、网络运维涉及的所有文档、代码和设备相关的软件。具体的内容会在后续进行详细的说明。本节从以下几点进行描述：
·版本管理的重要性；
·网络管理中哪些内容需要版本管理；
·如何实施版本管理；
·版本管理常用的工具。2.1.1 版本管理的重要性
大家在进行网络维护的过程中，也许遇到过拿着一份错误的规划表对设备进行了配置，随后网络出现了故障；也许还遇到过相同角色的设备上存在着不一样的策略。例如，一对SR（Service Router，业务路由器）和RR（Route Reflector，路由反射器）之间建了BGPv4邻居。但是其中一台设备并没有发送BGP Community（BGP路由的一种属性），导致流量进行切换时发生了故障。这些问题都与版本管理有着密切的关系。
其实，版本管理在任何管理领域都是一项非常重要的内容。现代社会存在着大量协作，大家在互相沟通合作的时候需要确保信息的统一准确，因此信息的版本管理是非常重要的。即便是由一个人完成的工作，由于时间的关系也需要做好版本的管理工作。只要在过程中出现了信息变化，就需要有版本管理。版本管理存在着如下两个基本要素。
首先，版本管理需要有一个明确的位置来存放这些信息。在考虑了安全性之后，存放信息的位置应该是便于查询的。
其次，存放这些信息的地方需要有一个好的手段来知道它们的版本信息，既要方便知道最新的版本内容，也要方便查询历史的版本内容。图2-1所示就是一种非常糟糕的信息保存方法。单纯通过文件名的方式是比较难于管理的，但是这又恰恰是我们日常管理版本最常用的方法。图2-1 设备配置文件名2.1.2 需要管理哪些文档
网络管理通常可以分为三个阶段：网络规划、网络建设与网络运维，每个阶段都会产生很多的信息。这些信息很多是通过文档（这里说的文档指一类文件）的形式来体现的。部分公司会采用一些软件系统进行替代，将其保存在数据库中。表2-1列出了一些较为常见的文档类型及其常用格式类型。表2-1 常见文档
除了上述的文件外，还有一种文件是二进制文件。它们通常由其他公司提供，并不是网络管理者自己产生的。对于这样的文件，通常只需要管理其版本信息即可。
上面描述的这些文档都是需要进行版本管理的。这些文档的类型基本上是Office文档的格式或者纯文本的格式。2.1.3 如何实施版本管理
如果有一些系统能进行版本管理是最好的，但是很多时候并不具备此类完善的系统，这就需要网络工程师自己来管理这些文件和版本信息。管理好这些文件以及它们的版本信息是NetDevOps的基础。如何在没有管理系统帮助的情况下快速而有效地进行管理呢？首先，我们需要对这些文件按照格式进行分类。这些文件大体可以分为以下三类：
·微软Office格式的文件，如规划与描述的文件；
·纯文本文件，如设备配置与一些脚本文件；
·二进制文件，如网络设备使用的软件操作系统。这一类文件并没有包含在表2-1中。这是因为这种文件通常是由设备厂商提供，并不是网络管理者自己产生的。
其次，笔者建议尽量使用纯文本的格式来编写文档。Office格式的文件通常使用文件名和文件中的版本信息来进行管理。例如，文件名为《XXX网络实施总体方案V1.2》。在文件的开头会有如图2-2所示的内容。这样的版本信息是比较常见的版本管理方法。通过阅读文件中的版本信息，我们可以非常清晰地了解这个文件的相关版本信息。它适合在不同的人员之间、不同的部门，乃至不同的公司之间进行单个文件的传递。虽然我们可以在“文档变更过程”这里找到一些文档修改的简要信息，不过采用这样的方式很难在文件中保留全部的历史细节信息。因此，一些公司会使用微软SharePoint（https://products.office.com/zh-cn/sharepoint/collaboration）工具来进行团队的文档管理。它可以提供历史版本的管理，以及不同版本之间的比较信息。图2-2 文档版本信息注意 在网络管理中常常会遇到网络拓扑图信息，这样的内容是比较难以管理的。这里笔者推荐大家使用DOT文件格式进行网络拓扑的绘制。DOT是一种描述图形的语言，它能用一种简单的方式来描述图形，而且能兼顾人和机器同时读取和处理。
例如，在代码清单2-1中描述一个简单的IDC的拓扑：
代码清单2-1 一个简单的拓扑graph G { spine1 [label="核心1" color=blue] spine2 [label="核心2"] leaf1 [label="接入1"] leaf2 [label="接入2"] leaf3 [label="接入3"] leaf4 [label="接入4"] leaf5 [label="接入5"] leaf6 [label="接入6"] spine1 -- leaf1 [color=red]; spine1 -- leaf2; spine1 -- leaf3; spine1 -- leaf4; spine1 -- leaf5; spine1 -- leaf6; spine2 -- leaf1 [color=red]; spine2 -- leaf2; spine2 -- leaf3; spine2 -- leaf4; spine2 -- leaf5; spine2 -- leaf6; }
解析这个DOT文件在Chrome浏览器（需要安装DOT Lang Viewer插件）中的显示结果如图2-3所示。使用DOT语言可以借助文本的方式来保存一个网络拓扑图。http://www.graphviz.org提供了DOT的详细说明，读者可以参考。
试读结束[说明：试读内容隐藏了图片]