1. 内网环境下的 Jenkins 痛点与项目定位1.1 为什么会在内网环境搭 Jenkins如果只是在一台能上网的机器上装 Jenkins那流程基本是下载、安装、装插件、开工。但一旦把场景换成内网环境这条默认路径就断了一大半。很多研发团队的服务端、客户端、算法模型项目都部署在纯内网区域代码仓库在内网制品库在内网生产环境也在内网。出于安全审计和合规要求整个开发链路不能访问外网资源。这时候想建一套持续集成基础设施就只能老老实实考虑内网安装、内网插件分发、内网依赖管理的问题。我接触过几次类似的项目发现一个普遍规律第一次在内网搭 Jenkins 的团队往往会低估“离线”这两个字带来的工作量。他们以为把安装包拷进去就能跑结果装完后第一步配插件就卡住更新中心连不上插件依赖链断掉构建时 Maven / npm 又要从中央仓库拉依赖怎么都跑不通。所以做这个项目的核心不是把 Jenkins 启动起来而是把“离线环境下的安装、配置、插件、工具链、权限”整条链路打通。这个项目定位很明确帮助有内网隔离环境的团队建立一套可持续运行的 Jenkins 服务重点解决离线安装、插件依赖、多项目隔离和权限管理问题。适合的对象是运维工程师、DevOps 工程师或者需要在隔离网络里搭建 CI/CD 平台的研发同学。看这篇文章之前不需要已经有 Jenkins 实战经验但如果你踩过内网环境的一些坑应该会更容易产生共鸣。1.2 内网搭建与有外网搭建的最大区别先聊一个最直观的差异有外网时Jenkins 安装完插件会自动去更新中心拉依赖碰到缺依赖就自动补非常省心。内网环境没有这个能力插件包、依赖包、JDK、Maven、Node 都要提前准备还要考虑版本兼容性。更麻烦的是Jenkins 插件之间存在复杂的依赖关系A 插件依赖 B 插件的某个版本版本B 又依赖 C 和 D。手动逐个下载、逐个上传很容易漏掉中间的依赖装到最后插件列表里一堆“需要重启生效”或“加载失败”的状态。下面用表格做个对比方便大家快速理解环节有外网环境内网环境Jenkins 安装包在线下载安装需要事先获取安装介质插件安装自动从更新中心拉取需要离线获取 HPI/JPI 包并手动安装插件依赖自动解析并安装需要人工核验依赖树逐个补齐构建工具链自动下载 JDK / Maven / Node需要内网私有源或预先安装工具环境升级维护点按钮即可完成需要替换包、核对插件兼容性问题排查可以参考大量公开资料资料少更多依赖日志和自身经验从这个表能看出来内网环境的核心难点不是“安装 Jenkins”而是“安装后如何让插件体系可用、如何让构建工具链完整、如何把权限模型在团队间顺畅落地”。所以后面内容我会按照“准备 → 安装 → 插件 → 配置 → 排查”的顺序来展开拿我实际做过的方案来讲不会讲太过理想化的操作。2. 安装前准备工作环境规划与安装包准备2.1 服务器选型与资源评估内网环境搭 Jenkins首先要确定用什么服务器。我的建议是独立一台虚拟机或物理机不要和其他高负载业务共用。Jenkins 本身是一个常驻服务虽然平时空闲但一旦有构建任务跑起来CPU 和内存的使用率会突然拉满。尤其是多个任务并行时如果和其他业务抢资源两边都会受影响。具体资源怎么评估我一般看三个维度并发构建数量同时会跑多少个流水线任务构建任务类型Java 编译、前端打包、容器镜像构建、静态扫描是否有主从架构如果只跑一个主节点资源要适当放大如果后续有独立 agent 节点主节点可以弱一些以大多数中小团队的场景为例主节点 4 核 8G 内存系统盘 50G再挂一块 100G 以上的数据盘用来放 JENKINS_HOME 和构建工作目录基本够用。如果团队构建任务很重并且全部挤在主节点上执行CPU 至少 8 核内存 16G 起步会更稳。还有一个经常被忽略的点JVM 参数。内网环境的服务器有时还装着监控代理、日志采集、堡垒机进程启动 Jenkins 前不能只看系统总内存还得给系统预留空闲内存。我习惯的做法是启动脚本里设置-Xms1024m -Xmx2048m并且明确指定 JVM 的堆外内存避免和系统其他进程抢资源。2.2 JDK 版本选择的坑JDK 版本这件事是很多人踩坑的重灾区。Jenkins 在不同版本对 Java 的依赖不一样老版本的 Jenkins 通常基于 Java 8 或 Java 11 运行而较新的 LTS 版本已经逐步转向 Java 11 或 17。如果选了版本较新的 Jenkins却强行用 Java 8 启动很容易碰到UnsupportedClassVersionError服务起不来反过来如果 Jenkins 版本比较旧搭配过新的 JDK 也可能出现兼容问题。我的建议是在内网环境选用一个较新但已经稳定的 LTS 版本配套使用对应官方文档中明确支持的 JDK。比如当前阶段JDK 17 搭配新版 LTS 是比较稳妥的选择。获取 JDK 时要注意内网环境通常没有外网需要提前从可联网的机器上下载对应平台的压缩包比如 Linux x64 的 tar.gz 包。这里有一个实操细节解压 JDK 后一定要检查一下bin/java -version能否正常执行确认解压完整、位数正确。之前我遇到过 JDK 包下载不完整解压报错服务一直起不来排查很久才发现是二进制文件损坏。所以安装前多花一分钟做校验能省下后面大量排查时间。2.3 离线安装包的获取与校验内网环境想要安装包最基本的方式是在一台有外网访问权限的机器上提前下载然后通过企业的内部审批通道、U 盘或者建好的内网软件分发目录传到目标服务器。下载时别偷懒强烈建议同时获取校验信息。比如 Jenkins 的 war 包官方提供了对应的.sha1文件下载完后用sha1sum和源文件对比确认一致再拷贝进内网。这样做的原因很简单内网一旦安装了不完整的包后续排查成本很高而校验可以第一时间发现问题。需要提前准备的安装包和资源我一般列成这样一个清单资源类别说明jenkins.war主程序包选 LTS 版本jdk 压缩包对应 Jenkins 版本要求的 JDK插件 HPI 包按插件依赖清单提前下载构建工具包Maven / Gradle / Node 的离线压缩包配置文件模板systemd 单元文件、启动参数说明等这里说的“插件 HPI 包”在第 4 章会专门展开。现在只想强调一个原则内网环境的准备工作宁可多准备也不要少准备。因为一旦进入内网再想补一个遗漏的插件包又要走一次外部下载、审批、传入的流程效率很低。3. Jenkins 本体的三种安装方式及选择思路3.1 WAR 包模式最灵活、最贴近内网需求我在内网环境最常用的是 WAR 包模式。Jenkins 的 war 包本身自带 Jetty Web 容器直接执行java -jar jenkins.war就能启动不依赖外部 Tomcat。它的好处很直接升级时替换 war 包再重启一下即可几乎不需要改动其他配置。对内网环境这种“每次升级都希望最小化改动”的场景WAR 包模式优势很明显。启动命令可以这样写java -jar /opt/jenkins/jenkins.war \ --httpPort8080 \ --webroot/data/jenkins/war \ -Duser.timezoneAsia/Shanghai注意--webroot这个参数它指定了解压后的 web 资源目录WAR 包模式在启动时会将内置资源解压到这里。如果服务器上有多个 Jenkins 节点或需要频繁重启把它指向独立目录会更清爽。WAR 包模式有一个需要自己处理的问题开机自启。不像 RPM 包装完自动生成 systemd 服务WAR 包模式需要手动配置服务管理。我一般会在/etc/systemd/system/jenkins.service下写一个服务单元文件大概长这样[Unit] DescriptionJenkins CI Server Afternetwork.target [Service] Userjenkins Groupjenkins EnvironmentJAVA_HOME/opt/jdk-17 EnvironmentJENKINS_HOME/data/jenkins/home ExecStart/opt/jdk-17/bin/java -jar /opt/jenkins/jenkins.war --httpPort8080 --webroot/data/jenkins/war Restarton-failure [Install] WantedBymulti-user.target创建好文件后依次执行systemctl daemon-reload、systemctl enable jenkins、systemctl start jenkins。整个流程不复杂但能有效避免重启机器后 Jenkins 没有自动恢复的问题。3.2 RPM 模式适合 RedHat 系快速部署如果你的内网服务器是 CentOS / RedHat 系列而且运维团队习惯用 RPM 包管理软件那么 RPM 模式会比较省心。官方提供的 RPM 包安装后会做几件事情创建jenkins系统用户、创建/var/lib/jenkins作为默认 JENKINS_HOME、生成 systemd 服务脚本、自动配置端口和基本启动参数。安装命令很简单rpm -ivh jenkins-xxx.rpm systemctl start jenkins systemctl enable jenkins但 RPM 模式也有局限。它对默认目录的约束比较强如果我们想自定义 JENKINS_HOME 路径或者修改服务运行用户需要在启动参数里额外指定不方便做到像 WAR 包模式那样灵活。另外RPM 包可能依赖系统中的一些基础库如果内网环境没有配置对应的 yum 源安装时可能提示缺少依赖。所以我的经验是如果团队已经有比较成熟的 RPM 仓库运维机制可以考虑 RPM 模式如果这个内网环境是独立的、后续要长期自定义维护 WAR 包模式更可控。3.3 原生 JAR 模式与目录规划其实要谈 JAR 模式本质和 WAR 包模式相似只不过为了强调“JENKINS_HOME 目录规划”这个点。JENKINS_HOME 是 Jenkins 所有配置、插件、任务、构建日志存放的地方默认情况下位于~/.jenkins。在内网正式使用前我非常建议把 JENKINS_HOME 显式指向一个独立的、挂载了数据盘的位置。比如我在前一家公司做过类似项目当时把 JENKINS_HOME 设置为/data/jenkins/home。选择这个路径有几点考虑数据盘独立挂载系统盘重装或扩容不影响 Jenkins 数据便于备份只需针对/data/jenkins做定时快照或同步目录权限容易隔离只允许jenkins用户读写设置方式有两种一种是在 systemd 服务单元里通过EnvironmentJENKINS_HOME/data/jenkins/home指定另一种是在启动脚本里export JENKINS_HOME/data/jenkins/home。我的习惯是用 systemd 里的 Environment 字段这样全服务生命周期内环境变量都稳定存在。这里要特别提醒JENKINS_HOME 目录的属主要正确。很多人安装完直接跑忘了chown -R jenkins:jenkins /data/jenkins结果 Jenkins 启动时没有权限写日志和创建目录报一堆莫名其妙的错误。启动前花十秒钟检查权限归属能避开较大的问题。4. 内网插件离线管理最核心的拦路虎4.1 插件体系与离线安装原理Jenkins 的插件文件扩展名是.hpi本质上是一个 JAR 包里面包含了插件的代码、资源和元信息。安装插件时Jenkins 并不是只把文件丢到 plugins 目录就结束它还要解析插件的依赖声明、检查与当前 Jenkins 核心版本是否兼容、确定是否存在已安装的冲突插件。这一套逻辑在有外网时是无感的因为更新中心会帮忙计算依赖树。而离线环境下这些依赖必须由我们自己准备齐全。理解插件依赖关系是离线安装的关键。每个 HPI 包内都有一个名为MANIFEST.MF的文件里面会列出依赖项。比如Plugin-Dependencies: structs:1.23, workflow-step-api:5.2这表示当前插件依赖两个其他插件分别是structs和workflow-step-api。如果内网环境里没有这两个依赖插件或者版本不满足要求插件安装后会一直处于加载失败状态。所以在离线安装插件时我建议按这样的顺序确认准备好核心插件和工具链插件比如credentials、plain-credentials、git、pipeline安装依赖链底层的通用插件再安装面向具体业务集成的插件比如代码库插件、制品库插件、通知插件这样做的好处是依赖先被满足后续插件安装的成功率会高很多。4.2 插件依赖关系与批量下载工具的使用离线插件准备阶段最忌讳的做法是手动一个个去下载插件然后碰运气地安装。因为插件版本很多、依赖关系复杂人工操作容易漏。这里我提供一个比较靠谱的路径在可联网的机器上从 Jenkins 官方更新中心获取元数据文件然后解析其中的依赖关系批量下载插件包。官方更新中心提供了update-center.json里面有所有插件的版本、下载地址和依赖声明。我通常写一个简单的 Python 脚本解析出需要的插件及其所有传递依赖拼出下载链接然后直接下载所有 HPI 文件。下面是一个简化示例import json import requests with open(update-center.json, r, encodingutf-8) as f: data json.load(f) plugins data[plugins] # 需要安装的插件列表初始种子 wanted { git, workflow-aggregator, credentials-binding, role-strategy, } download_list set(wanted) def resolve_deps(name): info plugins[name] deps info.get(dependencies, []) for dep in deps: dep_name dep.get(name) # 过滤可选依赖中的默认值确保必选依赖被下载 if dep.get(optional) is False: if dep_name not in download_list: download_list.add(dep_name) resolve_deps(dep_name) for w in list(wanted): resolve_deps(w) for name in download_list: info plugins[name] version info.get(version) url info.get(url) print(fdownload: {name}-{version}.hpi - {url}) # 这里可以用 requests 把文件保存下来这个脚本的思路是从种子插件开始递归解析依赖最后得到一个完整的插件集合。下载完成后统一拷贝进内网再手动上传到 Jenkins。需要注意两个问题第一update-center.json必须和 Jenkins 核心版本对应因为不同核心版本兼容的插件版本不同用错会导致后续加载异常第二脚本只是参考实际生产环境中最好加一层网络错误重试和文件大小校验避免下载出残缺文件。4.3 手动安装 HPI 文件及版本校验插件文件拿到内网后安装入口在“系统管理 → 插件管理 → 高级设置”。移动到页面的“上传插件”区域选中 HPI 文件并提交Jenkins 会尝试解析和安装。这个过程如果顺利等待一会儿就能在“已安装”列表里看到新插件。但我在实操中碰到的真实情况是上传后页面直接报错或者插件出现在列表里但状态显示“依赖缺失”。这时候不要慌去两个日志位置看$JENKINS_HOME/logs目录下的 Jenkins 日志浏览器页面的详细错误信息最常见的错误信息是类似Missing dependency: xxx的提示。解决办法就是去下载对应版本的依赖插件再上传一次。如果依赖插件版本和主插件要求的版本存在冲突优先满足主插件的版本要求不要随便拿一个新版本凑数因为大版本升级可能带来 API 不兼容问题。上传完成并不代表工作结束。安装插件后最好确认一下状态。如果插件旁出现黄色感叹号或者显示“禁用”说明加载异常需要进一步检查日志。此时可以尝试重启 Jenkins因为有些插件在运行时才加载重启后才会正常生效。4.4 常用插件离线包清单建议为了让第一次做内网环境的朋友少走弯路我列一个常用插件清单和用途说明插件名称用途常见依赖credentials提供全局凭据管理框架无plain-credentials支持用户名密码等基础凭据credentialsgitGit 代码拉取与仓库集成credentials, scm-apipipeline声明式/脚本式流水线支持workflow-aggregatorworkflow-aggregator流水线核心聚合插件workflow-api, workflow-jobrole-strategy基于角色的权限控制credentialsmaven-pluginMaven 构建集成无nodejs在构建中提供 Node 运行时无publish-over-ssh通过 SSH 分发制品无build-timestamp构建时间戳变量支持无extended-choice-parameter扩展参数类型无这个清单不是固定的大家要根据自己团队的技术栈调整。原则是插件越精简越好。内网环境下加插件容易但维护和升级成本很高没必要装一些花花哨哨的增强功能核心业务的 CI 链路往往只需要基础插件就能跑得很稳。5. 基础配置与多项目权限管理5.1 系统基础配置端口、时区、代理、更新站点Jenkins 启动之后第一件事不是建任务而是把系统配置调好。内网环境比较常遇到的是时区问题。默认情况下 Jenkins 使用系统 JVM 时区如果服务器时区不是中国时区构建历史时间显示就会偏移 8 小时。我的做法是在启动参数里显式加-Duser.timezoneAsia/Shanghai无论系统时区是什么Jenkins 进程内部时间都是准的。监听端口默认是 8080。如果这台机器上已经有其他服务占用了端口可以在启动参数里通过--httpPortxxxx修改或者把 Jenkins 放在反向代理后面。内网环境下不建议把 Jenkins 直接暴露到过大的网络范围可以只监听内网管理网段的 IP。比如启动参数里加--httpListenAddress192.168.10.20这样服务只能通过这个地址访问安全性会好一些。更新站点配置也需要调整。虽然内网环境不能访问外网更新中心但 Jenkins 仍然会在某些功能中请求更新中心地址导致页面卡顿或报错。在“系统管理 → 插件管理 → 高级设置”里把 update site 地址改为一个内网能接触到的地址或者设置成本地file:///data/jenkins/update-center.json也可以。这一步的目的是消除无意义的网络请求避免界面等待超时。5.2 凭据管理与密钥存储Jenkins 的凭据管理是一个很容易被忽略的环节。内网环境经常要拉取内网 Git、上传制品到内网制品库这些操作都涉及账号密码或密钥。直接在流水线脚本里硬编码密码是非常危险的做法一旦脚本泄露整个内网资源就会被暴露。Jenkins 提供了一套凭据管理机制可以将密码、Token、SSH 密钥都集中存储在服务器端使用时通过 ID 引用。创建凭据的路径是“系统管理 → 凭据 → 全局”。支持的凭据类型包括用户名密码、SSH 密钥、Secret file、Token 等。我用得最多的是用户名密码和新生成的 SSH Key。比如拉取内网 Git 代码时强烈推荐用专门的部署公钥而不是把开发人员的个人密钥放到 Jenkins 里。这样即使离职换人也不影响构建流程只需更换 Jenkins 里的部署凭据就好。这里要提醒一点JENKINS_HOME 目录下有secrets/目录里面保存着 Jenkins 用来加密凭据的主密钥。如果整个 Jenkins 环境损坏或需要迁移到新的内网服务器只拷贝任务配置是不够的必须同时备份secrets/目录。否则所有凭据都无法解密所有引用这些凭据的任务都会报错。这个点我见过太多人踩坑所以单独写在这里。5.3 全局工具配置JDK / Maven / Node 的多版本管理内网环境不像外网那样可以让 Jenkins 自动下载工具链所以全局工具的配置逻辑要以“本地路径绑定”为主。Jenkins 支持配置多个 JDK、Maven、Gradle、Node 的安装实例并可以在不同任务里指定使用哪一套。打开“系统管理 → 全局工具配置”添加 JDK 时不要选择“自动安装”而是直接填一个名字和JAVA_HOME路径例如Name: JDK17 JAVA_HOME: /opt/jdk-17Maven 类似填安装目录Name: maven-3.9 MAVEN_HOME: /opt/maven-3.9NodeJS 插件安装完成后同样可以配置本地 Node 目录。这里的关键是确保jenkins用户对这些目录有读取和执行权限。如果权限不对构建任务会一直卡在工具初始化阶段而且日志并不一定会给出清晰提示。多版本的场景也要提前考虑。比如存量项目还在用 JDK 8新项目已经切换到 JDK 17。在全局工具配置里把两个 JDK 都加进去每个任务单独指定需要的版本就能实现“互不干扰”。这种方式比在服务器上不断切换系统默认 JAVA_HOME 要可控得多。5.4 用户与权限模型基于角色的分配策略内网环境里 Jenkins 通常会被多个团队共用如果所有人都能管理所有任务很容易出现误操作。比如某个团队调整了自己的流水线却不小心改到了别的团队的配置。这个问题需要用权限模型去约束最常用的是基于角色的权限控制。首先要安装role-strategy插件然后在“系统管理 → 安全 → 授权策略”里选择“基于角色的策略”。配置角色时可以创建全局角色和项目角色两类。全局角色我一般分三种角色权限范围admin全部系统权限和任务权限developer可读、可构建、可查看配置viewer只读权限项目角色则需要按项目名匹配规则来划分。比如/project/app-a/.*的规则将某个角色绑定到 app-a 相关任务上只允许该团队管理和查看这些任务。这里有个实际经验给每个团队分配独立的管理角色前要先把全局管理员账号保留好不要把所有用户都设为管理员。否则一旦某个用户误删了管理员角色整个系统可能陷入无法管理的状态。为了避免这种情况我一般会额外创建一个服务账号只用于紧急管理平时不登录权限设置为系统管理员。6. 常见问题与排查经验实录6.1 启动失败与日志分析内网装 Jenkins 最容易遇到的启动失败情况我来按出现频率排个序端口被占用启动时报Address already in use很直接换端口或者停掉占用端口的进程JVM 参数不合法多半是JAVA_HOME指向了错误目录或者命令行参数写错位置目录权限不足启动时无法写入 JENKINS_HOME 或日志目录插件与核心版本不兼容新插件要求更高版本内核老插件可能不兼容新内核排查这些问题的第一步永远是对着日志看。用 systemd 管理时执行journalctl -u jenkins -n 200 --no-pager查看服务日志或者手动用java -jar在前台启动错误信息会直接打印在终端。我发现很多人在启动失败时去翻界面日志其实界面日志往往记录不全反而启动阶段的 JVM 输出才藏着真正的线索。有一个很实用的恢复技巧如果怀疑某个插件导致启动失败可以先进入$JENKINS_HOME/plugins/目录把可疑插件的.hpi文件临时移动到备份目录再重启 Jenkins。服务起来后再逐个分析这些插件的问题而不是一上来就重装整个系统。这个方法能节省大量时间。6.2 插件离线安装失败 / 依赖缺失问题插件离线安装失败的现象比较集中上传时提示 “该插件需要以下依赖”或者安装后在插件管理页面看到插件列表里有红色状态条。碰到这种情况先查依赖的名字和版本再回到可联网的机器上下载对应版本的 HPI 包。还有一种情况是版本冲突。两个插件同时依赖同一个底层插件的不同版本当 Jenkins 尝试加载时可能只保留一个版本另一个插件就会加载失败。此时最好的做法是找到两个插件都能接受的底层插件版本。官方插件通常都会在MANIFEST.MF里标明依赖范围如果无法直接看出妥协版本就查看两个插件各自的发布日期选择两个插件发布期间都兼容的稳定版本。我的一个小技巧是把插件遇到问题时的具体错误日志保留下来里面有非常明确的类名和依赖版本号搜索比凭空猜测快得多。不要只靠界面上的红色感叹号去猜原因日志里的信息量远远大于页面提示。6.3 时区与日志时间问题很多内网环境团队会来问Jenkins 的构建历史时间比当前时间晚了 8 小时是不是服务器时间不准其实不一定是服务器问题。Jenkins 的界面时间来自 JVM 默认时区如果进程启动没有显式指定时区而系统时区又被设置为 UTC 或容器默认时区就会出现 8 小时偏差。在启动参数或服务单元文件的Environment字段中加上-Duser.timezoneAsia/Shanghai就能解决。改完参数记得重启 Jenkins 进程只改配置文件不重启不会生效。构建日志里的时间戳则受构建工具自身时区影响比如 Maven 的日志时间可能跟随 JVM 参数Node 脚本打印的时间跟随 Node 运行时环境。这个情况需要分别处理但 Jenkins 界面时间只要配置对大概率能把干扰降到最低。6.4 构建执行时的权限与资源问题构建任务跑起来之后遇到的权限问题往往是Permission denied。原因是 Jenkins 任务默认以jenkins用户身份执行如果构建脚本里需要写/data下某些目录而这些目录的所有者是 root就会报权限不足。解决办法不外乎两种调整目录属主或者在构建脚本里对相关操作加上适当的权限控制。但是不要为了方便直接把 Jenkins 服务改成 root 用户运行那样虽然省事会整体放大安全风险一旦流水线脚本被恶意构造后果会很严重。资源方面比较常见的是内存不足。前端项目用 Node 打包或者 Java 项目用 Gradle 编译消耗内存都很大。如果并发任务多主节点的内存可能持续告警。我的建议是如果团队构建任务确实多尽早做主从拆分。主节点只负责编排和调度用标签agent把具体构建分配到独立节点执行。这样既能提升构建并发能力又能避免主节点因为高负载而卡死。另外构建工作目录也会越来越占磁盘。Jenkins 的任务 workspace 默认保留在 JENKINS_HOME 下长时间不清理磁盘会慢慢被写满。可以定期清理旧任务、归档历史构建、删除不需要的 workspace或者在“系统管理 → 管理节点”里限制每个节点的工作目录保留策略。总的来说内网环境更像一个封闭的独立小系统磁盘、内存、权限都需要有计划地管理否则时间一长各种小问题就会集中爆发。最后再分享一个我在实际维护中比较受益的做法每次对 Jenkins 做升级或大调整前先把JENKINS_HOME下的config.xml、plugins/、secrets/这三个核心区域完整备份一次。内网环境恢复手段少备份是最低成本的保险。只要这几个目录都在即使系统崩溃也能很快在新环境里恢复出一套可用的 Jenkins 服务。这个习惯从第一次搭内网 Jenkins 到现在一直帮我省了不少事。