NetDevOps杂谈其二，cli与netconf
最近后台收到了一些小伙伴的疑问，本着粉丝不多，都是上帝的理念，也抽空都做了一些解答。
昨天收到了这样一条消息：
你好，我看了你介绍的yang模型和netconf，挺有启发的，自己写了脚本实践了配置交换机，
想请教下你我有厂家的yang模型文档，怎样方便的编排脚本呢，
感觉在python文件上写yang的模型数据工程量不小啊，和cli也差不了多少了这位同学的直观感受是没错的，yang model 与 netconf的工程量很大，和cli差不多，其实我个人觉得可能是多很多。
但是为什么还要做netconf ？
我从个人的认知角度去分享我对这个问题的理(拙)解（见）。也欢迎大家纠正补充。
我最近也在做一个南向的控制器，我的控制器里要实现三种方法去控制设备（包括信息获取）：cli、netconf、RESTful API。不排斥snmp、ansible以及其他的。
cli 现阶段最香
如果一个字形容，就是香，符合我们网络运维的思路，就是命令行，打开ssh软件，复制粘贴就好了。命令行，大家再熟悉不过了。无论是show和config都很方便。
大家工作量的很大一部分还是和cli打交道，每天在复制粘贴命令行，调参数，刷配置。把这三个摆在一起，cli就是大家的亲人。
基于这种思路，我一直在想把人的经验固化下来，这部分经验基本都是基于cli的一些输入和输出及判断，做成程序。一个人会，就可以有100个人会，补填运维技能的不均衡。
运维人员会非常熟悉这个过程，体验应该是最好的。
这个时候，主体还是人，自动化做的是人重复做的事情。可以比较短平快的把一些事情搞定，同时对老设备的支持也比较好。
很少有网络设备不支持命令行，但是太多的网络设备API不够丰富（无论是netconf的还是rest的）。
Netconf 目力所及的网络未来可编程之路
我们先来解答这个同学的疑惑，我先下一个结论，netconf和yang model不是直接给现阶段的网络运维人员使用的东西（我觉得这个措辞的严谨程度已经要爆炸了）。
大家有兴趣可以去看看netconf的官方文档，里面讲的很详细，它的很多功能都不是cli能做到的。
举几个我能记住的例子：
- 事务性，配置失败可以回滚
- 下发前可以先检查配置是否成功，dry run
- yang model保驾护航，面向对象的方式，能定义什么字段，这个字段支持哪些值，没有二义性
- 大厂商openconfig的支持，使得一些配置在不同厂商之间是无差异的。
- 完善的容错机制，错误冲突的时候可以预设模式，继续还是终止回退等等
- 支持订阅
- 比较好的版本管理，一定程度上有比较好的兼容性
以上几点，我们其实可以得出一个结论，netconf是给APP使用的，这个APP可以是你写的小脚本也可以是一些比较大的管理平台（比如opendaylight、nso、各厂商控制器的软件层面）。
基于最原始的netconf，我们在开发的时候肯定会封装，把一些网络参数和yang model的某些对象的某些参数对应起来，其实可以通过比较巧妙的设计，简化调用过程，比如基于一些模板引擎。
开发中有一个dry原则，don't repeat yourself。一次开发，每次都是传参数（参数可变），出来对应的netconf配置，一劳永逸可能夸张了，但是针对某些场景是差不多的。
大的平台，比如很多控制器上实现的功能，我觉得不会超出这个思路，还是基于用户的参数，比如csv文件，快速生成netconf，然后通过ssh 推送到设备，实现一个配置生效。
这才是netconf的玩法，netconf是给app 或者说是给开发人员使用的。
程序基于一些预设的逻辑和事务回滚的控制，理论上可以非常完美的对网络进行管理。
cli写好，每次耗费10人力，netconf写好耗费100人力，后续时候使用耗费2人力，这笔账大家都懂。
netconf的起始成本确实比较高，但是慢慢的就会下降，包括下一个场景的起始成本随着你的熟练程度或者工具的封装也会降低。
不知道我解答了这位读者的疑问没。
起始netconf的优点还有很多，我也只是抛转引玉。
目力所及，网络未来的可编程之路，还是要基于netconf，restconf和其他变种，我觉得可以忽略不计。
但是历史债，很多旧设备是不支持netconf的，这个也是需要我们去考虑的。同时有些新设备也比较极端，不给普通用户开放cli，逼着你用控制器或者netconf去设备获取信息。
我们再谈谈RESTful api
RESTful API
从管理点分两种，设备上的比如nxos的nxosapi，是设备级的；控制器或者网管平台级的，比如AC控制器或者opendaylight等的API
从使用上分两种，普通API，以及基于yang的API，前者占大部分吧。基于yang的，我见得少，大部分还是控制器给你什么API你用什么API。
这个东西是受限的，为什么呢
- 设备API的非常少，支持restconf的不如netconf的那么多。
- 控制器对外暴露的API不一定，比如国内的某些控制器对外暴露的大API不多，这个时候如果是读取信息，我其实是可以直接netconf去设备读的，但是写的话我还得考虑它这个控制器的配置一致，很恶心人。
比较理想的情况是控制器给出足够多的API，但是我不是很指望，坑太多，他们填不过来。很多underlay的居然不提供API，大部分只是围绕着overlay层面。
但是有些东西还是得通过控制器，不到万不得已，除非你真抛开厂商控制器，自己设计一套控制器（基于开源也可），通过控制器就是靠RESTful API，所以这个东西，又香又臭。
我感觉某T大厂，部分环境下，是自研的控制器，因为他们让厂商必须支持openconfig，其野心或者用意可想而知、
小结
cli现阶段肯定是最香的，且支持最广，但是成本高，很多厂商异构问题。
netconf，目力所及的未来，我觉得还是得靠它，但是一定是要写程序封装的，不是给人用的。
RESTful API 其实是一种更高层次的封装了。
