1. 部署中的痛点
为什么要用Jenkins?我说下我以前开发的痛点,在一些中小型企业,每次开发一个项目完成后,需要打包部署,可能没有专门的运维人员,只能开发人员去把项目打成一个exe包,可能这个项目已经上线了,需要把服务关,在部署到服务器上,将项目启动起来,这个时候可能某个用户正在操作某些功能上的东西,如果你隔三差五的部署一下,这样的话对用户的体验也不好,自己也是烦的很,总是打包拖到服务器上。希望小型企业工作人员学习一下,配置可能复杂,但是你配置好了之后,你只需要把代码提交到Git或者Svn上,自动构建部署,非常方便。
2. 什么是jenkins
Jenkins是一个开源的、提供友好操作界面的持续集成(CI)工具,起源于Hudson(Hudson是商用的),主要用于持续、自动的构建/测试软件项目、监控外部任务的运行(这个比较抽象,暂且写上,不做解释)。Jenkins用Java语言编写,可在Tomcat等流行的servlet容器中运行,也可独立运行。通常与版本管理工具(SCM)、构建工具结合使用。常用的版本控制工具有SVN、GIT,构建工具有Maven、Ant、Gradle。
3. jenkins的安装和配置
这个jenkins我们不会直接安装在 192.168.0.104 我们会在一个新的虚拟机上运行 192.168.0.102,我们会在下一节课中专门讲解
安装java
yum install java-1.8.0-openjdk* -y
mac用户请参考: https://www.jianshu.com/p/8e82d74295
下载jenkins
ubuntu安装Debian Jenkins Packages
jenkins-2.284-1.1.noarch.rpm
https://mxshop-files.oss-cn-hangzhou.aliyuncs.com/jenkins-2.284-1.1.noarch.rpm
上传安装包并安装
rpm -ivh jenkins-2.284-1.1.noarch.rpm
修改jenkins配置
vim /etc/sysconfig/jenkins
ubuntu中在/etc/default/jenkins中
可以修改下面两个配置
JENKINS_USER="root" #这里改为root 会省去很多权限的麻烦
JENKINS_PORT="8088"
启动jenkins
systemctl start jenkins
关闭防火墙
使用命令“systemctl status firewalld.service”查看防火墙状态:
systemctl stop firewalld.service
systemctl disable firewalld.service
们先用下面的代码来查看有没有开放我们设置的jenkins的端口:
firewall-cmd --list-ports
如果发现没有jenkins的端口,则用
firewall-cmd --permanent --zone=public --add-port=8080/tcp
开启已经配置好的jenkins的端口,然后在重启防火墙,注意一定要重启防火墙!
systemctl reload firewalld
在浏览器中访问输入 http://192.168.0.104:8088
需要我们输入密码,初始化密码可以通过下面命令查找到
看到下面内容:
复制出来输入到密码框即可
接下来进入插件安装提示页面
但是因为插件下载地址是官方地址,所以会很慢,我们要跳过安装后续自己安装,我们点击右侧的 “选择插件来安装”进入:
然后选择 “无”,进入新建用户页面
jenkins插件管理
jenkins本身功能简单,但是jenkins提供的插件机制使得jenkins可以开发很多插件来使得jenkins很强大。
但jenkins插件默认从国外官方地址下载,速度会很慢,所以需要在安装插件前将下载地址改为国内的下载地址
1. 修改插件下载地址
修改default.json文件
sed -i 's/https:\/\/updates.jenkins.io\/download/http:\/\/mirrors.tuna.tsinghua.edu.cn\/jenkins/g' /var/lib/jenkins/updates/default.json && sed -i 's/http:\/\/www.google.com/https:\/\/www.baidu.com/g' /var/lib/jenkins/updates/default.json
进入 Manage Jenkins -》 Manage Plugin -> Advanced 最下面有 Update Site 设置为:https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
如下图所示:
重启一下jenkins,直接在浏览器中输入 http://192.168.0.104:8088/restart 重启
2. 安装常用插件
1.汉化
课程中常用的插件地址,Localization: Chinese (Simplified) | Jenkins plugin
部署到远程服务器并运行
安装Send build artifacts over SSH插件
这个插件是jenkins连接linux系统的时候使用。以下针对插件的每个属性进行说明。
构建服务后操作的一些参数
Name
SSH Server的Name属性就是你希望连接的服务器。
Source files
这里输入的是你希望传到服务器的文件夹和文件。路径是相对jenkins的workspace的项目名称的。例如项目名称是Test_Project的go项目,编译打包后的路径为Test_Project文件夹下的target,则Surce files填入target/*.go。
Remove prefix
如果Source files为target/*.jar,但是不想把target目录创建到服务器端,这个时候就可以在Remove prefix里填入target
Remote directory
这里指定文件将被拷贝到服务器的路径。
PS:被拷贝文件在服务器上的完整路径=登录服务器账号的默认路径+Remote directory。
Exec command
这里就是连接服务器之后需要执行的命令。
Jenkins Pipeline参数详解
插件名pipline
创建您的第一个Pipeline
pipeline模式相对style free门槛较高, 比较复杂的构建 ,以及构建过程很重要
Pipeline 是什么
Jenkins Pipeline 实际上是基于 Groovy 实现的 CI/CD 领域特定语言(DSL),主要分为两类,一类叫做 Declarative Pipeline,一类叫做 Scripted Pipeline。
Declarative Pipeline 体验上更接近于我们熟知的 travis CI 的 travis.yml,通过声明自己要做的事情来规范流程,形如:
pipeline {
agent any
stages {
stage('Build') {
steps {
//
}
}
stage('Test') {
steps {
//
}
}
stage('Deploy') {
steps {
//
}
}
}
}
而 Scripted Pipeline 则是旧版本中 Jenkins 支持的 Pipeline 模式,主要是写一些 groovy 的代码来制定流程:
可以从下面的链接中自动生成
node {
stage('Build') {
//
}
stage('Test') {
//
}
stage('Deploy') {
//
}
}
一般情况下声明式的流水线已经可以满足我们的需要,只有在复杂的情况下才会需要脚本式流水线的参与。
过去大家经常在 Jenkins 的界面上直接写脚本来实现自动化,但是现在更鼓励大家通过在项目中增加 Jenkinsfile 的方式把流水线固定下来,实现 Pipeline As Code,Jenkins 的 Pipeline 插件将会自动发现并执行它。
语法
Declarative Pipeline 最外层有个 pipeline 表明它是一个声明式流水线,下面会有 4 个主要的部分: agent,post,stages,steps,我会逐一介绍一下。
Agent
agent 主要用于描述整个 Pipeline 或者指定的 Stage 由什么规则来选择节点执行。Pipeline 级别的 agent 可以视为 Stage 级别的默认值,如果 stage 中没有指定,将会使用与 Pipeline 一致的规则。在最新的 Jenkins 版本中,可以支持指定任意节点(any),不指定(none),标签(label),节点(node),docker,dockerfile 和 kubernetes 等,具体的配置细节可以查看文档,下面是一个使用 docker 的样例:
agent {
docker {
image 'myregistry.com/node'
label 'my-defined-label'
registryUrl 'https://myregistry.com/'
registryCredentialsId 'myPredefinedCredentialsInJenkins'
args '-v /tmp:/tmp'
}
}
Tips:
- 如果 Pipeline 选择了 none,那么 stage 必须要指定一个有效的 agent,否则无法执行
- Jenkins 总是会使用 master 来执行 scan multibranch 之类的操作,即使 master 配置了 0 executors
- agent 指定的是规则而不是具体的节点,如果 stage 各自配置了自己的 agent,需要注意是不是在同一个节点执行的
Stages && Stage
Stages 是 Pipeline 中最主要的组成部分,Jenkins 将会按照 Stages 中描述的顺序从上往下的执行。Stages 中可以包括任意多个 Stage,而 Stage 与 Stages 又能互相嵌套,除此以外还有 parallel 指令可以让内部的 Stage 并行运行。实际上可以把 Stage 当作最小单元,Stages 指定的是顺序运行,而 parallel 指定的是并行运行。
接下来的这个 case 很好的说明了这一点:
除了指定 Stage 之间的顺序关系之外,我们还可以通过 when 来指定某个 Stage 指定与否:比如要配置只有在 Master 分支上才执行 push,其他分支上都只运行 build
还能在 Stage 的级别设置 environment,这些就不展开了,文档里有更详细的描述。
Steps
steps 是 Pipeline 中最核心的部分,每个 Stage 都需要指定 Steps。Steps 内部可以执行一系列的操作,任意操作执行出错都会返回错误。完整的 Steps 操作列表可以参考 Pipeline Steps Reference,这里只说一些使用时需要注意的点。
- groovy 语法中有不同的字符串类型,其中 'abc' 是 Plain 字符串,不会转义 ${WROKSPACE} 这样的变量,而 "abc" 会做这样的转换。此外还有 ''' xxx ''' 支持跨行字符串,""" 同理。
- 调用函数的 () 可以省略,使得函数调用形如 updateGitlabCommitStatus name: 'build', state: 'success',通过 , 来分割不同的参数,支持换行。
- 可以在声明式流水线中通过 script 来插入一段 groovy 脚本
Post
post 部分将会在 pipeline 的最后执行,经常用于一些测试完毕后的清理和通知操作。文档中给出了一系列的情况,比较常用的是 always,success 和 failure。
比如说下面的脚本将会在成功和失败的时候更新 gitlab 的状态,在失败的时候发送通知邮件:
每个状态其实都相当于于一个 steps,都能够执行一系列的操作,不同状态的执行顺序是事先规定好的,就是文档中列出的顺序。
Shared Libraries
同一个 Team 产出的不同项目往往会有着相似的流程,比如 golang 的大部分项目都会执行同样的命令。这就导致了人们经常需要在不同的项目间复制同样的流程,而 Shared Libraries 就解决了这个问题。通过在 Pipeline 中引入共享库,把常用的流程抽象出来变成一个的指令,简化了大量重复的操作。
在配置好 lib 之后,Jenkins 会在每个 Pipeline 启动前去检查 lib 是否更新并 pull 到本地,根据配置决定是否直接加载。
所有的 Shared Libraries 都要遵循相同的项目结构:
目前我们的使用比较低级,所以只用到了 vars 来存储全局的变量。
vars 下的每一个 foo.groovy 文件都是一个独立的 namespace,在 Pipeline 中可以以 foo.XXX 的形式来导入。比如我们有 vars/log.groovy:
那么 Jenkinsfile 中就可以这样调用:
大家可能已经注意到了,在 groovy 文件中,我们可以直接像在 steps 中一样调用已有的方法,比如 echo 和 sh 等。
我们也能在 groovy 文件中去引用 Java 的库并返回一个变量,比如:
这样就能够在 JenkinsFile 中去设置一个环境变量:
除了定义方法之外,我们还能让这个文件本身就能被调用,只需要定义一个 call 方法:
还能够定义一个新的 section,接受一个 Block:
这样可以让指定的 Body 在 windows 节点上调用:
常用技巧
发送邮件通知
主要使用 emailext,需要在 Jenkins 的配置界面事先配置好,可用的环境变量和参数可以参考文档 Email-ext plugin
结果同步到 gitlab
同样需要配置好 gitlab 插件,在 Pipeline 中指定 options:
然后就可以在 post 中根据不同的状态来更新 gitlab 了:
文档参考:Build status configuration
构建过程中可用的环境变量列表
Jenkins 会提供一个完整的列表,只需要访问 /env-vars.html/ 即可,别忘了需要使用 "${WORKSPACE}"
在 checkout 前执行自定义操作
在 Multibranch Pipeline 的默认流程中会在 checkout 之前和之后执行 git clean -fdx,如果在测试中以 root 权限创建了文件,那么 jenkins 会因为这个命令执行失败而报错。所以我们需要在 checkout 之前执行自定义的任务:
在 Jenkinsfile 中配置以跳过默认的 checkout 行为:
在每个 stage 中执行自定义的任务即可:
总结
Jenkins 作为使用最为广泛的 CI/CD 平台,网上流传着无数的脚本和攻略,在学习和开发的时候一定要从基本出发,了解内部原理,多看官方的文档,不要拿到一段代码就开始用,这样才能不会迷失在各式各样的脚本之中。
更重要的是要结合自己的业务需求,开发和定制属于自己的流程,不要被 Jenkins 的框架限制住。比如我们是否可以定义一个自己的 YAML 配置文件,然后根据 YAML 来生成 Pipeline,不需要业务自己写 Pipeline 脚本,规范使用,提前检查不合法的脚本,核心的模块共同升级,避免了一个流程小改动需要所有项目组同步更新。
6. 定时构建的语法
1.定时构建语法
定时字符串从左到右依次: 分 时 日 月 周
*号等同于H,表示任意一个合理的数
* * * * *
第一个*表示分钟,取值0~59,若其他值不做设定,则表示每个设定的分钟都会构建
5 * * * * ,表示每个小时的第5分钟都会构建一次
第二个*表示小时,取值0~23, 若其他值不做设定,则表示每个设定小时的每分钟都会构建
* 5 * * * ,表示在每天5点的时候,一小时内每一分钟都会构建一次
第三个*表示一个月的第几天,取值1~31,若其他值不做设定,则表示每个月的那一天每分钟都会构建一次
* * 5 * *,表示在每个月5号的时候,0点开始每分钟构建一次
第四个*表示第几月,取值1~12,若其他值不做设定,则表示每年的那个月每分钟都会构建一次
* * * 5 *,表示在每年的5月份,1号0点开始每分钟构建一次
第五个*表示一周中的第几天,取值0~7,其中0和7代表的都是周日,若其他值不做设定,则表示每周的那一天几每分钟都会构建一次
* * * * 5,表示每周五0点开始每分钟构建一次
2.构建实例
每天凌晨2:00跑一次
H 2 * * *
每隔5分钟构建一次
H/5 * * * *
每两小时构建一次
H H/2 * * *
每天中午12点定时构建一次
H 12 * * * 或0 12 * * *(0这种写法也被H替代了)
每天下午18点前定时构建一次
H 18 * * *
每15分钟构建一次
H/15 * * * * 或*/5 * * * *(这种方式已经被第一种替代了,jenkins也不推荐这种写法了)
周六到周日,18点-23点,三小时构建一次文章来源:https://www.toymoban.com/news/detail-446391.html
H 18-23/3 * * 6-7文章来源地址https://www.toymoban.com/news/detail-446391.html
到了这里,关于jekins自动化部署的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!