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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1514|回复: 0

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

[复制链接]
发表于 2018-8-23 15:02:34 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-8-30 09:39 编辑 3 Z# h* h: R' D0 `" C. Y

' S* Z! t+ a7 i+ v1 y

0 [9 H5 T( F& f2 i: Q
8 A0 T# q5 Z, z' X4 T3 z" D
1.png
' x$ L: Z( t, ]# [
0 h3 X8 Z$ {  K8 T5 B7 Q4 X
企业做ITILxf.com" target="_blank" class="relatedlink">DevOps平台,本质上是做企业的IT生产线,最终是实现整个企业级的数字化生产线。构建作为落地DevOps平台必不可少的环节之一,是持续集成、交付和部署的基础。本文我们从DevOps的CICD总体思路出发,和大家分享一下DevOps是如何做构建管理的。
4 ]9 Z: d1 X% f! \6 Z# K; g
3 y3 P, q+ A0 l" e# W1 ]

! d; @! e# I/ M+ f
# k) K1 |  ^$ ^
目录:
' s4 G7 a: K6 W! e7 Y( j
2 P8 ^1 V( ?( h, b5 h$ ]
一、CI/CD总体思路

& f- F4 `# E8 C6 C- S

& T/ d1 J3 @! Y. d/ @' N! K
二、构建定义与任务编排
" k9 W* ?* {$ k! M5 t* G+ X1 v/ P
4 n3 S( L2 K6 U! j! `2 ~
三、构建策略

  `' H% t2 U, h$ K# S' q; ?7 t" ?

) h( K7 T0 c- L! _
四、构建执行与跟踪
& T4 R6 e, Y2 L! n, c1 t% D

: P9 x. C6 f/ D9 B( h) i, {# |
五、总结
0 w( q1 A) U* f; W, c
8 u9 q: C( [/ L1 G8 E

( W1 z: G0 s7 C; K( U9 r  ^. s4 k$ X% f
、CI/CD总体思路
1.jpg
: }- F7 u( ?* Q, w/ @
4 c; J+ ~( A7 G2 g% ?8 j: n7 p
在DevOps中,做到持续构建是基本的,其中复杂的地方主要是对多种环境的构建支撑。项目中有用maven编译的、有用ant编译的,如果有移动应用,有android系统的、ios系统的,还有一些前端应用的编译,比如:nodejs,这么多不同的环境我们怎么支持?另外,构建过程中还需要考虑和代码质量分析,单元测试、介质上传等能力的结合,这样的构建过程其实也是一个工作流程。
5 }+ E' e; F# c3 {6 o+ h5 z
1.png
' p9 @& [% _1 F9 y
举个最典型的例子,比如:构建时,先要进行maven编译,编译过程中包含单元测试,然后进行代码质量分析,之后将交付物上传到二方库,最后还要看到构建详情、日志、单元测试报告、代码质量分析报告等详细情况,可以查看并下载介质。只有完成了这样一个过程才能说基本做到了持续集成。

" _1 x$ _( F5 Q( M6 \% |* ~
1.png
4 t$ b) B, ^# o9 i4 Z8 J
我们的DevOps中持续集成与持续部署的总体设计思路就是在DevOps中进行设计,然后通过Jenkins执行的方式。DevOps负责进行构建定义或部署架构的设计,生成Jenkins的pipeline job的配置文件;然后Jenkins根据这个配置文件创建并执行pipeline job;DevOps再通过Jenkins的Rest API跟踪执行进度和结果。

4 g; a  j1 S0 {" y) n  L
( w& d3 `; e2 e2 R) v
之所以用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)。

3 O( A1 `& ]) o3 |# a3 Z
1.png

3 q1 G" s; h+ B. ^" T7 y. b
此外,顺便分享一下我们集成Jenkis时遇到的一些难点。
' _, V' w& i3 N0 I8 T

$ n( V4 R- ~5 F1 b8 X1 a
首先是执行效率问题,我们的DevOps通过API启动Jenkins时,Jenkins先排队调度再执行的机制造成启动较慢,比如会等待5,6秒,有时甚至是10几秒的情况,之后才会开始执行真正的脚本,用户体验较差。这方面我们自己通过异步和队列来解决用户体验问题。
其次是信息去重问题,Jenkins的Master-Slave的集群模式,使得我们在从多节点获取执行情况时需要进行去重处理,目前我们采用轮询加锁的方式解决。

5 C6 S6 s8 [, w. a( ~+ W6 W
, O6 K3 Y, v0 _; l# J" ~. N
此外是信息扩展问题,从Jenkins获取的结果都是日志形式的,Jenkins没有很好的扩展机制来支持定制,比如:过滤用户名密码、获取URL地址等等,需要DevOps自己进行过滤和处理。(如:有些需要的信息只能通过脚本先写到日志中再获取;用户名和密码明文存放,需要进行过滤和处理等等)。
0 `" \, S  l# P1 D, k" w
3 Z7 [" a. U" V; E, k  K& H6 H
另外,Jenkins的官方客户端REST API文档不太健全,需要通过调试的方式自己摸索。
# @- h+ d! @- j

, F  |: s  S4 F  `% Q& A* J: q( T
二、构建定义与任务编排
1.png

# ]2 r' O! m& d- l$ Q$ E
$ e5 H; ?" \3 A# C' @5 q/ R% U
首先我们了解一下DevOps的构建定义。这是DevOps中持续集成的操作流程。首先,可以在项目中创建构建定义,在每个构建定义上可以选择若干个需要的构建任务,通过原子步骤进行编排,组装成一个完整构建流程。通过触发策略和保留规则的定义,可以在代码提交时触发构建(支持gitlab、github、svn等常用代码库版本管理工具),或者在指定时间进行日构建。在最新版本的DevOps中,我们增加了组件的构建定义,一个构建定义可以对应一个或多个组件。
% H: r# y8 [" w4 g# C) f
1.png

! v- N- x! H% Y, Z
在构建定义时,DevOps中的每个构建任务对应jenkins的一个pipeline stage。在执行时,将所有构建任务结合构建定义的一些基础信息,创建jenkins的pipeline job进行执行。

* N9 _6 s4 ?3 B& k3 f
1.png
! K( c! [" b* A$ ^) Z1 p/ o8 f
  
目前DevOps平台将构建任务分成了三类:

% O4 u9 t4 Q: T; W; _' Q0 p8 D

% x$ w7 y7 C. c8 j3 I8 `
第一类是构建类任务,如:从Git/SVN拉代码、使用Maven、Ant、Npm、Gradle进行编译,以及调用已有的构建定义进行构建等与构建相关的;
' t& O% g4 X" b  ^( p1 a9 o" X

+ Y( U$ ^  g5 T+ Q% C, X  T
第二类是测试类任务,如:执行Sonarqube代码分析、Jmeter测试、Selenium测试等与测试和代码分析相关;

1 \" M* u9 i% ^* `1 W7 }

0 k" O& E3 I: }4 c& T( \
第三类是工具类任务,如:Shell脚本执行、介质提交到Nexus仓库、介质上传二方库等。  

8 R# {; y, D" W4 g% m  d0 R+ _
1.png

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

$ k( c% h1 ^* w
9 |( L0 ~- b5 Y3 d6 P: S* a
DevOps首先将构建任务原子化,抽取成各种类别的原子任务,然后通过编排的方式将这些原子任务进行串接,就形成了灵活的任务组合,通过这种灵活的编排就可以支持各种类型应用的持续集成。之前看到的三大类构建任务就是目前我们DevOps已经抽取的原子任务,我们还在不断扩展原子任务,以支持更多的构建使用场景。

! Q0 D! W0 m6 [  |! d2 f
( D9 y! d: G! L" _
下面是DevOps对几类常见应用的持续集成的支撑。
' C8 Y, d1 w; u0 A% M% u. C
1.png

# h# {- `4 h- Z
对于springboot类的应用,首先是拉取代码,可以从Git库拉取,也可以从svn拉取,接着是构建,可以使用maven构建,也可以使用ant,gradle构建,然后用SonarQube进行代码分析,最后执行一些脚本并提交介质。

# {( B5 _  U5 h
1.png
% n+ D! r9 N# {
对于移动类的应用,目前我们支持安卓应用的构建,首先是拉取代码,可以从Git库拉取,也可以从svn拉取,接着使用gradle构建,然后进行测试,最后是提交介质。对于ios应用的编译涉及到证书管理,我们正在扩展相关的构建任务。

! _6 `, i3 Z# b5 j8 P! w
1.png
  c  d4 ^- B6 T6 G4 F, R

9 i* v# W3 j/ Z% b  q+ W) v0 F
对于前端应用,步骤类似,可以选择npm进行编译。
3 [) `/ J  k( F1 `4 T  |+ x
1 i% I0 d  f! D# w
总之,通过不断扩展原子构建任务,并通过编排的方式定义构建流程,我们就能够支持更多的构建使用场景。

5 d0 A6 W# N% s4 v% _. ~9 E0 i
1 e) x- s1 P8 ]3 h/ R( K! k7 @
顺便提一句,按照我们DevOps的扩展机制扩展构建任务是不需要进行前端代码开发的,可以自动生成配置界面,是不是很酷?
$ q5 ^2 n& M* H. Z6 K

" B2 r/ i( D8 D2 [) \( o

& k& V$ ^6 E* g  L
三、构建策略
7 t" E4 \1 I: p, v
& [$ _, q' t, u' k
  • 超时策略
    ) |$ v2 r$ e7 R& t& q) I
1.png
% s* M9 v# h) C4 y2 r- D
我们在DevOps中进行构建定义时,可以配置超时时间。这个超时时间是指在Jenkins中执行这个构建流程的时候,最长允许执行多长时间,如果超过这个时间,这个构建流程就会被Jenkins强行终止。
' L, B4 e* C  ?
1.png
. ?0 ^3 {/ \1 d: _! T
为什么要定这个超时策略,定好的构建流程为什么要强制终止呢?
2 d- _. o% O& Q9 k7 O# U

6 ?, ]* M  c4 X7 ~! H; B  a- {& D7 y
这里面主要有两个原因:

& a$ A7 N7 S0 F4 v, o
+ c+ L% Y% I3 F2 ~
  • 一是在微服务架构下,构建任务非常频繁,我们认为每一次构建都应该高效完成,不能超过一定的时间,如果超过这个时间,排除外部因素,可能就是这个微服务的设计或者实现有问题,或者测试用例写的有问题,不停调用外部资源,导致执行得很慢。

    ) q; J9 y: f0 W7 z% A# |

. s4 z- {/ m/ V* {9 l& |$ h# ^9 \
  • 二是碰到一些外部因素,比如网络不太稳定的情况,导致某一个构建环节时间过长,比如从github拉代码或者将构建产物上传到Nexus仓库,网路传输很慢,这样会因为这个编译任务被挂起,而导致所有后续的编译任务都在排队,整个jenkins Job无法正常执行,同时还占用了系统资源。配置超时后,可以及时释放占用的资源,提升整体构建效率。目前我们DevOps中默认的是10分钟,如果超过这个时间构建就会自动终止,并自动提一个Bug。开发或管理人员可以跟踪日志定位构建超时的具体原因,优化内部实现或调整外部环境。

    & S$ w  d+ V& F8 |" f7 V
2 t: |7 ]& x: w( ^( d- k% }+ B
  • 保留策略
    " o4 [- I, F/ q  H' D
1.png

! b2 A2 F4 \% i: p, X. B+ B' ?
保留策略可以定义我们需要保留几次构建记录,成功的保留几次,失败的保留几次。设置了保留策略之后,DevOps会保留最近几次的构建记录,而将之前的构建记录,主要包括Jenkins上的日志和临时空间清理掉。设置这个保留策略,主要是为了节省存储空间,因为每次构建都会生成一些构建日志和临时空间里的文件,通过保留策略可以优化Jenkins的磁盘空间使用效率。我们可以在构建历史中看到保留下来的那些构建记录。

% r4 F" L9 C, v# t

( a% [/ S) U8 ~; u! x: c9 _0 w
  • 触发策略
    , k1 |7 K1 M$ y. A3 L9 r' v

    $ ~  p  k: \; `0 o" _7 N
    ! r9 o0 |/ N8 `$ p+ Q; K* w) Y
    5 ?/ K# q' c3 B( u
1.png
+ S  \/ U+ Y: f: r$ L2 }3 Q
触发策略是指这个构建流程在什么时间会被执行。DevOps支持代码提交时触发构建、定时构建、手动构建三种构建触发策略。
3 T  Q' ^0 |$ b% ~! n* {/ Q7 T
' r% ]& U  L( I0 ]
第一种代码提交时触发构建,支持通过gitlab或github管理的代码库。DevOps平台提供了触发构建的RestAPI,只需要在github或gitlab的webhook中配置payloadUrl,调用DevOps提供的RestAPI即可。可以根据需要扩展RestAPI实现,配置在其它时机触发,比如打Tag的时候,添加注释的时候等等。

# p6 m. ?+ |; f5 N' T% z6 O1 y6 m7 O- {: Y

; z- v. n9 ^) l& E
第二种是定时构建,就是每天到指定的时间就开始执行构建任务。DevOps提供了定时器,可以按照给定的时间定时触发执行日构建,这也是最常用的一种方式。

! ]& H9 |- N# r: E' R1 ^

9 `. D/ Z, a' n/ F* y
第三种是手动构建,可以根据需要随时手动执行构建。总之,触发策略的目的就是让我们能够在需要的时间进行构建。
( Q- H& M! N  x2 N) x' }
+ a  y* i3 ?8 Z9 t) y
' t! O$ z" P6 O3 r
  • 通知策略

    . v: F& U0 U! H- b3 [1 d
    2 }! ^9 |6 A. j4 W
    1 g. W( T" k: k- P+ r1 ^1 Y
    7 Y' L: N+ h' v8 j0 b# Z
1.png
3 e9 ]* S0 C3 u- P7 m2 V
当需要将构建结果通知项目组成员时可以配置通知策略,在发布流水线中也可以配置通知策略。DevOps目前支持发送邮件通知,还可以根据需要扩展短信通知、微信通知等多种通知形式。只需要选择通知发送的项目组成员即可,设定完毕后DevOps平台将会发送构建成功或失败的邮件给选定的成员,以便相关人员及时了解构建结果。

' j! F3 O# f7 V, t% Y! A$ u

0 C0 n" k% b6 z5 k8 }& u9 {

1 k! t5 U  c6 ^, n( z2 f
四、构建执行与跟踪
! Z5 o1 d2 r" j* c/ _, V4 Z# K
1.png

% T7 G" X1 }1 o! ], e
首先介绍一下构建执行。构建执行与触发策略配置相关,可以在代码提交时触发执行,也可以定时触发每日构建,这两个是DevOps自动执行,还可以根据需要手动执行。
' e" z' K3 k# r! ?* @! u
& a9 n& E+ c( |% l) k6 Y" @
无论是自动触发执行构建还是手动执行构建,DevOps的构建执行流程都是一样的。首先是DevOps根据构建定义生成Jenkins pipeline job配置文件,并调用Jenkins API传递配置参数启动Jenkins pipeline job,然后,Jenkins根据配置参数创建Jenkins pipeline job,执行pipeline job,通过Groovy脚本驱动相关的插件执行任务,最后,DevOps调用Jenkins Rest API查询执行进度和结果,这就是构建执行的大致流程。在执行过程中,开发人员还可以实时跟踪构建的执行进度,DevOps能够显示每一步的执行状态,是成功了还是失败了,以及每一步执行的时长。

# e* e( m4 ?5 C
1.png

* E- z4 D- A+ b& v7 g

# I% y& E$ f: W8 l( [8 T; B
构建执行结束后,我们可以在DevOps中跟踪构建执行的情况、查看构建日志、查看质量报告,下载构建介质,跟踪构建历史。
% U' I3 W1 h# n: i
1.png
5 y# D. z: A0 i1 {: m
首先,我们可以跟踪构建执行的总体情况,构建是成功了还是失败了,构建执行了多长时间,产生了几个构建产物。点击每一个任务的链接我们还可以查看这个任务的执行日志,了解任务执行的详情。
1 p( c- g1 y$ m
1.png

$ ^4 k/ \! y9 o" D0 L6 u: y9 I/ b( D
如果任务执行失败了,我们可以通过日志定位失败的原因。

2 \3 C) K8 |3 m* |' Z* t. l
1.png
' p+ w, s. v! U; b5 x4 {0 |
此外,在控制台信息里DevOps提供了整个构建过程的日志浏览,包括相关的上下文信息,我们也可以通过控制台信息来定位构建过程中的问题。

0 \  c4 q. _2 W) ?
1.png

& Y, a+ Y+ I. `0 Y  o
其次,我们可以查看代码质量情况。
& v1 ]/ _) W8 ]1 I3 s  _

$ W4 R0 K1 x9 n; j, P" h$ M
有单元测试的,可以看到单元测试通过了多少,失败了多少,耗时多少。并且可以查看测试明细,了解是哪一个单元测试失败了,耗时比较长。对于Java项目DevOps在Maven构建时集成了Junit进行单元测试,我们在构建定义时如果选择了执行Junit测试,在单元测试报告中就可以看到Junit的测试报告;对于前端项目可以根据需要在前端代码编译时选择单元测试插件,在DevOps中使用npm构建时配置单元测试报告存放路径,这样就可以在DevOps中查看前端项目的单元测试结果了。
) j* f7 _6 t! q0 {( t
6 p& p  J+ W* [& O- T
如果在构建定义时添加了SonarQube代码质量检测任务,我们还可以看到SonarQube的代码质量分析结果。有多少缺陷,多少漏洞,多少坏味道。点击链接可以进入SonarQube查看更详细的质量报告。
* o( _0 Y2 j: `/ n) g- x
# j2 U5 A4 Y* q8 a
对于前端项目如果在项目中配置使用了代码质量扫描插件eslint,在DevOps中使用npm构建时配置eslint报告存放路径,就可以在DevOps中查看前端项目的Eslint报告,了解代码质量情况。  
  ?% j) b+ H" F9 c
1.png
3 L( z" h* w$ G% w9 j" O9 [- c
另外,DevOps还提供了构建介质下载链接,可以查看构建后的介质列表并下载介质。

- Y: _4 }9 u1 s# n" Y. d
1.png
. y& E5 M: }5 t. @
如果我们想了解近期的构建情况,可以通过构建历史查看DevOps保留的构建记录。在构建历史中,我们能够看到近期执行构建的情况,每次执行了多长时间,是成功了还是失败了或者是被超时取消了,能看到的构建记录数与保留策略的设置相关。点击具体的构建我们就可以了解这次构建的详细情况。
6 K& ^1 q! T$ b" R+ o! E( l, s. k
! Z$ c3 L9 s5 o* n
五、总结

- x0 ?( k8 u' ^! B8 d9 F! i
" G1 y$ I$ Y6 J" Y
总结一下,在DevOps中进行构建,平台帮您屏蔽了不同操作系统、不同构建工具、不同应用等等复杂的环境,您可以很方便地编排自己的构建流程,定义构建策略,并对构建结果进行跟踪。构建的目的是帮助我们随时获取可运行的产品,是向自动化运维迈进的第一步。

1 q' L) |, S. f5 W

5 o$ {8 c1 G" z5 e; A2 k
原创:李卜,普元DevOps布道师,曾任普元多个产品的项目经理,并作为资深咨询顾问参与工行、德邦物流、上海规土等多个项目开发和过程管控。拥有超过15年的开发团队管理和软件架构设计经验,致力于高效研发过程的落地和不断改进推广。
3 T( d& s, n# m( }# @
转载本文需注明出处:微信公众号EAWorld,违者必究。
1.png
1.png




上一篇:你会写DevOps的文档吗?
下一篇:大公司使用DevOps的必然性
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-5-23 04:12 , Processed in 0.120050 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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