成都创新互联-专业网站定制、快速模板网站建设、高性价比盈江网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式盈江网站制作公司更省心,省钱,快速模板网站建设找我们,业务覆盖盈江地区。费用合理售后完善,10多年实体公司更值得信赖。
从2016年底发布的第一个版本到如今能够完全支撑猪八戒网500+研发人员的日常研发工作,DevOps团队经历了不断的试错和改进总结。本文侧重于解决方案,更多细节可以关注八戒技术团队公众号获取,希望对即将实践DevOps和正在实践DevOps的团队有所帮助。
2015年,历经10年步步为营,稳定发展的猪八戒网厚积薄发,迎来了业务的快速增长,随之而来的就是公司人员的壮大,研发团队从几十人扩张到了几百人,而正是人才的引入和业务增长的迫切需求,使得猪八戒网开始了一场轰轰烈烈的改革运动,而这样的运动,在过去的十年里已经搞了6次,因为公司的取经文化,我们将这样的运动称之为“腾云行动”。
而这次的腾云行动,我们主要做了两件事情:
第一件事是服务拆解,把庞大的单体应用根据业务划分,模块功能划分,拆解成一个个独立的小应用进行部署;
而这两件事情,将交付周期从之前的月,缩短至周,甚至为天。这无疑对我们的交付能力提出了严峻的考验。
于是,经过充分的调研和准备,以及慎重的决定,在2016年第三季度,研发团队抽调了部分运维人员和开发人员组建了devops团队,这个团队的目标只有一个,那就是满足频繁的交付,随时随地地交付。
而要实现这个目标,就必须要做到以下几点:
我们将猪八戒网的业务拆成了一条条业务线,现在将这些业务线抽象成一条条产品线,然后产品线下面有子产品线,子产品线下面就是具体的产品,从而形成了一棵层次分明、业务清晰的产品树。
接着我们引入了产品责任制的概念,我们可以看到,每一个产品都包含了一些基本信息,这里需要注意的是,每一个产品都必须有一个产品经理,而产品经理也是有归属部门的,于是我们就得到了一条责任链,产品-产品经理-归属部门。
然后,我们又引入了工程责任制概念,同理,我们每个工程也包含了一些信息,如源码地址、开发语言、运维配置信息,以及我们的工程负责人,每个工程负责人也有归属部门,这样我们也得到了一条责任链,工程-工程负责人-归属部门。
我们现在将产品与工程关联起来,并规定每一个工程必须关联一个产品,这样就保证了每一个产品都能找到实实在在的生产源码。
而做到这些还不够,我们还需要一个东西,把这些全部穿起来,于是我们使用jira构建了四种标准的需求发布流程:
现在有了产品树、产品责任制、工程责任制,以及需求发布流程,我们最后就建立了需求-产品-工程的标准研发生产线。
要做到这点,我们需要实现四个功能:
1)创建源码仓库:根据用户填写git祖名和工程名自动创建git仓库。
2)提供各种技术栈的工程模版:根据用户填写的开发语言提供对应的工程模版,并在创建git仓库后,完成初始化,提交到git仓库。
3)生成部署配置信息:根据用户填写的基本信息和系统预设配置动态生成流水线配置信息。
4)生成配置中心信息:生成各环境配置中心信息。
流水线做的其实总结起来就四件事:拉取源码,编译构建,将制品上传制品库,将制品部署到服务器。
而为了使这个过程可靠、可控以及规范,我们加入了校验任务,校验一些准入准出。
其次,再加入了测试任务,如自动化测试等。
然后就形成了这么一条流水线:
最后应用到各个环境后,便成为了以下的流水线:
流水线具有如下功能:
1)支持虚拟机容器两种发布方式
虚拟机发布,在完成编译构建之后,把生成的制品上传到文件服务器,这个文件服务器就相当于是虚拟机发布工程的制品库,文件服务器上保存了这个工程发布的历史制品版本,在上传到文件服务器后,接着会从文件服务器将制品同步到代码源,最后,虚拟机服务器上的守护进程会检测代码的代码是否发生变更,如果变更,便主动拉取代码,然后重启服务。
而容器发布,则会在编译构建完成之后,根据用户提供的dockerfile文件构建镜像,然后将镜像上传到公司内部的hub仓库,接着组装元数据,调用容器云接口,部署到k8s集群。这里的容器云是猪八戒网自己基于k8s做的二次封装,主要的功能,就是将元数据拿来处理生成deploy文件,然后调用k8s执行部署操作。
容器发布&虚拟机发布构建打包示意图
2)多分支开发,主干上线
在测试阶段,可以用各种分支进行开发测试,测试通过后,就必须合并到主干,然后用主干进行发布上线。
3)一次构建处处使用
考虑到设置的分支策略,于是我们规定,测试环境的制品只能用于测试环境使用,这样一来就需要在预发布再进行一次构建操作,而此次的制品因为是经过测试而合并到主干的代码生成的,所以认为是稳定可靠的,于是在后续的环境中,将不需要再次构建,而直接使用预发布生成的制品。
4)使用Jenkins作为后台构建作业机器
采用多master,多slave的Jenkins集群方案,其中master只做调度,slave执行确定任务,我们预先在jenkins master上创建了流水线对应的job,图中的左边是我们自研的流水线服务,用Java编写的,通过调用jenkins API触发构建,jenkins master调度slave节点执行job,然后左边的流水线服务定时调Jenkins API获取构建状态和结果,实时更新推送记录的状态和日志。
现在,我们将需求发布流程和流水线结合起来,就能得到下图所示的标准生产过程。
上面我们讲了流水线,现在来讲一下,如果上线出现了问题,如何进行回滚。不知道大家有没有注意到上图的一个细节,那就是在预发布的时候,有一个任务——打tag,而这个操作就是我们实现回滚的关键。
这个打tag主要做了两件事情:
现在我们看看这种情况:
比如现在我们发布了一次线上,发布的tag版本是v1.3.35,对应的代码版本是a,镜像是A,这次发布是成功的,没问题的。
然后我们又发布了一个版本到线上,v1.3.36,对应的版本是a,镜像是A,当发布到线上后,发现服务异常,于是需要进行回滚操作,选择上一次成功的版本v1.3.35,因为保存了这个版本对应的代码信息和镜像信息,所以当选择这个版本时就能找到这个正确的制品,然后触发一次流水线,就进行了回滚。整个过程可以控制到几十秒内,让线网故障导致的损失降到最低。
最后,我们看一下整个devops的生态链:
至此,我们的devops第一阶段完成。
1)带来的意义与价值:
2)不足之处:
基础服务和工具众多,需要多个平台间切换,增加开发人员负担;
没有高效自助执行的研发类工作流,大量实际工作需要人工处理;
缺乏成本管控手段,服务器成本居高不下。
我们针对以上不足做了以下改造:
1)把流水线的任务拆解成一个个独立的原子任务,并将原子人按功能划分为校验类和执行类。
2)根据工程的开发语言,发布方式,以及推送环境,预设了一套流水线任务列表。
可以看到,这里面有两种箭头,分别代码同步任务和异步任务:
3)自研了Jenkins rabbitMQ插件,实现流水线服务与Jenkins之间通过消息队列通信。
重构之前,前面讲到是通过调用Jenkins API的方式实现的,而重构之后,流水线服务组装好构建信息后将消息发布到队列里,jenkins 插件消费消息,然后调度slave执行任务,同时将状态和结果生成消息也发布到队列中,流水线服务消费消息更新日志和状态,这种方式极大地提升了成功率。
4)Jenkins slave节点容器化
重构之前,所有的slave节点都是虚拟机,这样就导致节点数量固定,要么造成资源浪费,要么无法满足高并发,而且维护成本较高,一旦涉及改动,需要人工更改每一个节点。
重构之后,我们利用k8s 插件,链接我们的k8s集群,创建slave节点。利用k8s特性,可动态调整节点数,既满足高并发,又不造成资源浪费,并且维护简单,一旦涉及改动,只需要重新构建slave镜像应用即可。
重构之后的流水线有如下特点:
1)工程创建阶段
定义六大工程类型,完全覆盖所有研发需求,且配置简单,一键创建。
2)工程研发阶段
根据工程类型生成配套组件,研发阶段全面赋能。
配套组件有工程权限管理、工程服务管理、工程资源管理、配置中心管理、调度任务管理、域名管理、安全管理等。
3)工程上线阶段
统一需求发布流程,cicd流水线标准生产,保证每一步的可靠性。
4)工程运行阶段
实时监控服务,多种维度的异常告警机制。
5)工程下线阶段
智能检测中心检测无用工程,360度检查工程依赖项,一键下线,操作简单。
由此我们实现了工程的全生命周期管理:
1)提供一站式查询和使用
2)提供各类工具使用文档
1)三步自定义工作流模版
有了工作流模版,我们就可以创建工作流了。
2)三步创建工作流
3)实时记录工作流状态和执行过程
当创建完一条工作流后,这条工作流所有的执行状态以及过程都会被清晰地记录下来,如图从发起到各个节点的扭转,以及执行结果、执行时间。
4)数十种系统自动执行节点任务
如果经办人是系统,那么就会根据当前工作流类型执行对应的系统任务,我们预置了几十种系统执行任务,基本覆盖了所有的研发需求,如数据库相关操作、运维相关操作。
5)实时通知经办人和进行催办
在扭转到某个节点的时候,我们通过系统通知和用户催办,尽可能地缩短工作流的办理时间。
至此我们得到高效扭转的研发工作流。
1)产品纬度统计各部门服务器成本费用。
前面我们提到,每一个工程都会关联到一个产品,而每个产品都有归属部门,由此我们便能更具产品纬度统计部门的服务器成本费用,当然,不仅是服务器成本费,也可以是其他费用,如代运维费,开发人员成本等,都可以照此计算。
2)监控每个部门的服务器成本是否超过预算,若超过预算则不允许发布上线。
至此,我们的devops第二阶段完成,总结一下成果和价值:
DevOps实践之路还在继续,因为不同公司有不同的业务场景,而同一公司的业务也会随着时代的发展不断变化,只有适合自己的才是最好的,只有能拥抱变化的才是最好的,但万变不离其宗的,我觉得应该有以下几点:
1)DevOps应该是以提高研发效率为目标的实践,脱离了这个目标,做得再好也只是炫技。
2)DevOps应该是紧贴业务的,因为业务的不同,要求的技术架构也会有所不同,随之而来,要求的交付方式也会有所不同。
3)DevOps应该是以人为本的,我们应该尽可能地将一切繁琐的过程交给程序去执行,而人只需要“坐享其成”或者做少量的决策即可。
当前名称:这才是DevOps演进及CI/CD实践的正确打开方式!
链接分享:http://www.shufengxianlan.com/qtweb/news26/180576.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联