引言部署 Jenkins 之前在若依项目的治理系列中我们已经完成了用户体系构建、权限管控、LVM存储规划和日志分析体系——目录有归属了权限有边界了日志有可追溯性了。这时候一个顺理成章的问题浮出水面谁来负责持续集成谁来把若依项目的代码自动构建、自动部署Jenkins正是回答这个问题的工具。一、为什么 Jenkins 需要“被治理”很多人在部署 Jenkins 时往往只关注怎么让它跑起来”而忽略了另一个同样重要的问题它要跑多久怎么让它持续跑前台运行java -jar jenkins.war确实能启动 Jenkins但问题也接踵而至运行方式是否持久是否自愈是否可控java -jar前台❌ 关闭终端即停❌ 崩溃即死❌ 需手动重来nohup ... 后台✅ 可后台运行❌ 崩溃即死⚠️ 难管理Systemd 服务✅ 开机自启✅ 自动重启✅ 统一管理在前面的若依项目治理中我们已经用 Systemd 管理了 Nginx 和 MariaDB。Jenkins 也应该享有同样的“待遇”——它不是一次性的任务而是持续的自动化基础设施。部署 Jenkins 的方式决定了它成为“工具”还是“负担”。二、环境准备Java 是第一道门槛Jenkins 是用 Java 编写的所以部署 Jenkins 的第一步永远是安装 Java。2.1 安装 JDK 25杨哥提示Jenkins 需要 JDK 11 或更高版本。在 Rocky Linux 上我们统一使用 JDK 25。[rootmagedu ~]# dnf install -y java-25-openjdk-headless验证安装[rootmagedu ~]# java -versionopenjdk version25.0.32026-04-21 LTS OpenJDK Runtime Environment(Red_Hat-25.0.3.0.9-1)(build25.0.39-LTS)OpenJDK64-Bit Server VM(Red_Hat-25.0.3.0.9-1)(build25.0.39-LTS, mixed mode, sharing)2.2 一个容易被忽略的问题字体如果使用 Rocky Linux 最小化安装启动 Jenkins 时可能会遇到这个错误java.lang.RuntimeException: Fontconfig head is null, check your fonts or fonts configuration这是因为 Jenkins 的 Web UI 需要渲染字体而最小化安装没有字体包。解决方法dnfinstall-yfontconfig dejavu-sans-fonts dejavu-serif-fonts三、下载 Jenkins镜像源的选择# 创建目录[rootmagedu ~]# mkdir -p /opt/jenkins# 下载清华镜像源速度快[rootmagedu ~]# wget -O /opt/jenkins/jenkins.war https://mirrors.tuna.tsinghua.edu.cn/jenkins/war-stable/latest/jenkins.war为什么用清华镜像源因为 Jenkins 官方下载速度不稳定而国内的镜像站提供了稳定的加速通道。四、演示一直接启动Java -jar[rootmagedu ~]# cd /opt/jenkins[rootmagedu ~]# java -jar jenkins.war启动后浏览器访问http://服务器IP:8080看到 Jenkins 解锁页面说明启动成功。初始密码获取[rootmagedu ~]# cat /root/.jenkins/secrets/initialAdminPassword0ba21e9c86cb470d8daff75ded044ece优缺点分析优点缺点快速验证关闭终端即停止适合测试无法开机自启调试方便崩溃无人管五、演示二Systemd 服务——把 Jenkins 变成“基础设施”如果 Jenkins 只用于临时测试java -jar就够了。但如果 Jenkins 要作为若依项目持续集成的核心工具就必须把它变成可管理、可自愈的系统服务。5.1 创建服务文件[rootmagedu ~]# vim /etc/systemd/system/jenkins.service填入以下内容[Unit] DescriptionJenkins Continuous Integration Server Afternetwork.target [Service] Typesimple Userroot Grouproot WorkingDirectory/opt/jenkins ExecStart/usr/bin/java -jar /opt/jenkins/jenkins.war Restarton-failure RestartSec10 [Install] WantedBymulti-user.target各部分说明部分参数含义[Unit]Description服务描述[Unit]Afternetwork.target网络就绪后再启动[Service]Typesimple默认类型主进程就是服务进程[Service]WorkingDirectory工作目录[Service]ExecStart启动命令[Service]Restarton-failure崩溃后自动重启[Service]RestartSec10重启前等待10秒[Install]WantedBymulti-user.target开机自启5.2 启动并验证# 重新加载 systemd 配置[rootmagedu ~]# systemctl daemon-reload# 启动服务[rootmagedu ~]# systemctl start jenkins# 开机自启[rootmagedu ~]# systemctl enable jenkins# 查看状态[rootmagedu ~]# systemctl status jenkins.service状态输出示例● jenkins.service - Jenkins Continuous Integration Server Loaded: loaded (/etc/systemd/system/jenkins.service; enabled) Active: active (running) since Thu 2026-07-23 02:28:32 CST; 14s ago Main PID: 4394 (java) Memory: 138.7M CGroup: /system.slice/jenkins.service └─4394 /usr/bin/java -jar /opt/jenkins/jenkins.war5.3 防火墙配置# 开放端口[rootmagedu ~]# firewall-cmd --permanent --add-port8080/tcpsuccess[rootmagedu ~]# firewall-cmd --reloadsuccess# 确认已开放[rootmagedu ~]# firewall-cmd --permanent --list-allports:8080/tcp六、演示三崩溃自动重启Restarton-failure 实战Systemd 的Restarton-failure可以让 Jenkins 在崩溃时自动恢复。6.1 验证服务正在运行[rootmagedu ~]# systemctl status jenkins.service● jenkins.service - Jenkins Continuous Integration Server Active: active(running)since Thu2026-07-23 02:28:32 CST;5min ago6.2 获取进程 PID[rootmagedu ~]# ps aux | grep jenkins.war | grep -v greproot43942.311.33802996420072? Ssl 02:280:09 /usr/bin/java-jar/opt/jenkins/jenkins.war6.3 模拟崩溃[rootmagedu ~]# kill -9 43946.4 查看自动恢复等待几秒后再次查看状态[rootmagedu ~]# systemctl status jenkins.service● jenkins.service - Jenkins Continuous Integration Server Active: active(running)since Thu2026-07-23 02:35:30 CST;3s ago Main PID:4709(java)Memory:141.3M关键结论kill -9强制杀死了 Jenkins 进程但 systemd 在 10 秒后自动启动了一个新的 Jenkins 进程PID 从 4394 变为 4709。在生产环境中这种自动恢复能力意味着即使 Jenkins 因内存溢出或意外崩溃而退出系统也会自动拉起它无需人工介入。七、从 Java -Jar 到 Systemd治理逻辑的延续回顾若依项目治理系列的核心脉络Jenkins 的部署方式变化不是技术升级而是治理思维的延展。治理阶段核心内容Jenkins 对应操作用户治理告别共用 rootJenkins 进程以 root 运行端口管控防火墙开放端口firewall-cmd --add-port8080/tcp目录治理/opt/ruoyi标准化/opt/jenkins作为安装目录服务治理Nginx/MySQL 用 Systemd 管理Jenkins 用 Systemd 管理自愈能力服务异常自动恢复Restarton-failure可观测性日志可追溯systemctl statusjournalctl核心思路一致把 Jenkins 从“手动运行的一次性工具”变成“可管理、可自愈、可追溯的系统服务”。八、故障排查速查问题检查方法解决方案启动失败systemctl status jenkinsjournalctl -u jenkins -n 50端口被占用netstat -tlnpgrep 8080字体缺失java -jar报 Fontconfig 错误dnf install fontconfig dejavu-sans-fonts防火墙未放行curl localhost:8080失败firewall-cmd --add-port8080/tcp初始密码找不到cat报错确认 Jenkins 已启动等待几秒再试九、总结Jenkins 的部署看似简单但部署方式的选择决定了它在生产环境中的可靠性。通过 systemd 服务化部署我们实现了持久化运行开机自启终端关闭不影响自动恢复进程崩溃后自动重启统一管理与系统其他服务统一管理可观测性通过 systemd 工具链监控状态。这正是若依项目治理系列的核心思想将临时工具转变为可持续的基础设施。Jenkins 作为持续集成的核心值得这样的“待遇”。三条核心结论部署方式决定工具属性。java -jar让 Jenkins 成为“运行一次的工具”Systemd 让 Jenkins 成为“长期服役的基础设施”。若依项目需要的是后者。治理是可复用的方法论。若依项目目录用 750 保护配置防火墙用--add-port开放端口服务用systemctl统一管理——这些操作不仅适用于若依同样适用于 Jenkins。治理不是一次性工程而是一套可复用的标准化动作。Restarton-failure 是最低成本的运维保障。Systemd 的自动重启机制是生产环境服务治理的基石。它不需要写任何监控脚本不需要额外部署告警系统仅仅是三行配置Restarton-failure、RestartSec10就能实现崩溃自动恢复。这是性价比最高的运维投入。标准化的目录是骨骼安全的权限是肌肉日志与审计是神经系统——而 Systemd 服务治理则是让 Jenkins 这条持续集成的生产线能够稳定运行的关节。当 Jenkins 成为 Systemd 服务后它不仅有了“家”/opt/jenkins有了“门禁”防火墙端口有了“健康检查”systemctl status还有了“自愈能力”Restarton-failure——它不再是孤立的工具而是融入若依项目治理体系的基础设施组件。下一步就是用 Jenkins 把若依项目的 CI/CD 流水线搭建起来。本文是若依项目Linux生产环境治理系列之 Jenkins 部署篇。系列其他文章覆盖用户权限治理、目录结构规范化、sudo 精细化权限管控、LVM 存储管理、日志分析与正则实战等内容构建了一套从底层存储到上层应用的完整治理方法论欢迎关注。
