jenkins的pipeline介绍

Posted 2021-04-07 BBOSSArchitect

当前浏览器不支持播放音乐或语音，请在微信或其他浏览器中播放

在DevOps的工具链中，有人曾说过唯一不可替换的就是持续集成的工具Jenkins。目前使用较多的可以与之抗衡的是hudson，但是jenkins和hudson，仅仅是被oracle收购之后产生的副作用，jenkins由hudson被迫更名，仅此而已。当然还有一些商业软件也用于持续集成，但是均难以撼动jenkins目前如日中天的地位。

Jenkins2.0的核心特性：

Pipeline as Code是2.0的精髓所在，是帮助Jenkins实现CI(Continuous Integration)到CD(ContinuousDelivery)华丽转身的关键推手。所谓Pipeline，简单来说，就是一套运行于Jenkins上的工作流框架，将原本独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂发布流程（例如下图）。Pipeline的实现方式是一套Groovy DSL(类似Gradle)，任何发布流程都可以表述为一段Groovy脚本，并且Jenkins支持从代码库直接读取脚本，从而实现了Pipeline as Code的理念。

 

Pipelined的产生背景：

第一层面，与不断增长的发布复杂度有关，其中一个典型场景就是灰度发布。原本只有大公司才有的灰度发布，随着敏捷开发实践的广泛采用、产品迭代周期的不断缩短、数据增长理念的深入人心，越来越多的中小公司也开始这一方面的探索，这对发布的需求也从点状的CI升级到线状的CD。

第二层面，与应用架构的模块化演变有关，以为代表，一次应用升级往往涉及到多个模块的协同发布，单个CI显然无法满足此类需求。

第三层面，与日益失控的CI数量有关。一方面，类似于Maven、pip、RubyGems这样的包管理工具使得有CI需求的应用呈爆发性增长，另一方面，受益于便捷的Git分支特性，即便对于同一个应用，往往也需要配置多个CI。随着CI数量的不断增长，集中式的任务配置就会成为一个瓶颈，这就需要把任务配置的职责下放到应用团队。

基本概念：

Stage: 一个Pipeline可以划分为若干个Stage，每个Stage代表一组操作。注意，Stage是一个逻辑分组的概念，可以跨多个Node。

 Node: 一个Node就是一个Jenkins节点，或者是Master，或者是Agent，是执行Step的具体运行期环境。

 Step: Step是最基本的操作单元，小到创建一个目录，大到构建一个Docker镜像，由各类Jenkins Plugin提供。

 

具体构成：

Jenkinsfile: Pipeline的定义文件，由Stage，Node，Step组成，一般存放于代码库根目录下。

Stage View: Pipeline的视觉展现，类似于下图。

pipeline的功能和优点：

1）durable持久性：在jenkins的master按计划和非计划的重启后，pipeline的job仍然能够工作，不受影响，也就是说Pipeline的进程独立于Jenkins进程本身。

2）可暂停性：pipeline基于groovy可以实现job的暂停和等待用户的输入或确认后继续执行。

3）更灵活的并行执行，更强的依赖控制，通过groovy脚本可以实现step，stage间的并行执行，和更复杂的相互依赖关系。

4）可扩展性：通过groovy的编程更容易的扩展插件。

新旧pipeline插件比较：

1）旧的pipeline只是简单的视图概念，把多个job任务通过视图关联到一起，利用上一个任务触发下一个任务，无实际操作。

2）新的pipeline插件是完全不同于旧的插件。

i、新的pipeline 可以不受jenkins master重启的影响，可以暂停重启。

ii、新的pipeline 可以实现更复杂的持续发布流程。

iii、新的pipeline通过groovy脚本构建复杂的工作流。

Jenkins Pipeline的简单使用：

有了Pipeline，jenkins也走向了正规的工程化交付方式即使用配置文件.这本身也印证了行业的经验everything is code。

jenkins的pipeline主要是通过一个配置文件或者job里面的pipeline配置来设定每个job的步骤。

pipeline定义了几乎所有要用到的流程, 比如执行shell, 存档, 生成测试报告, 发布报告等.

创建pipeline项目。

项目名称填写 jenkins ，项目类型选择 “Pipeline”，然后点击“OK”按钮，如下图：

然后在“构建触发器” 勾选 “Poll SCM”，日程表填入 “* * * * *” , 每分钟构建一次

配置Pipeline ，填入下面的代码：  

node {

   // Mark the code checkout 'stage'....

   stage 'Checkout'

 

   // Get some code from a GitHub repository

    git([url: 'https://xx.xx.xx.xx/xxxx.git',branch: 'master'])

   // Mark the code build 'stage'....

   stage 'Build'

   // Run the gcc build

   sh "gcc jenkins.c -o jenkins"

  

    // Mark the code run 'stage'....

   stage 'Run'

   // Run the program

   sh "./jenkins"

}

然后保存项目。

 

检查任务是否正常运行

通过“Stage View”，我们可以清楚看到项目分为三步执行，每部的执行结果都是成功的。

 在“Run”这一步的log中，可以看到sh "./jenkins"的执行结果。

下面的例子是项目中实际使用的pipeline代码，具体含义将在下次的文章中详细说明，敬请关注，谢谢。

1）Checkout and  Package

node(‘linux’){

  giturl:'http://xx.xx.xx.xx:7302/EC_WEB/ECWEB.git'

  defmvnHome=tool'M3'

  env.PATH="${mvnHome}/bin:${env.PATH}"

  sh'mvn -B clean verify'

}

2）Sonar静态代码审查：

node{

    stage"auth"

    sshagent(['xxxx-xxxx-xxx-xxxx-xxxx']){

       stage'Checkout'

       giturl:'[e-mail]:EC_WEB/ECWEB.git'

    }

   stage'Build'

   sh"mvn clean install -Dmaven.test.skip=true"

   stage"Sonar"

   sh"mvn sonar:sonar" 

}

 

3）分析测试结果

node{

   giturl:'https://xxxx.git'

   defmvnHome=tool'M3'

   sh"${mvnHome}/bin/mvn -B -Dmaven.test.failure.ignore verify"

   step([$class:'ArtifactArchiver',artifacts:'**/target/*.jar',fingerprint:true])

   step([$class:'JUnitResultArchiver',testResults:'**/target/surefire-reports/TEST-*.xml'])

}

 

4）与docker结合

于Docker容器运行时和外部环境的依赖比较小，将应用的发布过程简化为容器镜像的拉取和运行，避免了去运行容易出错的过程化脚本。

stage"Build Source"

node (‘docker’){

docker.images(maven:3.3.3-jdk-8){

  giturl:'[e-mail]:EC_WEB/ECWEB.git'

  sh ‘mvn clean package’

}

}

node (‘docker’){

docker.withServer(‘serverUri’.’ serverCredentialsId’){

     stage‘Build Docker Images’

     def image = docker.build “xx.xx.xx.xx:1179/ec_web:latest”

     stage‘Publish  Docker Images’

      docker.withRegistry(‘registryUrl’.’registryCredentialsId’){

        image.push()

     }

     stage‘Deploy  Docker Image’

def container = image.run(‘—name ec_service –p 8080:8080’)

   }

}

我们运维组的大才子赵纪飞（美女马珊珊画）