当前位置 博文首页 > yzwine：Jenkins自动部署spring boot
本公司属于微小型企业，初期业务量不高，所有程序都写在一个maven项目里面，不过是多模块开发。
分了login模块，service模块，cms模块。
我们初期部署的是两台服务器，使用nginx把http请求分发到两台服务器上，每次需要发布新功能的时候，都是手动打包上传：
1.mvn clean install -Dmaven.test.skip=true（生成好几个jar包）
2.上传（两台服务器上传，总共6个jar包）
3.重新启动(虽说写了脚本，但还是要手动敲命令./restart 回车)。
起初，两台服务器还行，也没闲太麻烦，但是有一天做活动，考虑到业务量上升，需要把服务器扩到6台（当时我的内心是拒绝的，然并卵），还手动上传jar这种方式，那岂不是究极打工仔么，我自动部署一搞，岂不美滋滋？
说干就干，让运维把jenkins部署起来，我就开始搞自动部署了。
1.选择新建任务
2.输入任务名称，并选择构建一个maven项目，确定。
如果没有maven选项，可以在系统管理->插件管理->可选插件，搜索 Maven Integration plugin 下载安装，需要重启生效。
General是构建任务的一些基本配置。名称，描述之类的，这里调重点来讲。
项目名称: 是刚才创建构建任务步骤设置的，当然在这里也可以更改。
描述: 对构建任务的描述。
丢弃旧的构建： 服务器资源是有限的，有时候保存了太多的历史构建，会导致Jenkins速度变慢，并且服务器硬盘资源也会被占满。当然下方的"保持构建天数" 和 保持构建的最大个数是可以自定义的，需要根据实际情况确定一个合理的值。
其他几个选项在这里不做介绍，有兴趣的可以查看Jenkins"帮助信息"， 会有一个大概的介绍。不过这些"帮助信息"都是英文的。
参数化构建过程选择选项参数和字符参数。
选项参数名称输入Status，选项输入Deploy、Rollback。
Deploy：发布最新版本
Rollback：版本回滚
字符参数名称输入Version，这个的值是用来版本回滚用的。
源码管理就是配置你代码的存放位置。
Git: 支持主流的github 和gitlab代码仓库。因我们的研发团队使用的是gitlab，所以下面我只会对该项进行介绍。
Repository URL：仓库地址
Credentials：凭证。可以使用HTTP方式的用户名密码，也可以是RSA文件， 但要通过后面的"ADD"按钮添加凭证（不懂的可以百度）。
Branches to build：构建的分支。*/master表示master分支，也可以设置为其他分支。
构建触发器，顾名思义，就是构建任务的触发器（具体我也没用到，一下是百度来的，可以看看）。
触发远程构建(例如，使用脚本): 该选项会提供一个接口，可以用来在代码层面触发构建。
Build after other projects are built： 该选项意思是"在其他projects构建后构建"。
Build periodically： 周期性的构建。很好理解，就是每隔一段时间进行构建。日程表类似 linux crontab书写格式。
Poll SCM：该选项是配合上面这个选项使用的。当代码仓库发生改动，jenkins并不知道。需要配置这个选项，周期性的去检查代码仓库是否发生改动。
构建环境就是构建之前的一些准备工作，如指定构建工具(这里也没有用到，感兴趣的可以研究一下)。
编译前预处理步骤，我这边用于版本回滚。选择执行shell
输入以下文本
case $Status in
Rollback)
echo "-----本次操作为回滚,版本号为$Version-----"
git reset --hard $Version
echo "-----回滚完成,打包中-----"
;;
*)
exit
;;
esac
打包命令，如果编译的时候需要其他参数，可以加在后面。
build的后置工作，选择Run only if build succeeds（这里选择的是第二个），在bulid成功后才会执行此操作
由于编译完成的jar包要发布到其他的服务器上，这里选择Send files or execute commands over SSH（如果没有的话，请去插件管理中下载）。
**SSH Server ** 传输配置
name 传输的服务器（在系统配置的SSH Servers中配置，只需把jenkins服务器生成的id_rsa.pub放到传输的服务器上就行了，详情请百度）
Transfer 传输信息
? Source file：需要scp到远程服务器的构建jar（如：target/yzwine-0.01.jar）
? Remove prefix：移除掉构建jar的前缀（如：target/）
? Remote directory：scp到远程服务器的目录（如：/usr/local/web）
? Exec command：scp完成之后，执行的脚本命令（如：cd /usr/local/web && ./restart）最好进入文件夹执行，不要/usr/local/web/restart这样执行，很容易出问题
没有用到，不做详解
没用到，不做详解
如果直接发布，不用填写version，直接开始构建就好了，如果需要回滚，输入git上的commit_id，可以构建某个时刻的jar包
由于需要6台重新发布，准备在Post Steps这一步配置6台服务器传输部署，但是测试的时候就有问题。
先是配置了一台，从构建到发布需要3分钟（Jenkins服务器是上海阿里云，正式jar运行服务器是香港亚马逊的），初步一算，六台就要18分钟，如果发布login、service、cms，就要54分钟??。。。
自动构建太慢的主要问题是传输太慢，而6台服务器是属于同一个内网的，那完全可以上传到一台服务器之后，这台服务器通过内网scp传输，那速度肯定是噶快噶快的。
#循环传输jar并重启服务，针对每个服务器第一次可能需要输入yes，后面都不需要了
#! /bin/sh
for i in 172.31.20.113 172.31.22.210 172.31.25.202 172.31.19.108 172.31.20.205 #内网地址
do
expect -c "
spawn scp -r /usr/local/web/test-0.0.1-SNAPSHOT.jar root@$i:/home/
expect {
\"*assword\" {set timeout 20; send \"123456\r\"; exp_continue;} #123456是传输密码
}
expect eof"
sleep 1
ssh root@$i 'cd /home && ./restartJar.sh' #进入目录，重启服务命令
done
果然，这样处理之后，部署时间就很快了（100M的jar几乎是秒传），基本上3分钟就能部署好，如果还要加服务器的话，在内网地址里面加就好了。
很多时候，需要转换思路，不一定需要配置多个server上传，最终目的达到就行了。
当然，这个过程中少不了运维同事的配合，有一群志同道合的同事是真的很重要??。
