企业官网建设流程全解析

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 LTS（x86_64）和Jenkins LTS 2.440.3（2024 年 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 # 输出应为 jammy（Ubuntu 22.04）或 focal（20.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 11，Jenkins 2.440 无法启动） openjdk version "11.0.22" 2024-04-16 OpenJDK Runtime Environment (build 11.0.22+7-post-Ubuntu-1ubuntu122.04) OpenJDK 64-Bit Server VM (build 11.0.22+7-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.10+7-Ubuntu-122.04) OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04, mixed mode, sharing)

Ubuntu 22.04 默认apt install openjdk-11-jdk，这是历史包袱。必须显式卸载并安装 OpenJDK 17：

sudo 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/java

2.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是高危操作。原因有三：

1. 版本不可控：apt list jenkins显示2.440.3，但apt install实际安装的可能是2.440.2（缓存未更新）或2.426.3（LTS 通道延迟）；
2. 依赖污染：apt会强制安装openjdk-11-jre-headless，与我们已锁定的 Java 17 冲突；
3. 无离线能力：一旦内网环境断网，整个 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），然后构造下载 URL：

https://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 jenkins

APT 安装生成的/lib/systemd/system/jenkins.service存在硬编码路径和危险参数。我们必须手写一个符合生产标准的服务单元：

# /etc/systemd/system/jenkins.service [Unit] Description=Jenkins Continuous Integration Server Documentation=https://www.jenkins.io/ After=network.target [Service] Type=simple User=jenkins Group=jenkins Environment="JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64" Environment="JENKINS_HOME=/var/lib/jenkins" Environment="JENKINS_OPTS=--httpPort=8080 --httpsPort=-1 --prefix=/" ExecStart=/usr/bin/java -Dcom.sun.akuma.Daemon=daemonized -Djava.awt.headless=true -Djenkins.install.runSetupWizard=false -Xmx2g -Xms1g -XX:MaxMetaspaceSize=512m -XX:+UseG1GC -jar /var/lib/jenkins/jenkins.war Restart=on-failure RestartSec=10 TimeoutSec=120 LimitNOFILE=65536 LimitNPROC=4096 ReadWritePaths=/var/lib/jenkins /var/log/jenkins [Install] WantedBy=multi-user.target

关键参数解析：

• Environment=显式声明JAVA_HOME和JENKINS_HOME，避免依赖 shell profile；
• ExecStart=中-Xmx2g -Xms1g设置堆内存，-XX:MaxMetaspaceSize=512m防止 Metaspace 泄漏，-XX:+UseG1GC启用 G1 垃圾回收器（Java 17 默认，但显式声明更稳妥）；
• LimitNOFILE=65536解决 Jenkins 在高并发构建时文件描述符耗尽问题（默认 1024）；
• ReadWritePaths=声明 Jenkins 进程可读写的路径，替代危险的PermissionsStartOnly=true。

启用服务：

sudo systemctl daemon-reload sudo systemctl enable jenkins sudo systemctl start jenkins sudo systemctl status jenkins # 观察 Active: active (running) 及 Loaded 路径是否为 /etc/systemd/system/jenkins.service

3.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> <scope>GLOBAL</scope> <id>admin-api-token</id> <description>Admin API Token for automation</description> <username>admin</username> <password>$(openssl rand -base64 32)</password> </com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl>'

提示：create-credentials-by-xml命令需提前安装credentials-plugin。这引出了下一个关键点——插件源。

4.2 插件源切换：为什么国内镜像站必须手动配置，且不能只改 URL

Jenkins 默认插件中心地址为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 包。

正确方案是双层替换：

1. 修改update-center.json地址为镜像站；
2. 修改 Jenkins 内部插件下载基础 URL。

编辑/var/lib/jenkins/hudson.model.UpdateCenter.xml：

<?xml version='1.0' encoding='UTF-8'?> <sites> <site> <id>default</id> <url>https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json</url> </site> </sites>

然后，在JENKINS_HOME下创建init.groovy.d/update-center-url.groovy（Jenkins 启动时自动执行）：

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 Token（apiscope），而非 Project Access Token；
• 未勾选Enable authentication for Git client，导致 Pipeline 中checkout失败；
• 测试连接时点击Test Connection成功，但 Pipeline 仍报401 Unauthorized。

根源在于：Jenkins GitLab 插件的认证机制分两层：

• Server Level：用于调用 GitLab API（如获取分支列表），需apiscope；
• Project Level：用于克隆代码，需read_repositoryscope，且 Token 必须绑定到具体项目。

正确配置流程：

1. 在 GitLab 项目 Settings > Access Tokens 中创建 Token，Scope 仅勾选read_repository；
2. Jenkins 中GitLab servers添加新服务器，URL 填https://gitlab.example.com，Credentials 选刚创建的 Token；
3. 在Configure System底部GitLab区域，勾选Enable authentication for Git client；
4. 测试连接时，必须填写 Project ID 或 Path（如my-group/my-project），否则Test Connection仅验证 API 连通性，不测试克隆权限。

注意：若 GitLab 启用了 Two-Factor Authentication（2FA），则必须使用 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_HOME；
• Job 执行环境变量：由 Jenkins 注入到每个构建进程中，如BUILD_NUMBER、GIT_COMMIT。

关键变量注入位置：

• JAVA_HOME、JENKINS_HOME：已在systemd服务单元中通过Environment=设置；
• PATH：必须在/etc/environment中追加 Jenkins 工具链路径，而非修改~jenkins/.bashrc（systemd 不加载 shell profile）：

echo 'PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/jenkins/tools"' | sudo tee -a /etc/environment

• Job 环境变量：通过Manage Jenkins > Configure System > Global properties添加Environment variables，例如：

提示：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?tree=quietingDown port: 8080 initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 3

/api/json?tree=quietingDown返回 JSON：{"quietingDown":false}表示 Jenkins 已就绪，可接受新构建。这是 Jenkins 官方推荐的 readiness 检查端点。

5.3 日志轮转：为什么logrotate必须同时处理jenkins.log和jenkins.out

Jenkins 默认将日志输出到两个文件：

• jenkins.log：Jenkins 自身日志（java.util.logging）；
• jenkins.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 --signal=SIGHUP jenkins endscript }

postrotate中的systemctl kill --signal=SIGHUP jenkins是关键：它通知 Jenkins 重新打开日志文件句柄，避免logrotate重命名后 Jenkins 继续向旧文件写入。

5.4 安全加固：关闭 Setup Wizard、禁用 Script Console、限制 Agent 连接

Jenkins 安全基线必须包含三项硬性措施：

1. 关闭 Setup Wizard：防止未授权用户重置管理员密码。在JENKINS_HOME下创建noSetupWizard文件：

sudo touch /var/lib/jenkins/noSetupWizard sudo chown jenkins:jenkins /var/lib/jenkins/noSetupWizard

2. 禁用 Script Console：Manage Jenkins > Script Console是最高危入口。通过systemd启动参数禁用：

# 在 jenkins.service 的 ExecStart 中添加 --disable-session-attribute-store

3. 限制 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 R750，64GB RAM，2TB NVMe）。执行uname -m、lsb_release -sc、df -h /三连问，发现 RAID 卡电池老化，更换后重新初始化磁盘——此步耗时 90 分钟，但避免了后续因 I/O 延迟导致的构建超时。
• 10:30–12:00：Java 17 安装与验证。update-alternatives配置失败两次，原因是alternatives数据库损坏，最终用sudo dpkg-reconfigure -f noninteractive openjdk-17-jdk-headless强制重建——教训：最小化系统需重置 alternatives 数据库。
• 13:30–15:00：WAR 包下载与 SHA256 校验。官网archives.jenkins-ci.org响应缓慢，改用curl -v抓包发现 DNS 解析超时，临时修改/etc/resolv.conf加入nameserver 114.114.114.114——公网 DNS 不可靠，内网必须部署本地 DNS 缓存。
• 15:00–17:00：systemd服务单元编写与启动。LimitNOFILE=65536导致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:00：GitLab 连接测试失败。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:00：Prometheus 监控接入。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:00：Agent 节点部署。第二台 Agent 服务器JAVA_HOME指向 OpenJDK 11，导致 Maven 构建失败，强制统一为 OpenJDK 17 ——Agent 环境必须与 Master 严格一致