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 11JDK 17当前主流插件兼容性最好2.3xx LTSJDK 8 / 11JDK 11逐步被淘汰新插件支持变差2.19x 以前JDK 8JDK 8老旧版本不建议新项目使用还有一点如果你的服务器是Windows环境例如Windows Server或者某些内网隔离的机器那JDK要用安装包版本而不是解压版因为Jenkins有些插件在Windows下会尝试调用系统环境变量里的JAVA_HOME解压版如果环境变量没配好会出现明明能跑但插件报找不到Java的诡异现象。这种问题排查起来特别费劲因为Jenkins主程序能起来只是某些构建环节失败容易让人误以为是插件本身的毛病。提示安装前先执行java -version确认版本再执行echo $JAVA_HOMELinux/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 --httpPort8080 --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 --httpPort8080 /opt/jenkins/jenkins.log 21 系统包方式也就是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 \ --restartalways \ 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层。三