Jenkins 实战教程：三大仓库 + 自动构建 + 公网远程部署
Jenkins 作为一款开源的自动化服务器，核心功能覆盖了代码构建、测试到部署的全流程，适配前端 Vue、后端 Spring Boot 等各类项目，还能对接 GitHub、Gitee 等主流代码仓库。其丰富的插件生态和可视化控制台，能大幅减少重复的手动操作，提升开发效率。
不过使用 Jenkins 也有不少需要注意的地方，比如初次配置时要做好权限分配，避免非授权人员修改构建任务，插件安装也需按需选择，否则会拖慢服务器运行速度，另外构建脚本的编写要简洁，不然容易出现构建失败却难排查的问题。
如果仅在局域网内使用 Jenkins，会带来诸多不便：比如居家办公时，想修改代码后触发构建，却连不上公司内网的 Jenkins；多设备开发时，只能在局域网内的电脑操作，外出用笔记本改完代码，还得等回到公司才能部署测试，严重影响进度。
而将 Jenkins 与内网穿透工具结合后，这些问题都能迎刃而解：无需公网 IP 和路由器权限，就能把内网的 Jenkins 映射到公网，不管是在家、出差，只要能上网就能访问 Jenkins 控制台，测试人员也能通过公网链接验证部署效果，既不影响业务又能保证迭代效率。
1. 什么是 Jenkins?
Jenkins 是一个开源的自动化服务器，用于构建、测试和部署软件项目。它是一个持续集成（CI）和持续交付（CD）工具，旨在帮助开发团队更快地交付高质量的软件。
以下是一些关于 Jenkins 的重要信息和功能：
- 自动化构建和部署：Jenkins 允许开发团队自动化软件项目的构建、测试和部署过程。这意味着当代码发生变化时，Jenkins 可以自动触发构建和部署流程，从而减少了手动干预的需要。
- 大量插件支持：Jenkins 拥有一个庞大的插件生态系统，其中包含各种插件，可以用于集成不同的开发、测试和部署工具。
- 分布式构建：Jenkins 支持分布式构建，可以在多台构建代理（节点）上并行运行构建任务。
- 易于配置：Jenkins 提供了一个直观的 Web 界面，使得配置构建和部署任务变得非常简单。
- 多种集成选项：Jenkins 可以集成到许多版本控制系统（如 Git、SVN 等）和项目管理工具中。
- 安全性：Jenkins 提供了一些安全性功能，包括用户认证、访问控制和插件管理。
- 社区支持：Jenkins 拥有庞大的社区，可以轻松找到解决问题的资源、插件和教程。
在本教程中，Jenkins 将作为部署核心，自动拉取代码并完成构建发布。结合内网穿透工具，我们还将打通公网访问，实现从远程触发构建到访问部署结果的完整流程。
2. Jenkins 安装（CentOS7）
2.1 CentOS7 环境准备
在 CentOS7 系统上安装 Jenkins 前，需要先准备 Java 环境：
# 下载并安装 Adoptium OpenJDK 17
cd /opt
# 下载 jdk-17 压缩包
curl -L -O https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.11%2B9/OpenJDK17U-jdk_x64_linux_hotspot_17.0.11_9.tar.gz
# 解压压缩包
tar -xvzf OpenJDK17U-jdk_x64_linux_hotspot_17.0.11_9.tar.gz
# 重命名
mv jdk-17.0.11+9 temurin17
设置 Java 环境变量（全局）：
sudo tee /etc/profile.d/java.sh <<EOF
export JAVA_HOME=/opt/temurin17
export PATH=$JAVA_HOME/bin:$PATH
EOF
使其生效：
source /etc/profile.d/java.sh
验证是否成功：
java -version
2.2 下载 Jenkins
下载链接：https://ftp-nyc.osuosl.org/pub/jenkins/war-stable/latest/jenkins.war
- 第一种方式：在浏览器中下载，然后将文件传入系统中（可使用 xftp 传输，或者使用 scp 命令进行远程拷贝）
scp "D:\Download\jenkins.war" [email protected]:/home/jenkins
**说明：**运行时会提示输入 Linux 的密码，输入 root 密码即可。
- 第二种方式：使用 wget 命令直接进行下载
mkdir -p /opt/jenkins
cd /opt/jenkins
# 未安装 wget 先安装
yum install wget -y
wget https://ftp-nyc.osuosl.org/pub/jenkins/war-stable/latest/jenkins.war
下载完成后将会存在一个 jenkins.war 的 war 文件。
2.3 启动 Jenkins
# 使用 java-jar 启动 war 文件，设置端口 8090，并使用 nohup 设置后台启动以及指定日志文件路径为 /var/log/jenkins.log
nohup java -DJENKINS_HOME=/opt/jenkins_home -jar jenkins.war --httpPort=8090 > /var/log/jenkins.log 2>&1
# 如果发现启动不了，可以查看日志进行排错（例如：地址已经在使用，换个端口就好了）
cat /var/log/jenkins.log
也可以创建一键启动脚本：
# 创建 start_jenkins 脚本
sudo vim start_jenkins.sh
# 给 start_jenkins 脚本赋权
chmod +x start_jenkins.sh
创建脚本后输入如下内容：
#!/bin/bash
# 设置 Jenkins 持久化目录
export JENKINS_HOME=/opt/jenkins_home
# 获取监听 8090 端口的进程 PID
pid=$(netstat -lnp 2>/dev/null | grep 8090 | awk '{print $7}' | awk -F "/" '{print $1}')
if [[ -n "$pid" ]]; then
echo "找到 Jenkins 的 8090 端口进程，PID 为：$pid"
kill -9 $pid
echo "Jenkins 服务已停止"
else
echo "未找到 Jenkins 的 8090 端口进程，跳过停止步骤"
fi
# 删除日志文件
if [[ -f "jenkins-war.log" ]]; then
rm -f jenkins-war.log
echo "日志文件已删除"
else
echo "日志文件不存在"
fi
# 启动 Jenkins
nohup java -Xms512m -Xmx1024m -Xmn256m -XX:SurvivorRatio=6 -jar jenkins.war --httpPort=8090 >> ./jenkins-war.log 2>&1 &
echo "Jenkins 服务已启动，监听端口 8090，日志输出至 jenkins-war.log"
保存退出后，输入如下命令进行脚本赋权：
chmod +x start_jenkins.sh
创建 jenkins_home 目录：
mkdir -p /opt/jenkins/jenkins_home
chmod -R 777 /opt/jenkins/jenkins_home
执行脚本进行启动：
./start_jenkins.sh
记住控制台输出的管理员密码：
# 注意，每个用户生成的都不一样
c90251a01796458595c575fb2dfbaf72
这样，Jenkins 就已经启动啦！
2.4 配置 Jenkins
执行如下命令开放 Jenkins 防火墙端口：
# 开放 8090 端口 脚本中设置的 jenkins 端口为 8090
firewall-cmd --zone=public --add-port=8090/tcp --permanent
# 刷新防火墙配置
firewall-cmd --reload
开放防火墙后，访问测试：
http://<您的服务器 IP>:8090
# 如：http://192.168.184.133:8090
出现如上页面即代表启动成功且成功访问 Jenkins 啦！
接下来，输入之前复制的密码，也可以使用如下命令查看密码：
cat /opt/jenkins/home/secrets/initialAdminPassword
输入完成密码点击继续后，选择安装推荐的插件。
等待插件安装。
安装完成自动跳转该页面（设置一个管理员账号，也可以使用 admin 账号继续）。
配置完成后会让你进行设置访问地址，没其他要求，默认即可。
3. Jenkins 用户权限
3.1 创建用户
依次点击右上角设置图标，然后点击 Security 下的 Users 即可进入。
3.2 删除用户
删除账号点击删除图标即可。
3.3 权限分配
3.3.1 安装权限插件
路径：右上角设置图标 > System Configuration 下面的 Plugins > Available plugins
搜索 Role-based Authorization Strategy 即可。
点击安装后会跳转安装界面，滚动到最下面，勾选安装完成重启 Jenkins。
3.3.2 切换权限控制插件
路径：右上角设置图标 > Security 下的 Security > 授权策略。
3.3.3 添加角色权限
路径：右上角设置图标 > Security 下的 Manage and Assign Roles > Manage Roles。
设置好后，点击下方的 Save 保存按钮。
3.3.4 用户分配角色
路径：右上角设置图标 > Security 下的 Manage and Assign Roles > Assign Roles。
这样，给用户分配角色就完成了！
3.4 权限类别说明
| 权限类别 | 主要权限 | 说明 | 适用角色 |
|---|---|---|---|
| Overall | Administer、Read | 系统管理、基础访问 | 管理员必须、所有用户需要 Read |
| Job | Create、Build、Configure、Read | 项目创建、构建、配置、查看 | 开发者核心权限 |
| Credentials | Create、Update、View | 凭据增删改查 | 管理员和高级开发者 |
| Agent | Create、Configure、Connect | 构建节点管理 | 管理员专用 |
| View | Create、Configure、Read | 视图创建和配置 | 按需分配 |
4. 使 Jenkins 公网访问（内网穿透篇）
4.1 为什么要穿透 Jenkins?
在实际部署 Jenkins 的过程中，通常会将其部署在局域网环境中，以保障安全性和管理便利性。然而，内网部署也带来一个限制：无法直接通过公网访问 Jenkins 服务。这意味着当需要在远程设备上访问 Jenkins、配置任务或查看构建状态时，操作将变得非常受限。
为了解决这一问题，可以通过内网穿透工具将 Jenkins 映射到公网地址。这样，无论是在家办公、远程协作，还是需要跨网络环境访问 Jenkins，都能够通过分配的公网 URL 直接连接到内网中的 Jenkins 服务。
例如，一台部署在公司内网的 Jenkins 实例，默认只能在本地或同一局域网内访问。如果希望在外地通过浏览器访问这台 Jenkins 实例，只需使用隧道工具创建一个 HTTP 隧道，即可将内网地址映射到一个公网可访问的链接，实现对 Jenkins 的远程管理与操作。
4.2 什么是内网穿透工具？
内网穿透工具是一款用于内网穿透的工具，能够将本地或局域网中的服务，映射到公网地址，使其能够被外部网络访问。它支持 HTTP、HTTPS、TCP 等多种协议，并提供稳定的公网访问通道，无需公网 IP、无需复杂的路由或防火墙配置。
在实际使用中，只需简单几步配置，就可以为本地服务生成一个可访问的公网链接，广泛应用于远程调试、Webhook 回调、移动办公、内网接口测试等场景。
常见应用场景包括：
- 将本地 Web 应用、API 接口映射到公网，供他人访问或调试；
- 在没有公网 IP 的服务器上部署服务，实现外网访问；
- 支持 Jenkins、GitLab 等系统通过公网访问；
- 进行微信、小程序、支付平台的开发联调（需要公网回调地址）；
4.3 安装内网穿透工具
以 Linux（Centos7）为例，首先，我们需要先安装 curl：
sudo yum install curl
接下来下载工具，一条命令完成安装：
curl -L https://www.cpolar.com/static/downloads/install-release-cpolar.sh | sudo bash
测试工具版本以确保安装：
cpolar version
4.4 配置系统服务
向系统添加及启动服务：
# 添加服务
sudo systemctl enable cpolar
# 启动服务
sudo systemctl start cpolar
查看服务状态：
sudo systemctl status cpolar
4.5 注册及登录管理界面
4.5.1 注册
访问官网，点击免费注册按钮，进行账号注册。
4.5.2 放行 9200 端口（web ui 端口）
在访问 web 页面前，需要先检查系统防火墙是否放行 9200 端口，避免访问不了。
systemctl status firewalld
有两种方式可以实现访问，一种是放行该端口，另一种是直接关闭防火墙（不建议）。
# 放行 9200 端口
# --zone=public：使用默认区域（通常是 public）
# --add-port=9200/tcp：添加 TCP 协议的 9200 端口
# --permanent：永久生效（不加此参数则是临时规则，重启失效）
firewall-cmd --zone=public --add-port=9200/tcp --permanent
# 重载防火墙配置 (及刷新配置使其生效)
firewall-cmd --reload
验证端口是否已放行：
firewall-cmd --zone=public --query-port=9200/tcp
输出内容为 yes 则成功放行。
4.5.3 访问管理界面
在访问之前，不确定 ip 地址可以通过 ifconfig 命令查看服务器 ip。
ifconfig
确定好 ip 地址后，在浏览器中访问：
http://<此处应为您的 IP>:9200
# 如：http://192.168.184.133:9200
将前面步骤注册好的账号登录即可进入后台页面。
登录成功同时，服务器也会后台无感自动配置 token，无需手动配置 token。
配置文件位置：/usr/local/etc/cpolar/cpolar.yml
cat /usr/local/etc/cpolar/cpolar.yml
4.6 配置 Jenkins 隧道及访问测试
4.6.1 配置 HTTP 隧道绑定到 8090 端口
点击左侧菜单栏的隧道管理，展开进入隧道列表页面，页面下默认会有 2 个隧道：
- ssh 隧道，指向 22 端口，tcp 协议
- website 隧道，指向 8080 端口，http 协议（http 协议默认会生成 2 个公网地址，一个是 http，另一个 https，免去配置 ssl 证书的繁琐步骤）
接着点击创建隧道菜单，进入到创建页面，如下图配置：
创建完成后，点击左侧菜单的状态菜单，接着点击在线隧道列表菜单按钮，可以看到有 2 个 gitlab 的隧道，一个为 http 协议，另一个为 https 协议。
注意：每个用户创建的隧道显示的公网地址都不一样！
4.6.2 访问公网地址验证 Jenkins 是否可访问
在浏览器中访问创建 jenkins 隧道生成的公网地址（http 和 https 皆可）。
这里以 https 为例：
登录 jenkins 账号，成功进入 jenkins 首页！
4.7 设置固定二级子域名
使用工具为其配置二级子域名，该域名为固定格式域名，不会随机变化，方便后续远程访问 jenkins 自动化构建平台。
列表中显示了一条已保留的二级子域名记录：
- 地区：显示为 China Top。
- 二级域名：显示为 jenkins。
注：二级域名是唯一的，每个账号都不相同，请以自己设置的二级域名保留的为主。
进入侧边菜单栏的隧道管理 > 隧道列表，可以看到前面配置名为 jenkins-8090 的隧道。
点击编辑按钮进入编辑页面，修改域名类型为二级子域名，然后填写前面配置好的子域名，点击更新按钮。
来到状态菜单下的在线隧道列表可以看到隧道名称为 jenkins-8090 的公网地址已经变更为二级子域名 + 固定域名主体及后缀的形式了。
这里以 https 协议做访问测试：
访问成功！
5. 演示项目实战
在开始配置 Jenkins 自动化部署之前，我们需要准备两个简单的演示项目作为部署对象。这两个演示项目专门为本教程设计，将贯穿整个教程，用于演示从代码提交到自动构建、部署的完整 CI/CD 流程。
通过这两个演示项目，您将学会：
- 如何在 Jenkins 中配置前端 Vue 项目的自动化构建与部署
- 如何在 Jenkins 中配置后端 Spring Boot 项目的自动化构建与部署
- 如何通过 Webhook 实现代码提交后的自动触发构建
- 如何将构建产物部署到服务器并提供访问服务
5.1 演示项目介绍
本节准备两个简单的演示项目，专门用于演示 Jenkins 自动化部署流程：
演示前端项目（jenkins-ci-demo-frontend）
- GitHub 地址：https://github.com/TanChengBin/jenkins-ci-demo-frontend
- 技术栈：Vue 3 + Vite + Element Plus
- 功能：演示前端项目的 Jenkins 自动化构建与部署
- 端口：3000
- 构建产物：静态文件（部署到 Nginx）
演示后端项目（jenkins-ci-demo）
- GitHub 地址：https://github.com/TanChengBin/jenkins-ci-demo
- 技术栈：Spring Boot 2.7 + Maven
- 功能：提供 RESTful API，演示后端项目的 Jenkins 自动化构建与部署
- 端口：8080
- 构建产物：jar 包（Java 应用）
重要说明：这两个项目专为本教程设计，包含完整的 Jenkins 构建配置项目代码简洁易懂，便于理解 CI/CD 流程后续所有 Jenkins 配置都基于这两个项目进行演示
5.2 下载演示源码
请按照以下步骤获取演示项目：
# 克隆前端项目
git clone https://github.com/TanChengBin/jenkins-ci-demo-frontend.git
# 克隆后端项目
git clone https://github.com/TanChengBin/jenkins-ci-demo.git
在任意文件夹，单击鼠标右键，打开 shell 窗口，执行 clone 命令下载代码。
5.3 本地运行测试（可选）
为了更好地理解演示项目结构和功能，建议先在本地测试运行这两个演示项目：
5.3.1 后端 Maven 启动
在启动前，需要确保当前系统中有 Java 和 Maven 环境，本文使用的为 windows 系统，以 windows 系统举例： 键盘输入 win+R 键，打开运行窗口，输入 cmd 回车，打开 cmd 命令终端：
检查是否存在 Java 版本：
如果没有，需要先下载 jdk（jdk8~jdk17 均可），下载官网（Oracle）：https://www.oracle.com/cn/java/technologies/downloads/
java -version
检查 Maven 环境：
如果没有，需要先下载 Maven，下载官网（Apache）：https://maven.apache.org/
mvn -v
以上环境都有的情况下，即可进行下一步骤啦！
在后端项目（jenkins-ci-demo）的目录中，地址栏输入 cmd，可以在当前目录打开 cmd 窗口：
cmd 窗口的路径就会在当前打开 cmd 的目录路径：
然后输入 Maven 命令：
mvn spring-boot:run
这个命令会进行依赖下载和启动项目：
这里显示已经运行在 8080 端口上了，接着请求一下 Api 接口测试一下：
# 后端唯一 api 接口 返回：项目名称、版本号、作者 方便后期 jenkins 修改代码，提交 git 测试
http://localhost:8080/api/info
/**
* 系统信息控制器
*
* @author cpolar
*/
@RestController
@RequestMapping("/api")
public class InfoController {
/**
* 获取系统信息
* 返回系统的基本信息，包括项目名称、版本号和作者信息
*
* @return 系统信息
*/
@GetMapping("/info")
public ResponseEntity<SystemInfo> getSystemInfo() {
// 硬编码返回系统信息
SystemInfo systemInfo = new SystemInfo("jenkins-ci-demo", "1.0", "cpolar");
return ResponseEntity.ok(systemInfo);
}
}
可以看到正常返回接口信息啦！
5.3.2 前端 Vue 项目启动
在 5.3.1 小节中，后端项目已经启动，占用后端的 cmd 窗口保留。重新开一个新的 cmd 窗口（可以直接在前端项目目录中打开 cmd）:
打开 cmd 窗口后，检查一下前端环境：
node -v
npm -v
node 版本建议在 16.x 或更高版本，如果没有下载 node，可以前往官网进行下载： 官网链接 (中文)：http://nodejs.org/zh-cn
接下来进行安装前端项目依赖，在 cmd 终端执行（前端项目路径的 cmd 终端）：
# 依赖安装
npm install
安装完成会有类似 added 164 packages in 5s 提示，接下来启动项目：
npm run dev
输入如上命令后，项目会启动，启动成功后显示如下：
在浏览器中输入 Local 这一栏显示的地址即可访问前端项目：
http://127.0.0.1:3000
如果后端的 cmd 窗口叉掉了，没有重启后端，前端页面则显示的应该如下：
6. Jenkins 项目创建及配置
Jenkins 在集成 GitHub、Gitee、GitLab 等代码仓库时，项目的创建流程整体上较为一致。因此，本节将以 GitHub 项目为例进行详细讲解，涵盖 Jenkins 插件安装、构建环境配置、依赖缺失处理等内容。Gitee 和 GitLab 也将分别演示对应的前后端项目配置流程，GitLab 由于是私有项目，在配置 git 源仓库时会出现用户凭证问题，大家如遇到该问题便于对比和参考，您可以根据实际使用的仓库平台进行调整。
6.1 github 项目（开源）
6.1.1 前端 Vue 项目创建
Jenkin 首页选择新建 item:
接着输入任务名称，名称自定义，风格选择自由风格：
然后下拉，找到源码管理，配置好 github 仓库地址信息：
提示没有安装 git，接下来在服务器中安装一下 git:
yum install git
安装完成后，错误提示就没啦，然后配置好信息点击，保存即可：
接着，回到首页，点击刚才创建的项目 dev-github-jenkins-ci-demo-frontend，点击进入，然后进行构建，如下图：
点击这一条构建记录，也就是 Builds 下面编号为 #6（大家应该是 #1）的这条：
6.1.2 后端 Maven 项目创建
首先需要安装 Maven 风格插件，位置：右上角设置图标 > System Configuration > Plugins > Available plugins 中，输入 Maven
等待安装完成（可以勾选一下自动重启）：
等待一段时间，刷新一下页面，如果跳转登录界面，登录一下即可，然后选择新建 Item:
接着填写任务名称，选择构建一个 Maven 项目的风格：
下拉到源码管理，配置好远程 github 仓库，如下图：
继续滚动到下方，或者点击侧边的 Build 菜单：
点击蓝色字体跳转新页面，进行如下 Maven 配置：
回到刚才 build 的页面，点击保存，重新回到 build 页面就可以看到错误消失了，然后配置一下 build 配置：
# 清理 打包 跳过测试
clean install -Dmaven.test.skip=true
接着可以继续回到该 build 页面，如图依次点击，可以出现一个可编写 shell 脚本的文本域：
写一个简单的脚本测试一下，填写完成后点击保存：
echo "---------Maven 版本（start）---------"
mvn -v
echo "---------Maven 版本（end）---------"
点击构建测试：
如下为构建信息，具体内容请查看如下图：
首次下载依赖需要一些时间，所以构建时间也比较长，如下图为剩余日志部分：
6.2 gitee 项目（开源）
6.2.1 前端 Vue 项目创建
首页点击新建 Item，跳转到填写任务名和选择风格界面：
任务名称自定义即可，风格选择自由风格：
接下来进行源码管理配置，填写相关 gitee 仓库信息：
保存后点击 Build Now 按钮进行构建测试
查看控制台日志信息：
项目简单创建就完成啦！
6.2.2 后端 Maven 项目创建
首页选择新建 Item：
然后填写任务名称和选择 Maven 风格：
接下来进入源码管理，进行配置 gitee 的 Maven 项目信息
然后左侧选择 Build 菜单，进行 build 相关配置：
# 清理 打包 跳过测试
clean install -Dmaven.test.skip=true
写一个简单脚本，查看 maven 版本，进行测试：
echo "---------Maven 版本（start）---------"
mvn -v
echo "---------Maven 版本（end）---------"
接着点击构建 Build Now 进行构建，等待进度条出来，点击进度条可以直接跳转控制台日志输出页面：
可以看到如下信息：
接着再看一下结尾构建信息：
6.3 gitlab 项目（私有）
通常情况下，GitLab 多部署在局域网环境中，默认无法直接通过公网访问。本教程所使用的 GitLab 示例地址为经过公网映射后的链接，使用了内网穿透实现访问能力。
为了确保 Jenkins 能正常拉取代码并集成构建，本文在 GitLab 侧完成了以下配置：
- 使用固定二级子域名保持公网地址稳定；
- 将仓库的 clone 地址修改为公网可访问的 HTTP 链接，以适配 Jenkins 拉取代码流程。
详细配置方法可参考上一篇文章：CentOS7 私有 GitLab + cpolar 内网穿透实现公网访问教程
首页选择新建 Item
任务名称自定义即可，风格选择自由风格：
接着，左侧菜单选择源码管理，填写 git 相关配置：
如下为填写账号信息凭证参考图：
接下来，点击构建，进行测试：
控制台日志输出如下：
6.3.2 后端 Maven 项目创建
首页点击新建 Item：
然后填写任务名称，风格选择构建一个 Maven 项目：
左侧菜单选择源码管理，填写相关 Git 信息：
然后左侧选择 Build 菜单，进行 build 相关配置：
# 清理 打包 跳过测试
clean install -Dmaven.test.skip=true
写一个简单脚本，查看 maven 版本，进行测试：
echo "---------Maven 版本（start）---------"
mvn -v
echo "---------Maven 版本（end）---------"
接下来，点击 Build Now 按钮，进行构建
输出日志如下：
剩余日志如下，供参考：
这样基本的项目创建就完成啦！
7. Jenkins 自动化构建
由于 GitHub 与 Gitee 的构建流程与 GitLab 基本一致，为避免重复冗余，本小节仅以 GitLab 仓库为例，演示完整的构建过程。过程中也会针对可能出现的错误进行排查说明。其他平台（如 Gitee、GitHub）的项目配置方式可参考本节中 Jenkins + GitLab 的配置流程，进行相应替换与调整。
7.1 前端 Vue 项目自动化构建
在构建并部署前端项目之前，需确保服务器已安装并配置好 Web 服务环境。此处推荐使用 Nginx，用于部署构建后的静态资源并对外提供访问服务。
7.1.1 安装 Nginx
以 CentOS7 为例，目录位置为/opt，安装一下需要的依赖：
cd /opt
yum -y install gcc zlib zlib-devel pcre-devel openssl openssl-devel
下载并解压安装包：
# 下载压缩包
wget http://nginx.org/download/nginx-1.20.0.tar.gz
# 解压压缩包
tar -zxvf nginx-1.20.0.tar.gz
安装编译 nginx：
# 进入 nginx 目录
cd nginx-1.20.0/
# 执行命令 考虑到后续安装 ssl 证书 添加两个模块
./configure --with-http_stub_status_module --with-http_ssl_module
# 执行 make 命令
make
# 执行 make install 命令
make install
执行 make 和 make install 命令
编译后，nginx 目录会存在于/usr/local/nginx 中，接着，启动 nginx 进行测试：
# 进入 nginx 目录
cd /usr/local/nginx/
# 启动 nginx
./sbin/nginx
如果不知道 ip 地址，可以使用 ifconfig 命令进行查看：
ifconfig
nginx 默认端口为 80 端口，接下来需要开放防火墙，以支持访问：
# 开放 80 端口
firewall-cmd --zone=public --add-port=80/tcp --permanent
# 重新加载防火墙配置
firewall-cmd --reload
接着，浏览器访问测试一下：
http://192.168.184.133
成功啦，成功访问到 Nginx 默认首页！
7.1.2 添加构建脚本
首页点击任务项目名称进入详情页：
接着点击配置按钮，进入配置页面：
点击侧边菜单栏的 Build Steps 进行构建相关设置：
7.1.3 前端构建脚本
整个前端项目的构建部署流程主要包括从 Jenkins 的构建工作目录中启动，确保 node 环境正确，并通过 npm 安装依赖和执行打包操作，将打包生成的静态文件压缩成 tar.gz 文件后，移动至预设的部署目录 /home/project/jenkins/jenkins-ci-demo-frontend/ 中。部署前会清理旧内容，解压新构建产物替换更新，以此实现自动化构建与部署。整个过程简洁高效，适合用于前端 Vue 项目的持续集成场景中。
#!/bin/bash
# 输出当前系统 PATH 环境变量（调试用，可忽略）
echo $PATH
# 切换到 Jenkins 工作目录（当前项目源码根目录）
cd $WORKSPACE
# 输出 Node.js 和 npm 版本，确认环境正常
node -v
npm -v
# 安装指定版本的 chromedriver，并使用国内镜像源加速（若项目依赖）
npm install [email protected] --chromedriver_cdnurl=https://npmmirror.com/mirrors/chromedriver
# 安装项目依赖
npm install
# 执行 Vue 项目构建命令（默认产物生成在 dist 目录）
npm run build
# 切换到构建产物目录
cd $WORKSPACE/dist
# 删除旧的压缩包（避免文件冲突）
rm -rf jenkins-ci-demo-frontend.tar.gz
# 将构建产物打包为 tar.gz 文件
tar -zcvf jenkins-ci-demo-frontend.tar.gz *
# 准备部署路径
DEPLOY_PATH="/home/project/jenkins/jenkins-ci-demo-frontend"
# 创建部署目录（如果不存在）
mkdir -p $DEPLOY_PATH
# 删除旧的部署文件（保险起见）
rm -rf $DEPLOY_PATH/*
rm -rf $DEPLOY_PATH/jenkins-ci-demo-frontend.tar.gz
# 将新的压缩包移动到部署目录
mv $WORKSPACE/dist/jenkins-ci-demo-frontend.tar.gz $DEPLOY_PATH/
# 解压新部署包到目标路径
tar -zxvf $DEPLOY_PATH/jenkins-ci-demo-frontend.tar.gz -C $DEPLOY_PATH/
# 输出部署完成提示
echo "✅ 前端构建并部署完成，部署路径：$DEPLOY_PATH"
7.1.4 构建查看日志
将自定义脚本填写到 Execute shell 中，然后保存：
接下来进行构建，检查脚本是否存在问题：
控制台日志如下：
7.1.5 日志问题排查
第一次构建脚本日志得知，服务器中没有安装 nodejs，让我们安装一下 nodejs：
# 1. 添加 Node.js 16 的官方源（可改为 18、20 等其他版本）
curl -fsSL https://rpm.nodesource.com/setup_16.x | sudo bash -
# 2. 安装 Node.js（含 npm）
sudo yum install -y nodejs
# 3. 验证版本
node -v
npm -v
添加 nodejs16 的官方源：
安装 node.js 以及验证版本是否成功安装！
接着，我们再次点击构建，查看最新日志，日志如下：
我们可以看到提示，最后提示部署路径为：
/home/project/jenkins/jenkins-ci-demo-frontend
让我们进入服务器中查看一下该目录下的文件内容：
确实存在 index.html 文件，且包含前端的压缩文件，接着，我们需要配置 Nginx，以此来正确指向前端静态资源位置：
# 编辑 nginx 文件
sudo vim /usr/local/nginx/conf/nginx.conf
找到 nginx 配置文件中监听端口为 80 的服务，将 location 模块中 root 指向的路径，修改为前端项目的静态资源路径：
# nginx 配置如下：
server {
listen 80;
server_name localhost;
location / {
root /home/project/jenkins/jenkins-ci-demo-frontend;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
接着执行如下命令，进行刷新 nginx
/usr/local/nginx/sbin/nginx -s reload
重新刷新 nginx 后，让我们查看一下浏览器，是否正确显示咱们部署的前端页面：
可以发现，前端 vue 页面正常显示啦！
7.1.6 提交代码测试 Jenkins 构建
为了确保前端可以正确的拉取最新提交的 git 代码，这边简单修改一下前端页面，咱们把前端页面显示的 Jenkins CI 演示修改为 Jenkins CI 演示 V1.0：
接着，让我们再次点击构建按钮，进行日志查看和 Nginx 前端页面访问是否变更：
让我们查看前端 Nginx 页面：
好啦，前端完美实现流水线脚本自动化部署啦！
7.2 后端 Maven 项目自动化构建
7.2.1 添加构建脚本
首页点击后端项目任务名进入详情页面：
接着点击配置按钮，进入配置页面：
左侧菜单选择 Post Steps，可以看到前面编写过的测试脚本：
7.2.2 后端构建脚本
整个后端项目的构建部署流程是以 Jenkins 构建产物为起点，首先从 Jenkins 的构建输出目录中复制打包生成的 jenkins-ci-demo-1.0.jar 文件，并将其分别放置到项目运行目录和预设的部署备份目录 /home/project/jenkins/jenkins-ci-demo-backend/ 中。部署前会清理掉旧的 jar 包，确保工作目录干净整洁。随后通过预设的启动脚本 start_jenkins-ci-demo.sh 对服务进行重启，脚本会自动停止旧进程并拉起新的 jar 服务，同时生成独立的日志文件用于后续排查与追踪。整个流程自动化程度高、稳定性好，适合 Spring Boot 类型的后端服务持续集成与部署使用。
#!/bin/bash
# 防止 Jenkins kill 脚本
BUILD_ID=dontKillMe
# 项目 & jar 包配置
PROJECT_NAME="jenkins-ci-demo"
PROJECT_VERSION="-1.0"
JAR_FILE_NAME="${PROJECT_NAME}${PROJECT_VERSION}.jar"
# Jenkins 构建产物目录（Maven target）
JENKINS_TARGET_DIR="$WORKSPACE/target"
# 统一后的部署目录
DEPLOY_DIR="/home/project/jenkins/jenkins-ci-demo-backend"
# 启动脚本名
START_SCRIPT="start_jenkins-ci-demo.sh"
echo "======== Jenkins 后端部署开始 ========"
echo "项目名称：$PROJECT_NAME"
echo "Jar 文件名：$JAR_FILE_NAME"
echo "构建输出目录：$JENKINS_TARGET_DIR"
echo "部署目录：$DEPLOY_DIR"
# 保证部署目录存在
mkdir -p "$DEPLOY_DIR"
# 删除旧 jar（如果存在）
if [ -f "$DEPLOY_DIR/$JAR_FILE_NAME" ]; then
echo "删除旧 jar 包：$DEPLOY_DIR/$JAR_FILE_NAME"
rm -f "$DEPLOY_DIR/$JAR_FILE_NAME"
fi
# 拷贝新 jar 到部署目录
if [ -f "$JENKINS_TARGET_DIR/$JAR_FILE_NAME" ]; then
echo "拷贝新 jar 到部署目录..."
cp "$JENKINS_TARGET_DIR/$JAR_FILE_NAME" "$DEPLOY_DIR/"
else
echo "❌ 构建产物不存在：$JENKINS_TARGET_DIR/$JAR_FILE_NAME"
exit 1
fi
# 切换到部署目录
cd "$DEPLOY_DIR" || { echo "❌ 切换目录失败：$DEPLOY_DIR"; exit 1; }
# 确保启动脚本存在并可执行
if [ ! -x "$START_SCRIPT" ]; then
echo "启动脚本不存在或不可执行：$DEPLOY_DIR/$START_SCRIPT"
exit 1
fi
# 重启服务
echo "执行启动脚本..."
sh "$START_SCRIPT" restart
# 等待并检测是否启动成功
sleep 20
RUNNING_COUNT=$(ps -ef | grep "$JAR_FILE_NAME" | grep -v grep | wc -l)
if [ "$RUNNING_COUNT" -gt 0 ]; then
echo "✅ 服务已成功启动 (进程数：$RUNNING_COUNT)"
exit 0
else
echo "❌ 服务启动失败，未检测到 jar 运行中"
exit 1
fi
后端 Jar 文件启动脚本 (start_jenkins-ci-demo.sh) ：
# start_jenkins-ci-demo
# ====================== 配置区 ======================
# === 使用前请确保已安装 lsof：sudo yum install lsof -y ===
PORT=8080
# 应用监听端口
JAR_FILE="jenkins-ci-demo-1.0.jar"
# 构建后的 JAR 文件名
LOG_DIR="log"
# 日志目录
LOG_PREFIX=""
# 可选：日志前缀（留空自动识别）
# ====================================================
# 提取 jar 文件前缀（自动用于日志命名）
extract_jar_prefix(){
local jar_name=$(basename "$JAR_FILE")
echo "$jar_name" | sed -E 's/(-[0-9]+\.[0-9]+.*)?\.jar$//i'
}
# 获取监听端口的 PID
get_pid(){
lsof -ti :$PORT
}
# 停止服务
stop(){
echo "正在停止监听 ${PORT} 端口的进程..."
local pids=$(get_pid)
if [[ -n "$pids" ]]; then
echo "发现进程 PIDs: $pids"
kill -9 $pids
echo "进程已终止"
else
echo "未找到运行中的进程"
fi
}
# 启动服务
start(){
if [[ ! -f "$JAR_FILE" ]]; then
echo "错误：JAR 文件不存在 [$JAR_FILE]"
exit 1
fi
local existing_pids=$(get_pid)
if [[ -n "$existing_pids" ]]; then
echo "错误：应用已在运行 (PIDs: $existing_pids)"
exit 1
fi
local jar_prefix=$(extract_jar_prefix)
local prefix=${LOG_PREFIX:-$jar_prefix}
mkdir -p "$LOG_DIR"
local timestamp=$(date "+%Y%m%d-%H%M%S")
local log_file="${LOG_DIR}/${prefix}-${timestamp}.log"
echo "启动 Java 应用 [$JAR_FILE]..."
nohup java -Xms512m -Xmx512m -Xmn256m -XX:SurvivorRatio=6 -jar "$JAR_FILE">> "$log_file" 2>&1 &
echo "✔ 应用已启动"
echo "▷ 日志文件：$(pwd)/$log_file"
echo "▶︎ 实时日志查看：tail -f $log_file"
}
# 重启服务
restart(){ stop sleep 2 start }
# 命令入口
case "$1" in
start) start ;;
stop) stop ;;
restart) restart ;;
*)
echo "使用方法：$0 {start|stop|restart}"
exit 1
;;
esac
exit 0
7.2.3 构建查看日志
首先，需要先在服务器中添加后端 jar 文件启动脚本 start_jenkins-ci-demo.sh
# 创建后端工作目录
mkdir -p /home/project/jenkins/jenkins-ci-demo-backend/
# 进入工作目录
cd /home/project/jenkins/jenkins-ci-demo-backend/
接着添加 jar 文件启动脚本 start_jenkins-ci-demo.sh：
# 编辑脚本 (添加 7.2.2 小节中的后端 jar 文件启动脚本)
sudo vim start_jenkins-ci-demo.sh
进行脚本赋权：
chmod +x start_jenkins-ci-demo.sh
授权后，脚本便会显示为绿色（即可执行脚本）
接下来打开 jenkins 中的后端项目 dev-gitlab-jenkins-ci-demo-backend，进入配置页面，填写构建脚本（7.2.2 小节中的）：
点击构建，查看控制台日志输出：
为了方便测试后端接口是否能够正常访问，接下来我们需要开放一下后端访问端口：
# 开放 8080 端口
firewall-cmd --zone=public --add-port=8080/tcp --permanent
# 重新加载防火墙配置
firewall-cmd --reload
让我们访问一下后端的 Api 接口进行测试：
# 注意 此处 IP 地址应修改为您的服务器地址
http://192.168.184.133:8080/api/info
可以看到成功访问啦！
7.2.4 提交代码测试 Jenkins 构建
为了确保后端可以正确的拉取最新提交的 git 代码，这边简单修改一下后端接口返回的信息，咱们把后端接口 V1.0：
让我们再次构建 Jenkins，查看最新日志：
构建结果如下：
成功启动啦，接下来测试一下后端 API 接口，看看是否更新最新接口信息：
可以看到接口返回的信息成功从 1.0 变为 2.0 啦！
8. 修改 Nginx 配置联通前后端
8.1 内网联通前后端
在修改 nginx 之前，请求前端的时候，打开开发者模式可以看到：
从图中可以看到，前端请求的地址是 http://192.168.184.133/api/info，而后端的地址为 http://192.168.184.133:8080/api/info，所以需要进行 nginx 反向代理，让我们修改一下 nginx 配置：
# 编辑 nginx 配置
sudo vim /usr/local/nginx/conf/nginx.conf
nginx 配置修改如下：
server {
listen 80;
server_name localhost;
# 前端页面静态资源路径
location / {
root /home/project/jenkins/jenkins-ci-demo-frontend;
index index.html index.htm;
try_files $uri $uri/ /index.html;
# 支持前端路由（如 Vue/React）
}
# 反向代理 /api 到后端服务 http://192.168.184.133:8080
location /api/ {
proxy_pass http://192.168.184.133:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# 错误页面配置
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
修改后如图：
接着刷新一下 nginx 配置：
# 刷新 nginx 配置
/usr/local/nginx/sbin/nginx -s reload
再次访问前端页面：
已经可以正常联通后端啦！
8.2 远程访问前端项目（内网穿透）
8.2.1 配置 HTTP 隧道绑定到 80 端口
登录到管理端，点击左侧菜单栏的隧道管理，展开进入隧道列表页面，页面下默认会有 2 个隧道：
- ssh 隧道，指向 22 端口，tcp 协议
- website 隧道，指向 8080 端口，http 协议（http 协议默认会生成 2 个公网地址，一个是 http，另一个 https，免去配置 ssl 证书的繁琐步骤）
来到侧边栏的隧道管理 > 创建隧道表单，填写隧道信息如下：
接着来到侧边栏状态 > 在线隧道列表，可以看到 2 条隧道信息：
8.2.2 访问公网地址验证前端是否可访问
一条协议为 http 的，另一条为 https 协议，让我们浏览器访问测试一下，以 https 为例：
可以正常访问，接着测试一下功能请求 Api：
8.2.3 设置固定二级子域名
使用工具为其配置二级子域名，该域名为固定格式域名，不会随机变化，方便远程访问前端项目。
进入官网的预留页面。
列表中显示了一条已保留的二级子域名记录：
- 地区：显示为 China Top。
- 二级域名：显示为 jenkinscidemo。
注：二级域名是唯一的，每个账号都不相同，请以自己设置的二级域名保留的为主。
进入侧边菜单栏的隧道管理 > 隧道列表，可以看到前面配置名为 jenkins-ci-demo-80 的隧道
点击编辑按钮进入编辑页面，修改域名类型为二级子域名，然后填写前面配置好的子域名，点击更新按钮：
来到状态菜单下的在线隧道列表可以看到隧道名称为 jenkins-ci-demo-80 的公网地址已经变更为二级子域名 + 固定域名主体及后缀的形式了：
g)
这里以 https 协议做访问测试：
访问成功，这样一个固定不变的域名就设置好啦！
9. Webhook 自动触发 Jenkins 构建
本节主要演示：通过 GitLab Webhook 远程触发 Jenkins 自动构建。 这种方式适用于将代码提交或推送到 GitLab 仓库后，自动通知 Jenkins 进行构建部署，实现持续集成（CI）流程自动化。
**说明：**本教程以 GitLab 为例，Gitee、GitHub 等代码仓库平台的 Webhook 配置方式与 GitLab 类似，仅在触发 URL 和权限管理等细节上略有差异，不再一一赘述。后续你可以根据相同思路，配置 Gitee/GitHub 的 webhook 即可实现同样效果。前端项目使用'自由风格（Freestyle）构建任务'，后端使用'Maven 项目'，这两种 Jenkins 任务类型都支持通过 webhook 插件触发。配置方式大同小异，因此本节采用前端项目进行演示，不重复分别演示前后端项目。
9.1 安装 Generic Webhook Trigger 插件
点击首页右上角设置图标按钮 > 找到 System Configuration 下的 Plugins 模块，点击进去选择 Available plugins，然后搜索 Generic Webhook Trigger 插件：
安装好后，选择前端项目 dev-gitlab-jenkins-ci-demo-frontend 进入项目配置，菜单选择 Triggers，如图：
填写完成后，直接点击 Save 保存即可，webhook 地址格式如下：
# 如：http://jenkins.cpolar.top/generic-webhook-trigger/invoke
http://JENKINS_URL/generic-webhook-trigger/invoke
接着，来到 gitlab，打开前端项目，然后依次选择：Settings > Webhooks
来到 webhooks 配置页面。填写相关信息：
填写完成相关信息后，点击 Add webhook，然后滚动到底部可以进行简单的测试：
回到 jenkins 中可以看到，配置了 webhook 的项目工程被 gitlab 推送事件触发了构建：
日志如下：
9.2 修改代码提交 gitlab 测试推送事件
在本地修改前端代码，进行推送：
打开 jenkins 可以看到，本地进行 git push 操作时，gitlab 向 jenkins 发送了推送事件，触发了 jenkins 的自动构建：
控制台日志如下：
查看剩余日志，可以看到脚本流水线自动化部署完成：
访问前端网页，查看效果是否更新：
好啦！现在每次向 GitLab 提交代码后，Jenkins 就会通过 Webhook 自动开始构建，无需手动操作。
10. 总结
本教程完整演示了在 CentOS 7 服务器上搭建 Jenkins 自动化部署平台并通过内网穿透实现公网触发的全过程。
主要实现步骤包括：
- Jenkins 2.x 的安装与 Java 环境配置
- 内网穿透工具的部署与服务配置
- Jenkins 用户权限管理与角色分配
- HTTP 隧道创建与公网地址生成
- 固定二级子域名设置
- GitHub、Gitee、GitLab 多平台项目集成
- 前端 Vue 项目自动化构建与 Nginx 部署
- 后端 Maven 项目自动化构建与 Jar 包部署
- Webhook 自动触发机制配置与测试验证
这套解决方案实现了完整的 CI/CD 流程，既保障了代码的持续集成与自动化部署，又提供了便捷的远程访问环境，适用于企业内部开发、个人项目管理以及团队协作等多种场景。通过内网穿透，即使在没有公网 IP 的环境下，也能实现专业级的自动化部署体验。
11. 项目源码
本教程使用的前后端分离演示项目已开源，展示了完整的 Jenkins CI/CD 自动化部署流程。
前端项目（Vue 3 + Vite + Element Plus）：
- 开源地址：https://github.com/TanChengBin/jenkins-ci-demo-frontend
- 技术栈：Vue 3.x + Vite + Element Plus
- 功能：演示 Jenkins 前端项目自动化构建与部署
后端项目（Spring Boot + Maven）：
- 开源地址：https://github.com/TanChengBin/jenkins-ci-demo
- 技术栈：Spring Boot 2.7 + Maven
- 功能：提供 RESTful API 接口，演示后端自动化构建与部署
总结来说，Jenkins 凭借自动化能力解决了代码构建部署的重复性工作，让开发者从机械操作中解脱出来，而内网穿透工具则弥补了 Jenkins 仅能内网使用的短板，通过内网穿透实现了公网远程访问和操作。二者结合，不管是个人开发者多设备同步开发，还是中小企业团队协同部署，都能贴合实际开发场景解决痛点，让代码从提交到上线的全流程更顺畅，是提升日常开发效率的实用组合。
更多内网穿透解决方案，请访问相关工具官网。