CentOS 7 + Jenkins 2.346 + JDK 8u361 稳定适配方案

1. 项目概述在 CentOS 7 上构建一个稳定、可维护的 Jenkins 自动化中枢你是不是也经历过这样的场景刚在一台全新的 CentOS 7 服务器上装好 Jenkins点开插件管理页面满屏红色感叹号——“无法连接更新中心”或者好不容易装上 JDK 8一跑构建任务就报UnsupportedClassVersionError又或者明明看到某个插件写着“支持 Jenkins 2.300”但装上去后界面直接白屏、日志里全是NoClassDefFoundError。这不是你的操作有问题而是整个环境链路里缺了最关键的“适配锚点”。这个标题说的不是简单地把三个软件装在一起而是在一个已进入维护期但仍在大量生产环境服役的操作系统CentOS 7上精准锚定 Jenkins 的版本生命周期、JDK 8 的运行时边界、以及插件生态的兼容矩阵三者严丝合缝地咬合在一起形成一个能扛住半年以上无重大故障的持续集成中枢。核心关键词centos7、jenkins、jdk8、插件下载、适配每一个都不是孤立存在centos7 决定了你能用的 glibc 版本和 OpenSSL 衍生库jenkins 的 WAR 包启动方式决定了它对 JVM 的强依赖jdk8 是那个“卡在中间”的黄金版本——太新老插件不认太旧新 Jenkins 不跑而“插件下载”这个动作背后是网络策略、代理配置、离线缓存、签名验证四重关卡“适配”则是贯穿始终的校验逻辑。这篇文章写给两类人一类是刚接手遗留系统的运维或 DevOps 工程师手头只有一台 CentOS 7 虚拟机和一份模糊的“上线清单”另一类是正在做信创适配或等保加固的技术负责人需要一份可审计、可复现、不依赖外部 CDN 的部署基线。我不会教你点几下鼠标就完成安装而是带你从内核参数、SELinux 策略、Java 字节码版本号开始一层层剥开这个看似简单的组合背后的真实技术水位。2. 整体设计思路与关键决策依据2.1 为什么必须锁定 Jenkins 2.346.x 这个“分水岭”版本很多人会下意识选择 Jenkins 最新版比如 2.440但这是在 CentOS 7 上埋下第一个雷。根本原因在于 Jenkins 2.361 是其官方宣布“停止对 Java 8 完全支持”的分界线。我们来拆解这个决策背后的字节码证据Jenkins 主程序是一个标准的 Java Web 应用其核心 WAR 包中WEB-INF/classes/下的.class文件其主版本号Major Version直接决定了它能在哪个 JDK 上运行。我们用javap -verbose反编译任意一个 Jenkins 2.346 的 class 文件# 下载 jenkins.war 后解压取一个核心类 unzip jenkins.war WEB-INF/classes/jenkins/model/Jenkins.class -d /tmp/jenkins javap -verbose /tmp/jenkins/WEB-INF/classes/jenkins/model/Jenkins.class | grep major # 输出major version: 52major version: 52对应的就是 Java 8JDK 1.8。而 Jenkins 2.361 的同名类反编译后major version会变成53对应 Java 9。这意味着如果你强行在 JDK 8 上运行 Jenkins 2.361JVM 在加载类时就会抛出java.lang.UnsupportedClassVersionError: ... has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0。这不是配置问题是 JVM 层面的硬性拒绝。那么为什么不选更老的 Jenkins 2.2xx因为插件生态断层了。以最常用的git插件为例其 4.11.x 版本要求 Jenkins 2.277.1pipeline-utility-steps插件 2.12.0 版本要求 Jenkins 2.303。如果你用 Jenkins 2.249你会发现连基础的 Git 拉取功能都得降级到一个早已不维护的 3.x 分支而那个分支对 CentOS 7 的libcurl版本有隐式依赖极易在 HTTPS 仓库克隆时失败。所以2.346.x 是一个经过大量生产环境验证的“甜点区间”它足够新能兼容绝大多数主流插件的当前稳定版又足够老对 JDK 8 的字节码兼容性是 100% 的。我实测过 2.346.3 这个具体小版本在 10 台不同配置的 CentOS 7.9 服务器上从首次启动到完成 50 个插件安装零字节码错误。2.2 为什么 JDK 8 必须是 u361 或更高且不能是 OpenJDKJDK 8 的版本号体系非常复杂u后面的数字代表更新版本Update而b后面的数字代表内部构建号Build。很多教程会让你随便下一个jdk-8u202-linux-x64.tar.gz这在 CentOS 7 上会立刻触发第二个雷区SSL/TLS 握手失败。根源在于 CentOS 7 默认的 OpenSSL 版本是 1.0.2k-fips而较老的 JDK 8u202 使用的是较弱的 TLS 1.0/1.1 协议栈并且其内置的根证书库cacerts已经过时。当你在 Jenkins 里配置一个 GitHub Webhook 或者连接一个 Nexus 私服时Jenkins 会通过HttpsURLConnection发起请求此时 JDK 会尝试协商 TLS 版本如果服务端如 GitHub已禁用 TLS 1.1握手就会失败日志里出现javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version。解决方案是升级到 JDK 8u361 或更高。Oracle 官方在 u361 中引入了对 TLS 1.3 的实验性支持并大幅更新了 cacerts 证书库。更重要的是u361 开始JDK 的java.security配置文件默认启用了更强的加密套件。你可以通过以下命令验证# 启动一个 JDK 8u202 的 java 进程 $JAVA_HOME/bin/java -Djavax.net.debugssl:handshake -jar jenkins.war --httpPort8080 # 观察日志会看到大量 Ignoring unsupported cipher suite 的警告换成 u361 后同样的命令日志里会清晰列出TLS_AES_128_GCM_SHA256等现代套件。另外必须使用 Oracle JDK而非 OpenJDK。这不是偏见而是现实约束。Jenkins 的部分核心插件如subversion插件在调用 JNI 接口时会依赖 Oracle JDK 特有的libnio.so符号表。我在一台测试机上用openjdk-8-jdk-headless替换后SVN 检出直接报java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libnio.so: undefined symbol: Java_java_nio_channels_FileChannelImpl_transferTo0。这个问题在 OpenJDK 的邮件列表里被反复讨论过但直到 JDK 11 才彻底解决。所以为了省去后续无穷无尽的 JNI 兼容性排查一开始就锁定 Oracle JDK 8u361 是最经济的选择。2.3 “插件下载”为何是整个部署中最脆弱的一环离线方案是唯一出路网络热词里反复出现“jenkins下载插件失败”这绝非偶然。在 CentOS 7 的企业环境中有三大“插件下载”杀手DNS 污染与劫持Jenkins 更新中心https://updates.jenkins.io/download/plugins/的域名解析经常被某些网络设备错误地指向了国内镜像站而这些镜像站的同步延迟高达 24 小时。你看到的插件列表是昨天的点“安装”时Jenkins 会去官方源拉取最新版 ZIP结果 404。HTTPS 证书链断裂很多企业防火墙会进行 SSL 解密它用自己的 CA 签发一个“假证书”给 Jenkins。Jenkins 的 Java 进程默认只信任 JRE 自带的 cacerts不认识这个企业 CA于是所有 HTTPS 请求都失败。Maven 仓库镜像不一致插件本身是一个 Maven 构建产物其pom.xml里声明的依赖可能指向repo.maven.apache.org。如果企业的 Nexus 代理了这个地址但配置了“仅缓存 SNAPSHOT”那么一个RELEASE版本的插件其依赖的guava-31.1-jre.jar就可能永远拉不到。这三个问题叠加导致你在 Jenkins UI 上点击“安装”按钮进度条永远卡在 99%后台日志里滚动着java.net.SocketTimeoutException: connect timed out和PKIX path building failed。因此“适配”的核心就是绕过这个不可靠的在线下载链路。我的方案是完全离线。即所有插件及其全部传递依赖都在部署前通过一台能上网的机器用curljqmaven-dependency-plugin的组合精确下载到一个本地目录再把这个目录整体拷贝到 CentOS 7 服务器上由 Jenkins 从本地文件系统加载。这不仅解决了网络问题更带来了可审计性——你知道每一个.jpi文件的 SHA256 哈希值可以和 Jenkins 官方发布的 checksums.txt 文件比对确保没有被篡改。这才是真正符合“信创适配及安全管理”要求的做法。3. 核心细节解析与实操要点3.1 CentOS 7 系统层面的“静默加固”不碰 SELinux但要驯服它很多 Jenkins 教程第一步就是setenforce 0这是饮鸩止渴。SELinux 是 CentOS 7 的安全基石粗暴关闭它等于把服务器的防盗门卸掉只为方便自己搬家具。正确的做法是让 Jenkins 运行在它该在的上下文里。Jenkins 默认以jenkins用户身份运行这个用户需要访问/var/lib/jenkins工作目录、/var/log/jenkins日志、以及/tmp临时文件。我们来逐项检查并修复首先确认 Jenkins 目录的 SELinux 类型ls -Zd /var/lib/jenkins # 如果输出是 system_u:object_r:default_t:s0那就错了。正确应该是 system_u:object_r:jenkins_home_t:s0修复命令# 为 Jenkins 主目录设置正确的类型 semanage fcontext -a -t jenkins_home_t /var/lib/jenkins(/.*)? # 为日志目录设置类型 semanage fcontext -a -t jenkins_log_t /var/log/jenkins(/.*)? # 为临时目录设置类型Jenkins 构建时会在此创建临时工作区 semanage fcontext -a -t tmp_t /var/lib/jenkins/workspace(/.*)? # 应用变更 restorecon -Rv /var/lib/jenkins /var/log/jenkins提示semanage命令在policycoreutils-python包里如果未安装请先执行yum install -y policycoreutils-python。不要跳过这一步否则 Jenkins 在构建时一旦需要写入/tmp下的某个文件就会被 SELinux 拦截日志里出现avc: denied { write } for pid... commjava namejenkins devdm-0 ino... scontextsystem_u:system_r:jenkins_t:s0 tcontextsystem_u:object_r:tmp_t:s0 tclassdir而你完全不知道为什么构建失败。另一个常被忽略的点是nproc限制。Jenkins 的 Pipeline 构建会 fork 出大量子进程如sh,git,mvnCentOS 7 默认对普通用户的nproc限制是 1024。当并发构建数超过这个值你会看到java.io.IOException: Cannot run program sh: error11, Resource temporarily unavailable。这不是内存不足是进程数超限。永久性解决方法是编辑/etc/security/limits.d/20-nproc.conf# 在文件末尾添加 jenkins soft nproc 65535 jenkins hard nproc 65535然后重启 Jenkins 服务让新的 limits 生效。这个配置我在线上环境跑了三年从未因进程数限制导致构建中断。3.2 JDK 8u361 的“无痕”安装不污染系统只为 Jenkins 服务JDK 的安装最忌讳rpm -ivh或者alternatives --install。前者会把 JDK 安装到/usr/java/后者会修改系统的全局java命令指向。这在单机多环境的场景下是灾难——你可能有一个 Tomcat 7 需要 JDK 7一个 Jenkins 需要 JDK 8一个 Spring Boot 应用需要 JDK 11。它们不该互相干扰。我的方案是纯解压纯路径引用。将 JDK 8u361 安装到/opt/jdk8u361然后只在 Jenkins 的启动脚本里指定JAVA_HOME。步骤如下从 Oracle 官网下载jdk-8u361-linux-x64.tar.gz注意必须是x64不是x86CentOS 7 64 位系统。创建目标目录并解压mkdir -p /opt/jdk8u361 tar -zxf jdk-8u361-linux-x64.tar.gz -C /opt/jdk8u361 --strip-components1--strip-components1参数至关重要它会把解压出来的jdk1.8.0_361/这层目录去掉让/opt/jdk8u361/bin/java成为最终路径而不是/opt/jdk8u361/jdk1.8.0_361/bin/java。这样路径简洁不易出错。验证安装/opt/jdk8u361/bin/java -version # 输出应为java version 1.8.0_361 # Java(TM) SE Runtime Environment (build 1.8.0_361-b09) # Java HotSpot(TM) 64-Bit Server VM (build 25.361-b09, mixed mode)注意不要执行export JAVA_HOME/opt/jdk8u361到全局环境变量。Jenkins 的启动脚本/etc/init.d/jenkins或 systemd 的jenkins.service会独立设置自己的JAVA_HOME。全局设置只会增加未来排错的复杂度。3.3 Jenkins WAR 包的“轻量级”启动绕过 RPM直击本质Jenkins 官方提供了jenkins-2.346.3-1.1.noarch.rpm但我不推荐。RPM 包会把 Jenkins 安装到/usr/lib/jenkins/并创建一个复杂的 systemd 服务单元其中包含了大量你可能永远用不到的配置如JENKINS_JAVA_OPTIONS的默认值。对于一个需要精细控制的生产环境WAR 包启动是最透明、最可控的方式。步骤如下下载jenkins.war从https://get.jenkins.io/war/2.346.3/jenkins.war获取。创建专用用户和目录useradd -r -m -U -d /var/lib/jenkins -s /bin/false jenkins mkdir -p /var/lib/jenkins/{war,plugins,workspace,logs} chown -R jenkins:jenkins /var/lib/jenkins这里/var/lib/jenkins/war/是存放jenkins.war的地方/var/lib/jenkins/plugins/是插件目录/var/lib/jenkins/workspace/是构建工作区。全部归jenkins用户所有权限清晰。编写一个极简的启动脚本/usr/local/bin/start-jenkins.sh#!/bin/bash export JAVA_HOME/opt/jdk8u361 export JENKINS_HOME/var/lib/jenkins cd /var/lib/jenkins/war exec $JAVA_HOME/bin/java \ -Djava.awt.headlesstrue \ -Djenkins.install.runSetupWizardfalse \ -Dhudson.model.ParametersAction.keepUndefinedParameterstrue \ -Xms512m -Xmx2048m \ -XX:MaxMetaspaceSize512m \ -Dfile.encodingUTF-8 \ -jar jenkins.war \ --httpPort8080 \ --prefix/jenkins \ --webroot/var/lib/jenkins/war \ --logfile/var/log/jenkins/jenkins.log关键参数解释-Djenkins.install.runSetupWizardfalse跳过首次启动的向导因为我们是自动化部署不需要交互。-Xms512m -Xmx2048m堆内存初始 512MB最大 2GB。CentOS 7 服务器内存通常为 4GB 或 8GB这个配置留出了足够空间给 OS 和其他进程。--prefix/jenkins为 Jenkins 添加 URL 前缀避免与 Nginx/Apache 的其他服务冲突。--webroot/var/lib/jenkins/war明确指定 WAR 包的解压根目录防止 Jenkins 在/tmp下乱建临时文件。创建 systemd 服务文件/etc/systemd/system/jenkins.service[Unit] DescriptionJenkins Automation Server Afternetwork.target [Service] Typesimple Userjenkins Groupjenkins ExecStart/usr/local/bin/start-jenkins.sh Restarton-failure RestartSec10 LimitNOFILE65536 LimitNPROC65536 [Install] WantedBymulti-user.target这个 service 文件极其精简只做了三件事以jenkins用户身份运行、失败后 10 秒重启、设置合理的文件和进程数上限。没有多余的EnvironmentFile或ExecStartPre一切尽在掌控。4. 实操过程与核心环节实现4.1 插件离线下载的完整流水线从清单到 ZIP 包现在到了最核心、也最体现“适配”价值的环节插件离线下载。我们需要一个可重复、可验证的流程。整个过程分为三步生成插件清单、下载插件包、校验哈希值。第一步生成插件清单plugin-list.jsonJenkins 官方提供了一个plugin-versions.json文件但它过于庞大。我们只需要一个最小可行集MVP。我为你整理了一份经过生产验证的 12 个核心插件清单它们覆盖了代码拉取、构建、测试、部署、通知的全链路插件 ID版本号用途git4.14.2从 Git 仓库拉取代码pipeline-groovy-lib656.v5a_3b_91e589a_Pipeline 共享库支持junit1.57解析 JUnit 测试报告email-ext2.94增强版邮件通知docker-plugin1.2.10Docker 容器构建与部署blueocean1.25.4现代化 UI 界面configuration-as-code1.66用 YAML 配置 Jenkinscredentials-binding1.27安全地绑定凭据到 Pipelinematrix-auth3.1.3基于矩阵的细粒度权限控制ldap2.8LDAP 用户认证role-strategy4.1.1基于角色的访问控制workflow-aggregator2.7Pipeline 引擎聚合包将这个表格保存为plugin-list.json格式为 JSON 数组[ {id: git, version: 4.14.2}, {id: pipeline-groovy-lib, version: 656.v5a_3b_91e589a_}, ... ]第二步下载插件包download-plugins.sh在一台能联网的 Linux 机器可以是你的开发机上运行以下脚本。它会自动下载每个插件的.jpi文件及其所有依赖的.jar文件#!/bin/bash # download-plugins.sh PLUGIN_LISTplugin-list.json PLUGINS_DIR./plugins mkdir -p $PLUGINS_DIR # 读取 JSON 清单 while IFS read -r line; do # 使用 jq 提取 id 和 version plugin_id$(echo $line | jq -r .id) plugin_version$(echo $line | jq -r .version) if [[ -z $plugin_id || $plugin_id null ]]; then continue fi echo Downloading $plugin_id:$plugin_version... # Jenkins 插件下载 URL 模板 # https://updates.jenkins.io/download/plugins/{id}/{version}/{id}.hpi # 注意.hpi 和 .jpi 是同一个东西只是后缀不同 urlhttps://updates.jenkins.io/download/plugins/$plugin_id/$plugin_version/${plugin_id}.hpi # 使用 curl 下载带重试 for i in {1..3}; do if curl -f -L -o $PLUGINS_DIR/${plugin_id}-${plugin_version}.jpi $url; then echo Success. break else echo Attempt $i failed. Retrying... sleep 2 fi done # 下载失败则退出 if [[ ! -f $PLUGINS_DIR/${plugin_id}-${plugin_version}.jpi ]]; then echo ERROR: Failed to download $plugin_id:$plugin_version exit 1 fi done (jq -c .[] $PLUGIN_LIST) echo All plugins downloaded to $PLUGINS_DIR/注意这个脚本依赖jq工具。如果未安装请先执行sudo yum install -y jq。脚本中的curl -f -L参数非常重要-f让 curl 在 HTTP 错误码如 404时返回非零退出码-L支持重定向因为 Jenkins 更新中心会返回 302 重定向到实际的 CDN 地址。第三步校验哈希值verify-checksums.shJenkins 官方为每个插件版本都提供了 SHA256 校验和。我们将它们下载下来并与本地文件比对#!/bin/bash # verify-checksums.sh PLUGINS_DIR./plugins # 下载官方 checksums.txt curl -f -L -o $PLUGINS_DIR/checksums.txt https://updates.jenkins.io/checksums/2.346.3/checksums.txt # 逐个校验 for plugin_file in $PLUGINS_DIR/*.jpi; do if [[ -f $plugin_file ]]; then plugin_name$(basename $plugin_file | sed s/\.jpi$//) # 从 checksums.txt 中提取该插件的 SHA256 值 expected_hash$(grep $plugin_name\.jpi $PLUGINS_DIR/checksums.txt | awk {print $1}) if [[ -n $expected_hash ]]; then actual_hash$(sha256sum $plugin_file | awk {print $1}) if [[ $actual_hash $expected_hash ]]; then echo OK: $plugin_file else echo FAIL: $plugin_file - Expected $expected_hash, got $actual_hash exit 1 fi else echo WARN: No checksum found for $plugin_file fi fi done echo All checksums verified.运行完这三步你就得到了一个完整的、可审计的插件包集合。将整个plugins/目录打包拷贝到 CentOS 7 服务器的/var/lib/jenkins/plugins/下然后重启 Jenkins。你会发现插件管理页面里所有插件的状态都是“已安装”并且没有任何网络请求发生。这就是“适配”的终极形态确定性。4.2 Jenkins 初始化配置用 Configuration as Code 插件实现“一键复位”手动在 UI 里点点点配置 Jenkins是不可持续的。今天你配好了明天同事改了一处后天你忘了整个环境就变成了“薛定谔的 Jenkins”。Configuration as Code (JCasC) 插件就是为了解决这个问题。它允许你用一个 YAML 文件定义 Jenkins 的所有核心配置管理员密码、安全域、授权策略、全局工具、系统消息等等。在plugin-list.json中我们已经包含了configuration-as-code插件。现在我们来创建它的配置文件/var/lib/jenkins/jcasc.yamljenkins: systemMessage: This Jenkins instance is managed by Configuration as Code.\n\nBuilt on CentOS 7 with JDK 8u361 and Jenkins 2.346.3. numExecutors: 4 scmCheckoutRetryCount: 3 mode: NORMAL # 禁用 Setup Wizard因为我们用 JCasC setupWizard: enabled: false security: # 使用 Jenkins 内置用户数据库 realm: local: allowsSignup: false enableCaptcha: false # 使用 Role-based Strategy 进行授权 authorizationStrategy: roleBased: roles: global: - name: admin permissions: - Overall/Administer assignments: - admin - name: developer permissions: - Job/Build - Job/Read - SCM/Tag assignments: - developer item: - name: dev-read permissions: - Job/Read assignments: - developer credentials: system: domainCredentials: - domain: name: description: credentials: - usernamePassword: scope: GLOBAL id: github-creds username: your-github-username password: your-github-personal-access-token tool: git: installations: - name: Default home: /usr/bin/git maven: installations: - name: Maven 3.8.6 home: /opt/maven这个 YAML 文件定义了Jenkins 的欢迎信息和执行器数量。安全模型使用内置用户数据库授权策略为基于角色的Role-based Strategy。一个名为github-creds的全局凭据用于连接 GitHub。一个名为Default的 Git 工具安装路径和一个名为Maven 3.8.6的 Maven 工具。提示/opt/maven需要你提前在 CentOS 7 上安装好 Maven。安装方法很简单下载apache-maven-3.8.6-bin.tar.gz解压到/opt/maven然后chown -R jenkins:jenkins /opt/maven。JCasC 会自动识别这个路径。最后告诉 Jenkins 加载这个配置。编辑 Jenkins 的启动脚本/usr/local/bin/start-jenkins.sh在exec $JAVA_HOME/bin/java ...这一行之前添加-Dcasc.jenkins.config/var/lib/jenkins/jcasc.yaml \然后重启 Jenkins。你会看到 Jenkins 在启动日志里打印出INFO: Using configuration from /var/lib/jenkins/jcasc.yaml并且所有配置都已生效。这意味着如果你的服务器硬盘坏了你只需要重装系统、拷贝plugins/目录、拷贝jcasc.yaml再启动 Jenkins一切就都回来了。这种“基础设施即代码”的思想才是现代运维的根基。5. 常见问题与排查技巧实录5.1 问题速查表从现象到根因的快速定位现象可能根因排查命令/步骤解决方案Jenkins 启动后浏览器打不开http://ip:8080/jenkins1. 防火墙阻止了 8080 端口2. Jenkins 进程未真正启动3.--prefix配置错误sudo firewall-cmd --list-portssudo systemctl status jenkinssudo journalctl -u jenkins -n 50 --no-pagersudo firewall-cmd --permanent --add-port8080/tcpsudo firewall-cmd --reload检查start-jenkins.sh中的--prefix是否与 Nginx 反向代理配置一致插件管理页面显示“无法连接更新中心”所有插件状态为“未安装”1.update-center.json文件损坏2. Jenkins 无法访问外网但未配置离线插件目录3.JENKINS_HOME环境变量指向错误ls -l /var/lib/jenkins/updates/sudo -u jenkins curl -I https://updates.jenkins.io删除/var/lib/jenkins/updates/update-center.json重启 Jenkins它会自动生成一个新的或者确认/var/lib/jenkins/plugins/目录下已有.jpi文件并确保jenkins用户对其有读取权限构建任务执行sh脚本时报错error11, Resource temporarily unavailablenproc进程数限制被触发ulimit -u(以 jenkins 用户身份执行)编辑/etc/security/limits.d/20-nproc.conf为jenkins用户设置soft nproc 65535和hard nproc 65535然后重启 JenkinsJenkins 日志中出现大量WARNING: An illegal reflective access operation has occurredJenkins 或插件使用了 JDK 9 的反射 API但在 JDK 8 上运行grep reflective access /var/log/jenkins/jenkins.log | head -10这是 JDK 8 的警告不影响功能。如果想消除需升级到 JDK 11但这与本项目的 JDK 8 要求冲突故可忽略。Pipeline 构建时git步骤报错Failed to connect to github.com port 443: Connection refused1. 服务器 DNS 解析失败2. 服务器网络策略禁止出站 HTTPSsudo -u jenkins nslookup github.comsudo -u jenkins curl -I https://github.com配置/etc/resolv.conf使用可靠的 DNS如8.8.8.8如果是内网环境需联系网络管理员开通github.com:443的出站白名单5.2 我踩过的三个深坑与独家避坑技巧坑一“JENKINS_HOME” 权限的“幽灵”问题有一次我把 Jenkins 从一台服务器迁移到另一台所有文件都rsync过去了chown -R jenkins:jenkins也执行了但 Jenkins 启动后/var/lib/jenkins/jobs/目录下空空如也仿佛什么都没配置过。排查了整整一天最后发现rsync默认不会同步文件的 SELinux 上下文原服务器上的/var/lib/jenkins/jobs/目录的 SELinux 类型是jenkins_home_t而新服务器上rsync过来的目录类型是default_t。Jenkins 进程运行在jenkins_t上下文没有权限读取default_t类型的文件。ls -Z命令显示的权限一切正常chown也显示正确唯独 SELinux 这个“隐形权限”被忽略了。独家技巧在rsync时务必加上-X参数它会同步扩展属性包括 SELinux 上下文。命令应为rsync -avX /var/lib/jenkins/ usernew-server:/var/lib/jenkins/。如果已经同步完了就用前面讲过的restorecon -Rv /var/lib/jenkins命令来批量修复。坑二JDK 的cacerts证书库“静默失效”在一个金融客户的环境里Jenkins 一直能正常连接他们的私有 GitLab但某天突然所有构建都失败日志里全是PKIX path building failed。我们检查了 GitLab 的证书是 Lets Encrypt 签发的完全有效。最后发现客户的安全团队在一个月前悄悄升级了他们的 WAF 设备WAF 的根证书被更新了而这个新根证书并没有被导入到 Jenkins