DevOps is dirty work - Dream in One-Click

Posted 2020-08-24 Start Up Here

真是一晃就到年底，年初许的梦想实现了吗？这么残忍的问题还是不要知道答案了吧：）

这恍若隔世的大半年，不仅没有承接着上篇继续聊Continuous Delivery (CD)，反而疑似荒废。然而，梦想还是在的，即使工作再繁忙，至少老板也会这样时不时地提醒我。还记得去年的年末开始学着用Stackstorm做Orchestration，当时满心觉得One-Click已经不再遥远。而时至今日，事实也差一点证明了这一点。还差的那一点便在于过于乐观地估计了对改造已有项目部署方式的难度。做过Code Refectory的同行们一定有过这种心情，梦想明明就在眼前，却总是隔着一个Regression的距离。即使超过3个月的代码也偶尔会赋予挫败感，何况我们面对的是虚年6岁的壮年项目。虽然还是遗憾地遥望着One-Click，但是大概也就差着一片雾霾的距离，而一路到此，不虚此行。

 

安迪·格鲁夫在《只有偏执狂才能生存》中说过，“为了成功地穿越死亡之谷，第一件事就是设想出公司到达彼岸后的形象。”所以梦想要有，还要具体，不然谁知道实现了没有。One-Click的形象是什么？一千个人眼里有一千个哈姆雷特。我就聊聊我眼里的One-Click为何物。

在我的梦想中，One-Click的终极形象包括两个方面，

1. DevOps工程师可通过一条指令完成从建虚拟机到部署服务并使其在产线运行，这里自然也包括Scale up和Scale down。

2. 当工程师将代码逻辑push到CI系统之后，在没有任何人工特殊干预的情况下，代码逻辑自动部署到产线并运行服务。

 

关于第一个形象，如今IAAS的出现已经帮忙解决了关于自动建立定制化的虚拟机（VM）这道难题，从而令一个SAAS/PAAS运营者头疼的问题已经从怎么建虚拟机进化为该选谁的IAAS服务好。岔开一句，目前AWS的风头正劲，业界对它的肯定已经几乎到了无以复加的地步。于是在这个形象里，最难的其实是如何将需要部署的服务以及所需要涉及的整个拓扑结构(topology)根据应有的配置，该新建的新建，该连接的连接。头疼的事情当然有很多，比如：

a. 一边建VM，一边建拓扑，需要把控好逻辑顺序。

b. SSL所需要的证书随着VM的新建也需要根据拓扑新建和更新，并且需要实现自动化签名。

c. 纷繁复杂的配置信息需要精确地推送到某一个VM上，这要求配置管理做到层次分明和自适应调整。(自适应调整是指配置信息应随着环境变量的变化而自我更新）

d. 应用本身应是无状态的，状态信息的存取可依赖外部服务，比如由PAAS层提供的cache服务。

以上当然不是全部麻烦，不然怎么称得上梦想。对于很多问题，业界相应的solution每天都在更新，时不时便会听说某个问题已有了解。从个人经验以及道听途说的角度出发，有效的solution之一由 Jenkins (CI-CD管理) + Stackstorm (Orchestration) + OpenStack (IAAS) + Puppet with Hiera(部署应用及静态配置) + Consul(动态配置管理服务) 组合而成。当然这还不是整张蓝图的全部，毕竟这里只考虑了可行性，还没来得及考虑HA(High Availability)和性能。

 

关于第二个形象，参阅草图如下：

 

其实从CI的下游开始，第二个形象便与第一个形象多有类似了，不同点在于第二个形象更倾向于在正在运行的环境上操作。在What\'s the deal的结尾我说，“DevOps is dirty work where you have to be more than a Dev”。这第二个形象便是对“more than a Dev”的要求所在。如果没有对你所要部署的应用服务足够了解，CD将会是最让你手足无措的部分。比如，如果没有弄明白某个应用对另一个应用或服务的依赖是配置型的(即配或不配以及多种选配暂不影响HA)还是强制型的(即不配置便会挂)，甚至有时这样的依赖关系只在应用的代码级别定义，那么一旦出现服务停摆，在老板眼皮底下于无数VM的云中查找root cause的心灵之伤可不是几顿加班餐就能挽回的。从solution的角度来说，在没有scale up或scale down的情况下，除了IAAS部分也许不是必要的，上面提到的组合中其他部分还是很管用的，即 Jenkins (CI-CD管理) + Stackstorm (Orchestration) + Puppet with Hiera(部署应用及静态配置) + Consul(动态配置管理服务)。但由于第二个形象的不同点在于已有运行环境，那么HA和部署速度应该被纳入必须考虑的因素。

HA一直是做云服务运维最核心的部分。如果某天早晨起床发现你的微信朋友圈刷不出来，对于广大互联网依赖征重症患者来说大概一整天都不会好过，更别提那些把大笔资金堆在上面的商家了。当HA出了问题，消费市场尚且生不如死，那些企业市场的用户也许会有动武的可能，压力大了吧：）梦想嘛，就是被逼出来的。合理的HA策略在One-Click的场景中应该经过反复推敲，从高稳定性向高效率逐步推进。A-B和Rolling Upgrade是目前相对比较稳妥且不失效率的方式。A-B也是灰度发布的一种方式，即让部分用户继续使用A版本，同时让另外部分用户先使用B版本，然后适时决定是否所有应用都升级到B版本还是需要回滚到A版本。如此以来，加上合理的回滚策略，监控策略以及数据分析策略便可在One-Click过程中保证HA。Rolling Upgrade是指通过添加新的节点安装新版本，当达到适当规模的时候将老版本的节点去除，期间允许短期的新老版本共存。A-B和Rolling Upagrade两者是理念和方法的结合。Rolling Upgrade可通过新老节点的控制得以实现A-B方式，但这就需要IAAS的支持。当然这不是唯一的方法，对于一些对Capacity要求不明显的应用来说，在已有节点上做分批处理也能达到A-B的目的。不难发现，One-Click的第二种形象中最麻烦的便是HA，也是这个美好梦想中最有趣的部分。

关于One-Click的部署速度，每个人都会有不同的观点吧。对于有些SAAS服务来说，快速上线和bug fix是铁律，而对于一些PAAS服务则稳定大于速度。但不管如何，从理论上来说，One-Click在效率上必须比N-Click来的高。各种保障策略的联动机制将需要发挥作用，比如如何verify应用服务已正常运行，如何在一些条件下触发下一步流水线，如何对出错快速恢复并从断点继续任务等等。如今业界的监控工具和智能分析工具已是五花八门了，只要API好用，都可以在One-Click的场景中贡献力量。当然，时下炒得火热的AI概念自然适用于One-Click，这会使得梦想更丰满更华丽。

 

梦想描述至此，是不是勾起实现的冲动了：）大家都喜欢一杯咖啡一个Pad就把工作搞定，我一直认为懒人的梦想是最有价值的。然而如今的云端，世道沧桑，列强割据，风云变幻，每一分每一秒都有旧梦想破灭和新梦想实现。DevOps世界随着云端的格局更迭也是日新月异，One-Click的作用或许也是解放一部分重复劳动的时间去呼吸新世界的新鲜空气。眼前的那一段雾霾的距离应很快会缩短，我已经开始憧憬下一个梦想了，或许真的是脑电波替代Click，叫做One-Mind？好了，换一杯咖啡，Carry on！