• 对于注定会优秀的人来说,他所需要的,只是时间----博主
  • 手懒得,必受贫穷,手勤的,必得富足----《圣经》
  • 帮助别人,成就自己。愿君在本站能真正有所收获!
  • 如果你在本站中发现任何问题,欢迎留言指正!
  • 本站开启了防爆破关小黑屋机制,如果您是正常登录但被关进小黑屋,请联系站长解除!

<二十>Jenkins实战应用–Jenkins回滚方案探微

Jenkins eryajf 3个月前 (07-28) 1996°C 已收录 0个评论
本文预计阅读时间 9 分钟

*系列汇总*

这是一个系列文章,大大小小到今天惊然发现竟然已经累计二十篇了,也就不得不做一个小汇总。回想当初写第一篇文章的时候,就已经决心事无巨细,一应认真的走下来,回头遮望,看着皇皇这么多文章,一股强烈的成就感就此油然而生,于是便有了这些汇总整理。在这个过程当中,好像也帮助过不少的人,这是让我尤其开心的事情,同时也结识了一些志同道合的朋友,再没有比这更让人觉得愉悦的事情啦!也希望以后写出更多类似的系列文章。

文章汇总地址如右:Jenkins 入门教程。

如果相中哪个,点击进去便是。希望正在读这段话的你能够在这个小系列中获得自信以及喜悦!

当程序员确认可以发布版本,在由运维人员发布成功之后,测试人员发现刚刚发布版本有问题时,严重的,则需要进行回滚操作了。

对于程序员以及领导来说,回滚只不过是线上业务出现问题的时候一句话而已,但是对于运维人员来说,回滚则是平时就要做好准备的事情,不仅要做好准备,更要有经过演练。

我就曾有过自以为脚本方面都是梳理完整了放进 Jenkins 里,突然一天领导那边说需要回滚一下子,我当然觉得没有问题咯,于是兴致勃勃的跑去进行了回滚的操作,最后却发现,压根儿就没有成功,这就非常尴尬啦,顿时就脸红脖子粗起来,脖子粗也没用呀,问题总还要解决,于是最后只得手动打包,进行了一次原始部署了。

因此,回滚是一件闲时准备,战时不慌的操作,非常重要了。

我这里提到的回滚,都是基于 Jenkins 来进行部署考虑的,通过我个人对 Jenkins 的理解,大致分有以下方法可供选择:

1,gitlab 代码回滚。

由程序员先将 Git 的版本回退到上一个版本,然后再一次进行部署。就实现了上个版本回退。

但是这种情形很容易受到影响,如果过程中有其他人进行过提交,版本不容易定位,如果牵扯到一些数据库的问题,就更加复杂,极有可能出现一些无法控制的问题,因此这是一种十分不推荐也不可取的方式。但是据我了解到一些公司就曾采用过这种方式来进行回滚的操作,想起来也是十分让人难以理解的。

好了废话不多说,进入今天正题。

2,脚本方式回滚。

在 Jenkins 部署脚本当中加入 git rev-parse HEAD 命令记录每次发布的版本的唯一版本号,并将此记录在一个log文件里,如果需要回滚,则由脚本取出上一次发布的版本号(命令为:tail -n 2 version.log | head -n 1)进行版本的回退,而后在回退的基础上再发布即可。

这是一种非常保险,也绝对靠谱的一种方式了,非常非常推荐。

唯一的缺点,大概可能就是需要重新部署一次有点耗时间,对于某些高访问量(时间就是金钱)的线上业务来说,显得有点耽误工夫了。

具体的这种回滚方式的相关脚本以及思路的参考,我在另一篇文章当中已经写出,可以点击这里进行跳转浏览

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

因为这个脚本是一个最后环节的,所以我简单说明一下:

1,脚本承接 Jenkins 处传递过来的两个参数,一个是 mode 的值,一个是 project 的值,mode 决定是部署还是回滚,project 则决定了是对哪个项目进行操作。
2,部署的时候,先将上次备份的 bak 包放进一个专门存放 old 包的目录下,将正在用的包备份成 bak 包,然后进行常规的部署。
3,如果回滚,则直接将 bak 还原回来,即达到回滚目的。

这种简洁高效,非常好用。只要在部署的时候将对应的包进行很好的安置,事情都会非常好处理的。当然了,还少一个定期清理目录下包数量的脚本,别急,您可以参考我的另外一篇文章:如何让不断增加的目录只保留五个文件?

4,tag 回滚。

这种回滚方案配置非常简单,而且实用性也非常强,已经在另外一篇文章中进行发布,如需浏览,可以点击跳转:Jenkins 利用 tag 方式进行回滚!


二丫讲梵 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明<二十>Jenkins 实战应用–Jenkins 回滚方案探微
赞赏
喜欢 (1)or
[如果想支持本站,可支付宝赞助]
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
×
订阅图标按钮