Linux 上使用 yum 安装 Jenkins 的完整指南：从环境准备到彻底卸载

1. 为什么在 Linux 上首选 yum 装 Jenkins

很多刚接触持续集成的朋友，第一次在 Linux 上装 Jenkins 时，第一反应往往是去官网下载 war 包，然后java -jar jenkins.war一把梭。这个做法本身没错，临时跑个 Demo 完全够用，但一旦你要把它当成团队里长期在线的构建服务，问题就来了：进程怎么守护、开机怎么自启、日志往哪写、升级怎么平滑替换、端口冲突怎么改。这些琐事会一点点吃掉你的时间。

yum 安装的核心价值，就是把这些运维层面的脏活累活交给包管理器。它帮你把 Jenkins 注册成系统服务，帮你处理好依赖，帮你把配置、数据、日志分门别类放到标准目录里。你只需要systemctl start jenkins，剩下的它都替你兜住了。这也是为什么在基于 RPM 的发行版上，只要条件允许，我都会优先推荐 yum 这条路。

不过这里有个前提得说清楚：Jenkins 官方仓库里其实并没有直接可用的 jenkins 包，你需要先引入官方提供的仓库定义文件，才能用 yum 去装。很多人卡在第一步，就是因为直接yum install jenkins报 “No package jenkins available”，然后就开始怀疑人生。这不是你操作错了，而是仓库没配。

这篇文章我会把整个链路拆开讲：从环境确认、仓库引入、安装、初始化解锁，到端口调整、目录结构理解，再到彻底卸载时哪些目录必须手动清理。中间会穿插一些我实际踩过的坑，比如 Java 版本不匹配导致服务起不来、卸载后重装发现旧配置还在导致行为诡异等等。目标很明确：让你看完就能在自己的机器上完整走一遍，装得干净，卸得彻底。

提示：本文所有操作基于常见的 RPM 系发行版（如 CentOS、Rocky Linux、AlmaLinux 等），不同大版本之间细节略有差异，我会在关键处标注。

2. 装之前先把这几件事确认清楚

2.1 Java 环境是硬门槛

Jenkins 是 Java 写的，没有 JDK 或 JRE 它寸步难行。而且不同版本的 Jenkins 对 Java 版本要求不一样，这一点必须先确认，否则装完了服务起不来，日志里一堆UnsupportedClassVersionError，排查起来很烦。

比较稳妥的做法是先看系统里有没有 Java，版本是多少：

java -version

如果输出类似openjdk version "17.0.x"这种，基本没问题。如果提示 command not found，那就得先装。用 yum 装 OpenJDK 很直接：

sudo yum install -y java-17-openjdk java-17-openjdk-devel

装完再java -version验证一下。这里有个经验：尽量装 devel 版本，虽然 Jenkins 本身运行只需要 JRE，但很多构建任务里会调用javac编译代码，只装 JRE 到时候构建失败你还得回来补。

2.2 确认系统架构和发行版版本

引入仓库前，最好确认一下自己的系统底细，因为仓库文件里的baseurl有时候和发行版大版本挂钩：

cat /etc/os-release uname -m

uname -m输出x86_64说明是 64 位，这是主流情况。如果是aarch64，那仓库地址可能要用不同的路径，得去官方仓库页面确认对应架构的配置。这一步很多人跳过，结果仓库配好了却拉不到包，白白浪费时间。

2.3 网络与时间同步

Jenkins 仓库在国内访问速度时好时坏，如果拉取超时，先别急着怀疑配置，多半是网络问题。可以先用curl探一下仓库地址通不通。另外，系统时间一定要准，时间偏差过大在后续解锁、插件下载、证书校验环节都可能出幺蛾子。用timedatectl看一眼，必要时开启自动同步。

2.4 端口占用预检

Jenkins 默认监听 8080。这个端口太热门了，Tomcat、各种中间件、甚至一些开发工具都爱用它。装之前先查一下：

sudo ss -tlnp | grep 8080

如果有输出，说明被占了，要么停掉占用方，要么待会儿改 Jenkins 端口。提前查比装完发现起不来再回头查要省事得多。

3. 引入官方仓库并完成安装

3.1 添加 Jenkins 仓库定义

Jenkins 官方提供了一个仓库文件，最省事的做法是直接下载到 yum 的仓库目录：

sudo wget -O /etc/yum.repos.d/jenkins.repo \ https://pkg.jenkins.io/redhat-stable/jenkins.repo

这里选redhat-stable而不是redhat，是因为 stable 通道的更新节奏更保守，适合生产环境。如果你就是想尝鲜新特性，可以换成非 stable 的通道，但我不太建议在正式构建机上这么干。

下载完仓库文件后，还得导入 GPG 密钥，否则 yum 会因为无法验证包签名而拒绝安装：

sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io-2023.key

注意密钥文件名会随时间更新，如果这个 key 拉不到，去官方仓库页面找当前有效的 key 地址替换即可。这一步是很多人漏掉的，漏了之后安装时会报签名验证失败。

3.2 执行安装

仓库和密钥都就位后，安装就一行命令：

sudo yum install -y jenkins

yum 会自动解析依赖、下载包、完成安装，并且把 Jenkins 注册成 systemd 服务。装完之后可以确认一下服务状态：

systemctl status jenkins

这时候大概率是inactive (dead)，正常，因为还没启动。

3.3 启动服务并设置开机自启

sudo systemctl start jenkins sudo systemctl enable jenkins

enable这一步别省，否则机器重启后 Jenkins 不会自己起来，团队第二天早上发现构建全挂了，这种事故我见过不止一次。

启动后再看状态，应该是active (running)。如果起不来，直接看日志：

sudo journalctl -u jenkins -n 50 --no-pager

日志会明确告诉你原因，常见的就是 Java 版本不对或者端口被占。

3.4 放行防火墙端口

如果系统开了 firewalld，外部访问 8080 会被拦：

sudo firewall-cmd --permanent --add-port=8080/tcp sudo firewall-cmd --reload

这一步不做，你会遇到“本机 curl 能通、浏览器打不开”的经典现象，别问我怎么知道的。

4. 初始化解锁与首次配置

4.1 拿到初始管理员密码

Jenkins 首次启动会生成一个初始密码，放在特定文件里：

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

复制这串字符，浏览器访问http://你的服务器IP:8080，粘贴进去解锁。这个文件在完成初始化向导后会被清空或失效，所以别指望以后还能从这里翻密码。

4.2 插件安装策略怎么选

解锁后会让你选“安装推荐的插件”还是“自定义”。我的建议是：第一次装就选推荐插件。它会一次性把 Git、Pipeline、凭据管理等常用插件装好，省得你后面一个个补。虽然下载过程可能比较慢，但这是值得等的。

如果网络实在不给力，插件下载卡住，可以跳过，进系统后到插件管理里换镜像源再装。换源的位置在“Manage Jenkins -> Plugins -> Advanced settings”里，把更新站点 URL 换成国内可达的镜像即可。

4.3 创建管理员账号

向导最后会让你建第一个管理员用户。这里别偷懒直接跳过用 admin，老老实实设一个强密码账号。Jenkins 的权限体系后面可以细化，但初始管理员账号是根基，设得随意了后面麻烦。

4.4 实例地址确认

向导里有个“Jenkins URL”的配置，默认是http://IP:8080/。如果你后面要通过域名访问，或者前面挂了反向代理，这里要填对，否则邮件通知、构建回链里的地址全是错的。这个值后面也能在系统配置里改，但一开始就填对能省事。

5. 目录结构与关键配置项解读

5.1 各目录都装了什么

yum 安装的 Jenkins 目录布局很规整，理解它对你后续排查和迁移都有帮助：

最关键的是/var/lib/jenkins/，你所有的任务数据都在这里。做备份、做迁移，核心就是备份这个目录。反过来，卸载时如果不清这个目录，重装后会发现旧任务、旧用户全都还在，行为会很诡异。

5.2 改端口和 JVM 参数

端口配置在服务配置文件里，找到JENKINS_PORT这一项改掉即可。改完记得systemctl daemon-reload再重启服务，否则改动不生效。

JVM 内存参数也在同一个文件里，通常通过JAVA_ARGS或JENKINS_JAVA_OPTIONS传入。默认堆内存可能偏小，任务一多就容易 OOM。根据机器内存适当调大，比如给个-Xmx2g。这里的原则是：别超过物理内存的一半，给操作系统和其他进程留足空间。

5.3 服务运行用户

Jenkins 服务默认以jenkins用户运行，这个用户在安装时自动创建。这意味着它对你 home 目录下的东西没有权限，构建脚本里如果引用了只有 root 能读的文件就会失败。理解这一点，能帮你快速定位很多“权限拒绝”类报错。

6. 卸载：比安装更需要讲究的事

6.1 先停服务再卸载

卸载第一步永远是停服务，别在运行状态下直接删包：

sudo systemctl stop jenkins sudo systemctl disable jenkins

disable是为了防止残留的服务单元在重启时又被拉起来。

6.2 用 yum 移除包

sudo yum remove -y jenkins

注意，yum remove只会删掉包本身和它注册的服务文件，不会动/var/lib/jenkins/里的数据。这是包管理器的通用设计，防止误删用户数据。所以如果你是想彻底清干净，还得手动处理。

6.3 手动清理残留目录

彻底卸载要清掉这几处：

sudo rm -rf /var/lib/jenkins sudo rm -rf /var/cache/jenkins sudo rm -rf /var/log/jenkins

还有仓库文件和密钥，如果不再需要也一并清掉：

sudo rm -f /etc/yum.repos.d/jenkins.repo

以及那个jenkins系统用户，如果确认没有其他用途：

sudo userdel jenkins

注意：删/var/lib/jenkins是不可逆的，所有任务配置、构建历史、凭据都会消失。执行前务必确认你不需要里面的任何东西，或者已经做好了备份。

6.4 卸载后重装的常见坑

我遇到过好几次这样的情况：卸载了 Jenkins，重装后一进系统发现旧任务还在，或者初始密码文件读不到，或者端口配置还是老的。原因就是/var/lib/jenkins没清。包管理器不背这个锅，是你没清数据目录。

还有一种情况是重装后服务起不来，报用户已存在或权限错误，多半是jenkins用户被删了但目录还在，属主变成了一个不存在的 UID。这时候要么重建用户，要么把目录属主改对。所以我的建议是：要么完整保留数据做升级，要么彻底清干净重来，别搞半吊子。

7. 几个我实际踩过的坑和应对

7.1 Java 版本升级后服务起不来

系统里 Java 被升级或切换了默认版本，Jenkins 重启后直接挂掉。日志里能看到类版本不兼容的报错。解决办法是确认 Jenkins 支持的 Java 版本范围，把默认 Java 切回去，或者在服务配置里显式指定 Java 路径。这个坑的根源在于：Jenkins 用的是系统默认 Java，而系统默认 Java 可能被别的操作改掉了。

7.2 磁盘被构建记录撑爆

/var/lib/jenkins会随着构建次数增长不断膨胀，尤其是保留了大量历史构建且没配清理策略的时候。我见过一个实例，几个月没管，这个目录涨到几十 G，直接把分区写满，导致 Jenkins 无法写入而崩溃。应对办法是在任务配置里设置“保留最近 N 次构建”，并定期清理旧的构建记录。这个设置每个任务都要配，别指望有全局默认帮你兜底。

7.3 插件更新把服务搞挂

插件是 Jenkins 生态的双刃剑。某个插件更新后和核心版本不兼容，可能导致启动失败。我的经验是：生产环境的插件更新要谨慎，更新前先备份/var/lib/jenkins，出问题能快速回滚。别在周五下午手贱点全量更新。

7.4 端口改了但访问还是老端口

改了配置文件里的端口，重启后访问新端口不通，老端口反而还通。这通常是因为改了配置文件但没daemon-reload，或者改错了文件（不同发行版配置文件路径不同，可能有两个文件，改了一个另一个还在生效）。排查时把相关配置文件都看一遍，确认改的是真正被加载的那个。

8. 关于备份与迁移的一点个人做法

既然聊到了目录结构，顺带说下备份。我的习惯是定期打包/var/lib/jenkins，但打包前先停服务，避免打包过程中文件正在被写入导致数据不一致。如果服务不能停，至少要用支持一致性快照的方式，或者接受轻微不一致的风险。

迁移到新机器时，流程是：新机器装好同版本 Jenkins，停服务，把备份的/var/lib/jenkins覆盖过去，注意属主属组要设成jenkins，然后启动。版本尽量保持一致，跨大版本直接覆盖数据目录有风险，官方推荐的是用专门的升级路径。

这套流程我跑过很多次，只要版本对齐、权限设对，基本一次成功。真正容易出问题的反而是那些“看起来无关紧要”的小配置，比如实例 URL、时区、邮件服务器，迁移后记得逐项核对一遍。

最后分享一个小技巧：如果你只是想在本地快速验证某个流水线脚本，完全没必要在服务器上折腾 yum 安装，直接下载 war 包用java -jar跑一个临时实例，用完即删，干净利落。yum 安装适合的是那种要长期稳定运行、需要开机自启和服务守护的场景。搞清楚自己的需求，再决定用哪种方式，能省下不少无谓的折腾。