Jenkins在Java web项目CI/CD中的简单应用

时间 2019-11-16

原文原文链接

Jenkins

Jenkins 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的方式有不少种，本文介绍的只是我这几天一些粗略的摸索，仅供你们参考。

1、安装

Jenkins的安装方式有不少选择，这里不作详细讨论，我此次采用了比较熟悉的部署WAR包的方式，将其部署到tomcat上来运行。

部署完成以后访问相应地址便可，这是会提示新建用户，你们按照指引一步一步完成便可，不作赘述。

2、新建任务

Jenkins部署完成以后，接下来便要进入正题了，新建一项任务，已达到CICD的目的。
首页左侧菜单按选择新建任务-》输入任务名称-》构建一个自由风格的软件项目-》肯定（这里我已经建立过一个名为test的项目了）

点击肯定后进入了该项目的配置页面，先总览全部的配置项，共有六项：General，源码管理，构建触发器，构建环境，构建，构建后操做.从字面意思上不难理解。html
- General，一些通用的信息，本次不作重点；
- 源码管理，构建的来源，git，svn，亦或是其余一些源码管理服务；
- 构建触发器，以何种规则自动触发源码的构建（持续构建），若该项不作任何配置，则只能手动触发；
- 构建环境，本次也未作关键性修改；
- 构建，以何种方式构建，maven， gradle，亦或是其余；
- 构建后操做，成功构建以后的一些操做，持续交付/持续部署的操做主要放到这一块。

接下来分别较少这几项配置，以及用到的插件，已完成CI/CD的目标。git

1. General

本次并无作一些关键的修改

2. 源码管理

只说明git的一些相关配置，其余的源码管理服务同理

Repository URL： git上的源码地址
Credentials：用户名/密码
Branch Specifier：指定须要构建的分支
上边这些作完后其实基本上已经能够了，之因此修改Advanced clone behaiours，是防止第一次构建时拉取源码超时，默认超时时间为10minutes，屡次构建失败后，我把此处修改成了20minutes，若是依旧超时，可延长此处时间，或检查网络（点击Additional Behaviours旁边的add，选择Advanced clone behaiours）github
- Shallow clone，Shallow clone depth：浅拷贝，节省拷贝时间和磁盘空间

3. 构建触发器

实现触发构建的方式主要有定时触发、web hook触发，这些触发方式能够单独使用，也能够组合使用。

3.1 定时触发

Build periodically：周期性构建
Poll SCM：周期性检测，若源码有变化则构建
图中为每六小时检测一次web
- 搞清楚jenkins中“Poll SCM”和“Build periodically”的啥意思

定时构建部署，可控制频率

3.2 Gitlab Hook插件

　　web hook触发主要介绍gitlab hook插件，接下来咱们先保存已经完成的配置，回到首页，下载所需插件。
shell

　　可选插件中搜索gitlab，勾选列表中的GitLab Plugin和Gitlab Hook Plugin, 选择直接安装。待安装完成后回到首页，点击右边刚刚咱们建立的任务，而后点击配置回到咱们以前的配置页面。
tomcat

　　此时发现构建触发器中多了个选项：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。bash

Gitlab处须要增长的配置（设置-》集成，注意登陆帐户须要有相应权限）

随时提交，随时构建，快速相应开发人员的操做，但须要开发人员提交代码的时候确保提交可用，屡次commit一次push，除非紧急须要尽可能在午休时间，早上上班前，晚上下班后push代码
参考资料:Gitlab利用Webhook实现Push代码后的jenkins自动构建

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
```
<role rolename="manager-script"/>
<user username="caozeal" password="******" roles="manager-script"/>
```

![图片](https://github.com/caozeal/pictureStorage/blob/master/201803/Jenkins1.jpg?raw=true)

只是作上边这些配置的话，你会发现Jenkins的自动部署仅支持第一次，已有旧版应用运行时，自动部署会报undeploy失败，缘由是在应用运行时，tomcat会对应用的资源进行锁定，致使没法覆盖更新，这时需修改tomcat的另外一项配置：conf/context.xml（详情可查看Tomcat中antiResourceLocking和antiJARLocking的做用）

<Context antiJARLocking="true" antiResourceLocking="true">

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中，详细解决思路参考连接网络
- ssh链接远程主机执行脚本的环境变量问题
- 转：深刻了解bash与sh的区别

3、其余

至此已经完成了从开发人员push代码到应用构建、部署等相关操做的基本自动流程，具体细节部分还须要继续深刻研究探索
遗留问题：
- Jenkins构建的时候控制台乱码
  - 参考Jenkins控制台中文输出乱码解决方法处理
  - 解决以后，Jenkins启动的tomcat发生乱码
- 自动构建部署的时候，Jenkins调用命令启动StartTAS.sh的时候会一直监听启动日志，直到超时才断开连接，这时候因超时而致使本次构建为黄灯，即不稳定的构建