JenkinsJenkins is a self-contained, open source automation server which can be used to automate all sorts of tasks related to building, testing, and delivering or deploying software.主要介绍使用Jenkins来达到持续集成持续交付/持续部署(CICD)的一些方案和选择,不涉及Jenkins的深入研究。
实现CI/CD的方式有很多种,本文介绍的只是我这几天一些粗略的摸索,仅供大家参考。
一、安装Jenkins的安装方式有很多选择,这里不做详细讨论,我这次采用了比较熟悉的部署WAR包的方式,将其部署到tomcat上来运行。
部署完成之后访问相应地址即可,这是会提示新建用户,大家按照指引一步一步完成即可,不做赘述。
二、新建任务Jenkins部署完成之后,接下来便要进入正题了,新建一项任务,已达到CICD的目的。
首页左侧菜单按选择新建任务-》输入任务名称-》构建一个自由风格的软件项目-》确定(这里我已经创建过一个名为test的项目了)
点击确定后进入了该项目的配置页面,先总览所有的配置项,共有六项:General,源码管理,构建触发器,构建环境,构建,构建后操作.从字面意思上不难理解。General,一些通用的信息,本次不做重点;
源码管理,构建的来源,git,svn,亦或是其他一些源码管理服务;
构建触发器,以何种规则自动触发源码的构建(持续构建),若该项不做任何配置,则只能手动触发;
构建环境,本次也未做关键性修改;
构建,以何种方式构建,maven, gradle, 亦或是其他;
构建后操作,成功构建之后的一些操作,持续交付/持续部署的操作主要放到这一块。
接下来分别较少这几项配置,以及用到的插件,已完成CI/CD的目标。
1. General本次并没有做一些关键的修改
2. 源码管理只说明git的一些相关配置,其他的源码管理服务同理
Repository URL: git上的源码地址
Credentials: 用户名/密码
Branch Specifier:指定需要构建的分支
上边这些做完后其实基本上已经可以了,之所以修改Advanced clone behaiours,是防止第一次构建时拉取源码超时,默认超时时间为10minutes,多次构建失败后,我把此处修改为了20minutes,如果依旧超时,可延长此处时间,或检查网络(点击Additional Behaviours旁边的add,选择Advanced clone behaiours)Shallow clone,Shallow clone depth:浅拷贝,节省拷贝时间和磁盘空间
3. 构建触发器实现触发构建的方式主要有定时触发、web hook触发,这些触发方式可以单独使用,也可以组合使用。
3.1 定时触发Build periodically: 周期性构建
Poll SCM: 周期性检测,若源码有变化则构建
定时构建部署,可控制频率
3.2 Gitlab Hook插件
web hook触发主要介绍gitlab hook插件,接下来我们先保存已经完成的配置,回到首页,下载所需插件。
可选插件中搜索gitlab,勾选列表中的GitLab Plugin和Gitlab Hook Plugin, 选择直接安装。待安装完成后回到首页,点击右边刚刚我们创建的任务,然后点击配置回到我们之前的配置页面。
此时发现构建触发器中多了个选项:Build when a change is pushed to GitLab. GitLab CI Service URL: http://172.16.192.142:9081/jenkins/project/test,如果仍然没有,尝试重启Jenkins之后查看。
图中红框上边为Gitlab Web Hook处需要添加的URL,若Jenkins设置了不允许匿名用户执行构建操作,则需要在Gitlab安全令牌处添加第二个红圈处的Secret token。Gitlab处需要增加的配置(设置-》集成,注意登录账户需要有相应权限)
随时提交,随时构建,快速相应开发人员的操作,但需要开发人员提交代码的时候确保提交可用,多次commit一次push,除非紧急需要尽量在午休时间,早上上班前,晚上下班后push代码
4. 构建环境没有关键配置的修改,其中Color ANSI Console Output为下载的插件AnsiColor,可以使日志输出带有颜色,详情可查看Jenkins 的输出日志也可以变得色色的
5. 构建构建部分主要采用了maven构建,确保部署Jenkins的机器已经配置好了maven环境,maven的配置不做赘述。
6. 构建后操作使用maven构建打包完成后,与pom.xml同级的target目录下会生成一个war包(取决于pom.xml中的配置,对pom.xml的配置不做描述),接下来我们要做的就是将生成的war包部署到中间件或容器中,下面主要介绍两个插件,可以根据实际情况有选择的使用,使用之前首先需要参考之前介绍的步骤下载相应插件。
6.1 Deploy to Container插件达到效果:构建前需保证目标中间件正常启动,每次Jenkins构建时会把指定的war包自动部署到指定的服务器上的context path中,如果目标服务已存在,首先undeploy目标服务,再把新的war包redeloy上去,已完成自动部署的功能。
仅支持GlassFish,JBoss,Tomcat
增加构建后操作步骤中选择Deploy war/ear to a container
WAR/EAR files中填上所需要部署的程序包,支持**/*.war的形式
Context path配置程序相对于中间件环境的发布路径
本文中Containers我选择了Tomcat 7.x,Credentials需要在tomcat里配置上,Tomcat URL即环境的基础地址在tomcat中添加授权用户:修改conf/tomcat-users.xml
只是做上边这些配置的话,你会发现Jenkins的自动部署仅支持第一次,已有旧版应用运行时,自动部署会报undeploy失败,原因是在应用运行时,tomcat会对应用的资源进行锁定,导致无法覆盖更新,这时需修改tomcat的另一项配置:conf/context.xml(详情可查看Tomcat中antiResourceLocking和antiJARLocking的作用)
6.2 Publish Over SSH插件通过SSH操作目标服务,从而传输文件,执行命令已达到目的
更灵活,支持各种中间件服务器
首先在系统设置中配置上所需连接的远程服务器,配置上相关配置,其中Remote Directory是访问服务器的基础路径,之后步骤能用到
然后回到任务配置继续配置构建后操作一块
Remote directory 远程服务器文件夹,空即为默认的上边步骤配置的路径,如果此处不为空,即为相对路径Remove prefix 去除前置路径
Exec command 执行脚本,此处的脚本比较简单,调用目标中间件的停止与启动
需要注意的是执行脚本的时候有个坑,读取不到系统的环境变量,原因是此处执行脚本的方式为non-interactive + non-login shell,不会读取/etc/profile中的配置,此处的解决方案是采用bash执行命令,由于bash恒执行BASH_ENV中的变量,因此需要把/etc/profie赋值到BASH_ENV中,详细解决思路参考链接
三、其他至此已经完成了从开发人员push代码到应用构建、部署等相关操作的基本自动流程,具体细节部分还需要继续深入研究探索
遗留问题:Jenkins构建的时候控制台乱码解决之后,Jenkins启动的tomcat发生乱码
自动构建部署的时候,Jenkins调用命令启动StartTAS.sh的时候会一直监听启动日志,直到超时才断开链接,这时候因超时而导致本次构建为黄灯,即不稳定的构建