手把手教你用 Jenkins 自动部署 SpringBoot

文章目录

• ​​1. 什么是 CI/CD​​

• ​​1.1 CI（Continuous Integration）​​
• ​​1.2 CD（Continuous Delivery/Continuous Deployment）​​

• ​​2. 什么是 Jenkins​​
• ​​3. 准备工作​​

• ​​3.1 整体规划​​
• ​​3.2 准备代码​​
• ​​3.3 准备服务器​​

• ​​4. 搭建 Jenkins​​
• ​​5. 安装插件​​
• ​​6. 配置 Jenkins​​

• ​​6.1 基本的环境配置​​
• ​​6.2 JDK​​
• ​​6.3 Maven​​
• ​​6.4 Git​​
• ​​6.5 远程的凭证配置​​

• ​​6.5.1 应用服务器信息​​
• ​​6.5.2 Gitee 的信息​​

• ​​7. 开始一个项目的构建​​
• ​​8. 自动构建​​

• ​​8.1 修改 Jenkins​​
• ​​8.2 配置 Webhook​​

• ​​9. 小结​​

1. 什么是 CI/CD

CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。

CI/CD 的核心概念可以总结为三点：

• 持续集成
• 持续交付
• 持续部署

CI/CD 主要针对在集成新代码时所引发的问题（俗称"集成地狱"）。

为什么会有集成地狱这个“雅称”呢？大家想想我们一个项目部署的过程，​​拉取代码->构建->测试->打包->部署​​，如果我们经常需要部署项目，特别是在微服务时代，服务特别多的情况下，不停的测试打包部署，那估计得有个人一整天专门做这事了，而这事又是繁琐的重复无意义的。

具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署），这些关联的事务通常被统称为"CI/CD 管道"，由开发和运维团队以敏捷方式协同支持。

1.1 CI（Continuous Integration）

CI/CD 中的"CI"始终指持续集成，它属于开发人员的自动化流程。成功的 CI 意味着应用代码的新更改会定期构建、测试并合并到代码仓库中，该解决方案可以解决在一次开发中有太多应用分支，从而导致相互冲突的问题。

1.2 CD（Continuous Delivery/Continuous Deployment）

CI/CD 中的"CD"指的是持续交付和/或持续部署，这些相关概念有时会交叉使用。两者都事关管道后续阶段的自动化，但它们有时也会单独使用，用于说明自动化程度。

持续交付（Continuous Delivery）通常是指开发人员对应用的更改会自动进行错误测试并上传到代码仓库（如 GitHub、GitLab 等），然后由运维团队将其部署到实时生产环境中。这旨在解决开发和运维团队之间可见性及沟通较差的问题。因此，持续交付的目的就是确保尽可能减少部署新代码时所需的工作量。

持续部署（Continuous Deployment）指的是自动将开发人员的更改从代码仓库发布到生产环境，以供客户使用。通过一套全自动化的流程，来解决手动测试、编译、打包等操作。持续部署以持续交付的优势为根基，实现了管道后续阶段的自动化。

2. 什么是 Jenkins

前面说的 CI/CD 算是一种思想，思想要落地，就需要对应的工具。

Jenkins 是一款开源的 CI/CD 软件，可以算是 CI/CD 软件领导者，它提供了超过 1000 个插件来支持构建、部署、自动化，基本上能够满足任何项目的需要。

整体来说，Jenkins 有如下六大特点：

• 持续集成和持续交付

作为一个可扩展的自动化服务器，Jenkins 可以用作简单的 CI 服务器，或者变成任何项目的持续交付中心。

• 简易安装

Jenkins 是一个基于 Java 的独立程序，可以立即运行，包含 Windows、Mac OS X 和其他类 Unix 操作系统。

• 配置简单

Jenkins 可以通过其网页界面轻松设置和配置，其中包括即时错误检查和内置帮助。

• 插件

通过更新中心中的 1000 多个插件，Jenkins 集成了持续集成和持续交付工具链中几乎所有的工具。

• 扩展

Jenkins 可以通过其插件架构进行扩展，从而为 Jenkins 可以做的事提供几乎无限的可能性。

• 分布式

Jenkins 可以轻松地在多台机器上分配工作，帮助更快速地跨多个平台推动构建、测试和部署。

其实 Jenkins 有很多好玩的用法，今天我还是想先通过一个简单的案例，先来和大家捋一捋如何使用 Jenkins 来实现一个 Spring Boot 项目的自动发布部署，这样大家对 Jenkins 现有一个直观的认知，各种其他使用细节松哥在以后的文章中再来和大家细聊。

3. 准备工作

3.1 整体规划

我们先来通过如下一张图片来看下 Jenkins 在整个流程中扮演的角色：

结合第一二小节的介绍，这张图应该很好理解。

3.2 准备代码

提前准备好测试代码，并上传到代码仓库中。为了更加逼真一些，小伙伴们可以将这个代码仓库设置为私有的，这样将来可以检验 Jenkins 中的配置是否正确。

考虑到 GitHub 网络有时候不稳定，我这里使用了 Gitee，一个很简单的 Spring Boot 工程，里边有一个 hello 接口，仅此而已。

我的代码仓库地址（私有仓库）：

• ​​https://gitee.com/lenve/jenkins_demo.git​​

3.3 准备服务器

理论上，我们需要一台服务器用来跑 Jenkins，还需要一台服务器作为我的应用服务器，但是我手头没有多余的服务器，所以我就将 Jenkins 和我的 Spring Boot 项目部署到一台服务器上，在接下来的文章中我会和大家说明每个配置是针对 Jenkins 的还是针对 Spring Boot 的。

另外，有的小伙伴可能是在虚拟机上做实验，因为将来我们的代码提交到 Gitee 之后，Gitee 会通过一个 POST 请求将这个事件告知 Jenkins，进而触发 Jenkins 的构建操作。所以这就要求 Gitee 能够访问到你的 Jenkins 服务器，所以如果你的 Jenkins 刚好搭建在服务器上，这事就很容易了，但如果是搭建在虚拟机里，就得通过花生壳之类的内网穿透工具来辅助你的工作了，比较麻烦，而且花生壳网速也慢。

不过小伙伴们不必担心，如果你在虚拟上搭建的 Jenkins，并且不愿意折腾花生壳，那么也可以通过手动构建/定时构建的方式去完成项目构建的。

4. 搭建 Jenkins

为了省事，我决定用 Docker 搭建 Jenkins，一行命令搞定。

为了操作方便，我们将 Jenkins 的工作目录映射到我的宿主机中来，因此首先在宿主机中准备一个数据目录（不是必须）：

# 创建 jenkins 目录
mkdir /data/jenkins_home/
# 修改目录的所有者，以便于 Jenkins 容器能够操作该目录
chown -R 1000:1000 /data/jenkins_home/

接下来创建并启动 Jenkins 容器，同时挂载数据卷：

docker run -d --name jenkins -p 8088:8080 -p 50000:50000 -v /data/jenkins_home:/var/jenkins_home jenkins/jenkins

由于 Jenkins 在运行的时候需要用到 maven，所以有的人会选择将 maven 目录也作为挂载点，但是我觉得没有必要，特别是对于初学者而言，这块很容易出错，不如将 maven 将来直接拷贝到 Jenkins 容器中，这样反而省事一些。

执行如上命令，安装成功之后，浏览器输入 ​​http://localhost:8088​​ 就可以访问了。

然后稍等片刻，就可以访问 Jenkins 了：

访问之前，首先需要解锁 Jenkins，解锁密码位置网页上列出来了，但是由于我们创建容器的时候设置了数据卷，所以，现在直接去宿主机的 ​​/data/jenkins_home/secrets/initialAdminPassword​​ 位置查看初始化密码，如下：

在网页中，输入密码然后继续。接下来会让我们选择需要的插件，第一次使用，安装推荐插件即可。

如果因为网络原因安装失败，可以点击重试按钮进行重试。

接下来创建一个新的用户，也可以不创建新的用户，直接使用 admin 即可：

再设置 Jenkins 访问地址：

这个页面有乱码，不过不影响，设置完成后，我们点击保存并完成按钮即可。接下来就可以进入到 Jenkins 中了。

整个过程执行完毕后，建议执行如下命令重启一下 Jenkins，因为有的插件需要重启之后才会生效。

docker

5. 安装插件

Jenkins 启动成功之后，接下来我们安装三个必要的插件：

• Maven Integration：Maven 构建工具
• Publish Over SSH：整个工具，将来把 Jenkins 打包好的 jar 上传到应用服务器上。
• Gitee：协助使用 Gitee 仓库。

安装步骤如下：

点击左边的系统管理，然后点击右边的插件管理，进行配置。

然后在可选插件中，搜索 Maven Integration 和 Publish Over SSH 以及 Gitee 三个插件：

搜索完成后，点击 Install without restart。

安装成功之后，重启 Jenkins。

建议执行 ​​docker restart jenkins​​ 去重启，点击网页上的重启，会卡很久，还是执行 docker 重启命令靠谱一些。

6. 配置 Jenkins

6.1 基本的环境配置

插件安装成功之后，接下来我们开启 Jenkins 的配置，在正式开始配置之前，先做一点准备工作。

这个需要我们提前准备好 Maven，由于 Jenkins 容器中已经包含一个 JDK 了，所以我们可以不用提前准备 JDK，只需要提前准备 Maven 即可。为了避免权限问题，我们可以直接将 Maven 上传到 jenkins 容器中，然后去配置即可。

如下将宿主机中的 maven 拷贝到 Jenkins 容器中：

# 这个命令表示将宿主机中的 maven 目录拷贝到 jenkins 容器中的 /opt/ 目录下
docker cp

接下来就可以开始配置了，配置的位置如下图：

6.2 JDK

首先我们来配置 JDK，Jenkins 中默认安装了 JDK，我们只需要将其配置配出出来即可：

别名随意取，JAVA_HOME 则根据实际情况配置。

6.3 Maven

Maven 就是我们刚刚上传到 docker 中期中的 Maven，配置一下位置即可，Jenkins 将来会自动从 Gitee 上将代码拉下来，然后就利用你这里配置的 Maven 进行构建：

名字随意取，MAVEN_HOME 则是前面刚刚上传到容器中的 MAVEN 目录。

6.4 Git

配置 Git，由于 Jenkins 容器中已经存在 git 了，所以这里不需要额外安装 git，默认即可。

所有都配置完成，点击保存按钮。

6.5 远程的凭证配置

接下来还需要我们配置两个远程登录凭证。

6.5.1 应用服务器信息

应用服务器，就是将来 Jenkins 将代码构建成 jar 包后，要上传的服务器的信息（地址、用户名以及密码）。

配置步骤如下，首先找到配置的位置：

往下拉找到 Publish Over SSH，然后点击新增，开始配置，Hostname 位置填写你服务器的域名或者 IP：

配置成功后，点击测试连接进行测试，确保连接是成功的。

有的小伙伴反馈这里用户名密码会导致 jar 包上传失败，要在应用服务器上生成 ssh 密钥对，然后将私钥配置给 Jenkins（这块大家结合自己情况来看，如果后面 jar 上传失败，可以回来改一下这里）。

6.5.2 Gitee 的信息

接下来我们配置 Gitee 的信息。

首先配置仓库的基本信息：

接下来配置 Gitee 的凭证，要根据这些凭证，才能从 Gitee 上拉取代码下来，点击 ​​添加->Jenkins​​，添加凭证：

添加成功之后，就可以选择这个令牌了。

最后点击测试连接，确保可以连上 Gitee。

所有配置工作都做完了，接下来我们就可以开始构建一个项目了。

7. 开始一个项目的构建

首先我们新建一个任务

接下来我们选择构建一个 Maven 项目

点击确定之后，拉到源码管理位置，开始配置。

首先选择 Git，填入 Gitee 上的仓库地址，然后凭证就写 Gitee 的用户名/密码。

这里有一个需要注意的地方，就是默认的分支名称，GitHub 上现在默认的主分支名称是 main，Gitee 似乎还是 master，这个无所谓了，但是小伙伴们注意图片下面的分支，按你实际的情况填写。

这里也要添加凭证信息：

这里也要注意下，有小伙伴反馈 Gitee 上的用户名和用户空间不是一回事（如果用的 GitHub 就不存在这个问题），我这里用户名位置实际填入用户空间名（如果你也不知道什么是用户空间，那么恭喜你，直接写用户名就行了）。

加上时间，我们看下打印的过程：

接下来输入项目构建命令，将来 Jenkins 从 Gitee 上拉取代码下来之后，就执行该命令对项目进行打包：

最后，配置上传构建好的文件，并执行启动命令，如下：

配置的详细信息：

根据上图的配置，我们使用 root 用户登录，root 登录成功之后，默认进入到 /root 目录下，接下来会自动进入到 data 目录，然后我们的 jar 包就上传到这个位置上。

然后我们在应用服务器上也提前准备好一个 shell 脚本叫做 deploy.sh，位于 ​​/root/data​​ 目录下,这个脚本内容如下：

export JAVA_HOME=/opt/java
export PATH=$JAVA_HOME/bin:$PATH

JAR_PATH=/root/data

JARFILE=jenkins_demo-0.0.1-SNAPSHOT.jar

ps -ef | grep $JARFILE | grep -v grep | awk '{print $2}' | xargs kill -9

java -jar $JAR_PATH/$JARFILE > out.log &
if [ $? = 0 ];then
        sleep 30
        tail -n 50 out.log
fi

这个脚本其实很好理解，前面先配置一下环境变量，注意这个是应用服务器的环境变量，不是 Jenkins 的。

然后先检查一下，如果应用程序已经在运行了，就先将之停止掉。然后运行我们最新的 jar 即可。

另外，可以开启 SSH 操作日志，开启日志之后，就可以看到 Jenkins 中操作应用服务器其的过程了，特别是大家第一次配置的时候，容易出错，配置了日志，将来出错就知道什么原因导致的错误了。

配置方式如下图：

至此，这个项目就配置完成了。

保存之后，点击立即构建按钮，就可以开始构建了：

开始构建之后，可以点击构建按钮，查看构建过程：

点击控制台输出，可以查看整个构建过程：

构建完成后，来到应用服务器，执行 jps 命令查看运行的 Java 进程，就可以看到我们的应用程序已经跑起来了。

8. 自动构建

好了，现在我们的项目还不是自动构建，也就是当我们向 Gitee 上的代码仓库提交代码之后，并不会触发 Jenkins 的自动构建，得我们手动点击构建按钮，接下来我们再来继续配置，实现自动触发构建。

为了实现自动触发构建，我们需要修改两个地方。

8.1 修改 Jenkins

首先在 Jenkins 的当前项目中，配置一下触发构建的规则：

大家注意，在网页上 Jenkins 已经给出了将来要配置的 Webhook 的地址了，大家直接拷贝该地址即可。

8.2 配置 Webhook

接下来在 Gitee 的项目中，配置 WebHook，在当前项目中，选择管理选项卡，左边菜单点击 WebHooks，然后点击添加 WebHook。

由于 Jenkins 是要登录之后才可以操作的，处于公网的 Jenkins 我们也不能降至设置为匿名访问，所以这里我们将 Jenkins 的用户名密码放在请求地址中，最终地址类似这样：​​http://username:password@11.11.11.11:8088/xxxx​​。

好啦，这就行了，配置完成后，接下来我们向 Gitee 代码仓库提交代码，提交成功之后，我们去查看是否会触发 Jenkins 自动构建功能。

9. 小结

好啦，关于 Jenkins 还有很多好玩的用法，今天的文章限于篇幅我就先通过一个简单的案例来和大家分享一下 Jenkins 的基本用法，以便于小伙伴们对 Jenkins 建立一个直观的印象，更多的玩法，松哥将在后续的文章中和大家继续介绍，小伙伴们也可以留言说说你想看 Jenkins 怎么玩。

参考资料：

• ​​https://www.redhat.com/zh/topics/devops/what-is-ci-cd​​