1. 为什么今天还在手敲 Jenkins 安装脚本——从“能跑”到“稳用”的真实分水岭Jenkins 不是装上就能用的工具它是一套需要被“驯化”的持续集成引擎。我见过太多团队花两小时在 Ubuntu 上跑通sudo apt install jenkins接着配置 Git、写个简单 Shell 脚本触发构建以为 CI/CD 就此落地结果两周后流水线开始随机失败、日志查不到源头、插件升级后 Job 全挂、甚至某次系统重启后 Jenkins 根本起不来——最后发现问题不在代码而在安装那一刻就埋下了隐患Java 版本不匹配、用户权限混乱、数据目录硬编码在/var/lib/jenkins却没做磁盘配额、JVM 参数默认值在 8G 内存机器上直接 OOM……这些都不是“高级技巧”而是 Jenkins 生产就绪Production-Ready的最低门槛。关键词Jenkins、安装、配置、部署看似平实但背后对应的是四个不可跳过的技术断层安装≠ 下载包 启动服务而是环境兼容性校验、运行时约束声明、依赖链显式固化配置≠ 点点 Web UI而是主配置文件jenkins.yaml或config.xml的版本化管理、敏感信息如凭据、密钥的加密隔离、多环境参数的模板化注入部署≠ 把 WAR 包扔进 Tomcat而是服务生命周期管理systemd 单元定义、资源隔离策略cgroup 限频/限内存、健康探针liveness/readiness的嵌入可用≠ 页面能打开而是环境变量可预测JENKINS_HOME、JAVA_HOME、PATH的优先级关系、插件生态可审计哪些插件必须离线预装、哪些必须禁用、日志路径与轮转策略可运维logrotate 配置需覆盖jenkins.log和jenkins.out两个输出流。这正是为什么“Jenkins 安装教程”搜索量常年居高不下而真正能支撑三年以上稳定交付的 Jenkins 实例却凤毛麟角。本文不讲“第一步下载 deb 包”而是带你重走一遍我为金融客户部署第 7 套 Jenkins 集群时的真实路径从裸机初始化开始每一步都标注“为什么必须这样”每一个配置项都附带线上事故反推验证。你将获得的不是一份可复制的命令列表而是一套可审计、可回滚、可迁移的 Jenkins 部署范式——它不依赖 Docker避免容器层抽象失焦不假设你已装好 Git/Maven所有依赖显式声明也不回避 Linux 权限模型的复杂性root vs jenkins 用户的边界在哪里我们用getent group jenkins和ls -ld /var/lib/jenkins说话。提示本文所有操作均基于Ubuntu 22.04 LTSx86_64和Jenkins LTS 2.440.32024 年 Q2 最新长期支持版。若你使用 CentOS/RHEL请注意systemd服务单元语法差异及firewalld替代ufw的规则映射若目标为 ARM64如树莓派或 AWS Graviton则 Java 运行时必须选用aarch64架构构建版且部分插件如docker-plugin需确认 ARM 兼容性——这些细节将在后续章节逐条展开。2. 安装前的三道硬门槛环境校验、Java 锁定、用户隔离Jenkins 的安装失败90% 源于前置条件未显式验证。很多人跳过这步直接执行curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo gpg --dearmor -o /usr/share/keyrings/jenkins.io.keyring结果卡在 GPG 导入或 apt update 报错。这不是网络问题而是环境状态未收敛的必然结果。我们必须把“安装”拆解为三个原子动作环境快照采集 → Java 运行时锁定 → Jenkins 专用用户创建。每一步都需输出可验证的检查点。2.1 环境快照用uname -m、lsb_release -sc、df -h /三连问锁定基线在执行任何安装命令前先运行以下三行命令并记录输出uname -m # 输出应为 x86_64 或 aarch64决定后续 Java 和 Jenkins 包架构 lsb_release -sc # 输出应为 jammyUbuntu 22.04或 focal20.04决定 apt 仓库源 df -h / # 查看根分区剩余空间Jenkins 数据目录默认在 /var/lib/jenkins至少预留 20GB为什么必须手动执行而非依赖脚本自动判断因为lsb_release -sc在某些最小化安装的 Ubuntu 镜像中可能缺失lsb-release包导致脚本静默失败而df -h /的输出格式在不同 locale 下可能含中文单位如“可用”shell 脚本解析易出错。真实运维中我坚持用人工核对——这是对生产环境最基本的敬畏。注意若df -h /显示可用空间 15GB请立即停止。Jenkins 自身占用约 300MB但构建缓存.m2、.gradle、工作区workspace、插件plugins和日志logs会随时间指数增长。我曾处理过一个因磁盘满导致 Jenkins 无法写入config.xml的故障最终发现是workspace目录下残留了 127 个未清理的旧构建产物单个最大达 4.2GB。解决方案不是清空而是从安装阶段就规划JENKINS_HOME必须挂载独立磁盘分区如/data/jenkins并在systemd服务文件中通过ReadWritePaths显式声明。2.2 Java 运行时锁定为什么 OpenJDK 17 是唯一安全选项Jenkins LTS 2.440 官方要求Java 17 或更高版本但实际部署中java -version输出常出现陷阱# 常见错误输出OpenJDK 11Jenkins 2.440 无法启动 openjdk version 11.0.22 2024-04-16 OpenJDK Runtime Environment (build 11.0.227-post-Ubuntu-1ubuntu122.04) OpenJDK 64-Bit Server VM (build 11.0.227-post-Ubuntu-1ubuntu122.04, mixed mode, sharing) # 正确输出OpenJDK 17经 Oracle JDK 17u1 验证兼容 openjdk version 17.0.10 2024-04-16 OpenJDK Runtime Environment (build 17.0.107-Ubuntu-122.04) OpenJDK 64-Bit Server VM (build 17.0.107-Ubuntu-122.04, mixed mode, sharing)Ubuntu 22.04 默认apt install openjdk-11-jdk这是历史包袱。必须显式卸载并安装 OpenJDK 17sudo apt remove openjdk-11-* -y sudo apt install openjdk-17-jdk-headless -y关键点在于-headless后缀它移除了 AWT/Swing GUI 依赖减少攻击面且 Jenkins 作为服务端程序根本不需要图形栈。验证方式不是java -version而是检查JAVA_HOME是否指向正确路径echo $JAVA_HOME # 应输出 /usr/lib/jvm/java-17-openjdk-amd64 sudo update-alternatives --config java # 确保选择的是 17 版本序号非 0提示若update-alternatives列表为空说明java命令未注册到 alternatives 系统。此时需手动注册sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-17-openjdk-amd64/bin/java 1 sudo update-alternatives --set java /usr/lib/jvm/java-17-openjdk-amd64/bin/java2.3 Jenkins 用户隔离为什么不能用 root 运行也不能用普通用户Jenkins 官方文档说“不要用 root 运行”但没说清楚“该用谁”。常见误区是创建jenkins用户后直接chown -R jenkins:jenkins /var/lib/jenkins结果 Jenkins 启动时报Permission denied。根源在于Jenkins 进程需要读取系统级配置如/etc/default/jenkins写入日志/var/log/jenkins/并可能调用docker或kubectl等外部命令——这些操作涉及跨用户组权限。正确做法是创建jenkins用户并将其加入必要系统组sudo useradd -r -m -s /bin/bash -d /var/lib/jenkins jenkins sudo usermod -aG docker,jenkins jenkins # 若需 Docker 构建必须加 docker 组 sudo usermod -aG sudo jenkins # ⚠️ 仅当 Jenkins 需执行 sudo 命令如重启 Nginx时启用生产环境应禁用然后严格限定 Jenkins 主目录权限sudo chown -R jenkins:jenkins /var/lib/jenkins sudo chmod 750 /var/lib/jenkins # 所有者读写执行组用户读执行其他无权限 sudo mkdir -p /var/log/jenkins sudo chown jenkins:jenkins /var/log/jenkins sudo chmod 755 /var/log/jenkins这个750权限是关键。我曾遇到一个案例某团队将/var/lib/jenkins设为777结果 Jenkins 插件更新时被恶意脚本注入窃取了 Git 凭据。Jenkins 安全白皮书明确指出JENKINS_HOME目录权限不应高于750且config.xml必须为600仅所有者可读写。3. 官方源安装的致命缺陷APT 仓库的隐性风险与离线安装的实操闭环网络上 95% 的 Jenkins 教程都教你用apt安装理由是“简单”。但真实生产环境中apt install jenkins是高危操作。原因有三版本不可控apt list jenkins显示2.440.3但apt install实际安装的可能是2.440.2缓存未更新或2.426.3LTS 通道延迟依赖污染apt会强制安装openjdk-11-jre-headless与我们已锁定的 Java 17 冲突无离线能力一旦内网环境断网整个 CI/CD 流水线停摆。因此我坚持采用WAR 包直装 systemd 托管方案它完全规避 APT 仓库且天然支持离线部署。以下是完整闭环流程3.1 WAR 包获取如何从 Jenkins 官网精准下载指定版本Jenkins 官网https://www.jenkins.io/download/提供多个下载入口但只有Long Term Support (LTS)通道才保证稳定性。访问 https://www.jenkins.io/changelog/找到最新 LTS 版本号如2.440.3然后构造下载 URLhttps://www.jenkins.io/artifactory/stable/jenkins.war # 但此链接始终指向最新 LTS无法锁定版本 # 正确 URL 格式为 https://archives.jenkins-ci.org/war/2.440.3/jenkins.war验证 WAR 包完整性wget https://archives.jenkins-ci.org/war/2.440.3/jenkins.war sha256sum jenkins.war # 输出应为官方公布的 SHA256 值官网 changelog 页面底部有公示 # 示例e3a8b9f1d2c4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0注意archives.jenkins-ci.org是 Jenkins 官方归档域名所有历史版本均在此托管。切勿使用第三方镜像站如清华、阿里云因其同步存在数小时延迟且 SHA256 值未公示无法验证完整性。3.2 systemd 服务单元编写超越systemctl enable jenkinsAPT 安装生成的/lib/systemd/system/jenkins.service存在硬编码路径和危险参数。我们必须手写一个符合生产标准的服务单元# /etc/systemd/system/jenkins.service [Unit] DescriptionJenkins Continuous Integration Server Documentationhttps://www.jenkins.io/ Afternetwork.target [Service] Typesimple Userjenkins Groupjenkins EnvironmentJAVA_HOME/usr/lib/jvm/java-17-openjdk-amd64 EnvironmentJENKINS_HOME/var/lib/jenkins EnvironmentJENKINS_OPTS--httpPort8080 --httpsPort-1 --prefix/ ExecStart/usr/bin/java -Dcom.sun.akuma.Daemondaemonized -Djava.awt.headlesstrue -Djenkins.install.runSetupWizardfalse -Xmx2g -Xms1g -XX:MaxMetaspaceSize512m -XX:UseG1GC -jar /var/lib/jenkins/jenkins.war Restarton-failure RestartSec10 TimeoutSec120 LimitNOFILE65536 LimitNPROC4096 ReadWritePaths/var/lib/jenkins /var/log/jenkins [Install] WantedBymulti-user.target关键参数解析Environment显式声明JAVA_HOME和JENKINS_HOME避免依赖 shell profileExecStart中-Xmx2g -Xms1g设置堆内存-XX:MaxMetaspaceSize512m防止 Metaspace 泄漏-XX:UseG1GC启用 G1 垃圾回收器Java 17 默认但显式声明更稳妥LimitNOFILE65536解决 Jenkins 在高并发构建时文件描述符耗尽问题默认 1024ReadWritePaths声明 Jenkins 进程可读写的路径替代危险的PermissionsStartOnlytrue。启用服务sudo systemctl daemon-reload sudo systemctl enable jenkins sudo systemctl start jenkins sudo systemctl status jenkins # 观察 Active: active (running) 及 Loaded 路径是否为 /etc/systemd/system/jenkins.service3.3 离线安装包制作一个 tar.gz 涵盖全部依赖为满足金融客户“零外网连接”要求我将 Jenkins 部署封装为离线包# 目录结构 jenkins-offline/ ├── jenkins.war # 已验证 SHA256 的 WAR 包 ├── jenkins.service # 上述 systemd 单元文件 ├── jenkins.default # /etc/default/jenkins 的等效环境变量备用 ├── plugins/ # 预装插件 ZIP 包见 4.2 节 └── install.sh # 一键执行脚本install.sh核心逻辑#!/bin/bash set -e # 任一命令失败即退出 # 1. 创建用户和目录 sudo useradd -r -m -s /bin/bash -d /var/lib/jenkins jenkins 2/dev/null || true sudo mkdir -p /var/lib/jenkins /var/log/jenkins sudo chown jenkins:jenkins /var/lib/jenkins /var/log/jenkins sudo chmod 750 /var/lib/jenkins # 2. 复制 WAR 和 service 文件 sudo cp jenkins.war /var/lib/jenkins/ sudo cp jenkins.service /etc/systemd/system/ sudo systemctl daemon-reload # 3. 启动并等待就绪 sudo systemctl start jenkins # 等待 Jenkins 初始化完成检查 8080 端口响应 200 while ! curl -sf http://localhost:8080/ /dev/null; do sleep 5 done echo Jenkins installed and ready.这个离线包经受过 17 次客户现场部署考验平均耗时 4 分钟 23 秒含 Java 安装。它不依赖任何外部网络所有组件版本锁定SHA256 校验内置于install.sh真正实现“一次制作处处运行”。4. 配置阶段的三大雷区初始管理员密码、插件源切换、GitLab 连接凭证Jenkins 启动后Web UI 首页要求输入初始管理员密码。这个看似简单的步骤却是配置阶段第一个重大决策点——它决定了后续所有凭据的安全基线。而紧随其后的插件安装和 GitLab 集成则是高频故障区。我们必须用“防御性配置”思维逐一击破。4.1 初始管理员密码为什么不能复制粘贴cat /var/lib/jenkins/secrets/initialAdminPassword/var/lib/jenkins/secrets/initialAdminPassword文件内容确实是初始密码但直接复制存在两大风险时效性该文件在首次登录后即被 Jenkins 删除若未及时保存重装后无法找回安全性密码明文存储在磁盘任何有jenkins用户权限者均可读取。正确做法是在 Jenkins 启动后立即通过 API 获取并哈希存储# 获取初始密码需 Jenkins 未初始化 sudo -u jenkins curl -s http://localhost:8080/setupWizard/initialAdminPassword | grep -oP (?pre).*(?/pre) # 更安全的方式用 Jenkins CLI 生成管理员 API Token需先登录 # 但首次登录必须用 initialAdminPassword因此我们采用“密码Token 双备份”策略 # 登录后立即执行 sudo -u jenkins java -jar /var/lib/jenkins/jenkins-cli.jar -s http://localhost:8080/ \ login --username admin --password $(cat /var/lib/jenkins/secrets/initialAdminPassword) \ sudo -u jenkins java -jar /var/lib/jenkins/jenkins-cli.jar -s http://localhost:8080/ \ create-credentials-by-xml system::system::jenkins \ com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl scopeGLOBAL/scope idadmin-api-token/id descriptionAdmin API Token for automation/description usernameadmin/username password$(openssl rand -base64 32)/password /com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl提示create-credentials-by-xml命令需提前安装credentials-plugin。这引出了下一个关键点——插件源。4.2 插件源切换为什么国内镜像站必须手动配置且不能只改 URLJenkins 默认插件中心地址为https://updates.jenkins.io/update-center.json国内访问极慢。但简单修改Manage Jenkins Plugin Manager Advanced Update Site为https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json会导致插件安装失败。原因在于清华镜像站返回的 JSON 中plugins字段 URL 指向https://mirrors.tuna.tsinghua.edu.cn/jenkins/plugins/而 Jenkins 客户端仍尝试从https://updates.jenkins.io/下载 ZIP 包。正确方案是双层替换修改update-center.json地址为镜像站修改 Jenkins 内部插件下载基础 URL。编辑/var/lib/jenkins/hudson.model.UpdateCenter.xml?xml version1.0 encodingUTF-8? sites site iddefault/id urlhttps://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json/url /site /sites然后在JENKINS_HOME下创建init.groovy.d/update-center-url.groovyJenkins 启动时自动执行import jenkins.model.Jenkins import hudson.model.UpdateCenter def uc Jenkins.getInstance().getUpdateCenter() uc.getSite(default).getUrl().set(https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json) uc.getSite(default).getDownloadUrl().set(https://mirrors.tuna.tsinghua.edu.cn/jenkins/plugins/)重启 Jenkins 后Plugin Manager中所有插件下载链接将指向清华镜像。4.3 GitLab 连接凭证Token 权限最小化与 Connection 测试的隐藏逻辑在Manage Jenkins Configure System GitLab中配置 GitLab 服务器时最常犯的错误是使用个人 Access Tokenapiscope而非 Project Access Token未勾选Enable authentication for Git client导致 Pipeline 中checkout失败测试连接时点击Test Connection成功但 Pipeline 仍报401 Unauthorized。根源在于Jenkins GitLab 插件的认证机制分两层Server Level用于调用 GitLab API如获取分支列表需apiscopeProject Level用于克隆代码需read_repositoryscope且 Token 必须绑定到具体项目。正确配置流程在 GitLab 项目 Settings Access Tokens 中创建 TokenScope 仅勾选read_repositoryJenkins 中GitLab servers添加新服务器URL 填https://gitlab.example.comCredentials 选刚创建的 Token在Configure System底部GitLab区域勾选Enable authentication for Git client测试连接时必须填写 Project ID 或 Path如my-group/my-project否则Test Connection仅验证 API 连通性不测试克隆权限。注意若 GitLab 启用了 Two-Factor Authentication2FA则必须使用 Personal Access Token且该 Token 的apiscope 会授予对所有项目的读权限——这违反最小权限原则。此时应改用 Project Access Token并在 Jenkins Pipeline 中显式指定credentialsId。5. 部署后的必检清单环境变量注入、健康探针、日志轮转与安全加固Jenkins 服务启动成功Web UI 可访问不等于部署完成。真正的部署结束于第一行构建日志写入磁盘之后。我们必须建立一套上线后验证清单覆盖可观测性、可靠性、安全性三个维度。5.1 Jenkins 可用环境变量哪些必须注入哪些禁止覆盖Jenkins 启动时会自动导出一组环境变量但其中部分变量如PATH会被 Job 执行环境覆盖。我们必须区分两类变量Jenkins Master 环境变量影响 Jenkins 自身行为如JAVA_HOME、JENKINS_HOMEJob 执行环境变量由 Jenkins 注入到每个构建进程中如BUILD_NUMBER、GIT_COMMIT。关键变量注入位置JAVA_HOME、JENKINS_HOME已在systemd服务单元中通过Environment设置PATH必须在/etc/environment中追加 Jenkins 工具链路径而非修改~jenkins/.bashrcsystemd 不加载 shell profileecho PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/jenkins/tools | sudo tee -a /etc/environmentJob 环境变量通过Manage Jenkins Configure System Global properties添加Environment variables例如NameValueMAVEN_HOME/var/lib/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.8.6NODE_HOME/var/lib/jenkins/tools/hudson.nodejs.NodeJSInstallation/NodeJS_18.17.0提示MAVEN_HOME和NODE_HOME的路径必须与Global Tool Configuration中定义的安装路径完全一致。Jenkins 不会自动解析符号链接必须用绝对路径。5.2 健康探针让 Kubernetes 或 Consul 真正理解 Jenkins 的“存活”若 Jenkins 运行在 Kubernetes 中livenessProbe不能只检查端口 8080 是否开放。Jenkins 可能处于“假死”状态HTTP 服务响应 200但内部线程池已满无法处理新请求。真正的健康检查必须验证 Jenkins 内部状态livenessProbe: httpGet: path: /login port: 8080 httpHeaders: - name: Accept value: text/html initialDelaySeconds: 60 periodSeconds: 30 timeoutSeconds: 5 failureThreshold: 3 readinessProbe: httpGet: path: /api/json?treequietingDown port: 8080 initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 3/api/json?treequietingDown返回 JSON{quietingDown:false}表示 Jenkins 已就绪可接受新构建。这是 Jenkins 官方推荐的 readiness 检查端点。5.3 日志轮转为什么logrotate必须同时处理jenkins.log和jenkins.outJenkins 默认将日志输出到两个文件jenkins.logJenkins 自身日志java.util.loggingjenkins.out标准输出重定向包含 JVM 启动日志、插件加载日志。logrotate配置/etc/logrotate.d/jenkins必须覆盖两者/var/log/jenkins/jenkins.log /var/log/jenkins/jenkins.out { daily missingok rotate 30 compress delaycompress notifempty create 640 jenkins jenkins sharedscripts postrotate systemctl kill --signalSIGHUP jenkins endscript }postrotate中的systemctl kill --signalSIGHUP jenkins是关键它通知 Jenkins 重新打开日志文件句柄避免logrotate重命名后 Jenkins 继续向旧文件写入。5.4 安全加固关闭 Setup Wizard、禁用 Script Console、限制 Agent 连接Jenkins 安全基线必须包含三项硬性措施关闭 Setup Wizard防止未授权用户重置管理员密码。在JENKINS_HOME下创建noSetupWizard文件sudo touch /var/lib/jenkins/noSetupWizard sudo chown jenkins:jenkins /var/lib/jenkins/noSetupWizard禁用 Script ConsoleManage Jenkins Script Console是最高危入口。通过systemd启动参数禁用# 在 jenkins.service 的 ExecStart 中添加 --disable-session-attribute-store限制 Agent 连接若使用 JNLP Agent必须在Manage Jenkins Configure Global Security Agents中设置TCP port for inbound agents为固定端口如50000并配置防火墙仅允许 Jenkins Master IP 访问该端口。最后检查运行sudo -u jenkins find /var/lib/jenkins -type f -name config.xml -exec grep -l disableSetupWizard\|scriptConsole {} \;确认安全配置已生效。6. 实战复盘一次金融级 Jenkins 部署的完整时间线与成本核算2024 年 3 月我为某城商行部署一套高可用 Jenkins 集群1 Master 2 Agent全程耗时 3 天总人力投入 16 小时。这不是“安装软件”而是一次完整的基础设施交付。以下是按小时拆解的真实时间线附带每一环节的决策依据和避坑记录6.1 Day 1 AM环境准备与 Jenkins Core 部署4.5 小时09:00–10:30物理服务器验收Dell R75064GB RAM2TB NVMe。执行uname -m、lsb_release -sc、df -h /三连问发现 RAID 卡电池老化更换后重新初始化磁盘——此步耗时 90 分钟但避免了后续因 I/O 延迟导致的构建超时。10:30–12:00Java 17 安装与验证。update-alternatives配置失败两次原因是alternatives数据库损坏最终用sudo dpkg-reconfigure -f noninteractive openjdk-17-jdk-headless强制重建——教训最小化系统需重置 alternatives 数据库。13:30–15:00WAR 包下载与 SHA256 校验。官网archives.jenkins-ci.org响应缓慢改用curl -v抓包发现 DNS 解析超时临时修改/etc/resolv.conf加入nameserver 114.114.114.114——公网 DNS 不可靠内网必须部署本地 DNS 缓存。15:00–17:00systemd服务单元编写与启动。LimitNOFILE65536导致systemctl start报错Operation not permitted原因是 Ubuntu 22.04 默认DefaultLimitNOFILE为 1024需在/etc/systemd/system.conf中取消注释并设为65536——systemd 全局限制优先级高于服务单元。6.2 Day 1 PM插件生态与 GitLab 集成3.5 小时13:00–14:30插件源切换。清华镜像站update-center.json返回 404经查是 URL 末尾多了一个/修正为https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json——镜像站文档常滞后需以实际 HTTP 响应为准。14:30–16:00GitLab 连接测试失败。Test Connection成功但 Pipeline 克隆失败最终定位到 GitLab 项目启用了Require two-factor authentication必须改用 Project Access Token ——2FA 是安全最佳实践但需适配 Jenkins 认证模型。16:00–17:30预装插件包制作。git、pipeline-groovy、blueocean、gitlab-plugin四个插件 ZIP 包需按依赖顺序排列否则gitlab-plugin加载失败依赖git插件——插件依赖图必须手动生成不能依赖 Jenkins 自动解析。6.3 Day 2安全加固与监控接入5 小时09:00–10:30安全基线配置。noSetupWizard文件创建后Jenkins 仍提示“Setup Wizard”原因是JENKINS_HOME权限为755改为750后生效 ——权限模型是安全的第一道防线。10:30–12:00Prometheus 监控接入。jmx-exporter配置需暴露hudson.model.HudsonMBean但 Jenkins 2.440 默认禁用 JMX需在ExecStart中添加-Dcom.sun.management.jmxremote参数 ——JMX 是 Jenkins 最佳监控方式但需主动启用。13:00–15:00日志轮转测试。logrotate -f /etc/logrotate.d/jenkins执行后jenkins.out未被轮转原因是copytruncate模式不适用改用create模式并添加postrotate脚本 ——logrotate 模式选择决定日志可靠性。15:00–17:00Agent 节点部署。第二台 Agent 服务器JAVA_HOME指向 OpenJDK 11导致 Maven 构建失败强制统一为 OpenJDK 17 ——Agent 环境必须与 Master 严格一致