Jenkins 自动部署+回滚方案(初级阶段)

发布于 2019-03-05  214 次阅读


[dangerbox title="Jenkins 自动部署+回滚方案(初级阶段)"][/dangerbox]

前言

前面陆陆续续演示了jenkins的安装,job的配置,多种参数化构建,邮件通知,publish推送等功能,但是没有演示项目构建成功后发布,以及紧急回滚的操作。那么今天我将和大家一起学习下整个流程。

规范约束

因为Jenkins自动化想要很好的落地实现,就需要各个部门配合实现规范约束,比如maven项目中,每个版本的pox.xml中的version 格式,如果是动态变化的,那么每次打包后,包的名字是以version定义的命名,也是动态变化的.我们在脚本中会涉及对包的操作,比如移动包到部署站点目录。此时需要去匹配这个动态的名字,设立标准后,能够让动态的信息维持在稳定规则的变化中。

我的标准:

要求开发者pom.xml中version的版本号 和打的tag号一致,在jenkins中不同项目配置不同的job,以名字进行区分。比如pom.xml中version 是wds-1.0.0, 此时打包名字为wds-1.0.0.war(wds为项目名,1.0.0是项目版本) ,tag 号为1.0.0,使用jenkins构建时。选取对应项目的Job,然后通过Parameter拉取对应 tag (1.0.0)的代码,构建后将包移动到tomcat 发布目录。重启生效。

规划与准备

1.规划

  • 192.168.137.99   远程web发布站点,包含俩个tomcat实例(port 8888和8889)
  • 192.168.137.103   jenkins服务器
  • 官网gitlab服务器作为gitlab远程仓库(为了方便,gitlab搭建很简单,但是最少需要2G内存)

2.准备

  • jenkins安装以及相关配置,插件都已准备好,参看我之前的文章
  • git客户端上给两个不同版本的项目打tag,分别为1.0.0 和2.0.0并push到gitlab仓库】
  • 提前准备好tomcat服务器(最好多实例,生产环境可能会发布多实例。)

原理:

  • 通过Git parameter我们构建时可以获取到gitlab仓库上项目的tag,并且自定义变量(如tag)与仓库tag对应,从而实现选择tag构建项目,并且部署脚本配合tag也能实现回滚和部署
  • 通过选项型参数实现模式的选择,部署模式还是回滚。通过字符型参数增加其他变量,让构建更灵活
  • 打包成功后,部署与回滚功能则依赖于脚本。而脚本则依赖前面配置的各种变量。

总结:jenkins完成的功能主要是拉取代码,构建打包。配置变量。信息通知等。而部署与回滚的核心是脚本。需要将Jenkins配置的变量作为参数传递到脚本中。二者协同合作完成整个自动化发布流程。

功能

  • 拉取指定tag代码构建
  • 支持deploy 和rollback两个模式
  • 支持选择部署到哪个实例(通过端口号作为变量进行选择)
  • 其他功能(构建成功可以推送到远程仓库打tag(配合其他回滚方案),钉钉通知。163邮件通知。构建信息时间戳 )

部署

  • gitlab已经提交好两个tag的项目。

  • GitParameter配置

choice 参数配置

  • 字符参数配置

备注:通过配置也发现了,如果想要job变得灵活,无非就是把原来固定的值给变量化,也就是说在参数化构建中定义多个参数,然后修改脚本,与脚本配合实现功能。

  • git仓库配置

注意:由于我们用了GitParameter,此时需要添加 Branches to bulid 来告诉jenkins我拉取的代码是根据$tag变量,而不是默认得 */master,如果使用的是 */master,这样无论构建选择哪个tag或者branch,最终拉取得还是master代码

  • 脚本配置

#!/bin/bash
#描述: jenkins 自动部署/回滚脚本
#作者: 王庭威
#时间: 2019 3/4
#################################################################
catalina_home=/usr/local
tag=$1
model=$2
project_port=$3
webapps=$catalina_home/tomcat_$project_port/webapps
back_dir=/home/backup
ssh_war_dir=/home/data
war_name=ROOT.war
version_log_file=$ssh_var_dir/version.log
source /etc/profile
echo "正在构建$tag版本的代码,需要判断模式."
echo "当前模式是$model"
echo "操作实例tomcat_$project_port"
echo "$tag" >>$version_log_file
test -d $back_dir ||mkdir $back_dir
deploy()
{
if [ -f "$webapps/$war_name" ];
then echo "站点已存在ROOT.war,开始备份当前ROOT.war到$back_dir,并部署新的war包" &&
mv $webapps/$war_name $back_dir/ && mv $ssh_war_dir/wds211-0.0.1-SNAPSHOT.war $webapps/ROOT.war
else
echo "当前站点不存在ROOT.war,开始第一次部署" && mv $ssh_war_dir/wds211-0.0.1-SNAPSHOT.war $webapps/ROOT.war
fi
echo "重启tomcat" &&service tomcat_$project_port restart
/usr/sbin/lsof -i:$project_port && echo "tomcat_$project_port 服务重启成功"
}

rollback () {
if [ ! -f $webapps/$war_name ];
then echo "不存在war包,请执行部署" && echo "清理已传送的war包" && rm -rf $ssh_war_dir/wds211-0.0.1-SNAPSHOT.war
exit 7
else
echo "tomcat_$project_port 正在执行回滚操作"
rm -rf $webapps/ROOT.war && mv $back_dir/ROOT.war $webapps/
echo "清理已传送的war包" && rm -rf $ssh_war_dir/wds211-0.0.1-SNAPSHOT.war
fi
echo "重启tomcat" && service tomcat_$project_port restart
/usr/sbin/lsof -i:$project_port && echo "tomcat_$project_port 服务重启成功"
}
##################################
case "$2" in
'deploy')
deploy
;;
'rollback')
rollback
;;
*)
echo "Usage: $0 {deploy | rollback}"
exit 1

  • 验证效果

测试1 :webapp无war包,代码1.0.0,模式为deploy, 部署到tomcat_8888实例

1.为了直观,首先清空了tomcat两个实例的web站点。

2.首先部署1.0.0版本的代码,模式是deploy,tomcat主机是8888端口,可以手动输入其他端口

  • 构建信息输出

  • 查看tomcat_8888实例是否发布成功

 

测试2 :发布2.0.0版本。

  • 构建信息输出

  • 访问tomcat_8888 实例2.0.0版本网页

测试3:回滚到1.0.0版本

 

  • 这里tag选取哪个都可以,构建的包在脚本直接删除了。不会部署。但是执行回滚本身就不应该去构建包了。这里我是由于集成了到一起了。可以单独把回滚放一个job中

  • 构建信息输出

  • 查看tomcat_8888页面是否回滚

备注:

1.构建时候选取不同端口号部署到对应实例的功能也测试了。

2.如果本身站点无war包却执行回滚操作,会提示失败(已在脚本定义了该功能),也已经测试了。

 

 

 

 

 

 

 


一个幽默,喜欢动漫,音乐,爱小动物,逐渐成为二次元肥宅的LINUX运维工程师,我会用心写博客,刚开始写的不太好。但是我会不断进步的!。就像我的博客下面写的。我宁愿做错,也不愿什么都不做 ps:好像是伊泽瑞尔说的,看来你游戏没少玩啊 23333333333333