1. 先把Jenkins的版本账和JDK依赖算清楚，再动手装
我见过太多人卡在Jenkins安装的第一步，不是不会敲命令，而是根本没搞清楚自己要装的版本对JDK有什么要求。结果war包下下来，java -jar一跑，直接甩一个UnsupportedClassVersionError在屏幕上，人当场就懵了。这类问题占了我早期帮同事排查Jenkins问题里差不多三成，说白了就是版本没对齐。
Jenkins本身是个纯Java写的Web应用，它对你的Java运行环境有硬性门槛。长话短说，目前主流使用的LTS长期支持版本，普遍要求JDK 11及以上，官方更推荐用JDK 17。如果你还在用JDK 8，那你只能退回去装那种特别老的Jenkins版本，插件生态跟不上，构建脚本也处处别扭，纯属给自己找麻烦。所以我的建议很简单：先装JDK 17，再装Jenkins，顺序别搞反。
这里有个容易被忽略的细节——Jenkins的运行JDK和你项目编译用的JDK，可以是两码事。Jenkins自身跑在JDK 17上没问题，但你要构建的项目如果只兼容JDK 8，那完全可以在构建任务里单独指定编译用的JDK，或者在流水线里手动export JAVA_HOME切过去。这种"运行环境"和"构建环境"分离的认知，是很多人踩坑之后才慢慢悟出来的。
我帮你把常见的组合关系整理成一张表，照着对号入座就行：
| Jenkins版本区间 | 最低JDK要求 | 推荐JDK | 说明 |
|---|---|---|---|
| 2.4xx LTS 及以后 | JDK 11 | JDK 17 | 当前主流，插件兼容性最好 |
| 2.3xx LTS | JDK 8 / 11 | JDK 11 | 逐步被淘汰，新插件支持变差 |
| 2.19x 以前 | JDK 8 | JDK 8 | 老旧版本，不建议新项目使用 |
还有一点，如果你的服务器是Windows环境，例如Windows Server或者某些内网隔离的机器，那JDK要用安装包版本而不是解压版，因为Jenkins有些插件在Windows下会尝试调用系统环境变量里的JAVA_HOME，解压版如果环境变量没配好，会出现"明明能跑但插件报找不到Java"的诡异现象。这种问题排查起来特别费劲，因为Jenkins主程序能起来，只是某些构建环节失败，容易让人误以为是插件本身的毛病。
提示：安装前先执行
java -version确认版本，再执行echo $JAVA_HOME（Linux/macOS）或echo %JAVA_HOME%（Windows）确认环境变量指向的JDK就是你预期那一个。很多服务器上装了多个JDK，环境变量指向的未必是你以为的那个。
我先把这个前提讲透，是因为后面所有的安装、构建、部署操作，全都建立在"JDK装对了"这个地基上。地基歪了，上面砌的砖迟早塌。你要装Jenkins，第一件事不是去搜安装命令，而是先确认这台机器的Java环境，这一步花你五分钟，能省掉后面几个小时的抓狂。
2. 三种安装路线的真实取舍：war包、系统包与容器化
Jenkins的安装方式看着五花八门，其实归结起来就是三条路：直接跑war包、用系统包管理器安装、以及容器化部署。每种方式适用场景不一样，没有绝对的优劣，关键看你手头的环境约束和后续维护成本。我把这三种方式挨个拆开讲，顺便说说各自容易翻车的地方。
2.1 war包方式：最灵活，也最考验手动能力
war包方式的逻辑非常朴素——Jenkins就是一个.war文件，你用java -jar就能把它拉起来。适合的场景是：你只有一台干净的Linux机器，不想引入额外的包管理依赖，或者你想把Jenkins和它的数据目录放到指定位置。
# 下载war包后，直接启动（默认8080端口） java -jar jenkins.war # 指定端口和数据目录，推荐这种写法 java -jar jenkins.war --httpPort=8080 --prefix=/jenkins这种方式的核心变量是JENKINS_HOME，它决定了Jenkins把你的配置、插件、任务数据存哪儿。默认是用户目录下的.jenkins文件夹。如果你用root启动，那就是/root/.jenkins；用其他用户启动，就在那个用户的家目录下。千万别小看这个目录，将来迁移Jenkins、备份Jenkins，本质就是打包这个目录。
war包方式最容易踩的坑是"进程保活"。你手动java -jar起来的进程，一旦SSH断开或者终端关闭，Jenkins就跟着没了。所以生产环境一定要用nohup加上后台运行，或者干脆写成systemd服务：
nohup java -jar /opt/jenkins/jenkins.war --httpPort=8080 > /opt/jenkins/jenkins.log 2>&1 &系统包方式（也就是Linux上常见的包管理安装）本质上是帮你不熟手做了几件事——它会自动创建jenkins系统用户、把JENKINS_HOME设在/var/lib/jenkins、注册好systemd服务、还配好开机自启。你用包管理器一条命令装完，systemctl start jenkins就起来了，省心。代价是数据目录位置相对固定，想改得额外配置。这种方式适合那些"我就想快点跑起来、不折腾目录规划"的场景。
2.2 容器化部署：环境隔离最彻底，但持久化必须做对
容器化跑Jenkins是我现在最推荐的方式，尤其当你需要在一台机器上跑多个版本、或者想让环境彻底隔离时。核心就一条docker run命令，但里面有两个参数如果写错，你的Jenkins数据会在容器重建时全部丢失。
docker run -d \ --name jenkins \ -p 8080:8080 -p 50000:50000 \ -v /data/jenkins_home:/var/jenkins_home \ -v /var/run/docker.sock:/var/run/docker.sock \ --restart=always \ jenkins/jenkins:lts-jdk17这里-v挂载数据目录是命门。容器里的Jenkins数据默认存在/var/jenkins_home，如果不挂出来，容器一删你的所有任务配置就灰飞烟灭了。第二个-v把宿主机的Docker守护进程socket挂进容器，是为了让Jenkins能在构建过程中直接调用Docker命令——如果你不需要在Jenkins里构建镜像，这条可以不要，但加上会更方便。
容器化还有个经典的权限坑：容器内的Jenkins默认以jenkins用户运行，而挂载出来的宿主机目录可能属于root，结果容器启动时报权限拒绝。解决办法是用-u root启动，或者提前把宿主机目录的属主改成对应的UID。我一般推荐后者的变体——查一下容器里jenkins用户的UID（通常是1000），然后chown -R 1000:1000 /data/jenkins_home，这样既安全又不会因为root运行带来额外风险。
说到容器，还有个和Jenkins构建强相关的报错，热词里也出现了——docker: error response from daemon: Get "https://registry-1.docker.io/v2/": ...。这不是Jenkins的问题，而是Docker拉镜像时连不上默认镜像仓库。遇到这个，在Docker的配置里加一个可用的镜像加速地址，重启Docker即可。这个报错经常出现在Jenkins构建任务里执行docker build或docker pull的环节，别去Jenkins里找原因，问题在Docker层。
三
