企业官网建设流程全解析

1. 为什么我还在用 yum 装 Jenkins

先把结论摆在前面：如果你手头是一台干净的 CentOS 或者 Rocky、Alma 这类 RHEL 系的机器，想最快把 Jenkins 跑起来，yum这条路依然是性价比最高的选择。原因很朴素——Jenkins 官方维护了稳定的 RPM 仓库，装完之后服务托管、开机自启、日志归集这些事系统都帮你打理好了，你不需要额外去操心进程守护，也不用自己写 systemd 单元文件。

我自己这些年折腾过不少装法：war 包直接java -jar跑、Docker 容器跑、K8s 里跑，甚至源码编译过。每种方式都有它的适用场景，但如果目标只是"在一台内网构建机上快速拉起一个能用的 Jenkins"，那 yum 安装的体验是最顺滑的。它把依赖、用户、目录、服务这几件事一次性处理干净，你敲完命令等两分钟，浏览器打开 8080 端口就能看到解锁界面。

这篇文章我打算把两件事讲透：一是怎么用 yum 把 Jenkins 装好并且能正常用起来，二是怎么把它卸干净。别小看卸载这一步，很多人装的时候顺风顺水，卸的时候发现残留一堆目录和用户，下次重装就出各种诡异问题。我会把每一步背后的逻辑、参数选择的原因、以及我踩过的坑都摊开讲，你照着做基本不会翻车。

适合谁看？刚接触 CI/CD 想搭个环境练手的、运维同学要给团队配构建机的、还有那些装完发现端口冲突或者 Java 版本不对想重来的。只要你的系统是 RHEL 系，这篇都能直接用。

2. 装之前必须搞清楚的几件事

2.1 系统与 Java 环境的硬性前提

Jenkins 是个 Java 应用，这一点决定了它对 JDK 有强依赖。不同版本的 Jenkins 对 Java 版本要求不一样，这是最容易踩的坑。较新的 Jenkins 版本（比如 2.4xx 之后的 LTS）普遍要求Java 11 或 Java 17，如果你系统里还是 Java 8，装完启动会直接报错退出，日志里会明确告诉你版本不满足。

所以第一步不是急着加仓库，而是先确认 Java 环境：

java -version

如果输出显示是 1.8 或者根本没装，那就先处理 Java。RHEL 系装 OpenJDK 很直接：

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

装完再用java -version确认一遍。这里有个细节：java-17-openjdk是运行环境，java-17-openjdk-devel是开发包，Jenkins 本身跑起来只需要前者，但如果你后续要在构建机上编译 Java 项目，devel 包是必须的，索性一起装上省事。

提示：如果你机器上同时存在多个 Java 版本，用alternatives --config java可以切换默认版本。Jenkins 启动时读的是系统默认的那个，别装完了发现它用的还是老的。

2.2 网络与仓库源的现实考量

Jenkins 官方仓库地址是https://pkg.jenkins.io/，它分redhat和redhat-stable两个目录。前者是每周更新的最新版，后者是 LTS 稳定版。生产环境我一律建议用 stable，因为最新版偶尔会有插件兼容性问题，LTS 经过更长时间的验证，踩雷概率低得多。

但现实问题是，官方源在国内访问速度经常不理想，yum install的时候卡在下载环节是常事。这时候有两个思路：一是配置系统级的代理（这个属于网络配置范畴，具体方式因环境而异），二是找国内镜像源替换。很多高校和企业都维护了 Jenkins 的镜像，把仓库地址换成镜像地址，下载速度能快一个数量级。

替换的方式很简单，就是改/etc/yum.repos.d/jenkins.repo里的baseurl。不过要注意，镜像同步有延迟，可能比官方源晚几个小时到一天，对版本不是极度敏感的场景完全够用。

2.3 端口与防火墙的提前规划

Jenkins 默认监听8080端口。这个端口太常用了，很多机器上已经被别的服务占了（比如 Tomcat、某些监控 agent）。装之前先查一下：

ss -tlnp | grep 8080

如果被占用，你有两个选择：换 Jenkins 端口，或者把占用端口的服务挪走。换端口的话，较新版本的 Jenkins 不再推荐改/etc/sysconfig/jenkins里的JENKINS_PORT（这个文件在新版本里已经被标记为废弃），而是通过 systemd 的 override 来改，具体做法我在第 3 章会讲。

防火墙这块，如果只是内网访问，把 8080 端口放行即可：

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

如果机器压根没开 firewalld，那这步可以跳过。我见过有人装完访问不了，排查半天发现是防火墙没放行，这种低级问题其实提前一分钟就能避免。

3. yum 安装 Jenkins 的完整实操

3.1 添加官方仓库的两种方式

最标准的做法是把 Jenkins 的仓库文件下载到/etc/yum.repos.d/目录下：

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

这个jenkins.repo文件内容大概长这样：

[jenkins] name=Jenkins-stable baseurl=https://pkg.jenkins.io/redhat-stable gpgcheck=1

注意gpgcheck=1表示要校验包的签名，这是安全性的保障，别为了图省事改成 0。要校验签名就得导入 Jenkins 的 GPG 公钥：

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

这里有个坑：Jenkins 在 2023 年更换过签名密钥，老教程里给的jenkins.io.key已经失效了，导入老 key 会导致yum install时报签名校验失败。如果你看到类似Public key for jenkins-xxx.rpm is not installed或者GPG check FAILED的报错，八成就是 key 用错了，换成上面这个 2023 版即可。

导入完 key，可以顺手验证一下仓库是否可用：

yum repolist | grep jenkins

能列出 jenkins 仓库就说明配置没问题。

3.2 执行安装与版本选择

仓库配好之后，安装命令就一行：

yum install -y jenkins

但这里有个值得说道的点：默认装的是最新版。如果你想要指定版本，比如团队统一用某个 LTS 版本，可以这样：

yum install -y jenkins-2.440.3-1.1

版本号从哪来？用yum list jenkins --showduplicates能看到仓库里所有可用版本。我个人的习惯是，团队环境里锁定版本，避免某天自动升级后插件不兼容导致构建全挂。锁定版本还有个好处是回滚方便，出问题直接装回上一个版本。

安装过程会自动处理依赖，主要是 Java 相关的。装完之后，Jenkins 会创建几个关键的东西：

/var/lib/jenkins这个目录要特别留意，它是 Jenkins 的"家"，所有任务配置、构建历史、插件都在里面。卸载时如果只删包不删这个目录，重装后会发现之前的配置还在，有时候这是好事，有时候会带来困惑。

3.3 启动服务与首次解锁

装完先别急着启动，确认一下 Java 版本匹配：

systemctl start jenkins systemctl enable jenkins

enable是为了开机自启，生产环境基本都要开。启动后看状态：

systemctl status jenkins

如果显示active (running)就说明起来了。如果显示failed，直接看日志：

tail -n 100 /var/log/jenkins/jenkins.log

最常见的失败原因就是 Java 版本不对，日志里会写Jenkins requires Java 11 or newer之类的话。

服务起来之后，浏览器访问http://机器IP:8080，会看到解锁界面，要求输入初始管理员密码。这个密码在：

cat /var/lib/jenkins/secrets/initialAdminPassword

复制粘贴进去，然后选择安装推荐插件。这一步会联网下载一堆插件，如果网络不好会卡很久，甚至部分插件下载失败。我的建议是：如果网络环境一般，先跳过插件安装，进到主界面之后再按需装，这样至少能先把 Jenkins 跑起来，不至于卡在初始化界面进退两难。

3.4 改端口和调整 JVM 内存的正确姿势

前面提到新版 Jenkins 改端口不能靠/etc/sysconfig/jenkins了。正确做法是用 systemd 的 override 机制：

systemctl edit jenkins

这会打开一个空的 override 文件，在里面写：

[Service] Environment="JENKINS_PORT=9090"

保存退出后重载并重启：

systemctl daemon-reload systemctl restart jenkins

内存调整也是同样的思路。Jenkins 默认的堆内存可能偏小，构建任务多的时候容易 OOM。通过 override 加 JVM 参数：

[Service] Environment="JAVA_OPTS=-Xms1g -Xmx2g -XX:MaxMetaspaceSize=512m"

-Xms是初始堆，-Xmx是最大堆，一般设成一样大能避免堆动态扩缩带来的性能抖动。MaxMetaspaceSize限制元空间，防止类加载过多把内存吃光。具体设多大取决于你的机器内存和构建规模，8G 内存的机器给 Jenkins 2G 堆是比较稳妥的起点。

注意：改完 override 一定要daemon-reload，否则 systemd 不认你的改动。这个坑我踩过不止一次，改完配置重启发现没生效，就是因为漏了这一步。

4. 卸载 Jenkins 与残留清理

4.1 停止服务与卸载软件包

卸载的第一步永远是停服务，别在服务运行的时候直接删包，容易留下锁文件或者半截状态：

systemctl stop jenkins systemctl disable jenkins

然后卸载包：

yum remove -y jenkins

yum remove会自动处理依赖关系，但要注意它不会删除/var/lib/jenkins这个数据目录。这是设计上的选择——包管理器只管软件包本身，用户数据它不碰。所以如果你是想彻底清干净重装，还得手动删目录。

4.2 清理残留目录、用户与配置

卸载包之后，残留主要有这么几块：

rm -rf /var/lib/jenkins rm -rf /var/log/jenkins rm -rf /var/cache/jenkins rm -f /etc/sysconfig/jenkins rm -f /etc/yum.repos.d/jenkins.repo

/var/lib/jenkins是数据，/var/log/jenkins是日志，/var/cache/jenkins是缓存，/etc/sysconfig/jenkins是旧配置，jenkins.repo是仓库文件。这几处清完，基本就干净了。

还有用户和用户组。安装时 Jenkins 会创建一个jenkins系统用户，卸载包通常不会删它：

userdel jenkins groupdel jenkins

如果userdel报错说用户正在被进程使用，用ps -u jenkins查一下有没有残留进程，杀掉再删。

4.3 验证是否卸载干净

清理完做一次全面检查，确认没有漏网之鱼：

rpm -qa | grep jenkins find / -name "*jenkins*" 2>/dev/null id jenkins

第一条应该没有任何输出，第二条可能会列出一些你手动创建的文件（比如备份），第三条应该提示用户不存在。三条都符合预期，才算真正卸干净。

我特别想强调find这条命令。有时候 Jenkins 的插件会在一些意想不到的地方留文件，比如/tmp下的临时目录、/root/.jenkins（如果你用 root 跑过）。用find扫一遍心里踏实，尤其是准备重装的时候，残留文件可能导致新装的实例读到旧配置，出现莫名其妙的登录问题。

5. 常见问题与排查速查

5.1 安装与启动阶段的典型故障

装 Jenkins 遇到的问题，八成集中在下面这几类。我整理成表格，方便对照排查：

关于"启动卡住"这个，补充一句。有些虚拟机环境熵池很小，Jenkins 启动时生成密钥会阻塞，表现就是日志停在某一行不动。装个haveged或者rng-tools能显著改善：

yum install -y haveged systemctl start haveged systemctl enable haveged

5.2 卸载不干净的排查思路

卸载后重装出现"配置还在"的情况，基本就是/var/lib/jenkins没删。还有一种更隐蔽的：Jenkins 的 systemd override 文件没删。这个文件在/etc/systemd/system/jenkins.service.d/目录下，yum remove不会碰它。如果你之前改过端口或内存，重装后这些 override 依然生效，可能导致新实例用了你意想不到的端口。

排查方法：

ls -la /etc/systemd/system/jenkins.service.d/

有文件就删掉，然后systemctl daemon-reload。

5.3 我踩过的几个真实坑

第一个坑是用 root 直接跑 Jenkins。早期图省事，直接java -jar jenkins.war用 root 跑，结果 Jenkins 在/root/.jenkins下建了一堆文件，后来改用 yum 装，数据目录变成/var/lib/jenkins，两套配置混在一起，排查起来非常痛苦。结论：永远用 yum 装的服务方式跑，别手动用 root 起 war 包。

第二个坑是磁盘空间。Jenkins 的构建历史、工作区、插件会持续吃磁盘，/var/lib/jenkins涨得很快。我有台机器没监控磁盘，某天构建全失败，一看根分区满了。后来养成习惯，把/var/lib/jenkins单独挂一个数据盘，或者至少加个磁盘告警。

第三个坑是时区。Jenkins 默认可能用 UTC，构建日志的时间戳和本地对不上，排查问题时很误导。改时区的方式是在 JVM 参数里加-Duser.timezone=Asia/Shanghai，同样通过 systemd override 设置。

6. 几个提升体验的实用配置

6.1 配置国内插件更新源

Jenkins 装完之后，插件管理页面默认从官方源拉更新列表，速度慢是常态。改插件源的位置在系统管理 -> 插件管理 -> 高级里的Update Site，把 URL 换成国内镜像地址即可。改完之后点立即获取，更新列表会快很多。

这个配置存在/var/lib/jenkins/updates/default.json和hudson.model.UpdateCenter.xml里，重装前如果备份了这两个文件，新环境可以直接覆盖，省得重新配。

6.2 设置构建保留策略

Jenkins 默认保留所有构建历史，时间一长磁盘就爆。在任务的配置里有个"丢弃旧的构建"选项，勾上之后可以设置保留天数和最大个数。我的习惯是保留最近 30 天、最多 50 个构建，既能追溯近期问题，又不会无限膨胀。

对于全局的默认策略，可以在系统管理 -> 系统配置里找到相关设置，不过更推荐在每个任务里单独配，因为不同任务的构建频率和产物大小差异很大。

6.3 备份与迁移的简单方案

Jenkins 的备份其实很简单，核心就是/var/lib/jenkins这个目录。停掉服务，打包这个目录，就完成了全量备份：

systemctl stop jenkins tar -czf jenkins-backup-$(date +%Y%m%d).tar.gz /var/lib/jenkins systemctl start jenkins

迁移到新机器时，新机器装好同版本 Jenkins，停服务，把备份解压覆盖到/var/lib/jenkins，注意权限要改回jenkins:jenkins，然后启动即可。版本尽量保持一致，跨大版本迁移可能遇到配置格式不兼容。

提示：备份前停服务是为了保证数据一致性，运行中直接打包可能拿到半截写入的文件。如果实在不能停，至少避开构建高峰期。

7. 关于版本锁定与升级的取舍

最后聊一个很多人纠结的问题：Jenkins 到底要不要升级。我的观点是生产环境锁定 LTS 版本，按季度评估升级，而不是跟着最新版跑。

理由很实际：Jenkins 的插件生态太庞大，核心升级经常导致部分插件不兼容，表现就是任务突然跑不了、界面报错。锁定版本能让你在一个已知稳定的组合上安心干活。升级前一定要在测试环境验证，重点看常用插件是否正常、流水线语法有没有变化。

升级的方式，如果用 yum 装的，直接yum update jenkins就行，但升级前务必备份/var/lib/jenkins。我见过升级失败回滚不了的案例，就是因为没备份，最后只能重装重配，损失惨重。

降级稍微麻烦点，得先yum downgrade jenkins装回旧版本，再把备份的数据目录恢复回去。所以你看，备份这一步无论升级还是降级都是保命符，养成习惯比什么都强。

这套 yum 装和卸的流程，我在好几台机器上反复验证过，只要 Java 版本对、仓库 key 对、端口不冲突，基本就是一路顺畅。真正容易出问题的从来不是安装命令本身，而是环境准备和卸载清理这些边角料。把这两头处理干净，中间的过程自然就稳了。