服务器配备:
Jenkins | 192.168.96.26 |
---|---|
Gitlab | 192.168.96.27 |
Nexus | 192.168.96.28 |
MySQL | 192.168.96.29 |
Test Tomcat | 192.168.96.17 |
现在需要在要操作的服务器上做一些准备工作
- 1, 将Jenkins的秘钥拷贝到Git服务器,以使其在拉取代码的时候免密码操作。
- 2, 将Jenkins的秘钥拷贝到testtomcat服务器,以使其在同步等操作的时候免密码。
- 3, 在test tomcat 服务器添加与mysql的连接。我们公司是将mysql的ip写入到了test tomcat服务的hosts里边了。
- 4, 设置Jenkins上的maven与nexus的连接。
vim /usr/local/maven/conf/settings.xml
接着还需要将maven像jdk那样把环境写入到系统配置当中,不然等会儿编译可能会报错。
vim /etc/profile
在最底下添加。
# maven所在的目录
export M2_HOME=/usr/local/maven
export M2=$M2_HOME/bin
export PATH=$M2:$PATH
配置开始
来到Jenkins界面中。
输入项目的名称,选中构建一个自由风格的项目。
也可以在最低下复制其他的项目名称,直接copy其他的项目的配置,这样会省去很多相同的操作,非常nice。
点击确定,进行下一步
选择参数化构建过程,这里都是拿干货来说了,其他不重要的,可以自己进行测试着玩。 最后配置出来是这个样子
基本上这样就能够满足测试之需求了,注意这里边的名称都是可以作为参数进行传递的。一般项目都是有部署与回滚的功能,而在部署当中,添加一个Git分支的选择,这对于开发来讲,是非常必要的。
接下来是代码管理
我们这里用的是Git代码库,首先把项目的链接复制过来,然后需要添加一个能够登陆的用户,下边add添加一个就行,如果这个地方总是返回128错误,应该是Jenkins添加秘钥到Git了,但是还没有进行过登陆的确认,这个时候到服务器上进行一次代码的clone,然后就会看到这个地方的报错消失了。
这个时候,先不做其他任何操作,我们直接保存设置,然后进行一次构建看看再说。
点击进去
如果是第一次构建,那么这个地方会从nexus库当中下载很多需要的依赖包,但是这些并不是我想展示出来看的,真正想看到的是,Jenkins会在自己的工作目录当中创建这样一个项目,然后将所有的代码给拉取过来,随后进行编译的动作。
这个就是刚刚创建的项目名称,进去之后就能看到源代码了。 源码当然是不能看咯,不过现在可以把目光拉到Jenkins刚才的构建界面来。
这个构建项目需要依赖于antx.properties这个配置文件但是第一次构建还没有这个文件,因此会提示让更新一下,而Jenkins的web界面又是不提供这种交互功能的,于是来到服务器上进行编译并更新。(注意,以后如果开发人员再次对这个文件更新或者更改,部署的时候可能还会出现这样的情况,会一直提示让选择更新,却又选择不了,于是,需要告知开发人员,遇到这种情况,立马叉掉停止构建。)
到服务器上进入刚才的项目目录执行下边命令
mvn clean install -Dmaven.test.skip=true
稍等一会儿,会提示让更新:
输入y q y就行了,然后会保存在root目录下,如下图中所展示:
接着就会看到编译成功的界面
注意:现在这种操作逻辑呢,是Jenkins将代码从Git服务器拉去到Jenkins服务器上,然后在Jenkins服务器本机上进行编译的操作,比较建议这样的操作,因为Jenkins服务器相对于那些可能有四五个tomcat在跑着的服务器来说,压力会小很多很多,因此建议在Jenkins编译然后将war包同步到测试服务器。
编译完成之后,会在相应的目录下边生成一个war包,具体是什么目录,则由开发人员在代码当中定义的,不过一般规范化的话,会在web/target下
那么,再将这个包拷到测试服务器对应目录下,重启tomcat不就行了,事实上就是这样的,现在我们回到Jenkins的web界面来将这些事儿给完成了。
在构建界面找到Execute shell,可能上级目录略有不同,但是找到这个就对了,将构建的脚本进去。脚本内容如下:
#!/bin/bash
#git checkout new_website_dev_20160430
#git pull
#mvn clean package -Dmaven.test.skip=true
APP_DIR=/usr/local/tomcat/WAR #注意这个目录对方服务器(也就是test tomcat服务器)默认没有,需要创建
function MVN-SCP(){
chattr +i /root/antx.properties
cd $WORKSPACE
mvn clean install -Dmaven.test.skip=true
chattr -i /root/antx.properties
scp $WORKSPACE/web/target/ROOT.war root@192.168.96.17:$APP_DIR/
[ $? -ne 0 ] && echo -e '\033[31m[ error ] Failed to scp the ROOT.war\033[0m' && exit 1
sleep 1
}
function deploy()
{
echo "MVN & SCP"
MVN-SCP
sleep 3
ssh root@192.168.96.17 "echo "调用部署" && /usr/local/scripts/deploy.sh $mode"
}
function rollback()
{
ssh root@192.168.96.17 "echo "调用部署" && /usr/local/scripts/deploy.sh $mode"
}
case $mode in
deploy)
deploy
;;
rollback)
rollback
;;
*)
echo $"Usage: $0 {deploy|rollback}"
exit 1
;;
esac
这里的脚本主要就是完成两件事情,首先把本地拉取的代码进行编译,然后把编译好了的war包传到远程tomcat服务器,接着调用远程服务器的部署脚本(这个脚本下边会列出),这些操作都并不复杂,如果对Linux服务器所有目录结构以及shell脚本熟悉的话。更多的,则就是细心的配置了,很多时候出问题,基本上都是变量不统一或者脚本调用有误。
刚才说了部署的时候调用了一下远程的部署脚本,那么在远程服务器上的脚本是怎样的呢,是这样的:
#!/bin/bash
source /etc/profile
tomcat_dir=/usr/local/tomcat
bak_dir=$tomcat_dir/WAR_backup
date=$(date +"%Y%m%d%H%M%S")
stop_tomcat(){
ps aux |grep tomcat|grep -v grep|awk '{print $2}'|xargs kill -9
}
start_tomcat(){
/bin/bash $tomcat_dir/bin/startup.sh
}
deploy(){
echo "stop_tomcat"
stop_tomcat
echo "backup_war"
[ ! -d $bak_dir ] && mkdir -p $bak_dir
cp $tomcat_dir/webapps/ROOT.war $bak_dir/ROOT_$(date +"%y%m%d%H%M%S").war && \mv $tomcat_dir/webapps/ROOT.{war,warbak}
echo "rm -rf $tomcat_dir/webapps/ROOT"
rm -rf $tomcat_dir/webapps/ROOT && mv $tomcat_dir/WAR/ROOT.war $tomcat_dir/webapps/
sleep 2
echo "start_tomcat"
start_tomcat
sleep 10
}
rollback(){
echo "stop_tomcat"
stop_tomcat
sleep 2
echo "rollback"
rm -f $tomcat_dir/webapps/ROOT.war && rm -rf $tomcat_dir/webapps/ROOT
cp $tomcat_dir/webapps/ROOT.{warbak,war}
echo "start_tomcat"
start_tomcat
sleep 10
}
case "$1" in
'deploy')
deploy
echo "deploy success!!!"
;;
'rollback')
rollback
echo "rollback success!!!"
;;
*)
echo "Usage: $0 {deploy | rollback}"
exit 1
esac
而这个脚本的内容也是非常简单的,无论是部署还是回滚,都首先把服务停掉,然后进行war的对应操作,最后再启动服务。
如果说这个地方tomcat启动失败。那么就从前往后一步一步捋,先看Jenkins构建是否正常,然后再看tomcat启动日志,数据库连接是否正常,相关的环境配置是否妥当。
需要注意一点:
这个脚本放置的位置需要与上一个脚本里边指向的位置(/usr/local/scripts
)以及名称(deploy.sh
)相同。
当然,这个地方的两个小脚本,只是作为一个示例来讲解出利用脚本与Jenkins的配合,实际生产还应该结合自己环境情况进行不同的调整。
那么,整个一系列的部署就是这个样子的。