请选择 进入手机版 | 继续访问电脑版

IT运维管理,ITIL,ITSS,ITSM,ISO20000-ITIL先锋论坛

 找回密码
 点击获取邀请码 - 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

艾拓先锋
搜索
查看: 160|回复: 0

DevOps平台实践落地-构建管理详解

[复制链接]
来自- 美国

参加活动:0

组织活动:0

发表于 2018-8-23 15:02:34 | 显示全部楼层 |阅读模式 来自- 美国
本帖最后由 adminlily 于 2018-8-30 09:39 编辑 $ j; p) N3 d0 H! _$ a5 y3 I* T
3 F9 Z4 u5 S: T
# a: j! U' g  Q5 F. k& D/ p% s6 y
3 F/ l! ~: a- E
& u, K9 `/ f& ^/ u

$ z+ u9 a+ Y+ E, D
企业做DevOps平台,本质上是做企业的IT生产线,最终是实现整个企业级的数字化生产线。构建作为落地DevOps平台必不可少的环节之一,是持续集成、交付和部署的基础。本文我们从DevOps的CICD总体思路出发,和大家分享一下DevOps是如何做构建管理的。

3 e: o: {, r1 s: a, Z1 P% W, }* ?

# K  X( V" L, w; [# `. q
4 L3 B6 O1 n9 [0 ]7 n" A

8 o( G7 L7 n* U- o* O; w" ~5 n- ?
目录:
& M. A/ |9 _& H3 K" W8 E8 Z
8 O/ h" p: C% O  W
一、CI/CD总体思路

7 J: g; J4 y! x1 z! j
* r) j" E+ G7 S, k
二、构建定义与任务编排

# W. \/ v8 w* X/ x; O* u( F

3 o& j" e7 f3 Q; ^3 Q4 |! N/ t
三、构建策略

& t* L& q8 ?2 s! _3 s# \/ S

- R# m$ g+ y! F7 K) `% W  g7 d
四、构建执行与跟踪

* R, K; ~- M7 B! i1 R
9 g; K6 E& l8 Q5 @
五、总结
+ b7 ~- K8 C' p) G7 w

' T4 S+ i8 k7 n* ~+ O
; f  d6 E% I; H+ b5 J, c* }
、CI/CD总体思路

, u9 U$ ~4 h0 ]8 w4 X

' h2 @5 z) o1 l7 v
在DevOps中,做到持续构建是基本的,其中复杂的地方主要是对多种环境的构建支撑。项目中有用maven编译的、有用ant编译的,如果有移动应用,有android系统的、ios系统的,还有一些前端应用的编译,比如:nodejs,这么多不同的环境我们怎么支持?另外,构建过程中还需要考虑和代码质量分析,单元测试、介质上传等能力的结合,这样的构建过程其实也是一个工作流程。
  N+ q2 V+ x3 ?' o! ]
9 F  q8 o. _% }( z% `& Q
举个最典型的例子,比如:构建时,先要进行maven编译,编译过程中包含单元测试,然后进行代码质量分析,之后将交付物上传到二方库,最后还要看到构建详情、日志、单元测试报告、代码质量分析报告等详细情况,可以查看并下载介质。只有完成了这样一个过程才能说基本做到了持续集成。
$ }% z/ I5 F* R) ]4 J4 C1 B

6 v; f# C/ G; @' v
我们的DevOps中持续集成与持续部署的总体设计思路就是在DevOps中进行设计,然后通过Jenkins执行的方式。DevOps负责进行构建定义或部署架构的设计,生成Jenkins的pipeline job的配置文件;然后Jenkins根据这个配置文件创建并执行pipeline job;DevOps再通过Jenkins的Rest API跟踪执行进度和结果。
& D+ b6 }5 I+ I: Z

) J; j7 k% }. d( Z- c* z
之所以用Jenkins,正是因为它强大的集成能力和基于groovy脚本的可扩展工作流设计。Jenkins实现了与众多插件的集成,可以通过groovy命令调用git、maven、npm、gradle、shell、junit、sonarqube、ansible、docker、openshift、kubernetes等插件,让我们的集成工作非常简便。其次,Jenkins的核心Pipeline的实现方式就是使用Groovy脚本来表述复杂的流程,既可以支持点状的持续集成也可以支持线状的持续部署,能够支持复杂的构建和发布流程。关于Pipleline的介绍大家可观看我们的短视频:Jenkins集成(http://p.primeton.com/articles/599e770e4be8e65e9c008522)。

2 h( l3 C' E8 C  O# R$ {

4 Q9 L! d2 n2 L
此外,顺便分享一下我们集成Jenkis时遇到的一些难点。
9 t/ X; [& X0 D1 N0 `) i* X
. S! W" c3 J& Y1 E( C
首先是执行效率问题,我们的DevOps通过API启动Jenkins时,Jenkins先排队调度再执行的机制造成启动较慢,比如会等待5,6秒,有时甚至是10几秒的情况,之后才会开始执行真正的脚本,用户体验较差。这方面我们自己通过异步和队列来解决用户体验问题。
其次是信息去重问题,Jenkins的Master-Slave的集群模式,使得我们在从多节点获取执行情况时需要进行去重处理,目前我们采用轮询加锁的方式解决。

! p$ i5 M0 l! ?  H4 @3 S- M. Y2 a( t. ^# e) ~1 i
此外是信息扩展问题,从Jenkins获取的结果都是日志形式的,Jenkins没有很好的扩展机制来支持定制,比如:过滤用户名密码、获取URL地址等等,需要DevOps自己进行过滤和处理。(如:有些需要的信息只能通过脚本先写到日志中再获取;用户名和密码明文存放,需要进行过滤和处理等等)。
2 R! _( P+ \5 u+ N) X

; U" E! L) s( p$ D4 D  p3 ?
另外,Jenkins的官方客户端REST API文档不太健全,需要通过调试的方式自己摸索。
7 I0 G9 d; `8 T

/ Z" L( I/ C2 B6 V5 a
二、构建定义与任务编排

: f" e/ g( z5 ^7 A5 J7 \

8 N4 H5 d$ K) @
首先我们了解一下DevOps的构建定义。这是DevOps中持续集成的操作流程。首先,可以在项目中创建构建定义,在每个构建定义上可以选择若干个需要的构建任务,通过原子步骤进行编排,组装成一个完整构建流程。通过触发策略和保留规则的定义,可以在代码提交时触发构建(支持gitlab、github、svn等常用代码库版本管理工具),或者在指定时间进行日构建。在最新版本的DevOps中,我们增加了组件的构建定义,一个构建定义可以对应一个或多个组件。

! K2 z" [+ J) |. e" P
6 g0 Y$ C  q- `$ V5 u. D) ~
在构建定义时,DevOps中的每个构建任务对应jenkins的一个pipeline stage。在执行时,将所有构建任务结合构建定义的一些基础信息,创建jenkins的pipeline job进行执行。

. i) P6 \$ L" {( Z2 Z

- [4 V$ i/ y- l: r0 h6 F
  
目前DevOps平台将构建任务分成了三类:

# g4 o# _. R  w3 m3 c, K

2 j8 B7 e% v! N6 [" m8 X
第一类是构建类任务,如:从Git/SVN拉代码、使用Maven、Ant、Npm、Gradle进行编译,以及调用已有的构建定义进行构建等与构建相关的;

, M/ [$ p2 l, K
6 O$ O$ C. ^# _" p9 P& o
第二类是测试类任务,如:执行Sonarqube代码分析、Jmeter测试、Selenium测试等与测试和代码分析相关;
4 Z$ R) z  Z, V9 R/ H
& V+ C$ B' b5 a! X
第三类是工具类任务,如:Shell脚本执行、介质提交到Nexus仓库、介质上传二方库等。  
: X+ Q- R0 v# y0 t4 ]- X! E$ m1 v

6 N9 o* w+ F* @
DevOps通过原子任务+任务编排的方式来支持复杂的构建场景。那么,我们为什么要做编排呢?从构建任务的分类上大家可以看到,项目中使用的编程语言五花八门,对应的编译工具也各有不同,代码分析和测试工具也是五花八门,面对不同语言、不同类型的工具在构建过程中可能出现各种情况的组合,如何能够灵活地支撑这种任务的组合呢?最灵活的方式就是能够让开发人员自己根据需要进行编排。

& B3 h7 H! t1 B, c

8 o% ~5 O' o% P  Y+ I
DevOps首先将构建任务原子化,抽取成各种类别的原子任务,然后通过编排的方式将这些原子任务进行串接,就形成了灵活的任务组合,通过这种灵活的编排就可以支持各种类型应用的持续集成。之前看到的三大类构建任务就是目前我们DevOps已经抽取的原子任务,我们还在不断扩展原子任务,以支持更多的构建使用场景。
! L6 `3 ?, Z8 X( I/ L! ]
& V5 o: V/ h+ z. m9 ?2 X$ V7 W
下面是DevOps对几类常见应用的持续集成的支撑。

$ F8 m4 M3 Y) @/ J4 s; I, k

( m4 P* H4 `* c
对于springboot类的应用,首先是拉取代码,可以从Git库拉取,也可以从svn拉取,接着是构建,可以使用maven构建,也可以使用ant,gradle构建,然后用SonarQube进行代码分析,最后执行一些脚本并提交介质。
  q- p4 J" A. ?! W: x' _9 u

! a3 }' ?! O( C. y8 t- `
对于移动类的应用,目前我们支持安卓应用的构建,首先是拉取代码,可以从Git库拉取,也可以从svn拉取,接着使用gradle构建,然后进行测试,最后是提交介质。对于ios应用的编译涉及到证书管理,我们正在扩展相关的构建任务。

. s* m# P3 C$ e

4 p) ~, W3 W. J

/ |0 @! }) x; _& t4 x
对于前端应用,步骤类似,可以选择npm进行编译。
# F7 }1 x( @; V, a( |
4 {4 l1 Q  h; M8 l- n5 y$ B- a4 h
总之,通过不断扩展原子构建任务,并通过编排的方式定义构建流程,我们就能够支持更多的构建使用场景。

+ c7 S$ n0 d: _1 {4 ^

- G! f  u* m7 q) k5 ?. y, K
顺便提一句,按照我们DevOps的扩展机制扩展构建任务是不需要进行前端代码开发的,可以自动生成配置界面,是不是很酷?

1 @- _' S  s9 S, o- Z

; A2 G/ X- R" c* d0 ]
, ~! [! p+ ?- M* m5 |
三、构建策略

$ T8 i) ]4 V6 u/ Z
( A* K' D9 u( I" q! f0 p
  • 超时策略
    # f; J7 c) Y9 d8 `

3 L; D/ a4 c7 e# G3 Z! ?
我们在DevOps中进行构建定义时,可以配置超时时间。这个超时时间是指在Jenkins中执行这个构建流程的时候,最长允许执行多长时间,如果超过这个时间,这个构建流程就会被Jenkins强行终止。

* @; o( p0 s5 @; ^" {

- t' l7 W  [- E9 C/ P( l
为什么要定这个超时策略,定好的构建流程为什么要强制终止呢?
$ ]5 y( d$ e% C2 u7 O3 d
8 m- H+ n" T6 ^& W. o% ?/ n
这里面主要有两个原因:

& v& v- x/ T; E) l% O6 I7 g) C

, R% w. t  P9 Q2 g+ o
  • 一是在微服务架构下,构建任务非常频繁,我们认为每一次构建都应该高效完成,不能超过一定的时间,如果超过这个时间,排除外部因素,可能就是这个微服务的设计或者实现有问题,或者测试用例写的有问题,不停调用外部资源,导致执行得很慢。

    0 w9 m# K3 ^1 F; J) B; G
8 d/ Y. h$ B0 N( W  F
  • 二是碰到一些外部因素,比如网络不太稳定的情况,导致某一个构建环节时间过长,比如从github拉代码或者将构建产物上传到Nexus仓库,网路传输很慢,这样会因为这个编译任务被挂起,而导致所有后续的编译任务都在排队,整个jenkins Job无法正常执行,同时还占用了系统资源。配置超时后,可以及时释放占用的资源,提升整体构建效率。目前我们DevOps中默认的是10分钟,如果超过这个时间构建就会自动终止,并自动提一个Bug。开发或管理人员可以跟踪日志定位构建超时的具体原因,优化内部实现或调整外部环境。
    9 _5 r9 P0 Q# q( G1 T( R( G. l
: u1 j+ r! n$ L6 ?
  • 保留策略
    + c$ I# p$ P0 s

- A$ [1 K% L4 m2 q( R
保留策略可以定义我们需要保留几次构建记录,成功的保留几次,失败的保留几次。设置了保留策略之后,DevOps会保留最近几次的构建记录,而将之前的构建记录,主要包括Jenkins上的日志和临时空间清理掉。设置这个保留策略,主要是为了节省存储空间,因为每次构建都会生成一些构建日志和临时空间里的文件,通过保留策略可以优化Jenkins的磁盘空间使用效率。我们可以在构建历史中看到保留下来的那些构建记录。

" P9 G# T" z) N, d5 {, `3 w
3 @: r- i* |) x, I
  • 触发策略

    - f) _$ S* x# E9 f4 l1 w4 F, a
    ' {* m% {, l( y$ N2 `, F
    ( ]/ N6 O1 f* G3 f

    7 G7 h: O7 ~. L. E. G$ O" a

! z) a- r( i# V# |9 J
触发策略是指这个构建流程在什么时间会被执行。DevOps支持代码提交时触发构建、定时构建、手动构建三种构建触发策略。

: {( Y1 ^' D( z: Q) Q

/ ^! e& x0 |9 J5 p& A
第一种代码提交时触发构建,支持通过gitlab或github管理的代码库。DevOps平台提供了触发构建的RestAPI,只需要在github或gitlab的webhook中配置payloadUrl,调用DevOps提供的RestAPI即可。可以根据需要扩展RestAPI实现,配置在其它时机触发,比如打Tag的时候,添加注释的时候等等。

$ q0 y! s( N, y) T0 `1 z& k3 ^" ~9 b" G$ M! h
% n' s; z2 \; Z" }! u6 v" c
第二种是定时构建,就是每天到指定的时间就开始执行构建任务。DevOps提供了定时器,可以按照给定的时间定时触发执行日构建,这也是最常用的一种方式。

; z( @+ w4 I) H& D7 }
6 F3 Q3 u2 {; i9 |, _" r" C7 l
第三种是手动构建,可以根据需要随时手动执行构建。总之,触发策略的目的就是让我们能够在需要的时间进行构建。
1 d5 y( P& `# T2 J1 K5 q5 H

7 ~( h& T; B1 T0 _3 }! z5 }; Q( j6 v
7 j, k( t* |0 @9 y$ y0 ^6 e
  • 通知策略

    * P* Q$ N% R4 E; H4 H: l: O' N4 I: R9 }6 w
    8 O! H8 X% D5 G5 v+ ?

    ( D3 Q: P3 L: X. f0 w8 S% ~
. R' r  ]$ P( j( Q- _
当需要将构建结果通知项目组成员时可以配置通知策略,在发布流水线中也可以配置通知策略。DevOps目前支持发送邮件通知,还可以根据需要扩展短信通知、微信通知等多种通知形式。只需要选择通知发送的项目组成员即可,设定完毕后DevOps平台将会发送构建成功或失败的邮件给选定的成员,以便相关人员及时了解构建结果。
0 k. a' h8 R1 K  F$ A0 j( l( F
( Y) Q6 ]' a" O; T  \

6 i. d- n( Q5 Q; E
四、构建执行与跟踪
& ~' U2 q$ J8 \% ~3 g

3 J' f3 u0 f! I+ h
首先介绍一下构建执行。构建执行与触发策略配置相关,可以在代码提交时触发执行,也可以定时触发每日构建,这两个是DevOps自动执行,还可以根据需要手动执行。

9 b  ~  F. \/ Z# t( E

1 h& z6 I: D7 J" p+ |5 r
无论是自动触发执行构建还是手动执行构建,DevOps的构建执行流程都是一样的。首先是DevOps根据构建定义生成Jenkins pipeline job配置文件,并调用Jenkins API传递配置参数启动Jenkins pipeline job,然后,Jenkins根据配置参数创建Jenkins pipeline job,执行pipeline job,通过Groovy脚本驱动相关的插件执行任务,最后,DevOps调用Jenkins Rest API查询执行进度和结果,这就是构建执行的大致流程。在执行过程中,开发人员还可以实时跟踪构建的执行进度,DevOps能够显示每一步的执行状态,是成功了还是失败了,以及每一步执行的时长。
5 L2 u* u4 D* R6 l3 a) l9 `; G& @& C8 M

* p' N* p! I& P% l

$ r9 g2 t2 \4 j! D' p  f5 X# ]1 m
构建执行结束后,我们可以在DevOps中跟踪构建执行的情况、查看构建日志、查看质量报告,下载构建介质,跟踪构建历史。
& M3 V3 I: ?8 b+ a" ~# ^
9 L4 N! J& D# q: b* ~$ G
首先,我们可以跟踪构建执行的总体情况,构建是成功了还是失败了,构建执行了多长时间,产生了几个构建产物。点击每一个任务的链接我们还可以查看这个任务的执行日志,了解任务执行的详情。

" X: p4 [, ^# J
( o5 U5 p# i+ y) n( n) @0 i% \- @
如果任务执行失败了,我们可以通过日志定位失败的原因。

# n. {) b$ ]# h. D- B
; F( [8 A4 d1 u' J) |# a
此外,在控制台信息里DevOps提供了整个构建过程的日志浏览,包括相关的上下文信息,我们也可以通过控制台信息来定位构建过程中的问题。

. j) f1 v; w* X4 h" V7 J* r
; K, K( E" A6 |3 e# r- c1 o
其次,我们可以查看代码质量情况。
: s: N+ d8 Q% ?* X# s9 F5 [, z

7 w6 z0 j* u5 |' c  [; Y/ ]
有单元测试的,可以看到单元测试通过了多少,失败了多少,耗时多少。并且可以查看测试明细,了解是哪一个单元测试失败了,耗时比较长。对于Java项目DevOps在Maven构建时集成了Junit进行单元测试,我们在构建定义时如果选择了执行Junit测试,在单元测试报告中就可以看到Junit的测试报告;对于前端项目可以根据需要在前端代码编译时选择单元测试插件,在DevOps中使用npm构建时配置单元测试报告存放路径,这样就可以在DevOps中查看前端项目的单元测试结果了。

- z" I/ z4 W3 ], _

& o. {3 J2 s# }+ f- I  Q( f1 x
如果在构建定义时添加了SonarQube代码质量检测任务,我们还可以看到SonarQube的代码质量分析结果。有多少缺陷,多少漏洞,多少坏味道。点击链接可以进入SonarQube查看更详细的质量报告。

3 z+ {. a, W- P: |
1 Q) g6 x9 [# b2 P; d. e% T% k
对于前端项目如果在项目中配置使用了代码质量扫描插件eslint,在DevOps中使用npm构建时配置eslint报告存放路径,就可以在DevOps中查看前端项目的Eslint报告,了解代码质量情况。  
% Q% d( Q7 ]; }
6 Y3 G5 h1 F6 R# D
另外,DevOps还提供了构建介质下载链接,可以查看构建后的介质列表并下载介质。

0 p/ y3 c; U9 h5 i2 @
, W" d* m7 k$ z) J$ }
如果我们想了解近期的构建情况,可以通过构建历史查看DevOps保留的构建记录。在构建历史中,我们能够看到近期执行构建的情况,每次执行了多长时间,是成功了还是失败了或者是被超时取消了,能看到的构建记录数与保留策略的设置相关。点击具体的构建我们就可以了解这次构建的详细情况。
; P0 c) T) o8 ], X0 p! P
; H. T/ @( W/ g1 x: o2 k
五、总结
2 b: s: P& v1 ~. O/ `( m$ p
8 c+ u* u) N( u. S5 b" n5 m4 E! r' `
总结一下,在DevOps中进行构建,平台帮您屏蔽了不同操作系统、不同构建工具、不同应用等等复杂的环境,您可以很方便地编排自己的构建流程,定义构建策略,并对构建结果进行跟踪。构建的目的是帮助我们随时获取可运行的产品,是向自动化运维迈进的第一步。

7 u; U0 t' E9 q! J0 v* l9 Y
. y8 {8 H" H' J+ ]- ?+ _2 \. i
原创:李卜,普元DevOps布道师,曾任普元多个产品的项目经理,并作为资深咨询顾问参与工行、德邦物流、上海规土等多个项目开发和过程管控。拥有超过15年的开发团队管理和软件架构设计经验,致力于高效研发过程的落地和不断改进推广。
! a1 ?. X) g: m% ~* ~2 j2 c
转载本文需注明出处:微信公众号EAWorld,违者必究。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?点击获取邀请码 - 立即注册

x

本版积分规则

选择云运维时代的王牌讲师-长河老师,助你轻松入门ITIL Foundation培训课程

QQ|小黑屋|手机版|Archiver|ITIL先锋论坛五万运维人社区 ( 粤ICP备17056641号|网站地图

Baidu

GMT+8, 2018-9-21 00:45 , Processed in 0.344733 second(s), 34 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表