Build great things at any scale.
快速上手
起源
一个项目比较完整的生命周期该是怎样的?
由开发的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指数来反映国外的情况.
hudson/jenkins
hudson是jenkins的前称
jenkins 2012-2019百度搜索指数趋势图
hudson的趋势数量级在百,忽略不计
TeamCity
TeamCity是jet大脑的出品,百度搜索指数还未收录
Travis
Travis CI是最老的托管解决方案之一
其他
其他有如gitlab ci,bamboo由于存在关键词意义重叠的情况,目前还没有想到比较好的解决方案,这次不加入比较.
结论
从上面的趋势图中无论是基数还是趋势,jenkins的学习性价比对比travis要高许多.
当你选择了一种语言，意味着你还选择了一组技术、一个社区
从二次开发的角度来看,jenkins开源,而且使用的语言是java,使用的框架为spring,两者分别为国内语言社区和框架社区中的顶级社区,发展的特别的好.
使用
我们将使用jenkins完成三个最为重要和基础的功能
拉取远程git库代码到本地
主界面是这样的
为了规整,我们可以先创建一个文件夹(目录)
点击new任务,出现
点击文件夹,然后在输入框中输入文件夹的名字,后点击ok后进入了文件夹属性配置界面
不管这个界面,点击左上方的jenkins图标回到jenkins主页
发现此时多了一个文件夹
点击进入
点左上方的New item
和之前的new 任务页面类似
点击构建一个自由风格的软件项目
在输入框输入这个自动化任务的名称
点ok之后进入配置界面
在这个配置界面下拉到Source Code Management,点击选中git
在Repository URL中输入需要maven构建的代码的仓库地址
Branch Specifier中输入需要构建的分支的名称,/master表示构建分支名为master,/你的分支的名字
接下来需要认证这个仓库,点击Credentials右边的add
出现了下拉,一个是jenkins,一个是我们的文件夹名称(githubTasks)
我们选择文件夹名称
在弹出的窗口中类型选择为Username with password
然后输入你的登录到git仓库的用户名和密码
然后点击添加,在Credentials的无 下拉,有我们刚刚添加的账户
点击最下方的Save,完成这个自动化构建任务的第一步,拉取远程git库的代码到本地(jenkins所在服务器,docker的话就是docker的容器内部)
我们可以看到是否拉取成功,回到这个界面
点击进入
坐下方的Build History里面有一个 #1
点击进入
点击左侧栏的Console Output进入
注意这个位置是导航栏,这里我们可以随意跳转到主界面,文件夹界面或者是任务界面
jenkins是主界面,githubTasks是文件夹
compileGithub是任务界面
我们点击compileGithub进入任务界面
点击workSpace
进入到了这个界面,里面可以看到我们的拉取的代码
可以看到这个界面的标题节点master上的工作空间,在之后的将代码编译后的成品发布到任意指定机器上的那部份,我会对节点,加以解释,现在这个节点master值得就是jenkins所在的这台机器.
上面的工作完成了将代码从远程git仓库拉取到本地,接下来需要在本地编译这些代码
引申
如果我经常需要拉取不同的分支的代码,也就是分支这个字符串,是经常需要改变的,难道我每次都要修改任务配置中的Branch Specifier吗?
让我们返回到jenkins主页,这儿需要加入一个git参数动态化的插件
主页中点击系统设置,点击插件管理
然后点击Available
filter 中输入:git parameter
筛选出来的插件中勾选 Git Parameter
点击install without restart之后
等到Git Parameter 图标为 Success即ok
点击Go Back to the top page,回到首页
点击导航栏任务compileGithubCode,没有的话先进入文件夹githubTasks,然后从这里点击compileGithubCode进入任务
点击左侧的Configure
进入到了任务的配置界面
找到并勾选参数化构建过程
下拉选择Git Parameter
在name中为这个分支字符串变量起个名字,以后用$获取
Parameter Type下拉选择branch
点击左下角save
这时候我们发现任务左侧边栏的开始构建没有了,取而代之的是Build With Parameters
点击Build With Parameters转到界面
这个列表会罗列出该git仓库的所有分支,我们选择点击选择一个,然后点Build就好了
使用编译工具本地编译拉取到的代码
得到了远程库的代码,现在要在本地编译这些代码
java coder的话,使用maven编译打包
这个时候就要添加maven这一全局工具了
注意: 接下来是自动的在jenkins机器上安装了一个maven,但是如果你原本项目的maven编译依赖着.setting.xml中配置的maven私服或者是proxy代理的话,还需要别的操作,最粗暴不过进入到jenkins所在机器(这里是docker的容器内部),找到并配置maven的setting.xml
导航栏点击jenkins进入到主界面
点击左侧系统管理进入到了
点击全局工具配置,然后下拉到
点击add maven
在name中输入你给它起得名字,这里起了名字maven36来标识他是3.6.0版本
点击左下角的Save
然后回到了主界面,点击jenkins,点击文件夹githubTasks,点击任务compileGithubCode
点击左侧Configure
其实可以注意到,这里也有导航栏
我们点击Build
然后点击add build step
选择 执行顶层Maven目标
出来的界面中
maven version 中下拉选择我们上一步在系统设置的全局工具配置中起得maven名称
Goals部分大部分都是clean install,clean package之类的maven编译命令
点击左下方save,ok
回到任务compileGithub界面,点击左侧立即构建
看到了左下方build中标志着任务正在进行中的闪烁的图标
点击这个#3,进入到日志界面
我们在系统设置的全局工具配置中配置了如何下载maven等,但是实际上它是类似于单例模式,在第一次运行的时候初始化,以后都能使用
由于没有配置中央仓库为国内maven镜像库,而且是maven第一次构建,所以我这里构建的特别慢,花了将近15min
构建完成后的日志
构建完成之后我们进入任务界面compileGithubCode
点击workspace
进入到jar产生的target目录,发现成功编译得到了jar文件
但是以后比如别的人想从网页上下载这个编译好的jar,能不能直接从页面上下载下来,当然可以,点击这个jar就会下载下来
但是我们要明白这个任务的目的是什么,其实就是得到这个编译后的成果,过程怎么样是没人关心的,也就是这个任务应该对外完美暴露它的成功,也就是这个jar,不仅要方便大家从页面上下载这个jar,还有后面的任务可能会从这个任务上拿取jar
需要添加构建后操作,回到这个任务的配置页面,找到Post-build Actions,下拉选择归档成品
在Files to archive中填写需要暴露的jar的位置
位置是可以从任务的工作空间中看到的
然后我们回到任务主页,点击开始Build with parameter,选择分支,build
build成功后,我们进入该任务的主页
发现多了一个Last Successful Artifacts,这样就可以很方便的从页面上下载这个jar,而不用担心忘了编译后的成果在什么文件夹位置的情况.
注意: 这一步是必备的,不然下面的发布的任务会无法从这个任务中自动化的获取jar
至此完成了本地编译从远程库pull下来的代码的阶段.
将编译的结果部署到指定的机器上
接下来我们需要理解jenkins中节点的概念
jenkins安装在一台机器，所有的jobs都在这台机器上运行，如果超过太多jobs去运行，会形成等待，节点存在就是解决这个问题提高效率，安装jenkins的机器称为master机，而其它机器就属于master的分支，成为slave；而要利用其它机器用执行jenkins的jobs，则需要一些配置，形成两台机器互通，当然下面的例子你用本机当做slave也是可以的
从机节点的建立意味着这台从机就是master的一个复刻,master能执行的任务它都能干(master的向从机发送命令这一功能除外)
也就是完整的发布过程是这样的,master机器访问从机B,向B发送 拉取代码到本地 的命令,master机器做的仅仅是发送命令,然后干别的,等到B将远程代码pull到了B的本地
本地编译代码的过程也是如此
而现在我们就是需要从机得到代码,编译,然后在本地执行启动服务的脚,如果是tomcat应用的话(外置),可能是将编译后的war放入webapps下,然后启动tomcat的startup.sh
那我们先完成第一步,建立从机节点,说白了,就是我作为master,怎么访问从机,用户名加密码也好,ssh认证也好
建立从机节点
为了方便用户管理,我们最好不要使用使得master访问从机的root用户,比如这里,我们使用用户jenkins用户
连接到一台从机(root用户)
groupadd jenkins
useradd jenkins -g jenkins
passwd jenkins
接下来需要输入jenkins用户的密码,要求比较严格,密码要求为至少8位的非简单字符串
密码定位kinsjen0
然后我们切换到jenkins用户
su - jenkins
pwd
jenkins的~目录在/home/jenkins
因为jenkins是用java写的后台,需要注意这台从机机器需要有java环境
which java
得到的路径地址会在后面配置节点信息的时候用到
接下来我们进入jenkins主页,点击左侧系统管理,然后下拉找到节点管理,点击之后是这样的
注意到已经有了一个节点master,就是我们安装jenkins的机器,我们点击左边的New Node
在输入框中输入我们给这个节点机器起得名字
并勾选固定节点
切记这里的节点名不能包含中文字符,不然之后的操作会无法识别这个节点,如果已经发现了问题,可以在节点的设置中修改名称.
点击ok后展开页面
Remote root directory中输入你的从机的用户的~地址
也就是我们的从机的jenkins用户的~,/home/jenkins
然后下拉Usage,切换到 只允许绑定到这台机器的job,Host输入这台节点的ip
注意,要确保在master机器上能够ping通这个ip
然后下拉Host Key Verification Strategy,选择Manually trusted key Verification Strategy
随后点击Credentials右侧的add,点击下拉出现的jenkins,出现界面
在username中输入节点机器的用户名jenkins,在password中输入这个用户的密码,然后点击添加
随后在Credentials的下拉中选择我们刚刚添加的用户密码信息
点击Launch method右下方的Advanced,这里唯一要做的是填写javapath,也就是我们在节点机器上新建用户的时候说道的which java得到的java路径
注意: 如果ssh端口暴露的是36000,记得这里修改port的22为36000,不然启动日志会报错
点击左下方Save完成节点的配置.此时跳转到了节点管理界面.
可以看到此时的节点处于未启动状态,因为启动需要一段时间,主机会将服务的相关代码copy到从机的/home/jenkins下
可以点击节点 测试机器1jenkins用户,进入后的界面点击启动;也可以稍等一会儿,它会自动去启动,启动成功后可以看到这个节点管理界面发生了变化,这样表示成功建立了节点
至此完成了从机节点的配置.
提示: 可以登录到从机机器上,切到jenkins用户,切换到~目录下,ls后可以看到名为remoting.jar和remoting文件夹
在节点上部署服务
接下来让我们收货最终的成果,在节点机器上发布应用
这时候我们需要什么?
我们需要在从机机器上运行我们的代码编译完成的jar
那么第一步就是取得我们的jar
如何取得我们的代码的jar,我们已经在任务compileGithub中得到了远程代码,并编译了它,现在我们需要它的编译结果
有这么一个插件需要我们添加,来帮助我们在一个新的任务中拉取另一个任务的编译结果
回到jenkins首页,左侧系统管理,之后点插件管理,filter中输入:Copy Arti
勾选筛选出来的插件Copy Artifact
点击install without restart
Copy Artifact变为success之后
点击Go Back to the top page,完成插件的添加.
回到jenkins主页,进入githubTasks文件夹,点击左侧New Item,输入任务名称,比如deployMyCode,然后选择构建一个自由风格的软件项目,点OK
勾选Restrict where this project can be run,Label Expression中输入我们之前新建的节点的名字,输入了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
ls
packages test.log
cd packages
ls
vertx-api
cd vertx-api
ls
target
cd target
ls
vertx-api-1.0.0.jar
这样我们就明白了,这个脚本的执行目录在/home/jenkins/workspace/githubTasks/deployMyCode下,也就是我们的脚本实际上是在这个目录下被执行的
之后我们回到这个任务的配置界面,将我们的脚本修改为
#!/bin/bash
deploy_testMachine() {
java -jar ./packages/*.jar
}
deploy_testMachine
然后回到任务主页,立即构建,即可完成类似服务的发布这种
如果你需要每次删除上次残留在节点中的旧的代码,需要进入到任务的配置,在Build Environment下勾选Delete workspace before build starts即可
至此完成从编译产物到产物发布的过程