这次我们来看 Jenkins 安装完成后的第二件事：插件安装，以及 JDK、Maven、Git 的全局配置。标题里的 2，不是 Jenkins 版本号，而是这个系列的第二篇。上一篇把 Jenkins 本体跑起来了，这一篇把“构建环境”补齐，配好之后，项目提交代码就能触发自动打包，构建过程也不再依赖人工在本机执行mvn package。
这篇不会只停留在“点几个按钮”的程度。我会把插件安装、插件中心镜像源切换、三个全局工具配置、Git 凭证配置、Pipeline 验证脚本、REST API 调用和常见报错排查串起来。按这份流程操作，最直接的收益是：新建一个任务就能用上 Maven 和 Git，不再出现mvn: command not found、插件下载超时、Git 认证失败这类问题。整个过程以 Linux 服务器为示例，Windows 部署思路也一致，只是路径和命令有区别。
先说结论：Jenkins 的全局工具配置，本质是把服务器上已有的 JDK、Maven、Git 告诉 Jenkins，并把插件装齐。配置完成之后，Jenkins 就是一个真正可用的构建调度中心，后续无论是做单元测试、打包镜像，还是发布到远程服务器，都从这套基础配置开始。
1. Jenkins 插件安装与全局配置核心能力速览
| 能力项 | 说明 |
|---|---|
| 项目类型 | Jenkins CI/CD 工具链配置教程 |
| 核心功能 | 插件管理、JDK 全局配置、Maven 全局配置、Git 全局配置、Pipeline 构建验证 |
| 支持平台 | Linux、Windows、macOS 均可，本系列以 Linux 服务器为例 |
| 启动方式 | systemd 服务、Docker 容器、java -jar jenkins.war |
| 是否支持 API | 支持，Jenkins REST API 可查询任务、触发构建、获取控制台输出 |
| 批量任务 | 支持，构建队列、多任务并发、Pipeline 脚本化批量构建 |
| 硬件要求 | 无 GPU 需求，建议给 Jenkins 分配 2GB 以上可用内存 |
| 磁盘空间 | 建议预留 10GB 以上，Maven 仓库和构建产物会持续占用空间 |
| 常用插件 | Git、Pipeline、Maven Integration、Credentials Binding、Build Timeout 等 |
| 适合场景 | 自动化打包、持续集成、发布部署、测试环境更新 |
这里的硬件要求是通用建议。如果你的项目依赖复杂，编译过程会启动多个 Maven 进程，内存占用会明显上升，实际配置要根据项目规模调整。
2. 适用场景与使用边界
这套配置最适合下面几类人：
- 已经装好 Jenkins，但新建任务时发现没有 Maven 项目类型，或者构建脚本里找不到
mvn。 - 团队里每次发版都靠开发同学手动在本地打包，希望把“拉代码 -> 编译 -> 打包”固定到 Jenkins 上。
- 准备从 Freestyle 任务切换到 Pipeline，需要先理解全局工具和凭证如何管理。
- 刚接触持续集成的运维或测试同学，想把 Jenkins 的插件、JDK、Maven、Git 之间的关系理清楚。
不适合什么场景？如果你的项目已经有完整的 DevOps 平台，或者团队不打算维护自建 CI，那这套方案可以暂时不引入。另外，Jenkins 本质是一台能远程执行命令的机器。给了它 Git 凭证，它就能代表你拉代码；给了它服务器权限，它就能执行部署脚本。这里必须注意安全边界：
- 使用最小权限原则，jenkins 用户只给需要访问的目录和命令权限。
- 仓库凭证尽量使用独立的 Deploy Token 或只读 SSH Key，不要把个人管理员私钥放进构建机。
- 构建脚本不要写死明文密码，优先使用 Jenkins Credentials 绑定。
- 如果构建过程涉及第三方软件包、插件或素材，需要确认许可协议与合规要求，尤其是商业使用场景。
3. 环境准备与前置条件
3.1 操作系统与 Java 环境
Jenkins 本身是 Java 应用，服务器上必须先有可用的 JDK。注意，这里有两个层面：Jenkins 服务运行需要 Java，构建任务编译项目也需要 JDK。常见部署方式是在服务器上装一个 JDK 17，既给 Jenkins 用，也作为构建工具链的一部分。搜索材料里也出现了 jdk 17、找不到 jdk 等高频问题，说明这一环容易出岔子。
先用命令确认本机 Java 是否可用：
java -version readlink -f "$(which java)"第一条命令查看版本，第二条命令定位真实安装路径。后面配置 Jenkins 全局 JDK 时，需要填JAVA_HOME，就是第二条命令输出的目录，而不是bin/java所在路径。
3.2 磁盘、端口与网络
Jenkins 默认端口是 8080。如果服务器上已经跑着其他服务，先确认端口是否被占用：
ss -lntp | grep 8080磁盘方面，Maven 依赖下载到本地仓库后，体积增长很快，建议给 Jenkins 目录预留至少 10GB 空间。安装目录和JENKINS_HOME尽量放在独立分区，方便后续备份和扩容。
网络方面，插件中心如果访问不稳定，需要在 Jenkins 里配置国内镜像源，这一步在下一节详细说明。
3.3 准备好仓库凭证
接下来配置 Git 时，需要一个可访问代码仓库的账号或 SSH Key。建议提前在 GitLab/GitHub 上创建一个 Jenkins 专用账号，或者生成一对新的 SSH Key。不要把个人账号密码直接填到 Jenkins 全局配置里，方便后续做权限回收。
# 生成 Jenkins 专用 SSH Key（在 Jenkins 所在服务器执行） ssh-keygen -t ed25519 -C "jenkins@example.com" -f ~/.ssh/jenkins_ci_key生成后，把公钥~/.ssh/jenkins_ci_key.pub添加到 GitLab/GitHub 的 Deploy Keys 或目标账号的 SSH Keys 中，这一步就是实现“git 免密拉取”的关键。
4. Jenkins 插件安装：界面安装、镜像源与离线部署
4.1 通过系统管理界面安装
进入 Jenkins 后，点击左侧的“Manage Jenkins”，再进入“Plugins”或“插件管理”。在“Available plugins”里搜索需要的插件，勾选后点击安装。如果没有特别需求，建议选择安装后自动重启，或者等待插件安装完成后再继续操作。
常见基础插件包括：
| 插件 | 用途 |
|---|---|
| Git Plugin | 支持从 Git 仓库拉取代码 |
| Pipeline | 支持 Jenkinsfile 流水线语法 |
| Credentials Binding | 在构建中安全引用凭证 |
| Maven Integration | 提供 Maven 项目类型 |
| Build Timeout | 构建超时控制 |
| Timestamper | 控制台日志增加时间戳 |
| Publish Over SSH | 构建产物发布到远程服务器 |
| Localization: Chinese (Simplified) | Jenkins 界面中文化 |
插件的 shortName 在离线安装和 Script Console 批量安装时都要用到，建议记住几个核心插件的关键字：git、workflow-aggregator、maven-plugin、credentials-binding。
4.2 更换插件中心镜像源
插件安装最常遇到的问题就是下载慢、超时。国内访问默认插件中心不稳定时，可以更换插件中心镜像源。
操作路径：Manage Jenkins -> Plugins -> Advanced settings，找到 “Update Site”，把默认地址换成国内镜像站地址。常见镜像源包括清华、华为云等公开镜像，具体地址以镜像站当前说明为准。保存后，建议点击 “Check now” 重新拉取插件列表。
这里有一个容易混淆的点：更换 Update Site 只解决 Jenkins 插件元数据和插件包下载问题，不改变 Maven 依赖仓库地址。Maven 仓库镜像需要在settings.xml里单独配置，后面会写到。
4.3 离线安装 hpi 插件
某些内网环境无法访问外网，这时候只能离线安装。先在有网的机器上下载目标插件的.hpi或.jpi文件，然后上传到 Jenkins 服务器的插件目录。
# Debian/Ubuntu 常见路径是 /var/lib/jenkins/plugins # 上传插件文件后，修改属主并重启 Jenkins sudo cp /tmp/插件名.hpi /var/lib/jenkins/plugins/ sudo chown jenkins:jenkins /var/lib/jenkins/plugins/插件名.hpi sudo systemctl restart jenkins也可以在界面中操作：Manage Jenkins -> Plugins -> Advanced settings，在 “Deploy Plugin” 区域上传.hpi文件。离线安装的缺点是插件依赖需要手动处理，如果缺少某个依赖插件，启动时会在日志里报错。
4.4 使用 Script Console 批量安装插件
如果已经能联网，但不想在界面里一个个点，可以使用 Script Console 批量安装：
// 路径：Manage Jenkins -> Script Console // 插件名使用 shortName，需要联网从插件中心下载 def pluginShortNames = ['git', 'workflow-aggregator', 'maven-plugin', 'credentials-binding'] pluginShortNames.each { name -> if (!Jenkins.instance.pluginManager.plugins.any { it.shortName == name }) { println "Installing: ${name}" Jenkins.instance.pluginManager.install(name, false) } }执行后，等待 Jenkins 下载并加载插件。如果 Jenkins 实例存在多个节点，插件安装后通常需要重启才能被所有 executor 正确识别。
5. 全局工具配置：JDK、Maven、Git
5.1 先确认服务器本机工具可用
在配置 Jenkins 之前，先在服务器上确认三个工具都真实可用：
java -version mvn -v git --version如果mvn不在 PATH 里，有两种处理方式：要么把 Maven 目录加入系统 PATH，要么在 Jenkins 全局工具配置里直接指定MAVEN_HOME。推荐后者，因为 Jenkins 可以精确控制每个任务使用哪个版本的 Maven，不受系统默认版本影响。
5.2 配置 JDK 全局工具
路径：Manage Jenkins -> Tools -> JDK Installations -> Add JDK。
添加时有两种方式：
- 自动安装：Jenkins 从官方源下载 JDK。网络不好时不推荐，非常慢。
- 本地安装：填写服务器上已有的 JDK 路径，比如
/usr/lib/jvm/java-17-openjdk-amd64。
建议选择本地安装，名字可以填JDK17。注意：Name 字段不是随便起的，后面 Pipeline 脚本tools { jdk 'JDK17' }就会引用这个名字，需要严格对应。
5.3 配置 Maven 全局工具
路径：Manage Jenkins -> Tools -> Maven Installations -> Add Maven。
同样的思路，如果有本地 Maven，就填本地路径：
# 示例路径，实际以服务器安装位置为准 MAVEN_HOME=/opt/maven/apache-maven-3.9.xName 填Maven3。也可以在 PATH 里直接使用/usr/bin/mvn，但为了多版本切换，更推荐在全局工具里维护。Maven 工具配置好后，Freestyle 项目里就能看到 Maven 构建步骤，Pipeline 里也可以使用tools { maven 'Maven3' }。
5.4 配置 Maven 镜像仓库与构建参数
Maven 默认从中央仓库下载依赖，国内构建经常卡在下载阶段。常见做法是修改 Maven 的settings.xml，配置国内镜像仓库。这个文件在 Maven 安装目录的conf/settings.xml，或者用户目录下的~/.m2/settings.xml。下面是一个简化示例：
<settings> <mirrors> <mirror> <id>aliyun</id> <name>Aliyun Maven Mirror</name> <url>https://maven.aliyun.com/repository/public</url> <mirrorOf>central</mirrorOf> </mirror> </mirrors> </settings>这里以常见国内镜像为例，实际使用时根据你所在网络环境选择可达的镜像地址。配好之后，Maven 依赖下载速度通常会有明显改善。
构建内存也建议在全局配置里预留。在全局工具配置的 Maven 安装项里，可以设置MAVEN_OPTS：
MAVEN_OPTS=-Xms512m -Xmx1536m如果项目依赖复杂，可以适当调大堆内存，但要结合服务器总内存来控制。
5.5 配置 Git 全局工具与免密
路径：Manage Jenkins -> Tools -> Git Installations -> Add Git。
填 Git 可执行文件路径，Linux 下通常就是/usr/bin/git。配好后，Jenkins 拉取 Git 仓库时就知道该调用哪个 git 命令。
“git 免密”的核心不在 Jenkins 全局配置，而在于凭证。把 Jenkins 所在服务器的公钥加入 GitLab/GitHub 的 Deploy Keys 后，还需要告诉 Jenkins 使用哪个私钥。路径：Manage Jenkins -> Credentials -> Global -> Add Credentials。
SSH Key 方式：
- Kind 选择 “SSH Username with private key”
- Username 填 Git 平台的用户名
- Private key 选择 “Enter directly”，把之前生成的私钥内容粘贴进去
用户名密码方式：
- Kind 选择 “Username with password”
- Username 和 Password 填 Git 平台账号密码
两种方式都支持。推荐 SSH Key，因为不需要保存明文密码，也更容易做权限控制。保存后，会生成一个 credentialsId，后面构建脚本里要用这个 ID 引用凭证。
5.6 配置构建凭证
Pipeline 里使用凭证的方式如下：
git url: 'https://gitlab.example.com/group/project.git', branch: 'main', credentialsId: 'jenkins-ci-key'Freestyle 项目里，在 Git 配置页面选择对应的 Credentials 即可。如果凭证过期，只需要更新 Credentials，所有引用该 credentialsId 的任务都会生效，不需要逐个改任务配置。
6. 功能测试：用一个构建任务验证配置
6.1 新建 Pipeline 任务
配置完成后，立刻验证是否真的可用。最简单的办法是新建一个 Pipeline 任务，在脚本里同时调用 JDK、Maven 和 Git。
路径：New Item -> 输入任务名 -> 选择 “Pipeline” -> OK。然后在 Pipeline 区域粘贴脚本：
pipeline { agent any tools { jdk 'JDK17' maven 'Maven3' } stages { stage('Checkout') { steps { git url: 'https://gitlab.example.com/group/demo.git', branch: 'main', credentialsId: 'jenkins-ci-key' } } stage('Build') { steps { sh 'mvn clean package -DskipTests' } } stage('Archive') { steps { archiveArtifacts artifacts: 'target/*.jar', fingerprint: true } } } }注意三点：
tools块里的JDK17和Maven3必须与全局工具配置里的 Name 完全一致。credentialsId必须与 Credentials 里保存的 ID 一致。- Git 仓库地址要换成真实可访问的地址。
6.2 查看控制台输出
点击 “Build Now” 后，进入构建记录，打开 Console Output。整个流程可以分为三段来观察：
- Checkout 阶段：是否成功克隆代码。如果失败，重点检查 credentialsId 和网络连通性。
- Build 阶段：Maven 是否开始下载依赖，是否编译通过。这里最容易卡在依赖下载上。
- Archive 阶段：构建产物是否被 Jenkins 归档。
6.3 判断标准
构建成功的标志很简单：
- 页面左侧构建记录显示蓝色圆点。
- Console Output 末尾能看到
Finished: SUCCESS。 - Archive 阶段后，在任务页面能看到
target/*.jar产物。
如果脚本里把mvn写死，而任务没有配置 tools 指令，可能会看到mvn: command not found。这一点记得优先排查：构建脚本里的命令是否真的存在于 Jenkins executor 的 PATH 中，还是只存在于你手动登录的 shell 中。
7. Jenkins API 与批量任务扩展
全局配置完成后，Jenkins 就可以作为自动化构建中心对外提供接口服务。Jenkins 原生 REST API 支持查询任务、触发构建、获取控制台输出，方便接到内部平台或脚本里。
7.1 查询任务信息
JENKINS_URL="http://127.0.0.1:8080" JENKINS_USER="admin" JENKINS_TOKEN="你的API_TOKEN" curl -s -u "${JENKINS_USER}:${JENKINS_TOKEN}" \ "${JENKINS_URL}/job/demo-build/api/json" | jq '.displayName, .lastBuild.result'API Token 在 Jenkins 页面右上角点击用户名 -> Configure -> API Token 中生成。注意 API Token 等同于密码，不要把 Token 写入公共仓库或明文配置。
7.2 远程触发构建
新版 Jenkins 默认开启 CSRF 防护，直接 POST 触发构建需要先获取 crumb：
JENKINS_URL="http://127.0.0.1:8080" JENKINS_USER="admin" JENKINS_TOKEN="你的API_TOKEN" JOB_NAME="demo-build" # 获取 CSRF crumb，需要安装 jq CRUMB=$(curl -s -u "${JENKINS_USER}:${JENKINS_TOKEN}" \ "${JENKINS_URL}/crumbIssuer/api/json" | jq -r '.crumb') # 触发构建 curl -X POST \ -u "${JENKINS_USER}:${JENKINS_TOKEN}" \ -H "Jenkins-Crumb: ${CRUMB}" \ "${JENKINS_URL}/job/${JOB_NAME}/build"如果任务配置了“远程触发构建”的 Token，也可以用build?token=远程触发Token的方式触发，这个方式可以不依赖 crumb，但 Token 字段要合理保管。
7.3 批量触发与排队机制
Jenkins 自带构建队列。多个任务同时触发时，会按照 executor 数量排队执行。批量触发最常见的做法是在外部脚本里循环调用 API：
for job in service-a service-b service-c; do echo "Trigger ${job}" curl -X POST \ -u "${JENKINS_USER}:${JENKINS_TOKEN}" \ -H "Jenkins-Crumb: ${CRUMB}" \ "${JENKINS_URL}/job/${job}/build" sleep 2 done批量触发时要注意控制频率。如果一下子触发几十个任务，构建队列会瞬间积压，Maven 依赖下载和代码拉取也会抢占服务器带宽。建议分批触发，并且在任务里配置 Build Timeout。
7.4 批量任务稳定性建议
- 每个 Pipeline 任务增加超时控制，避免某个依赖卡住后永久占用 executor。
- 构建历史设置自动清理策略，比如保留最近 20 次构建。
- 日志保留策略单独设置，防止控制台输出占满磁盘。
- 批量任务之间不要写死全局唯一的资源，比如固定端口、固定文件路径，尽量用构建工作目录隔离。
8. 资源占用与性能观察
8.1 Jenkins 本体与构建进程如何占资源
Jenkins 主进程空闲时内存占用并不高，通常几百 MB 就能运行。真正吃资源的是构建过程。一个 Maven 构建会启动 Java 编译进程，如果还涉及前端 npm 打包、Docker 镜像构建，CPU 和内存会明显上升。
并发构建不是越多越好。executor 数量设置为 CPU 核数的 1 到 2 倍，然后根据项目实际耗时调整。如果是多模块 Java 项目，建议并发构建数设为 2 或 3，避免大量并发导致 Maven 进程互相争抢内存。
8.2 常用观察命令
在 Jenkins 所在服务器上，可以用下面命令观察资源占用：
# 查看内存占用 free -h # 查看 Jenkins 主进程与 Maven 子进程 top -c -u jenkins # 查看 JENKINS_HOME 占用空间 du -sh /var/lib/jenkins du -sh ~/.m2/repository重点观察两个目录：/var/lib/jenkins是 Jenkins 配置和构建记录，~/.m2/repository是 Maven 本地仓库。构建记录和 Maven 依赖是磁盘增长的主要来源。
8.3 降低资源占用的做法
- 丢弃旧的构建记录，在任务配置里设置 Discard Old Builds。
- Maven 依赖使用本地仓库缓存，避免每次构建重复下载。
- 减少 executor 数量，控制并发峰值。
- 将 Jenkins 服务和构建产物放在独立分区，避免写满系统盘。
- 如果是 Docker 部署，给容器设置内存上限，防止构建进程把宿主机内存耗尽。
9. 常见问题与排查方法
插件安装和全局配置阶段最容易踩坑，下面列出高频问题：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 插件中心加载慢或超时 | 默认 Update Site 访问不稳定 | 查看插件管理页面错误信息 | 更换插件中心镜像源，或离线安装 hpi |
| 安装插件后提示 Unable to find valid certification path | 当前 JDK 的 cacerts 不信任目标站点证书 | 使用keytool -list检查证书链 | 更新 JDK/CA，给 JVM 导入可信证书，避免使用不可信中间源 |
| 全局工具里找不到 JDK 版本 | JAVA_HOME 路径填写错误 | 执行readlink -f "$(which java)" | 使用真实 JDK 安装目录 |
| 构建提示 mvn: command not found | 构建脚本依赖系统 PATH，但 executor 环境缺少 Maven | 查看 Console Output 的 PATH 信息 | 在 Pipeline/Freestyle 中使用 tools 指令，或把 Maven 加入服务器 PATH |
| Git clone 失败 Authentication failed | 凭证未配置或已过期 | 查看控制台输出的 HTTP 状态码 | 在 Credentials 中更新账号/SSH Key，重新构建 |
| 构建队列一直卡住 | executor 数量为 0 或任务等待锁 | 查看 Build Executor Status | 确认节点在线，增加 executor 数量 |
| 插件安装后页面还是英文 | 未安装中文语言包 | 检查已安装插件列表 | 安装 Localization: Chinese (Simplified) 插件 |
| 8080 端口被占用 | 其他服务已监听 8080 | ss -lntp查看监听进程 | 修改 JENKINS_PORT 或 Docker 端口映射 |
| Maven 下载依赖极慢 | 中央仓库网络链路不稳定 | 查看 Maven 日志下载源地址 | 配置国内镜像仓库 settings.xml |
| Pipeline 中 tools 名称报错 | 全局工具 Name 不一致 | 对比 tools 块名称和全局工具配置 | 统一名称，比如 JDK17、Maven3 |
10. 最佳实践与使用建议
全局工具配置好之后，建议按下面方式维护 Jenkins：
- 优先在全局工具里声明工具版本，由 Jenkins 统一管理构建环境，不依赖个人机器的 PATH。
- 凭证统一存放在 Credentials 中，不要在 Jenkinsfile 或构建命令里写明文密码。
- 每个任务加上构建历史清理策略和超时时间，避免任务无限制占资源。
- Pipeline 脚本尽量写成 Jenkinsfile 入库管理，而不是只写在任务配置里，方便评审和追溯。
- 定期备份
JENKINS_HOME下的config.xml、jobs目录和 Credentials 配置，防止实例损坏。 - 更新插件前先在测试环境验证，不要在正式环境直接升级大版本。
- 构建机权限最小化，jenkins 用户只给必要的目录写权限。
- 涉及生产发布时，建议在 Pipeline 中增加人工审批节点，例如
input步骤或外部审批系统。
// Pipeline 中的人工审批示例 stage('Deploy Approval') { input message: '确认发布到生产环境？', ok: '确认' }这样可以把自动化效率和安全控制同时保留：日常构建全自动，生产发布前增加一道确认。
11. 总结与下一步
整套流程验证下来，最值得先做的一件事，是把 JDK、Maven、Git 三个全局工具配好，然后跑通一个最简单的 Pipeline。这个 Pipeline 能自动拉代码、编译、归档产物，说明基础链路已经打通。之后再去扩展远程部署、邮件通知、多分支流水线，都是在同一套基础上加阶段。
最容易踩的坑集中在三处：插件中心镜像源没换导致安装超时；JDK 的 JAVA_HOME 路径填错；Git 凭证没有配置导致 clone 失败。这三个问题排查清楚，Jenkins 日常使用就会顺手很多。
下一步可以尝试的方向：把mvn clean package替换成 Docker 镜像构建，通过 Publish Over SSH 把产物发布到测试服务器，或者接入 SonarQube 做代码质量检查。Jenkins 本身的扩展能力很强，但前提是基础配置足够稳固。建议把这篇的验证 Pipeline 保存为一个模板，后续新任务都基于它起步。
