本学习笔记参考《Jenkins 2.x实践指南》。

1. Jenkins 简介#

Jenkins 是一款自动化的任务执行工具。通常用于持续集成/持续交付领域。

可以通过界面或Jenkinsfile告诉Jenkins执行什么任务，何时执行。理论上，我们可以让它执行任何任务，但是通常只应用于持续集成和持续交付。

持续集成将软件生产过程从手工模式带入流水线模式，软件生产的某个环节都对应流水线上的每个环节。

流水线模式还能帮助我们将知识固化到自动化流水线中，在一定程度上解决了知识被人带走的问题。（手工模式对于整个软件生产流程很少有人全部知道，使用流水线模式整个软件生产的过程都以pipeline as code的形式保留下来，每个人都能看）

2. pipeline介绍#

什么是pipeline#

• 学术的讲：软件从代码版本库到用户手中这一过程的自动化表现；
• 通俗的讲：主要是指代码的自动构建、测试、打包和部署等过程；

Jenkins 1.x只能通过界面手动操作来“描述”部署流水线。Jenkins 2.x终于支持pipeline as code了，可以通过“代码”来描述部署流水线。

• 更好地版本化：将pipeline提交到软件版本库中进行版本控制。
• 更好地协作：pipeline的每次修改对所有人都是可见的。除此之外，还可以对pipeline进行代码审查。
• 更好的重用性：手动操作没法重用，但是代码可以重用。

什么是JenkinsFile#

Jenkinsfile就是一个文本文件，也就是部署流水线概念在Jenkins中的表现形式。像Dockerfile之于Docker。所有部署流水线的逻辑都写在Jenkinsfile中。

JK File 定义了流水线的部署逻辑

Jenkins默认不支持pipeline，需要安装pipeline插件。

pipeline语法的支持#

pipeline支持以下两种语法：

• Groovy语法（node为根节点的是脚本式语法）；
• 声明式语法（2.5版本开始支持，pipeline为根节点的是声明式语法，推荐使用）

3. pipeline 语法#

Groovy语法#

这里Groovy语法不是重点，但是还是需要了解必要的知识。如果想要详细了解，可以参考Groovy教程

// 一般用def定义变量
// 语句末尾不添加分号
def x = "abs"

// Groovy中的方法调用可以省略括号
println x
println "chensongxia"

// 支持命名参数
def m1(String givenName, String familyName) {
    return givenName + " " + familyName
}
// 调用时可以这样
println m1("chen", "songxia")
s1 = m1 familyName = "ru", givenName = "zhao"
println s1

// 支持默认参数
def m2(String name = "hi") {
    return name
}
// 括号不能省略
println m2()
println m2("chen")

// 支持单引号、双引号。双引号支持插值，单引号不支持
println '------支持单引号、双引号。双引号支持插值，单引号不支持 ---------'
println ''
def name = "world";
println "hello ${name}"
println 'hello ${name}'


// 支持三引号。三引号分为三单引号和三双引号。它们都支持换行，区别在于只有三双引号支持插值。
println ''
println '-----支持三引号。三引号分为三单引号和三双引号。它们都支持换行，区别在于只有三双引号支持插值。-----'
println """line one
line two
line three
${name}
"""

println '''line one
line two
line three
${name}
'''

// 支持闭包
println '-------支持闭包---------'
def codeBlock = { println "hello closure" }
// 闭包可以被当成函数直接调用
codeBlock();
// 闭包可以被当成一个参数传递给另外一个方法
def pipeline(closure){
    closure()
}
pipeline(codeBlock)

def stage(String name,closure){
    println name
    closure()
}
stage("jenkins",codeBlock)

pipeline组成#

Jenkins pipeline其实就是基于Groovy语言实现的一种DSL（领域特定语言），用于描述整条流水线是如何进行的。流水线的内容包括执行编译、打包、测试、输出测试报告等步骤。

从软件版本控制库到用户手中这一过程可以分成很多阶段，每个阶段只专注处理一件事情，而这件事情又是通过多个步骤来完成的，这就是软件工程的pipeline。Jenkins对这个过程进行抽象，设计出一个基本的pipeline结构。

pipeline {
    agent any

    stages {
        stage('Hello') {
            steps {
                echo 'Hello World'
            }
        }
    }
}

• pipeline：代表整条流水线，包含整条流水线的逻辑。
• stage部分：阶段，代表流水线的阶段。每个阶段都必须有名称。本例中，build就是此阶段的名称。
• stages部分：流水线中多个stage的容器。stages部分至少包含一个stage。
• steps部分：代表阶段中的一个或多个具体步骤（step）的容器。steps部分至少包含一个步骤，本例中，echo就是一个步骤。在一个stage中有且只有一个steps。
• agent部分：指定流水线的执行位置（Jenkins agent）。流水线中的每个阶段都必须在某个地方（物理机、虚拟机或Docker容器）执行，agent部分即指定具体在哪里执行。

以上每一个部分（section）都是必需的，少一个，Jenkins都会报错。

Jenkins的很多插件可以被直接拿来当作一个步骤使用。只要安装了这些适配了Jenkins pipeline的插件，就可以使用其提供的pipeline步骤。

Jenkins官方还提供了pipeline步骤参考文档（https：//jenkins.io/doc/pipeline/steps/）。

post部分#

根据pipeline或阶段的完成状态，post部分分成多种条件块，包括：

? always：不论当前完成状态是什么，都执行。
? changed：只要当前完成状态与上一次完成状态不同就执行。
? fixed：上一次完成状态为失败或不稳定（unstable），当前完成状态为成功时执行。
? regression：上一次完成状态为成功，当前完成状态为失败、不稳定或中止（aborted）时执行。
? aborted：当前执行结果是中止状态时（一般为人为中止）执行。
? failure：当前完成状态为失败时执行。
? success：当前完成状态为成功时执行。
? unstable：当前完成状态为不稳定时执行。
? cleanup：清理条件块。不论当前完成状态是什么，在其他所有条件块执行完成后都执行。post部分可以同时包含多种条件块。

下面给出一个例子：

pipeline支持的指令#

基本结构满足不了现实多变的需求。所以，Jenkins pipeline通过各种指令（directive）来丰富自己。指令可以被理解为对Jenkins pipeline基本结构的补充。

Jenkins pipeline支持的指令有：

? environment：用于设置环境变量，可定义在stage或pipeline部分。
? tools：可定义在pipeline或stage部分。它会自动下载并安装我们指定的工具，并将其加入PATH变量中。
? input：定义在stage部分，会暂停pipeline，提示你输入内容。
? options：用于配置Jenkins pipeline本身的选项，比如options {retry（3）}指当pipeline失败时再重试2次。options指令可定义在stage或pipeline部分。
? parallel：并行执行多个step。在pipeline插件1.2版本后，parallel开始支持对多个阶段进行并行执行。
? parameters：与input不同，parameters是执行pipeline前传入的一些参数。
? triggers：用于定义执行pipeline的触发器。
? when：当满足when定义的条件时，阶段才执行。

在使用指令时，需要注意的是每个指令都有自己的“作用域”。如果指令使用的位置不正确，Jenkins将会报错。

配置pipeline本身（option指令）（用到的时候可以来参考这块）#

options指令用于配置整个Jenkins pipeline本身的选项。根据具体的选项不同，可以将其放在pipeline块或stage块中。以下例子若没有特别说明，options被放在pipeline块中。

? buildDiscarder：保存最近历史构建记录的数量。当pipeline执行完成后，会在硬盘上保存制品和构建执行日志，如果长时间不清理会占用大量空间，设置此选项后会自动清理。

参考这个文档：https://weread.qq.com/web/reader/12f320007184556612f32b6k1ff325f02181ff1de7742fc

这节比较有用，可以参考下

在声明式pipeline中使用脚本#

Jenkins pipeline专门提供了一个script步骤，你能在script步骤中像写代码一样写pipeline逻辑。

pipeline {
    agent any

    stages {
        stage('Hello') {
            steps {
                script{
                    def s = "Hello World"
                    println s
                }
                echo 'Hello World'
            }
        }
    }
}

可以看出，在script块中的其实就是Groovy代码。大多数时候，我们是不需要使用script步骤的。如果在script步骤中写了大量的逻辑，则说明你应该把这些逻辑拆分到不同的阶段，或者放到共享库中。共享库是一种扩展Jenkins pipeline的技术

pipeline内置基础步骤（重要）#

Jenkins 的pipeline内置了很多基础步骤，我们可以直接使用。

参考章节：https://weread.qq.com/web/reader/12f320007184556612f32b6k4e73277021a4e732ced3b55

4. 环境变量与构建工具#

环境变量#

环境变量可以被看作是pipeline与Jenkins交互的媒介。比如，可以在pipeline中通过BUILD_NUMBER变量知道构建任务的当前构建次数。环境变量可以分为Jenkins内置变量和自定义变量。

1. 内置环境变量

使用方式：

小技巧：在调试pipeline时，可以在pipeline的开始阶段加一句：sh 'printenv'，将env变量的属性值打印出来。这样可以帮助我们避免不少问题。

不推荐方法三，因为出现变量冲突时，非常难查问题。

Jenkins的控制台也对内置的环境变量做了说明，可以自己打开看下。

2. 自定义环境变量

environment指令可以在pipeline中定义，代表变量作用域为整个pipeline；也可以在stage中定义，代表变量只在该阶段有效。

pipeline {
    agent any
    environment {
        DEVOPS_IP = '10.50.1.50'
    }
    stages {
        stage('Hello') {
            environment {
                NAME = 'Hello World...'
            }
            steps {
                echo "${DEVOPS_IP}"
                echo "${NAME}"
                sh 'printenv'
            }
        }
    }
}

但是这些变量都不是跨pipeline的，比如pipeline a访问不到pipeline b的变量。在pipeline之间共享变量可以通过参数化pipeline来实现。

在实际工作中，还会遇到一个环境变量引用另一个环境变量的情况。在environment中可以这样定义：

在定义变量的时候，为了防止变量冲突，建议将变量加上前缀（自定义的环境变量会覆盖默认的环境变量）。

3. 自定义全局环境变量

env中的变量都是Jenkins内置的，或者是与具体pipeline相关的。有时候，我们需要定义一些全局的跨pipeline的自定义变量。

进入Manage Jenkins→Configure System→Global properties页，勾选“Environment variables”复选框，单击“Add”按钮，在输入框中输入变量名和变量值即可。

自定义全局环境变量会被加入 env 属性列表中，所以，使用自定义全局环境变量与使用Jenkins内置变量的方法无异：${env.g name}。

构建工具#

构建每一步都是可重复的，尽量与机器无关。所以，构建工具的安装、设置也应该是自动化的、可重复的。

虽然Jenkins只负责执行构建工具提供的命令，本身没有实现任何构建功能，但是它提供了构建工具的自动安装功能。

1. tool指令

tools指令能帮助我们自动下载并安装所指定的构建工具，并将其加入PATH变量中。这样，我们就可以在sh步骤里直接使用了。但在agent none的情况下不会生效。通过命令sh "printenv"，可以看到环境变量的所有值。

tools指令默认支持3种工具：JDK、Maven、Gradle。通过安装插件，tools指令还可以支持更多的工具。

配置maven

进入Manage Jenkins→Global Tool Configuration→Maven页，设置如下图所示。

pipeline {
    agent any
    environment {
        DEVOPS_IP = '10.50.1.50'
    }
    
    tools {
        maven 'maven.3.6.3'
    }
    
    stages {
        stage('Hello') {
            environment {
                NAME = 'Hello World...'
            }
            steps {
                echo "${DEVOPS_IP}"
                echo "${NAME}"
                sh 'printenv'
                sh 'java -version'
                sh 'mvn -v'
            }
        }
    }
}

这样，当执行到tools指令时，Jenkins会自动下载并安装Maven。将mvn命令加入环境变量中，可以使我们在pipeline中直接执行mvn命令。

Config File Provider插件可以设置全局的setting设置。

利用环境变量支持更多的构建工具#

如果想让Jenkins支持更多的构建工具，也是同样的做法：在Jenkins agent上安装构建工具，并记录下它的可执行命令的目录，然后在需要使用此命令的Jenkinspipeline的PATH环境变量中加入该可执行命令的目录。

利用tools作用域实现多版本编译#

在实际工作中，有时需要对同一份源码使用多个版本的编译器进行编译。tools指令除了支持pipeline作用域，还支持stage作用域。

在打印出来的日志中，会发现每个stage下的JAVA_HOME变量的值都不一样。

5. 代码质量#

静态代码分析#

使用maven插件在某个stage加入静态代码分析。（静态代码扫描通常被安排在编译之后）

单元测试#

性能测试#

Jenkins集成SonarQube（有时间将这个环境搭建起来，将分析报告推送到GitLab）#

Allure测试报告（美化测试报告，不是重点）#

6. 触发 pipeline 执行#

自动化是指pipeline按照一定的规则自动执行。而这些规则被称为pipeline触发条件。

对于pipeline触发条件，可以从两个维度来区分：时间触发和事件触发。接下来，我们从这两个维度分别介绍。

时间触发#

时间触发是指定义一个时间，时间到了就触发pipeline执行。在Jenkins pipeline中使用trigger指令来定义时间触发。

tigger指令只能被定义在pipeline块下，Jenkins内置支持cron、pollSCM，upstream三种方式。其他方式可以通过插件来实现。

使用场景：一些比较重的任务可以放到凌晨再跑。

事件触发#

事件触发就是发生了某个事件就触发pipeline执行。这个事件可以是你能想到的任何事件。比如手动在界面上触发、其他job主动触发、HTTP API Webhook触发等。

常用的有下面几种：

• 由上游任务触发：upstream（其他job来触发）
• GitLab通知触发
• 在pipeline中实现GitLab trigger

将构建状态信息推送到GitLab#

Generic Webhook Trigger#

安装 Generic Webhook Trigger 插件（下文使用 GWT 简称）后，Jenkins 会暴露一个 API：＜JENKINS URL>/generic-webhook-trigger/invoke，即由GWT插件来处理此API的请求。

如何处理呢？GWT插件接收到JSON或XML的HTTP POST请求后，根据我们配置的规则决定触发哪个Jenkins项目。基本原理就这么简单。

7. 多分支构建#

在实际项目中，往往需要多分支同时进行开发。如果为每个分支都分别创建一个Jenkins项目，实在有些多余。

不同分支发布不同环境#

when指令的用法#

when指令允许pipeline根据给定的条件，决定是否执行阶段内的步骤。when指令必须至少包含一个条件。when指令除了支持branch判断条件，还支持多种判断条件。

这块内容非常有用，可以经常参考。

https://weread.qq.com/web/reader/12f320007184556612f32b6k9a132c802349a1158154a83

GitLab trigger对多分支pipeline的支持#

Generic Webhook Trigger插件在多分支pipeline场景下的应用#

在多分支pipeline场景下，我们希望触发某个分支的构建执行。

8. 参数化pipeline#

什么是参数化pipeline#

参数化pipeline是指可以通过传参来决定pipeline的行为。

使用parameters指令#

parameters {
      string defaultValue: 'none', description: '字符串', name: 'D_ENV', trim: true
      text defaultValue: 'a\nb\nc\n', description: '文本', name: 'D_TEXT'
      choice choices: 'a\nb\nc\n', description: '选一个', name: 'D_CHOICE'
      booleanParam defaultValue: false, description: '布尔值参数', name: 'FLAG'
      password name: 'PASSWORD',defaultValue:'SECRET',description: 'password'
   }

参考这个文章：https://zhuanlan.zhihu.com/p/80622378。

由另外一个pipeline传参数#

可以在一个pipeline中“调用”另一个pipeline。在Jenkins pipeline中可以使用build步骤实现此功能。build步骤是pipeline插件的一个组件，所以不需要另外安装插件，可以直接使用。

build步骤其实也是一种触发pipeline执行的方式，它与triggers指令中的upstream方式有两个区别：

（1） build步骤是由上游pipeline使用的，而upstream方式是由下游pipeline使用的。

（2） build步骤是可以带参数的，而upstream方式只是被动触发，并且没有带参数。

使用Conditional BuildStep插件处理复杂的判断逻辑#

Conditional BuildStep插件（https：//plugins.jenkins.io/conditional-buildstep）可以让我们像使用when指令一样进行条件判断。以下代码就是安装Conditional BuildStep插件后的写法。

使用input步骤#

执行input步骤会暂停pipeline，直到用户输入参数。这是一种特殊的参数化pipeline的方法。我们可以利用input步骤实现以下两种场景：

（1）实现简易的审批流程。例如，pipeline暂停在部署前的阶段，由负责人点击确认后，才能部署。

（2）实现手动测试阶段。在pipeline中增加一个手动测试阶段，该阶段中只有一个input步骤，当手动测试通过后，测试人员才可以通过这个input步骤。

input步骤可以与timeout步骤实现超时自动中止pipeline，防止无限等待。以下pipeline一小时后不处理就自动中止。

9. 凭证管理#

为什么要凭证管理#

在Jenkinsfile或部署脚本中使用明文密码会造成安全隐患。但是为什么还频繁出现明文密码被上传到GitHub上的情况呢

（1）程序员或运维人员不知道如何保护密码。

（2）管理者没有足够重视，否则会给更多的时间让程序员或运维人员想办法隐藏明文密码。

凭证是什么#

比如使用SSH登录远程机器时，用户名和密码或SSH key就是凭证。而这些凭证不可能以明文写在Jenkinsfile中。Jenkins凭证管理指的就是对这些凭证进行管理。

为了最大限度地提高安全性，在Jenkins master节点上对凭证进行加密存储（通过Jenkins实例ID加密），只有通过它们的凭证ID才能在pipeline中使用，并且限制了将证书从一个Jenkins实例复制到另一个Jenkins实例的能力。

也因为所有的凭证都被存储在Jenkins master上，所以在Jenkins master上最好不要执行任务，以免被pipeline非法读取出来。

创建凭证#

? Kind：选择凭证类型。

? Scope：凭证的作用域。有两种作用域：

? Global，全局作用域。如果凭证用于pipeline，则使用此种作用域。

? ? System，如果凭证用于Jenkins本身的系统管理，例如电子邮件身份验证、代理连接等，则使用此种作用域。

? ID：在pipeline使用凭证的唯一标识。

添加凭证后，安装Credentials Binding Plugin插件（https：//plugins.jenkins.io/credentials-binding），通过其提供的withCredentials步骤就可以在pipeline中使用凭证了。

常用凭证类型#

• Secret text
• Username with password
• Secret file
• SSH Username with private key

优雅的使用凭证#

声明式pipeline提供了credentials helper方法（只能在environment指令中使用）来简化凭证的使用。以下是使用方法。

https://weread.qq.com/web/reader/12f320007184556612f32b6k14b3246024514bfa6bb1534

使用HashiCorp Vault（加强版的凭证管理工具）#

在Jenkins日志中隐藏敏感信息#

10. 制品管理#

常见的制品管理仓库#

• Nexus
• Artifactory

版本号管理#

11.可视化构建及视图#

Green Balls插件#

这个插件的功能是让构建成功的pipeline编程绿色。

Build Monitor View插件#

Build Monitor View插件（https：//plugins.jenkins.io/build-monitor-plugin）可以将Jenkins项目以一块“看板”的形式呈现。

视图#

使用视图可以对pipeline进行分组管理。

12.自动化部署#

部署和发布的区别#

部署是指将应用程序放到对应的服务器上。

发布是指用户能访问到新的功能点。

Jenkins集成Ansible实现自动化部署#

Ansible采用了与Puppet、Chef不一样的解决方案，不需要在受控机器上安装额外的客户端软件。原因是Ansible使用的是SSH协议与受控机器进行通信的，一般服务器默认有SSH服务。Ansible也因此被称为agentless（去客户端的）。

Puppet和Chef都自己做了一套DSL，而Ansible使用YAML格式作为自己的DSL格式。

13. 通知#

邮件通知#

钉钉通知#

Http请求通知#

14. 分布式构建与并行构建#

Jenkins的架构#

Jenkins采用的是“master+agent”架构（有时也称为“master+slave”架构）。Jenkins master负责提供界面、处理HTTP请求及管理构建环境；构建的执行则由Jenkins agent负责（早期，agent也被称为slave。目前还有一些插件沿用slave的概念）。

基于这样的架构，只需要增加agent就可以轻松支持更多的项目同时执行。这种方式称为Jenkins agent的横向扩容。

对于Jenkins master，存在单节点问题是显而易见的，但是目前还没有很好的解决方案。

在学习Jenkins的过程中，发现各种文档中掺杂着node、executor、agent、slave4个术语，新手很容易被它们弄得一头雾水。它们分别是什么意思呢？

? node：节点，指包含Jenkins环境及有能力执行项目的机器。master和agent都被认为是节点。

? agent：代理，在概念上指的是相对于Jenkins master的一种角色，实际上是指运行在机器或容器中的一个程序，它会连接上Jenkins master，并执行Jenkinsmaster分配给它的任务。

? slave：“傀儡”，与agent表达的是一个东西，只是叫法不同。

? executor：执行器，是真正执行项目的单元。一个执行器可以被理解为一个单独的进程（事实上是线程）。在一个节点上可以运行多个执行器。

增加agent#

https://weread.qq.com/web/reader/12f320007184556612f32b6k697324802676974ce5aceab

如何使用agent#

agent部分描述的是整个pipeline或在特定阶段执行任务时所在的agent。换句话说，Jenkins master根据此agent部分决定将任务分配到哪个agent上执行。agent部分必须在pipeline块内的顶层定义，而stage块内的定义是可选的。

agent any告诉Jenkins master任何可用的agent都可以执行。

agent部分的定义可以放在阶段中，用于指定该stage执行时的agent。

通过标签指定agent

customWorkspace，自定义工作目录。

不分配具体的agent

如果希望每个stage都运行在指定的agent中，那么pipeline就不需要指定agent了。

在默认情况下，阶段内所有的代码都将在指定的Jenkins agent上执行。when指令提供了一个beforeAgent选项，当它的值为true时，只有符合when条件时才会进入该Jenkins agent。这样就可以避免没有必要的工作空间的分配，也就不需要等待可用的Jenkins agent了。

将任务构建交给Docker#

Docker拉取镜像时，默认是从Docker官方中心仓库拉取的。那么如何实现从私有仓库拉取呢？比如在“制品管理”章节中在Nexus上创建的私有仓库。

Docker插件为我们提供了界面操作，具体步骤如下：

进入Manage Jenkins→Configure System页面，找到“Pipeline ModelDefinition”部分

Docker Label：当 pipeline 中的 agent 部分没有指定 label 选项时，就会使用此配置。如docker {image'maven：3-alpine'}。

? Docker registry URL：Docker私有仓库地址。

? Registry credentials：登录Docker私有仓库的凭证。

并行构建#

可以用于优化构建速度。

一些名词#

• pipeline as code
• 
  

参考#

• jenkins官网：https://www.jenkins.io/
• 《Jenkins 2.x实践指南》：https://weread.qq.com/web/reader/12f320007184556612f32b6kc81322c012c81e728d9d180
• 《Jenkins权威指南》：https://weread.qq.com/web/reader/418326a07184553c4184bcekc81322c012c81e728d9d180
• 最佳实践：https://www.cnblogs.com/lasdaybg/p/10175152.html
• 最佳实践：https://blog.didispace.com/jenkins-pipeline-top-10-action/