欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

Jenkins加Shell实现最简单的持续部署

程序员文章站 2022-05-13 18:51:15
...

参考跳转链接:

http://ju.outofmemory.cn/entry/29263

 

 

 

 

大量的有关持续集成的书籍与文档中,基本都提到了持续部署这个步骤,然而具体怎么实现,并没有通行的做法,对于典型的Java Web应用来说,大致有两个思路,一是通过web容器(如Tomcat、JBoss)提供的接口部署,这方面的代表就是Cargo,然而,其缺点是配置复杂且不够稳定,我的经验是,部署了很多次之后,容器的JVM就会内存溢出,当然这个和具体容器有关,部署多少次之后才溢出,也要看Web应用的大小。

第二种初看起来会更复杂的做法是自己写Shell脚本来停止容器、更新Web应用、然后再启动容器,其实,如果你懂点Shell,这种方法非常简单,而且这种方法非常稳定,因为每次直接杀JVM进程,直接避免了内存溢出的问题。以下是具体的步骤,以Jenkins和Tomcat为例:

1. 配置Jenkins的Build Job在完成之后Archive war文件备用

Jenkins加Shell实现最简单的持续部署
            
    
    博客分类: Java 持续集成jenkins shell ssh 

这样每次Build完之后,到对应的Job,如:http://10.12.136.115:8080/job/fileserver/lastSuccessfulBuild/artifact/my-app/target/my-app.war。

另一种方法是直接让Jenkins Build完了之后直接deploy到Nexus,之后就可以直接从Nexus获取了,细节这里就不解释了。

2. 编写部署脚本并测试

脚本的基本思路就是,看有没有容器在运行,如果有就kill掉,然后从Jenkins/Nexus下载最新的war文件,替换掉旧的,再启动容器,如:

#!/bin/bashexport JAVA_HOME=/usr/java

tomcat_pid=`/usr/sbin/lsof -n -P -t -i :9009`[-n "$tomcat_pid"]&& kill -9 $tomcat_pid

cd /home/admin/
mv myapp.war myapp.war.bak
wget http://10.12.136.115:8080/job/fileserver/lastSuccessfulBuild/artifact/my-app/target/my-app.war
rm /home/admin/apache-tomcat-7.0.40/webapps/myapp.war
rm -fr /home/admin/apache-tomcat-7.0.40/webapps/myapp
cp myapp.war /home/admin/apache-tomcat-7.0.40/webapps/myapp.war

cd /home/admin/apache-tomcat-7.0.40/bin/./startup.sh

为什么要export JAVA_HOME环境变量稍后解释。这里的的lsof命令根据tomcat监听的端口来获取其进程ID然后杀掉,其他命令基本一目了然。在部署机器上运行该脚本确保其能工作,然后提交到源码仓库里。

3. 建一个Jenkins Job专门做部署

建一个freestyle的Job,然后scm等配置也照常,当然,部署脚本要在scm仓库中,然后Jenkins的Build配置像这样:

Jenkins加Shell实现最简单的持续部署
            
    
    博客分类: Java 持续集成jenkins shell ssh 

这条命令就是通过ssh远程登陆到部署机器上运行部署部署脚本deploy.sh,-x参数让shell打印每一行执行的命令,-s则表示从标准输入读取要运行的脚本,这里重定向了我们的deploy.sh。(如何设置ssh key实现免密码登陆请自理)

需要注意的是,这种远程执行脚本的方式,属于非交互式Shell,不会触发诸如~/.bash_profile之类文件的载入,这也是我为什么在Shell脚本中export JAVA_HOME,这个环境变量本来是在~/.bash_profile中的,当然,你也可以直接source整个~/.bash_profile

最后,你可以通过Jenkins的Pipeline,使得当my-app Build成功之后,自动触发deploy这个任务,做到自动持续。

如果有多个应用,按照类似的方法创建多个Jenkins Job就可以了,由于Shell脚本是自己写的,不论什么容器都OK,有所放弃的是,由于要重启容器,相比直接通过容器接口部署,会稍微耗时些,但考虑到稳定性的大幅提高及配置的简化,我觉得还是值得的。