Build great things at any scale.

快速上手

1. 安装jenkins
2. 使用jenkins

起源

一个项目比较完整的生命周期该是怎样的?

由开发的coding阶段和coding阶段的质量测试,再到多次发布投入使用阶段

而现代化的测试阶段并不是从coding结束后开始,而是和coding同步进行的,今天上午coding完成一个功能,下午就要投入测试

如何测试呢,也就是将开发者完成的代码,拉取到服务器A(一般是linux)上,按照开发者的部署文档搭建各种依赖服务(可能是mysql,redis,kafka等等),然后运行代码编译后的文件或者是运行脚本

如果我们测试得出开发者今天完成的新功能存在问题,我们需要提出bug,然后开发者解决这个bug,解决完之后呢?

如果开发者在bug解决文档中没有说明是依赖服务出现了问题导致的这个bug,那么A机器上的依赖服务我们是不用重新搭建的,无非就是启动和停止.

变化的往往都是开发者的功能的代码部分.对于java coder,一般是将开发者在git的指定分支上的代码pull下来之后编译打包,然后替换掉A机器上的编译后的包,重启服务,继续测试

每当需求发生变化,功能需要改进,bug等等问题的时候,代码就会发成变化,而将这种变化需要我们在测试机器上得以体现,可能就是替换代码包之类的,这个过程重复而且繁杂,也容易出现部署失误,这种需求背景下产生了自动化持续构建的概念.

而jenkins正是贯彻和发扬了这一理念的持续构建工具

The leading open source automation server, Jenkins provides hundreds of plugins to support building, deploying and automating any project.

领先的开源自动化服务,jenkins中提供了众多的插件以支持使用自动化的方式构建和发布任何工程.

本文作者同大家一起开始步入jenkins的镜像世界,一步一步,深入jenkins,从入门到精通,从使用到理解掌握

为什么选择jenkins

既然都是为了实现自动化持续构建,难道就jenkins这一个选择吗

通常我会使用google trends(谷歌趋势),在涉足一个新的领域的时候帮助我了解这个领域哪些将会是趋势,哪些只是残留.

百度指数也可以起到到和谷歌趋势起到的效果,但是只能反映国内的一部分情况,而且,比如我在搜索eclipse的热度的时候,谷歌会有针对eclipse(日食)这一词义,还是针对名为eclipse的软件的搜索划分,这一点显然特别重要.

hudson/jenkins

hudson是jenkins的前称

TeamCity TeamCity是jet大脑的出品,百度搜索指数还未收录

Travis

Travis CI是最老的托管解决方案之一

其他

其他有如gitlab ci,bamboo由于存在关键词意义重叠的情况,目前还没有想到比较好的解决方案,这次不加入比较.

对比

1. Google Trends

2. 百度指数

结论

从上面的趋势图中无论是基数还是趋势,jenkins的学习性价比对比travis要高许多.

当你选择了一种语言，意味着你还选择了一组技术、一个社区

从二次开发的角度来看,jenkins开源,而且使用的语言是java,使用的框架为spring,两者分别为国内语言社区和框架社区中的顶级社区,发展的特别的好.

使用

我们将使用jenkins完成三个最为重要和基础的功能

1. 拉取远程git库的代码到本地
2. 使用编译工具本地编译拉取到的代码
3. 将编译的结果部署到指定的机器上

1. 拉取远程git库代码到本地

主界面是这样的

为了规整,我们可以先创建一个文件夹(目录)

点击new任务,出现

点击文件夹,然后在输入框中输入文件夹的名字,后点击ok后进入了文件夹属性配置界面

不管这个界面,点击左上方的jenkins图标回到jenkins主页

发现此时多了一个文件夹

点击进入

点左上方的New item 和之前的new 任务页面类似

点击构建一个自由风格的软件项目 在输入框输入这个自动化任务的名称

点ok之后进入配置界面

在这个配置界面下拉到源码管理点击选中git

在Repository URL中输入需要maven构建的代码的仓库地址

Branch Specifier中输入需要构建的分支的名称,*/master表示构建分支名为master,*/你的分支的名字

接下来需要认证这个仓库,点击Credentials右边的add

出现了下拉,一个是jenkins,一个是我们的文件夹名称(githubTasks) 我们选择文件夹名称

选择githubTasks,意味着,我们即将添加的这个用户,将来只会在这个文件夹下使用

在弹出的窗口中类型选择为Username with password 然后输入你的登录到git仓库的用户名和密码

然后点击添加,在Credentials的无 下拉,有我们刚刚添加的账户

点击最下方的保存

点击左侧的立即构建

完成这个自动化构建任务的第一步,拉取远程git库的代码到本地(jenkins所在服务器,docker的话就是docker的容器内部)

我们可以看到是否拉取成功

左下方的Build History里面有一个 #1 点击进入

点击左侧栏的控制台输出进入

看到控制台里面的最近的提交记录,则说明git成功拉取代码

下一步查看拉取的代码在什么位置

注意这个位置是导航栏,这里我们可以随意跳转到主界面,文件夹界面或者是任务界面 jenkins是主界面,githubTasks是文件夹 compileGithub是任务界面

我们点击compileEms进入任务界面 点击工作空间

进入到了这个界面,里面可以看到我们的拉取的代码

可以看到这个界面的标题节点master上的工作空间,这个单词的意思和git没有任何关系,在之后的将代码编译后的成品发布到任意指定机器上的那部分,我会对节点,加以解释,现在这个built in节点指的就是jenkins所在的这台机器.

上面的工作完成了将代码从远程git仓库拉取到本地,接下来需要在本地编译这些代码

扩展

如果我经常需要拉取不同的分支的代码,也就是分支这个字符串,是经常需要改变的,难道我每次都要修改任务配置中的指定分支吗?

让我们返回到jenkins主页,这儿需要加入一个git参数动态化的插件

主页中点击manage jenkinss,点击manage plugins 然后点击available, 在search输入框中输入git parameter

筛选出来的插件中勾选 Git Parameter 点击install without restart之后

等到Git Parameter 图标为 Success即ok

点击返回首页,回到首页

点击导航栏任务compileGithubCode,没有的话先进入文件夹githubTasks,然后从这里点击compileGithubCode进入任务 点击左侧的配置 进入到了任务的配置界面

找到并勾选参数化构建过程

下拉选择Git Parameter

在name中为这个分支字符串变量起个名字,以后用$获取

Parameter Type下拉选择branch

接着,继续向下,找到一开始我们配置git仓库以及分支的那个地方,也就是源码管理

将指定分支右侧的输入框中的内容,换为$branchVar

点击左下角保存

这时候我们发现任务左侧边栏的开始构建没有了,取而代之的是Build With Parameters

点击Build With Parameters转到界面

这个列表会罗列出该git仓库的所有分支,我们选择点击选择一个,然后点Build就好了

2. 使用编译工具本地编译拉取到的代码

得到了远程库的代码,现在要在本地编译这些代码

java coder的话,使用maven编译打包

这个时候就要添加maven这一全局工具了

注意: 接下来是自动的在jenkins机器上安装了一个maven,但是如果你原本项目的maven编译依赖着.setting.xml中配置的maven私服或者是proxy代理的话,还需要别的操作,最粗暴不过进入到jenkins所在机器(这里是docker的容器内部),找到并配置maven的setting.xml,但是如果你想要更为规范的setting.xml的配置方式,这边文章中说的十分详细

导航栏点击jenkins进入到主界面

点击左侧manage jenkins进入到了

点击global tool configuration,然后下拉到

点击新增maven 在name中输入你给它起得名字,这里起了名字maven36来标识他是3.6.0版本

点击左下角的保存

然后回到了主界面,点击jenkins,点击文件夹githubTasks,点击任务compileGithubCode

点击左侧配置

其实可以注意到,这里也有导航栏

我们点击构建 然后点击增加构建步骤

选择 执行顶层Maven目标

出来的界面中 maven version 中下拉选择我们上一步在系统设置的全局工具配置中起得maven名称 目标输入框大部分都是clean install,clean package之类的maven编译命令

clean package -Dmaven.test.skip=true

点击左下方保存,ok

回到任务compileGithub界面,点击左侧 build with parameter

刷新一下当前页面 看到了左下方build history中标志着任务正在进行中的闪烁的图标

点击这个#3,进入到控制台输出界面

我们在系统设置的全局工具配置中配置了如何下载maven等,但是实际上它是类似于单例模式,在第一次运行的时候初始化,以后都能使用

由于没有配置中央仓库为国内maven镜像库,而且是maven第一次构建,所以我这里构建的特别慢,花了将近3min

构建完成后的日志

构建完成之后我们进入任务界面compileGithubCode

点击工作空间 进入到jar产生的target目录,发现成功编译得到了jar文件

但是以后比如别的人想从网页上下载这个编译好的jar,能不能直接从页面上下载下来,当然可以,点击这个jar就会下载下来

但是我们要明白这个任务的目的是什么,其实就是得到这个编译后的成果,过程怎么样是没人关心的,也就是这个任务应该对外完美暴露它的成功,也就是这个jar,不仅要方便大家从页面上下载这个jar,还有后面的任务可能会从这个任务上拿取jar

需要添加构建后操作,回到这个任务的配置页面,找到构建后操作, 下拉选择归档成品

在归档成品中填写需要暴露的jar的位置

位置是可以从任务的工作空间中看到的

然后我们回到任务主页,点击开始Build with parameter,选择分支,build

build成功后,我们进入该任务的主页

发现多了一个最后一次成功的构建结果,这样就可以很方便的从页面上下载这个jar,而不用担心忘了编译后的成果在什么文件夹位置的情况.

注意: 这一步是必备的,不然下面的发布的任务会无法从这个任务中自动化的获取jar

至此完成了本地编译从远程库pull下来的代码的阶段.

3. 将编译的结果部署到指定的机器上

接下来我们需要理解jenkins中节点的概念

jenkins安装在一台机器，所有的jobs都在这台机器上运行，如果超过太多jobs去运行，会形成等待，节点存在就是解决这个问题提高效率，安装jenkins的机器称为master机，而其它机器就属于master的分支，成为slave；而要利用其它机器用执行jenkins的jobs，则需要一些配置，形成两台机器互通，当然下面的例子你用本机当做slave也是可以的

从机节点的建立意味着这台从机就是master的一个复刻,master能执行的任务它都能干

也就是完整的发布过程是这样的,master机器访问从机B,向B发送 拉取代码到本地 的命令,master机器做的仅仅是发送命令,然后干别的,等到B将远程代码pull到了B的本地

jenkins实现远程发送执行命令的原理 使用了ssh的方式 详见

ssh 远程执行命令 - 杨哥哥 - 博客园​www.cnblogs.com/youngerger/p/9104144.html

本地编译代码的过程也是如此

而现在我们就是需要从机得到代码,编译,然后在本地执行启动服务的脚本,如果是tomcat应用的话(外置),可能是将编译后的war放入webapps下,然后启动tomcat的startup.sh

那我们先完成第一步,建立从机节点,说白了,就是我作为master,怎么访问从机,用户名加密码也好,ssh认证也好

3.1 建立从机节点

为了方便用户管理,我们最好不要使用使得master访问从机的root用户,比如这里,我们使用用户jenkins用户

连接到一台从机(root用户)

useradd -d /home/jenkins -m jenkins

接下来需要输入jenkins用户的密码,要求比较严格,密码要求为至少8位的非简单字符串

密码定位itszt19jenkins

然后我们切换到jenkins用户

su - jenkins
pwd

jenkins的~目录在/home/jenkins

因为jenkins是用java写的后台,需要注意这台从机机器需要有java环境

which java

得到的路径地址会在后面配置节点信息的时候用到

接下来我们进入jenkins主页,点击左侧manage jenkins,然后下拉找manage nodes and cloud,点击之后是这样的

注意到已经有了一个节点built in node,就是我们安装jenkins的机器,我们点击左边的New Node

在输入框中输入我们给这个节点机器起得名字 并勾选固定节点

切记这里的节点名不能包含中文字符,不然之后的操作会无法识别这个节点,如果已经发现了问题,可以在节点的设置中修改名称.

点击ok后展开页面

远程工作目录中输入你的从机的用户的~地址 也就是我们的从机的jenkins用户的~,/home/jenkins

然后下拉用法,切换到 only job with this lable ...

启动方式修改为 Launch agents via ssh

Host输入这台节点的ip

注意,要确保在master机器上能够ping通这个ip

然后下拉Host Key Verification Strategy,选择Manually trusted key Verification Strategy

随后点击Credentials右侧的add,点击下拉出现的jenkins,出现界面

在username中输入节点机器的用户名jenkins,在password中输入这个用户的密码,然后点击添加

随后在Credentials的下拉中选择我们刚刚添加的用户密码信息

点击启动方式下方的高级按钮,这里唯一要做的是填写java路径,也就是我们在节点机器上新建用户的时候说到的which java得到的java路径

注意: 如果ssh端口暴露的是36000,记得这里修改port的22为36000,不然启动日志会报错

点击左下方Save完成节点的配置.此时跳转到了节点管理界面.

可以看到此时的节点处于未启动状态,因为启动需要一段时间,主机会将服务的相关代码copy到从机的/home/jenkins下

可以点击节点 测试机器1jenkins用户,进入后的界面点击启动;也可以稍等一会儿,它会自动去启动,启动成功后可以看到这个节点管理界面发生了变化,这样表示成功建立了节点

至此完成了从机节点的配置.

提示: 可以登录到从机机器上,切到jenkins用户,切换到~目录下,ls后可以看到名为remoting.jar和remoting文件夹

3.2 在节点上部署服务

接下来让我们收货最终的成果,在节点机器上发布应用

这时候我们需要什么?

我们需要在从机机器上运行我们的代码编译完成的jar

那么第一步就是取得我们的jar

如何取得我们的代码的jar,我们已经在任务compileGithub中得到了远程代码,并编译了它,现在我们需要它的编译结果

有这么一个插件需要我们添加,来帮助我们在一个新的任务中拉取另一个任务的编译结果

回到jenkins首页,左侧系统管理,之后点插件管理,在 avaliable的 filter中输入:Copy Arti

勾选筛选出来的插件Copy Artifact

点击install without restart

Copy Artifact变为success之后

点击Go Back to the top page,完成插件的添加.

回到jenkins主页,进入githubTasks文件夹,点击左侧New Item,输入任务名称,比如deployMyCode,然后选择构建一个自由风格的软件项目,点OK

勾选限制项目的运行节点,输入框中输入我们之前新建的节点的名字,输入了MachineTest1就已经有了提示,选中它

这样就相当于是会让这个机器执行发布任务

接下来我们获取之前的任务构建的jar

然后在Project name中输入我们之前的拉取代码并本地编译的任务名称 compileGitHubCode,

Artifacts to copy中输入vertx-api/target/*.jar,这个就是我们的任务compileGitHubCode执行完后在工作空间中能找到的jar的位置.

提示: 这个在前面提到了编译代码后的保存构建生成物操作

Target directory中输入packages

之后再次点击构建中的,添加构建步骤, 我们创建一个shell

注意顺序,这个添加的shell应该在Copy artifacts from another project的下面

按道理我们应该在这个shell脚本中执行我们获得的jar,完成类似这样的发布任务的,但是为了熟悉一下这个脚本的执行环境,我们先运行一个简单的脚本

#!/bin/bash

deploy_testMachine() {
    touch test.log
}
deploy_testMachine

然后点击左下方的Save,回到了任务的主页面,我们点击左侧栏的立即构建

点击左下方的#5

然后点击左侧的Console Output

可以从日志中发现一些端倪

Building remotely on MachineTest1UserJenkins in workspace /home/jenkins/workspace/githubTasks/deployMyCode

也就是我们经常说的任务的工作空间实际是:

/home/jenkins也就是我们的节点用户

/workspace是我们的所有的工作空间的最上级

/githubTasks我们之前的文件夹

/deployMyCode是我们的这次任务

切入到/home/jenkins/workspace/githubTasks/deployMyCode

#!/bin/bash

deploy_testMachine() {
   sh /home/jenkins/apache-tomcat-8.5.82/bin/shutdown.sh
   cp packages/target/*.war /home/jenkins/apache-tomcat-8.5.82/webapps
   sh /home/jenkins/apache-tomcat-8.5.82/bin/startup.sh
}

deploy_testMachine

这样我们就明白了,这个脚本的执行目录在/home/jenkins/workspace/githubTasks/deployMyCode下,也就是我们的脚本实际上是在这个目录下被执行的

之后我们回到这个任务的配置界面,将我们的脚本修改为

#!/bin/bash

deploy_testMachine() {
    java -jar ./packages/*.jar
}
deploy_testMachine

然后回到任务主页,立即构建,即可完成类似服务的发布这种

如果你需要每次删除上次残留在节点中的旧的代码,需要进入到任务的配置,在Build Environment下勾选Delete workspace before build starts即可

至此完成从编译产物到产物发布的过程