Jenkins回滚方案探微
当程序员确认可以发布版本,在由运维人员发布成功之后,测试人员发现刚刚发布版本有问题时,严重的,则需要进行回滚操作了。
对于程序员以及领导来说,回滚只不过是线上业务出现问题的时候一句话而已,但是对于运维人员来说,回滚则是平时就要做好准备的事情,不仅要做好准备,更要有经过演练。
我就曾有过自以为脚本方面都是梳理完整了放进 Jenkins 里,突然一天领导那边说需要回滚一下子,我当然觉得没有问题咯,于是兴致勃勃的跑去进行了回滚的操作,最后却发现,压根儿就没有成功,这就非常尴尬啦,顿时就脸红脖子粗起来,脖子粗也没用呀,问题总还要解决,于是最后只得手动打包,进行了一次原始部署了。
因此,回滚是一件闲时准备,战时不慌的操作,非常重要了。
我这里提到的回滚,都是基于 Jenkins 来进行部署考虑的,通过我个人对 Jenkins 的理解,大致分有以下方法可供选择:
# 1,gitlab 代码回滚。
由程序员先将 Git 的版本回退到上一个版本,然后再一次进行部署。就实现了上个版本回退。
但是这种情形很容易受到影响,如果过程中有其他人进行过提交,版本不容易定位,如果牵扯到一些数据库的问题,就更加复杂,极有可能出现一些无法控制的问题,因此这是一种十分不推荐也不可取的方式。但是据我了解到一些公司就曾采用过这种方式来进行回滚的操作,想起来也是十分让人难以理解的。
好了废话不多说,进入今天正题。
# 2,脚本方式回滚。
在 Jenkins 部署脚本当中加入git rev-parse HEAD
命令记录每次发布的版本的唯一版本号
,并将此记录在一个log
文件里,如果需要回滚,则由脚本取出上一次发布的版本号(命令为:tail -n 2 version.log | head -n 1
)进行版本的回退,而后在回退的基础上再发布即可。
这是一种非常保险,也绝对靠谱的一种方式了,非常非常推荐。
唯一的缺点,大概可能就是需要重新部署一次有点耗时间,对于某些高访问量(时间就是金钱)的线上业务来说,显得有点耽误工夫了。
具体的这种回滚方式的相关脚本以及思路的参考,我在另一篇文章当中已经写出,可以点击这里进行跳转浏览 (opens new window)。
# 3,war 包回滚。
在每一次发布部署的同时,将每一个部署的(JAVA)war 包按时间进行备份,然后再备份一个紧邻的上次发布的 bak 包,如果需要紧急回滚,则直接将上一个包替换当前包即可。由于一般回滚不会回滚到很久以前的版本,所以这里的备份包,保留五个即可,多余的利用脚本进行删除,避免了时间长占用空间过大的问题。
思路基本如上,我这里列出一个简单脚本仅供参考。
#!/bin/bash
#author:eryajf
#time:2018-7
source /etc/profile
mode=$1
project=$2
code_dir=/root/project/$project
tomcat_dir=/usr/local/tomcat_$project
ROOTWAR_dir=$tomcat_dir/WAR
bakdir=$tomcat_dir/bak_dir
MAVEN_CODE(){
cd /root/project/$project
mvn clean install -Dmaven.test.skip=true
[ $? -ne 0 ] && echo -e '\033[31m[ error ] Failed to maven the code\033[0m' && exit 1
[ -d $tomcat_dir/WAR ] && mkdir -p $tomcat_dir/WAR
cp $code_dir/51fbadmin-web/target/ROOT.war $tomcat_dir/WAR
}
deploy()
{
echo "MAVEN_CODE"
MAVEN_CODE
[ ! -d $bakdir ] && mkdir -p $bakdir
echo "backup"
[ -f $ROOTWAR_dir/ROOT.war ] && [ -f $tomcat_dir/webapps/ROOT.war ] && mv $tomcat_dir/webapps/ROOT.warbak $bakdir/ROOT_$(date +"%y%m%d%H%M%S").war
mv $tomcat_dir/webapps/ROOT.{war,warbak}
echo "stop tomcat_$project" && ps aux | grep "$tomcat_dir" | grep java | grep -v grep | awk '{print $2}' | xargs kill -9
rm -rf $tomcat_dir/webapps/ROOT && mv $ROOTWAR_dir/ROOT.war $tomcat_dir/webapps
echo "start tomcat_$project" && /bin/bash /usr/local/tomcat_$project/bin/startup.sh
}
rollback(){
echo "stop tomcat_$project" && ps aux | grep "$tomcat_dir" | grep java | grep -v grep | awk '{print $2}' | xargs kill -9
rm -f $tomcat_dir/webapps/ROOT.war && rm -rf $tomcat_dir/webapps/ROOT
mv $tomcat_dir/webapps/ROOT.{warbak,war}
echo "start tomcat_$project" && /bin/bash /usr/local/tomcat_$project/bin/startup.sh
}
case "$1" in
'deploy')
deploy
;;
'rollback')
rollback
;;
*)
echo "Usage: $0 {deploy | rollback}"
exit 1
esac
exit 0
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
因为这个脚本是一个最后环节的,所以我简单说明一下:
1,脚本承接 Jenkins 处传递过来的两个参数,一个是 mode 的值,一个是 project 的值,mode 决定是部署还是回滚,project 则决定了是对哪个项目进行操作。 2,部署的时候,先将上次备份的 bak 包放进一个专门存放 old 包的目录下,将正在用的包备份成 bak 包,然后进行常规的部署。 3,如果回滚,则直接将 bak 还原回来,即达到回滚目的。
这种简洁高效,非常好用。只要在部署的时候将对应的包进行很好的安置,事情都会非常好处理的。当然了,还少一个定期清理目录下包数量的脚本,别急,您可以参考我的另外一篇文章:如何让不断增加的目录只保留五个文件? (opens new window)
# 4,tag 回滚。
这种回滚方案配置非常简单,而且实用性也非常强,已经在另外一篇文章中进行发布,如需浏览,可以点击跳转:Jenkins 利用 tag 方式进行回滚! (opens new window)