|
大量的有关持续集成的书籍与文档中，基本都提到了持续部署这个步骤，然而具体怎么实现，并没有通行的做法，对于典型的Java Web应用来说，大致有两个思路，一是通过web容器（如Tomcat、JBoss）提供的接口部署，这方面的代表就是Cargo，然而，其缺点是配置复杂且不够稳定，我的经验是，部署了很多次之后，容器的JVM就会内存溢出，当然这个和具体容器有关，部署多少次之后才溢出，也要看Web应用的大小。 第二种初看起来会更复杂的做法是自己写Shell脚本来停止容器、更新Web应用、然后再启动容器，其实，如果你懂点Shell，这种方法非常简单，而且这种方法非常稳定，因为每次直接杀JVM进程，直接避免了内存溢出的问题。以下是具体的步骤，以Jenkins和Tomcat为例： 1. 配置Jenkins的Build Job在完成之后Archive war文件备用
这样每次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/bash export 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配置像这样：
这条命令就是通过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，有所放弃的是，由于要重启容器，相比直接通过容器接口部署，会稍微耗时些，但考虑到稳定性的大幅提高及配置的简化，我觉得还是值得的。 |
|
|
