马全一：我分享的题目是我们华为目前开源做的一套DevOps的产品，我们把它定义为ContainerOps，我们讲了一个新的理念，DevOps编排，现在在容器社区大家都讲容器的Container的Orchestration，容器的Orchestration其实是底层调度管理，针对资源的应用，有点像OpenStack。但是真正在业务层面其实还是需要编排，你的业务的应用，你的DevOps的任务其实都需要编排，所以我们在容器编排的基础之上做了一个DevOps编排的系统，我们叫它ContainerOps。
这个是我演讲的主要内容，前面两位嘉宾也讲了到底什么是DevOps，到底怎么来的。后面会讲我们是怎么看DevOps的，依据于我们对这个产品的理念，设计的ContainerOps，还有一些它实现的细节，还有为什么要这样做。
先说什么是DevOps，在我个人理解，这个里面讲的是DevOps这个词的来历，它不是一个大牛怎么样，设计了一套理论，然后定义为DevOps。其实整个产生过程是比较有偶然性的，最早在2007年的时候有一个欧洲的比利时的顾问Patrick，他在顾问的过程中经常会遇到研发团队还有测试团队还有运维团队之间沟通的问题，遇到很多障碍，所以他一直在思考，因为他也算是一个敏捷的教练。2008年在多伦多敏捷的会议上，他们去听一个议题，安格的议题，但是他去了以后这个安格这个人并不在会场上，因为没有人去听，所以那个讲师没有人他也走了。他在大厅里把这个人找到，两个人聊了很久，两个人对DevOps遇到的沟通的问题有很深刻的共识，所以他们两个人发起了一个敏捷的Workgroup，在里面讨论。DevOpsDays，在后面一段时间里，推特有140个字限制，他们就把Days去掉了，从那个时候开始就出现了DevOps这个单词。所以其实不是谁设想的这个理念。在2010年的时候快事有DevOpsDays的会，这个会我在2015年的时候参加过一次，有很大的宴会厅，摆了20张桌子，有一个白板，大家把自己感兴趣的议题贴上，你在第几桌，所有感兴趣的人可以坐过去跟你交流。在2011年的时候，Gartner象限报告里第一次把DevOps放进去做一个统计。在2012年采访Patrick的时候，他说他很偶然的选择了DevOpsDays这样一个单词，很偶然的把Days这个单词去掉了，才产生了DevOps，他其实并没有说是一个Master，要设计一个很大的理念去做什么事情。所以从整个来看，DevOps其实就是在迭代过程中很偶然产生的东西，其实不是一个定义出来的东西。所以他没有一个完整的定义说到底什么是DevOps，被所有人觉得是共识的一个DevOps的定义，他也没有一个像刚才说的微服务，中文叫12条军规，你满足这些你做的就是微服务，他实际也没有。这个DevOps的定义，看完以后发现对你工作一点用也没有。我个人觉得，DevOps其实是一个无形的，应该是贯穿你整个工作过程中的一个追求，你是要把整个沟通的成本降低，把整个研发的效率提高，把你整个应用部署上线的时间缩短。最终目标是把你研发、运维还有测试，包括你的商业团队，包括你的Marketing部门之间的隔阂打破，怎么做到这点，商业和你的研发运维的这个逻辑之间，你其实要一个快速的迭代和响应，比如他的需求过来，你能在很短的时间帮他实现，这时候你的流程变快的时候其实就没有这个隔阂。在研发内部加快这个速度，让它整个最后变快。我个人觉得要做三点，第一点，你要把在你生产环境下的，你将来上线环境的描述、定义要尽早确定下来，并且跟你研发的环境要保持一致。这点像Zabbix，很多的运维管理工具其实都在做这件事。其实更简单的做法，就用一个容器，这是最直接的解决方案。第二点，你要把整个的流程定义好，这个流程其实还是要反复的去调整修改，根据你的业务，比如Gitlab有三个，Master，Production、duction，预生产、生产，他们的Gitlab.com可能是适合这种方式，但适不适合你，还要看你整个团队的素质情况怎么样，你研发产品的情况怎么样，这个过程其实你要去定义它，不停去根据你的业务情况去调整。第三，你尽量让一切都做到自动化，当然是我们每个做研发做工程师的终极目标，什么都是自动的，不需要我了，我只要看着就好了。这个过程还是很难的，我们追求的过程，其实在很多业务流程里，有的时候还是要有个老板出来说确定你要上线，点个按钮你才能做。所以我们在产品设计里也要预留这样的接口给他。
DevOps现在讲的，从去年开始这个理念比较热，但是真正在做这件事情的时候特别难，你在团队里面去推，说我要做DevOps，其实都遇到很大阻力，我也跟很多公司还有team都去交流过。我感觉第一点就像这张图一样，我们经常会说，可能新来个总监来个老板，说我原来用过什么，有成功的经验，我们要换个监控系统。这个时候有个很大的方向，业务团队不管怎么样，已经在往前走了。这个时候换个新的轮子，你跑得更快，这时候所有的团队都会抵制你，不管你的初衷是什么。当我推一个新的东西给你的时候，我第一点是给你承诺，你原来的工作不用做修改，或者非常低非常少的代价的修改，保证你原来的流程，大家原来做的事情不要动。第二步，我们会有一套工具，帮你原来的流程能够copy过来，上来以后我们在这个流程之中利用这个工具灰度的能力，慢慢的一点一点去改进，让你整个团队往前跑，而不是我上来说我们要配套新的系统，大家明天晚上来个通宵，然后把事情干完。这种方式肯定不可以。
基于这种理念我们去做ContainerOps这个产品，我们讲DevOps编排，这里我们产品有三个理念，第一个，有很多都用Jenkins，很多情况下我们还有工程师喜欢写一个文件，当你的研发团队变得很大的时候，一个DevOps这样的配置文件，你反而变得不可控。第三个，我们把所有的要执行的工作全部都容器化，由kubernetes来执行。第一，要减少你对环境的依赖，第二，你用kubernetes的时候其实你增加了很多的管理的能力。
我们怎么去把一个原先的任务变成一个Component，比如你要在一个流程里用到它，你一定要给它传递一些数据，比如最简单的，我告诉他一个github的地址，他做一次任务，你也要传一次github的地址，我们定义了传递的方式，以Key/Value的方式，只盯这个环境变量的名字，任务完成之后要把结果输出出来，这个时候直接向系统的标准的log输出，你打的时候告诉你格式是什么，如果你执行结果，以确定的方式打出来，我们会把所有容器的打出来的日志全部收集在一起。第三，你做一个容器的镜像，如果是Docker一定要选一个base，当然你有无数的选择，我们推荐的是github下的phusion/baseimage，很关键的一点，Docker的镜像其实是一个容器镜像跑一个应用，如果你的DevOps很复杂的时候，你可能需要里面比如说装一个数据库，然后再跑一个任务，这时候怎么办，它里面做了很多预先的设定，让你很容易在里面跑几个镜像。当你去写这样一个东西，比如你把一个原来Jenkins的封装成容器镜像了，这时候你去测试它的时候肯定会有各种各样的问题，如果你用了kubernetes测，你会发现再去找各种情况日知会很麻烦。这个镜像是默认开了SSH的Server，所以你可以直接就进去看里面的状况。我们为什么没有选择上kubernetes Pod的概念，Pod是几个Container连在一起完成一个任务，而我们选择的是一个容器内你用几个进程。两点，第一点，当然我们做这个东西现在我们这个产品是依据于底下的kubernetes平台的。但是你这样一个Component如果是单一的不依赖于Pod这个概念，你还是可以使用Docker的引擎。我们选一个Component，一个开源社区它的成功，技术当然是很重要的一部分，关键的一点是你有一个share的topic，比如Jenkins大家都用它，它有一个庞大的plug in的仓库。Docker大家也都在用，因为有一个Docker Hub，里面有几十万的仓库让你选择。包括github，有很多替代的，这是它的优势。你说它大优势是什么，当然它的Git托管能力上很强，除了这点以外其实它没有别的，作为一个商业产品，技术优势跟别的差距不是太大。所以我们也定义了一个新的Component的概念，我们要依据这个方式让它产生一个大家可以交流的东西，我们再去做一个host，然后把这个社区做起来。
方式，如果你用plug in，你可能要找到它，下载下来，装到Jenkins之上，要找到它运行的环境，把这些找到跑起来测试，最后没问题了。你要用的时候只要知道它的地址，粘到这个系统里，然后你就不用管了，它运行的时候，kubernetes会帮你把它从服务器下载下来，运行完以后，kubernetes的Master再把它干掉，后面所有事情都不用做。我们觉得这个方式要比plug in的方式更合理一些。我们w会去做这样一个Component的公共的Service，我们也有开源解决方案，很简单，第一个，我们跟Docker的Hub学了一个Library，你可以直接来用，你自己也可以上传管理你自己的。因为它是Component，是容器的，底下有个Registry，这一块我们后面会开源出来，包括我们也会做一个华为 host Service让大家来使。
这个是Component的模型，你底层有baseimage，把所有的东西输出到系统的stdout，包括错误信息，Docker会利用命令把所有日志抓出来，在每个节点上会有一个进程，会把所有的日志收集出来发到处理的模块。处理的逻辑是这样，这里把所有的日志都抓出来，发现道路这个模块，第一件事就是把所有的都存下来。这里开源产品我们选的是TiDB和TiKV。这里可以自定义一些处理的流程，因为我们会打特定的标签出来，这个时候你可以针对它去做一些处理，处理完之后会把结果发到处理的节点上，知道到底成功还是失败。这是最简单的工作流，它的方式，第一，这里定义Stage，可能是根据业务逻辑划分的，每一个方块是一个action。第一执行完了执行第二个，然后执行第三个，每个action是并行执行的，action里面确定的是一个Job。这里有一些它的属性，我们做了很多特性，比如说你可以设置整个环境变量，可以为它设很多的标签，比如我们前端时间咨询的情况，某银行跟我们讲他有5000条这样的流程，他想分组来管理，每一个做一个分组的名称。你如果在整个的流程中需要人为参与，你要方法一个特殊的Stage在这里，它会通过一个E-mail发出去。随着里面这个就是一个Job，这个是那些环境变量传尽量的那些KV的值，包括输出的。在它执行之前，你可以先去写一个脚本，确定你到底要做什么事情。为什么要这么做，因为我们这个东西做得不太像专业的Workflow的产品，其实更多是倾向于DevOps的，所以它没有流程控制能力，也没有循环判断。我们要给研发或者是团队提供这样的能力的时候，给他一个让他执行脚本的方式。最后还可以再一次执行一个Lua的脚本来确定。
这是这个界面的设计，这是第二版的设计，第一版比这个更酷炫一些，我后面会讲一个案例，在实际使用当中发现用起来并不是那么爽。这个是日志输出的情况，我们把这个项目拿到TiDB那家OpenStack的厂商去做，第一个，他们是开源的，所以他们每次都要经过Travis CI的检查，这是第一步。然后要执行1000万的数据库，执行完以后要根据用户实际场景测试，7×24小时，按照用户的场景把他数据库的节点部署好，不停的跑测试用例。整个DevOps分成这三个阶段这三个阶段不能连寨一起第一个是在用户服务，第二是在他办公室自己的机器做的，第三个是用其他云的，管理起来比较麻烦，很多个交付，很多个任务，需要去写一些东西出发的。github第一次Pr以后，我们把它原来的测试全部变成Component的测试，放在kubernetes平台执行。执行完以后调API，告诉github可以PR，再把MySQL的所有测试用例用kubernetes再跑一遍，这个跑完以后就会通过他们内部的Slack的team，然后说这个已经过了，包括性能的情况。然后再去这个7×24，有个手工触发的地方。这套测试大概花了我们十几个GCE的高配的虚拟机帮他来做，他原来整个流程跑完需要几个小时时间，我们帮他能做到1小时之内甚至40分钟，我们当时遇到的问题不是说调度管理的问题，而是他们有一部分的代码编译速度特别慢，包括在GCE上特别慢，所有时间消化在那上。我想解决第一点DevOps遇到的一个问题，很多公司说我要把DevOps提高，我要怎么怎么样，然后把时间缩短。但实际上是怎么样的，当然华为不一样，华为有编译器团队，我们可以说我们编译的跟别人就是不一样。一定是投入了更多的资源把你的任务分开。带来的第二问题，作为一个公司来讲，这时候他就要来考虑，我做这件事达到这些效率，花的这些钱值不值，可能我们觉得DevOps越快越好，但是很多公司不是这样的，他说这个方式虽然很好，但是我不想出这么多钱干这件事，虽然证明这个流程可以。DevOps选择的时候还是要依据很多条件，你要做这个事情，第一你的组织结构是什么样，第二你团队的整个成长历史经验包括积累是什么相同，更重要一点，你做的项目是什么样的，这个项目是不是需要那么多的流程，需要那么多的工具支持。最后你把所有的资源核算，算清楚我做这件事情的代价是什么，我的工程师要不要去breaking down我目前的工作流程。不是说越快越好或者花越来越多的钱越好。
热门专题
