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部署起来，我就开始搞自动部署了。

jenkins配置

新建任务

1.选择新建任务

2.输入任务名称，并选择构建一个maven项目，确定。

如果没有maven选项，可以在系统管理->插件管理->可选插件，搜索 Maven Integration plugin 下载安装，需要重启生效。

General

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并不知道。需要配置这个选项，周期性的去检查代码仓库是否发生改动。

构建环境

构建环境就是构建之前的一些准备工作，如指定构建工具(这里也没有用到，感兴趣的可以研究一下)。

Pre Steps

编译前预处理步骤，我这边用于版本回滚。选择执行shell

输入以下文本

case $Status  in

  Rollback)

    echo "-----本次操作为回滚,版本号为$Version-----"

    git reset --hard $Version

    echo "-----回滚完成,打包中-----"

    ;;

  *)

  exit

      ;;

esac

Build

打包命令，如果编译的时候需要其他参数，可以加在后面。

Post Steps

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包

后续问题

jenkins传输问题

由于需要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/xinxin-live-app-0.0.1-SNAPSHOT.jar xinxin@$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上传，最终目的达到就行了。

当然，这个过程中少不了运维同事的配合，有一群志同道合的同事是真的很重要。