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

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

Jenkins eryajf 9个月前 (07-28) 3665℃ 已收录 11个评论
本文预计阅读时间 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方式进行回滚!


weinxin
扫码订阅,第一时间获得更新
微信扫码二维码,订阅我们网站的动态,另外不定时发送WordPress小技巧,你可以随时退订,欢迎订阅哦~

二丫讲梵 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明<二十>Jenkins实战应用–Jenkins回滚方案探微
喜欢 (5)
[如果想支持本站,可支付宝赞助]
分享 (0)
eryajf
关于作者:
学无止境,我愿意无止境学。书山有路,我愿意举身投火,淬炼成金!

您必须 登录 才能发表评论!

(11)个小伙伴在吐槽
  1. hello 博主,有一篇文章你介绍了 用git tag 给项目打标签,然后末尾写了git reset代码回滚。是不是对应着你者篇文章回滚方案的第一个呢?这种是不是不被推荐的?另外我想听下你的建议,回滚该选择哪个比较好,我深入研究下。望解答 。抱拳了
    https://wangtingwei.info2019-03-01 00:59 Windows 10 | Chrome 71.0.3578.80
    • eryajf
      早上看到消息了,结果一直在忙,忘记回复了,抱歉哈,用tag回滚是第四种方案,这种方案不推荐的原因是因为每次构建都会搭一个tag,然后次数多了以后,回滚的时候需要找这个tag,他那个参数界面又很不规律,所以就不被推荐了。至于生产当中,当然推荐第二种以及第三种方案了,这两种方案针对不同的项目,可有不同选择,比如你是前端项目,每次部署只需要更新静态文件即可,这种方式就适合第二种方案,而第三种其实是部署本次项目之前备份上次构建的包,如果回滚的话,直接将备份的上次的包拿过来部署即可,这种方案适用于java这样需要编译的项目,这样就省去重新编译的时间了,会比较快捷。你可以几种方案都体验一下,然后仔细揣摩几种方案的思路,慢慢就能熟练掌握并运用啦!
      eryajf2019-03-01 12:30 Windows 7 | Chrome 70.0.3538.9
      • 感谢 博主再午休时间还特意为我解答问题,回答的太仔细了 :wink: ,通过场景举例让我更好的理解了这三种方式去优缺点,我会都试试的,加深下理解 不过今天再看您博客上的git push 功能。又引出几个疑问需要请教下你:1.git publisher 插件可以自动给git 打tag,那么这个tag 我看有很多种,有的加一个字符参数构建,自己手动定义tag,有的是根据build id 变量 自动 来定义。我不太清楚实际场景该怎么选择。希望博主大大给我一个建议2.打tag的目的,是不是就是为了给参数化构建中,通过tag 选择来做铺垫呢?我在流程用了参数构建,给tag变量一个值,然后通过git publisher 定义了构建后操作 即“打包成功后 把包 push 到git仓库”。我在仓库tag处也确实看到了我的tag,点开后是我项目的war包。但是我不明白,下面是怎么个玩法。是为了再次参数化构建,拉取我指定tag的包来部署么?思路断了。。 :cry:
        https://wangtingwei.info2019-03-01 21:51 Windows 10 | Chrome 71.0.3578.80
        • eryajf
          关于第一个问题,其实根据哪个变量都是可以的,这个没有约束的。
          eryajf2019-03-01 22:26 Windows 7 | Chrome 70.0.3538.9
      • 呃。。博主,关于第二个疑问我做下补充:因为看了很多文章,打tag都是针对代码而言,然后这边参数化构建,选择对应的tag的代码进行部署。可是我再做git publish实验。打tag显示只能在构建后操作定义(也就是代码构建好后,包打好了)结果打的tag实际是给war包打的。所以懵了。。。。需要博主指点下 我哪个地方没理解对
        https://wangtingwei.info2019-03-01 22:09 Windows 10 | Chrome 71.0.3578.80
        • eryajf
          其实你研究的都对,这个地方怪我说的不够清楚,要搞明白Git ParameterGit Publisher这两个是不一样的,前边的是参数化构建的一个功能,后者则是针对构建后操作的,也就是构建之后,将本次构建的代码通过tag打到Gitlab里边去。如果有回滚的需求,那么只需要在Git Parameter处选择上次构建所打出的tag,然后构建,即可实现回滚的需求。
          eryajf2019-03-01 22:31 Windows 7 | Chrome 70.0.3538.9
          • 博主讲解的已经很到位了,特别棒!回答也特别及时。我会一直在本站和楼主一起学习进步,交流。只不过就算是官方文档也不可能面面俱到,因为每个人理解的方向有区别,指不定在哪就入坑了。呃。。。。。我看了博主刚才的回答,重新理解下 不知道对不对。1 .git parameter 实现的功能是让一套构建模板变得更加灵猴,让其支持选模式(部署还是回滚)和版本(tag)然后给脚本传参(拉取指定tag的代码,) 进而执行对应操作。而git publisher 是 给成品打标记。配合回滚操作。2. 如果回滚是用war包的方式,是不是就不需要git publish呢?还是说它还有其他的作用
            https://wangtingwei.info2019-03-01 22:44 Windows 10 | Chrome 71.0.3578.80
          • eryajf
            看到似你这般好学,也是非常难得(仿佛看到了求学时的我自己 :lol: ),我当然应该知无不言啦。其实这两个不必混淆在一起,参数化构建里边,git parameter算是其中一种,这是整个构建流程当中的参数化构建里边的一种而已,它不依赖所谓的git publisher,因为它还可以选择分支来作为参数变量,而git publisher纯粹是为了备份一下当次构建,之所以能运用到回滚,其实只是我的一种思路,事实上生产中很少这样用。所以你别被带偏了哈。
            eryajf2019-03-01 22:56 Windows 7 | Chrome 70.0.3538.9
          • 哈哈哈,这些问题我如果不问楼主,感觉自己理解跑偏的坑 得填好久;那代码的tag,这个tag是开发自己打对么,不用通过Jenkins被,协商一个约束后,他们每次提交代码打tag,然后我通过git parameter选择指定的代码版本构建。
            https://wangtingwei.info2019-03-02 00:17 Windows 10 | Chrome 71.0.3578.80
          • eryajf
            这个地方不必纠结过多,根据实际工作情况来用就好了,只要你理解了这里的原理,知道哪个地方是做什么的就好了
            eryajf2019-03-02 11:31 Windows 7 | Chrome 70.0.3538.9
          • 好的好的。谢谢啦。
            https://wangtingwei.info2019-03-02 13:54 Windows 10 | Chrome 71.0.3578.80