返回 登录
1

支撑企业IT精益运营:普元DevOps平台实践之路

阅读1154

本文转自微信号EAWorld。扫描下方二维码,关注成功后,回复“普元方法+”,将会获得热门课堂免费学习机会!
图片描述

一、普元DevOps平台建设历程

普元从2008年开始研发持续集成平台(CIP)、自动化测试平台(UTP),2009年内部的所有产品都实现了持续集成、自动化测试、自动化部署。随着DevOps理念的兴起,企业的数字化转型的需求也愈发强烈,于是开始着手研发DevOps平台,并在这个过程中不断探索微服务、DevOps、容器云、ChatOps等的关系和最佳实践。
DevOps先后历经4个大版本,目前已经完成了落地的实践。

图片描述

2015年7月~2016年4月:为支撑企业数字化转型,普元开始研发数字化企业云平台(The Platform),于2016年4月完成1.0版本并进行内部上线。1.0版本主要提供了持续集成和持续部署的能力,同时还包含了自己的容器云平台,与容器云平台对接,贯穿设计、开发、测试、上线、维护五大软件研发生命周期,打通代码提交、触发集成、自动部署到容器云的快速链路。

2016年5月~2016年9月:基于自己吃自己狗粮的思想,通过1.0版本研发了2.0版本,考虑到产品的发展,将数字化企业云平台中的产品各自独立拆分出来,包括DevOps、容器云。每个产品都有着独立团队,持续发展。DevOps2.0在1.0版本的基础上,打通规划、需求等环节,将产品管理、项目任务管理等能力纳入进来。

做了2.0版本,大家反倒有些困惑了,DevOps平台真的就只是简单的通过和某些工具(如jenkins)集成,然后一键编译、部署到容器云上就可以了吗。我们开始借鉴很多国外的优秀产品,同时也开始和更多的其他公司进行深度交流。慢慢地发现,真正实现一个企业级的DevOps平台,远不止和jenkins做集成、一键部署到容器云这么简单。以持续集成为例,一个企业要支持的集成环境肯定不止一种,包括maven编译、ant编译、android编译、ios编译、前端应用编译(nodejs),在集成时还要考虑和代码质量分析,单元测试、单元测试覆盖率检查、介质上传等能力的结合,其实集成也是一个工作流。

最典型的一个流程如:maven编译(包含单元测试)–》代码质量分析 – 》交付物上传到二方库。在构建后还应该看到详细结果:构建详情、日志、单元测试报告、代码质量分析报告、介质查看与下载等能力。想想,这样的一个过程是不是才能基本满足了企业的正常使用方式?

以部署而言,企业的真实环境又岂会是只有容器云。对于大部分企业而言,物理机是必须的,有的企业甚至物理机、虚拟机、容器云三种环境并存,那么在部署的能力上,只支撑容器云环境的部署显然是远远不够的,至于企业实际的部署能力,自然又更加的复杂:应用部署(springboot应用,传统war包、纯前端应用)、中间件部署(数据库部署、分布式缓存、分布式消息队列)等都要一一考虑。所以在
2016年7月~2016年8月,我们开始研发3.0版本中,在持续集成和自动化部署的能力上,参考tfs和oneops的优秀设计,结合企业实际的使用场景,用了两个月的时间细化打磨持续交付的能力。

2016年10月份开始,我们重新梳理了整个DevOps平台的需求,将整个平台划分成了三大领域:敏捷过程、持续交付、持续改进。

敏捷过程:包含产品管理、项目管理、任务管理、进度管理、计划管理等,覆盖产品、项目的全生命周期。

持续交付:包含代码库的管理、持续集成、部署、交付流水线等能力,意在打通从代码提交到部署上线的全流程。持续集成支持编译、打包、测试、工具四类构建任务,支持代码提交时触发构建、定时构建、手动构建三种构建触发策略。在部署方面,支持springboot应用、传统war包、html站点、mysql等部署,支持灰度发布、滚动升级、蓝绿发布等多种部署策略。

持续改进:包含质量标准、质量监控、以及产品项目全生命周期过程中的各种度量报表。支撑企业的精益度量。

2017年6月份会发布5.0版本。

OK,以上是我们这两年的DevOps建设历程,下面我们在这过程中积累的经验,给大家介绍下,如何建设一个企业级的DevOps平台。

二、如何建设企业级的DevOps平台

这里为什么要强调“企业级”呢?一个小团队如果想要实现DevOps能力其实可以很简单,因为团队规模不大,比较容易管理,同时负责的应用也不会特别多,通过集成一些开源的工具完全可以做到持续集成、持续部署、持续交付,同样可以带来极大的效率提升,这其实也是一些互联网企业内部小团队的特色。但是当这一切放大到一个数百人,数千人甚至数万人的企业时,就会发现遇到的问题、阻碍呈几何级的上涨。一个企业要考虑的因素太多,历史越悠久的企业,内部的文化、流程越是根深蒂固,而当一个平台需要打通整个IT生命周期时,现有的文化、流程,现有的组织结构都不得不慎重推敲下是否能够满足。

所以,如何建设适合自己企业的DevOps平台,即使现有市场的DevOps理念已经基本普及开了,但是到落地的时候,却总会发现困难重重。到底该怎么去落地呢?

明确定位:DevOps是覆盖IT全生命周期的生产线

对于DevOps平台的定位还是要再明确下,DevOps代表的含义早已不仅仅是简单的开发运维一体化,而是在此基础上,打通产品、项目的软件研发全生命周期,覆盖持续交付、持续改进等能力,在纵向打通应用的全生命周期(需求、设计、开发、编译、构建、测试、部署、运维等),横向打通架构、开发、测试、质量、运维、运营等部门。我们把DevOps分为三大领域,敏捷过程、持续交付、持续改进,三者相互独立却又相辅相成。通过DevOps平台将企业软件研发的全生命周期管理起来,在保证质量、安全的前提下,通过一些自动化的手段不断提升软件交付的效率,通过不断精益度量对过程、对技术持续改进,最终支撑起企业的IT精益运营。

理清思维:DevOps思维和互联网思维的区别

可能很多人对于DevOps的理念还存在这样的误解:DevOps来源于互联网,也只适合互联网企业。但DevOps思维和互联网思维还是有着一定的区别的,不能简单的认为只有互联网公司才适合DevOps。恰恰相反,其实DevOps理念的提出以及最初的发展并非是互联网公司而是传统企业。互联网公司强调的是快速、用户口碑,性能,并且对于上线的大部分应用具有一定的容错性,严重的错误可以快速的修改和再上线。而DevOps追求的是质量、效率、精益、价值、稳定,企业尤其是金融类的企业对于线上应用的问题容忍度其实很很低的,很难想象如果一个交易业务出现问题后,会给企业带来多大的损失。

所以,DevOps绝不只是互联网企业可以实行,对于传统企业而言,更加适合。通过建设DevOps平台来大幅提升软件研发效率,提升对市场的响应速度,支撑企业的数字化转型,也许对于传统企业而言,DevOps平台带来的价值才是更大的。

认清价值:DevOps给你带来怎样的业务价值

清楚了DevOps平台的定位,也明白了DevOps平台对于任何企业都是可以实现的,那么还是回归到自身上,需要结合企业自身的现状思考下:到底DevOps能给自己的企业带来什么样的业务价值呢?DevOps平台的理念固然是将软件研发的全生命周期管理起来,但是并不意味着一定要做到全生命周期的管理,落实到企业内部,终究还是要结合企业的现状和实际的需求,有选择性有目标的去建设。比如某企业由于组织的问题无法打通整个生命周期,那么通过持续集成、自动化测试、自动化部署等能力,提升软件交付的效率也是极好的。

对于企业而言,不管是提升IT的运营效率70%,还是做到开发测试环境的持续集成、自动化测试、自动化部署,亦或是一天部署10次这种DevOps最初的目标,最重要的还是要结合现状,先认清DevOps能给企业带来什么样的业务价值。

建设步骤:DevOps平台建设步骤

梳理企业的流程和规范:

梳理企业的流程和规范是企业建设DevOps的前提,甚至即使不建设DevOps平台,这也是一个必不可少的行为。只有统一了企业的流程和规范,才能建设出一个适用于企业的DevOps平台,否则到最后,有可能会让DevOps平台脱离实际,导致没有人会去使用。那么有哪些流程和规范是要提前梳理和统一呢?这里列举几个如下:

产品(应用)管理规范:包括版本管理、需求管理的规范等

项目管理规范:包括团队的角色构成、过程工作流模板(Agile,CMMI,Scrum)、计划/任务管理规范等

开发和编译规范:包括代码开发规范(分支主干的使用)、代码提交规范、构建规范(触发策略,是否需要代码提交时构建等)、介质管理规范等

部署相关的流程和规范:比如部署架构的规范,环境的管理规范、软硬件资产管理规范等

总结自身的痛点和需求,规划建设路线图(MVP)

完整的DevOps平台是个很庞大的体系,如果全都靠自己建设的话,很显然不可能短时间建设完成,那么就要结合自身的痛点,从痛点入手,认清自己最迫切的需求,规划出DevOps平台的建设路线图。基于MVP(Minimum Viable Product)的理念,一步步有序的推进整个平台建设。假如自己的企业目前主要的瓶颈在于如何提升研发效率,那么就可以从统一开发平台、打通持续集成作为切入点。如果目前的主要问题是软件交付速度太慢,那么可以优先考虑持续集成、自动化部署、自动化测试、交付流水线的建设。

从组织、技术、流程、文化四个维度持续优化与改进

图片描述

DevOps的实施和企业的组织、技术、流程、文化紧密结合,根据我们的经验,在企业中,技术方面的实践最容易在团队中实践,流程次之,组织的优化与变革则是最为困难的。很多时候,不是技术上打不通整个生命周期,而是一些客观的因素导致无法打通各个部门。我们建议,在实践的过程中,由易入难,持续优化和改进。

细节至上:DevOps平台建设关键点

在建设DevOps平台中,有一些关键点是不得不注意的,简单列举几点:

如何支持异构环境、异构应用自动化部署?

企业的应用类型多样,纯前端应用(通过nginx等运行),传统war包(通过tomcat等应用服务器运行),springboot应用(fatjar包直接运行)、android应用、IOS应用等等,运行环境复杂的要同时支持物理机、虚拟机、容器云。如何做到异构环境、异构应用的部署支撑,并且考虑到后续的可扩展性,对于平台架构的设计是有一定要求的,这个会在后面的部署架构的章节中详细介绍。

如何打通工具链的集成?

其实大部分企业,现状都是在软件研发生命周期各个环节,已经有了一批的工具,只是这些没有串联起来,如果是小工具随便用用还好,但是如果是一些用的比较根深蒂固的,可能就不是那么好替换了,方案会更加倾向于集成。集成除了技术因素外,还必须要想清楚哪些工具去集成,哪些不集成。集成到什么程度,比如针对于底层的IaaS平台或者容器云平台,我们就只是进行接口调用,而并非功能的接管。对于jenkins这种敏感资源,更倾向于把整个jenkins封装起来,不对外进行暴露。

如何与现有的企业流程紧密结合?

不同企业有着不同的流程和规范,以持续交付流水线为例,可以是构建、SIT部署、SIT测试、提测、UAT部署、UAT测试、LAB部署、LAB测试、预发演练、生产部署等环节构成的一个大流程,也有会拆分成集测流程(开发过程中不断运行)、发布流程(从提测开始,UAT和LAB可以是并行的)两个流程,当然也有可能流程和这完全不一样。这也就对DevOps平台的建设提出了要求,如何和现有的实际流程紧密结合。

除此之外,还有一些问题也是要考虑进去的,如何快速支持流程使用过程中的一些微调(如环节的配置字段属性等)?如何做到流程手工和自动执行的自定义?如何让buildNumber贯穿整个流程,让后续环境部署的介质对应的是哪个buildNumber有迹可循?如何直观的查看交付流程目前到了哪个环节、每个环节的状态是什么样的?如何以环境为视角,看到该环境下正在运行哪些应用?当做到这些的时候,才能让整个交付流水线真正的实现价值。关于这一部分我们的设计同样在后面的持续交付流水线架构章节中进行详细介绍。

如何支撑企业IT精益运营?

精益运营的基础是度量,度量的三大维度:指标、执行监控、预测。首先是明确指标和执行监控,基于软件全生命周期的度量过程中企业遇到的最大困难莫过于拿不到完整的数据,各个部门、各个流程、各个系统之间数据相互隔阂,信息很难流通,导致无法从整体的角度对软件过程进行度量。当DevOps平台能打通企业的软件生产全生命周期时,数据的割裂性问题自然也就不存在。当然,度量不仅仅是事后的统计分析,更应该提供过程监控的能力,在过程中,通过一些看板(比如任务看板、需求看板、发布看板)、趋势图(比如任务燃尽图、bug燃尽图)等,提前预知风险,规避风险,持续把控项目质量和产品质量。

我们目前主要从质量、效率、进度三个维度,普通员工、团队负责人、部门领导等角色视角出发,提供如下能力:

图片描述

三、DevOps平台架构剖析

1.总体架构解析

先看看DevOps的整体架构,正如最一开始所说,我们把DevOps平台划分为三大模块:敏捷过程、持续交付、持续改进。平台的概念模型如图所示,划分为5大领域:产品域、组织机构与权限域,项目域、部署域、持续集成域。

图片描述

平台的逻辑架构如下:

图片描述

DevOps平台划分为领域层、基础服务层、工具层三层。领域层和概念模型的5大领域基本一一对应,包括项目管理、产品管理、交付中心、组织机构等。服务层则是封装的一些基础能力,如编译、部署、代码管理等。底层运行环境支撑传统主机、PaaS平台、容器云平台。同时平台机制支持灵活的的扩展(如工具集成扩展、部署能力扩展等),面对复杂的场景或者特殊的需求时,平台也可以提供更加灵活地能力。

2.敏捷过程

敏捷过程的架构核心在于工作项(WorkItem)的设计,工作项涵盖了需求(长篇故事、特性、用户故事)、开发(任务、缺陷)、测试(测试用例、测试计划)等。可以说,在整个项目周期中,将所有的工作项统一管理起来,工作流和工作项关联,不同的过程对应不同的工作项,比如Agile对应的需求相关工作项是Feature/Story。Scrum过程体系对应的需求工作项则是Epic/Feature/UserStory。

通过对工作项的设计,可能支撑多种工作流的差异化,便于设计和扩展,同时,可以从统一的视角查看所有的工作项,更加便于统一管理、统计分析。其实jira、tfs也是类似的设计思路,只不过jira把一切看成是“issue”,tfs则是把一切看成“工作项”。

图片描述

以需求为例说明,需求分Epic/Feature/UserStory三层,每一层都是一种工作项,工作项有哪些属性,属性对应的值类型,控件类型都会在数据中定义,页面上表单页面通过数据库中定义的属性和控件数据动态生成表单。用户可以自定义项目中需求属性和状态。

3.持续集成

持续集成模块功能主要有代码库管理、构建定义管理以及构建实例管理等。在构建定义管理模块中,DevOps平台将构建任务分成了四种类型:

编译类任务:Maven、Ant、Gradle、纯前端构建等
测试类任务:Sonarqube、Jmeter、Selenium等
打包类任务:Npm、Archive、Docker等
其他工具类任务:Copyfile、Shell、介质提交到Nexus仓库、介质上传二方库等。

在每个构建定义上可以选择若干个需要的构建任务,通过原子步骤编排,组装成一个完整构建流程。代码提交时触发构建(支持gitlab、github、svn等常用代码库版本管理工具)、日构建等不同的构建触发策略等支撑了持续集成的完整链路打通。

在持续集成的领域,绝大多数企业应该都会选择jenkins吧,我们也不例外。持续集成模块的核心框架就是jenkins。每个构建任务对应jenkins的一个pipeline stage。在执行时,将所有构建任务结合构建定义的一些基础信息,创建jenkins的pipeline进行执行。

jenkins的搭建采用master/slave集群模式,面对大量应用的编译压力时可以更好的分散压力,保证编译速度。如果想更灵活的话,可以考虑jenkins集群部署在容器中,通过容器云的动态伸缩能力,可以更灵活的去使用资源。这里要提到一个关于异构环境的编译,如ios应用的编译,就必须在mac os系统中进行。这就要求编译机和其他的机器有所区别。我们是采用jenkins的节点标签能力,如果是要进行ios编译任务的话,就会通过标签到ios的工作节点中执行任务。

4.自动化部署

在自动化部署模块中,为了更好的与实际结合,我们将部署分为三个阶段:设计、转换、运维。

图片描述

设计阶段:将部署架构分为三层:部署装配(Assembly)、部署容器(Platform)、部署组件(Component)。部署装配是对部署架构的描述,由多个部署容器组成,每个部署容器由若干个部署组件组成。

操作流程:

1.创建Assembly
通过选择可用的系统模版(Platform Template),添加一个新的Platform
每一个Platform都对应一种应用(如mysql,tomcat,springboot,nginx)
每一个Platform都是有一组组件(Component)组成的,并且已定义好了组件之间的依赖关系

2.管理Component
Component是最底层的部署(或者配置)单元,如springboot中的secgroup, compute, os, jdk, fatjar, lb都是一个组件
每一个Component都有相应的配置模版

3.提交设计
提交的过程是将已经完成的设计做一次Commit,做一次归档。

图片描述

转换阶段:转换(Transition),是在Assembly内对应用/系统在某一具体部署环境内的部署过程。部署环境是配置、架构设计、运行资源、部署策略的结合。

操作流程:

1.创建部署环境(Deploy Environment)
根据环境类型(如dev, test, prod等),添加属于某个Assembly的部署环境
部署之前,部署环境是应用/系统用于部署的配置的抽象
部署之后,部署环境就是管理和监控应用/系统的具体实例的集合

2.配置部署环境
设置每个Platform关联的资源(vm/container)、部署模式(单点,高可用)

3.选择Assembly内的一个或多个Platform生成并提交执行计划
根据部署策略不同,一个Platform的执行计划可能包含几个子计划

4.执行部署
每个Assembly/Environment/Platform下面的每个Component都有一个部署实例,这些实例可以进行单独操作

运维阶段:对于已部署的实例进行运维管理,包括启动、停止、重启、修复、状态检查等等

考虑到驱动的统一性以及jenkins2 插件的丰富性,DevOps自动化部署框架底层同样使用了jenkins。采用DevOps平台(设计)+Jenkins(执行)的方式完成。

DevOps的职责:
完成部署架构设计;
根据部署架构设计和部署环境的配置创建生成相应的执行计划及子执行计划,每一个子计划对应一个Jenkins pipeline job配置文件(config.xml);
查询Jenkins执行job的实时进度与结果。

Jenkins的职责:
根据config.xml创建Jenkins Pipeline Job;
执行pipeline job;
Jenkins job 通过pipeline script中ansible/openshift命令进行相应的部署等执行操作;
提供查询job执行情况的Rest API。

DevOps平台中的部署架构设计和jenkins pipeline的映射关系如下图所示:

图片描述

可以看到每个组件都会对应jenkins的一个stage。所有的stage组装成一个完整的pipeline在通过jenkins执行。

为什么选择jenkins pipeline?主要是结合以下几点进行考虑的:
durable持久性:在jenkins的master按计划和非计划的重启后,pipeline的job仍然能够工作,不受影响。
可暂停性:pipeline基于groovy可以实现job的暂停和等待用户的输入或批准然后继续执行。
更灵活的并行执行,更强的依赖控制,通过groovy脚本可以实现step,stage间的并行执行,和更复杂的相互依赖关系。
可扩展性:通过groovy的编程更容易的扩展插件。
丰富插件:Jenkins已经支持通过groovy命令调用git、maven、npm、gradle、shell、junit、sonarqube、ansible、docker、openshift、kubernetes等插件,不需要我们再单独实现集成。
Rest API:Jenkins提供通过Rest API的方式获取每一个stage的执行情况。

5.持续交付流水线

有了持续集成、部署、测试的能力是否就足够了呢?其实还是不够,DevOps的本质是IT生产线,交付流水线是持续交付的核心能力,它可以把分散的能力如构建、部署、测试等串联在一起,形成一个从代码提交到发布上线的流水线,通过流水线可以很直观的看到当前某个具体构建版本已经到了哪一个环节,从整体上对于软件交付进行更好的把控。

图片描述

如何快速支持流程使用过程中的一些微调(如环节的配置字段属性等)?如何做到流程手工和自动执行的自定义?如何让buildNumber贯穿整个流程,让后续环境部署的介质对应的是哪个buildNumber有迹可循?如何直观的查看交付流程目前到了哪个环节、每个环节的状态是什么样的?如何以环境为视角,看到该环境下正在运行哪些应用。

在设计流水线能力时,我们主要考虑到几点:

结合企业的不同交付流程,要能支持自定义的流程配置,要能支持多套流程配置
流程的每一个环节都要支持自动执行的配置
流程中每个环节的属性和配置信息可以自定义,灵活扩展
流程以构建开始,让buildNumber贯穿整个流程,方便追根溯源
要有一个看板,直观的看到整个产品的版本目前到了流程的哪个环节,是SIT还是UAT,结果如何
要有一个看板,直观的看到每个环境下,有哪些介质在运行

以这些为基础准则,我们底层基于了普元的BPS流程引擎,支撑流程的自定义和扩展。并且,针对于每个环节,都可以配置前置后置事件、人工执行还是自动执行,责任人等。整个流水线从构建开始,以代码的buildNumber贯穿全流程。便于问题、进度的追溯。看板的设计如下:

图片描述

王海龙 普元云计算架构师
毕业于华东师范大学,曾参与和负责银联Paas云平台项目、兴业银行CAP4J项目、交通银行信用卡中心统一监控平台项目、神华灾备云平台、万达DevOps平台等项目。

图片描述

关于EAWorld
微服务,DevOps,元数据,企业架构原创技术分享,EAii(Enterprise Architecture Innovation Institute)企业架构创新研究院旗下官方微信公众号。

扫描下方二维码,关注成功后,回复“普元方法+”,将会获得热门课堂免费学习机会!
微信号:EAWorld,长按二维码关注。
图片描述

评论