Jenkins如何部署到Linux服务器？持续集成环境搭建指南

Jenkins 是持续集成领域出现最早、用得最广的工具之一。很多团队的自动化是从它开始的：开发者 push 代码，Jenkins 拉取代码、编译、跑测试、打包，最后把产物推到目标服务器。它的优点很明显——插件生态极其丰富，几乎任何语言、任何构建工具都有现成支持；缺点同样明显——插件质量参差，版本升级偶发出问题，界面偏工程师向。但对中小团队来说，它依然是自建 CI 最省心的起点。

这篇文章解决的问题是：在你自己的 Linux 服务器上，从零把 Jenkins 装起来、跑起来、配好 Git 集成和构建触发，让它真正能干活。我会把 Java 依赖、三种安装方式的取舍、初始化流程、凭据管理、任务配置方式、常见触发方式讲清楚，每部分都给可执行的命令和 RHEL/CentOS/Rocky 与 Debian/Ubuntu 两套写法。

有一件事要先说在前面：Jenkins 不是"装完就好"的软件，它对内存和磁盘的要求比想象中高，配置错了会在几个月后以"构建越来越慢""磁盘满了"的形式找上门。所以这篇文章会特别强调资源规划和维护。

一、Jenkins 是什么，什么时候该上它

Jenkins 的核心模型非常朴素：它有一个常驻的调度进程，按照你定义的"任务"（Job）去执行一串命令。命令可以是编译、测试、打包、部署中的任意组合。任务可以由时间触发（比如每晚跑一次），可以由代码变化触发（比如 push 后），也可以由上游任务触发（A 成功后跑 B）。执行结果会记录下来，包括控制台输出、耗时、成功失败状态。

它和 GitLab CI、GitHub Actions 这类"配置即代码"的工具有本质区别：Jenkins 的配置主要存在它自己的数据库里，通过网页点击维护；后者的配置是仓库里的一个 YAML 文件，跟着代码走。这个差异决定了它们的适用场景。

一个务实的判断标准：如果你的代码已经在 GitLab 上，优先用 GitLab CI，省一套系统的维护成本；如果代码来源很杂（有的在 Git，有的在 SVN），或者需要把构建部署串成一棵复杂的依赖树，Jenkins 的灵活性就体现出来了。

二、资源规划与 Java 依赖

Jenkins 是 Java 应用，新版本（2.3xx 以后的 LTS）要求 Java 11 或 17，具体版本要求随 Jenkins 版本变化，装之前务必查一下对应版本的文档。用错 Java 版本的表现是启动直接失败或者插件报奇怪的错。

资源方面给几个经验量级：只跑几个小任务，2 核 4G 能跑起来，但会紧张；正经用建议 4 核 8G 起步；构建量大、并发多的话 8 核 16G 更稳妥。磁盘要特别留意，Jenkins 的工作目录（默认 ~/.jenkins 或 /var/lib/jenkins）会堆积每次构建的产物和日志，几十 G 是常态，建议单独挂一块盘，起步预留 50G 以上。

安装 Java

# RHEL / Rocky / AlmaLinux（JDK 17）
sudo dnf install -y java-17-openjdk java-17-openjdk-devel

# CentOS 7 用 yum，版本可能偏低，建议至少 11
# sudo yum install -y java-11-openjdk java-11-openjdk-devel

# Debian 12 / Ubuntu 22.04 及以上
sudo apt update
sudo apt install -y openjdk-17-jdk

# Ubuntu 20.04 也可用 java-11-openjdk
# sudo apt install -y openjdk-11-jdk

# 验证
java -version

如果系统里装了多个 Java 版本，Jenkins 可能用错那个。RHEL 系用 alternatives --config java 切换默认版本，Debian 系用 update-alternatives --config java。另一种更明确的做法是在 Jenkins 的启动参数或配置文件里写死 JAVA_HOME，不依赖系统默认。

三、三种安装方式

Jenkins 的安装方式大致三类，思路不同，维护方式也不同。

方式一：下载 war 包直接运行

这是最不依赖环境的方式，适合快速试用或者想完全掌控启动参数。

# 创建工作目录
sudo mkdir -p /opt/jenkins
sudo chown $(whoami) /opt/jenkins
cd /opt/jenkins

# 下载最新 LTS 版 war 包（文件名以 .war 结尾，-L 跟随重定向）
wget -L -O jenkins.war https://mirrors.tuna.tsinghua.edu.cn/jenkins/war-stable/latest/jenkins.war 2>/dev/null \
  || curl -L -o jenkins.war https://get.jenkins.io/war-stable/latest/jenkins.war

# 前台试跑，指定端口，方便看日志
java -jar jenkins.war --httpPort=8080

能访问后如果你打算长期用，别一直前台跑，要交给 systemd 托管（做法和后面 Debian 的示例一致，只是启动命令换成 java -jar）。

方式二：发行版包（推荐）

RHEL 系和 Debian 系都有官方维护的源，安装后自动生成 systemd 服务，升级也简单。

# RHEL / Rocky / AlmaLinux
sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io-2023.key
sudo dnf install -y jenkins
sudo systemctl daemon-reload
sudo systemctl enable --now jenkins
sudo systemctl status jenkins

# Debian / Ubuntu
sudo wget -O /usr/share/keyrings/jenkins-keyring.asc https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key
echo "deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/" | sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null
sudo apt update
sudo apt install -y jenkins
sudo systemctl enable --now jenkins

这种方式的优点是把服务、用户、数据目录都规范好了：服务名 jenkins，数据在 /var/lib/jenkins，配置在 /etc/default/jenkins（Debian）或 /etc/sysconfig/jenkins（RHEL）。要改端口或 JVM 参数，改配置文件后 systemctl restart jenkins 即可。

方式三：Docker 运行

适合已经全面容器化的环境，或者想快速起一个隔离的实例。

# 拉取 LTS 镜像
docker pull jenkins/jenkins:lts-jdk17

# 运行，数据目录挂出来，否则容器删了配置全没
docker run -d --name jenkins \
  -p 8080:8080 -p 50000:50000 \
  -v jenkins_home:/var/jenkins_home \
  -v /var/run/docker.sock:/var/run/docker.sock \
  --restart unless-stopped \
  jenkins/jenkins:lts-jdk17

风险提示：把 docker.sock 挂进容器等于把宿主机 Docker 的控制权交给了容器，方便是真方便，但一旦 Jenkins 被攻破，攻击者就能在宿主机上起任意容器。生产环境要权衡，替代方案是用 SSH 连接到宿主机执行 Docker 命令。

三种方式对比：

四、初始化与插件安装

首次访问 http://服务器IP:8080，会让你输入初始管理员密码。

# 发行版包安装的密码位置
sudo cat /var/lib/jenkins/secrets/initialAdminPassword

# Docker 方式
docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

输入后会有"安装推荐插件"和"自定义选择"两个选项。新手直接选推荐插件，它会装 Git、Pipeline、凭据等基础插件。但要注意，这个步骤需要从 Jenkins 插件中心下载，国内网络经常很慢甚至失败，表现是插件一直卡在安装中。

加速办法有两个：一是配 HTTP 代理，在"系统管理 → 系统配置 → 插件管理 → 高级"里填代理地址；二是换国内镜像，在"高级"里把更新站点地址换成清华或华为的 Jenkins 镜像地址。这两个操作都能在初始化界面完成，如果初始化时没配，之后在"系统管理 → 插件管理 → Advanced"里也能改。

初始化完成后建议做三件事：第一，创建管理员账号，不要用默认的匿名可读；第二，在"系统管理 → 系统配置"里设置 Jenkins 自身访问地址（Jenkins URL），否则邮件、Webhook 回调里的链接会是错的；第三，装完插件后重启一次，很多插件需要重启才生效。

五、创建第一个构建任务

Jenkins 有两类任务：自由风格（Freestyle）和流水线（Pipeline）。前者在网页上点选配置，上手快；后者用 Jenkinsfile 写脚本，可版本控制，适合复杂流程。新手建议从自由风格起步，理解了概念再转 Pipeline。

自由风格任务的核心配置项就这么几个：源码管理（从哪里拉代码）、构建触发器（什么时候跑）、构建环境（可选，比如清理工作区）、构建步骤（执行什么命令）、构建后操作（归档产物、通知）。

一个典型的 Java 构建流程：

# 在"构建步骤 → 执行 shell"里写
echo "当前构建号: $BUILD_NUMBER"
echo "工作目录: $WORKSPACE"

# Maven 构建，跳过测试加快速度，正式环境建议保留测试
mvn clean package -DskipTests

# 或者用 Gradle
# ./gradlew clean build -x test

# 把产物归档（在"构建后操作 → 归档成品"里配置 target/*.jar）
ls -lh target/*.jar

Jenkins 在构建时会注入一批环境变量，常用的有 BUILD_NUMBER（构建号）、WORKSPACE（工作目录）、JOB_NAME（任务名）、GIT_COMMIT（本次提交哈希）、BUILD_URL。这些变量在脚本里能直接引用，做版本标记、通知、回滚时很有用。

一个必须知道的细节：Jenkins 默认不会自动清理工作区，每次构建都在同一个目录里进行增量操作。这会导致一个典型问题——上次构建留下的文件这次还在，覆盖不干净。解决办法是在"构建环境"里勾选"删除工作区后再构建"，或者在脚本开头手动清理，代价是每次都要重新下载依赖，所以更推荐用构建工具的 clean 阶段而非删整个工作区。

六、凭据管理与 Git 集成

拉取私有仓库需要认证，Jenkins 提供了凭据系统专门存这类敏感信息，它是加密存储的，比把密码写进脚本安全得多。

操作路径是"系统管理 → 凭据 → 系统 → 全局凭据 → 添加凭据"。支持的常见类型：用户名密码、SSH 私钥、Secret text（存 token）、证书。添加时给一个 ID，脚本里通过 ID 引用而不是明文。

对于 Git 仓库，两种认证方式最常用。HTTP(S) 方式是用户名加密码或访问令牌，配置简单，适合大多数场景；SSH 方式需要把私钥存进 Jenkins，然后在"源码管理"里选择对应的凭据。注意 SSH 方式生成的公钥要加到 Git 服务器的 authorized_keys 里（做法见 Git 服务器那篇）。

# 脚本里引用凭据的推荐方式（PIPELINE 场景）
# 自由风格任务里直接在下拉框选即可

# 如果确实需要用到明文变量，用这个语法注入，避免直接写死
withCredentials([usernamePassword(credentialsId: 'git-cred',
                                  usernameVariable: 'GIT_USER',
                                  passwordVariable: 'GIT_PASS')]) {
    sh 'git clone https://$GIT_USER:$GIT_PASS@git.example.com/demo.git'
}

在自由风格任务里配置 Git 源时，填仓库地址、选凭据、指定分支（如 */main）。如果服务器用的是自签名证书，Jenkins 可能报 SSL 校验失败，这台机器上 Git 需要配 git config --global http.sslVerify false——但这会降低安全性，更好的做法是把自签 CA 加到系统信任链里。

七、构建触发方式

触发的四种常见方式，按使用频率排：手动点击、定时（cron）、代码提交触发（Webhook / 轮询）、上游任务完成后触发。

定时触发在自由风格任务里叫"Build periodically"，语法是标准 cron 但字段顺序是分、时、日、月、周。注意一个容易搞错的细节：Jenkins 里日和周是"或"的关系，写 H 3 * * 1 表示每周一凌晨三点左右执行，用 H 而不是具体数字可以让多个任务错峰，避免同一时刻挤爆。

轮询（Poll SCM）是让 Jenkins 定期检查仓库有没有新提交，属于拉模型。它的缺点是有延迟、对仓库有额外压力，优点是配置简单、不需要仓库端配合。间隔别设太短，H/5 * * * *（每五分钟）已经足够。

Webhook 是推模型，代码一提交仓库立刻通知 Jenkins，延迟最低。Jenkins 侧用 GitLab 插件或 Generic Webhook Trigger 提供回调地址，仓库侧配置 http://jenkins.example.com/project/你的任务名。要注意的是 Jenkins 必须能从仓库服务器访问到（内网 Jenkins 对外暴露的问题），以及回调地址里如果带 token 要保管好。

上游触发用"构建后操作 → 构建其他工程"实现，适合把"编译 → 测试 → 部署"拆成三个任务串联。Pipeline 里的 build 步骤也能做同样的事，而且依赖关系更清晰。

常见问题

Q：Jenkins 启动报 "Failed to start" 或一直重启？

先看日志：sudo journalctl -u jenkins -n 100 --no-pager。最常见的原因是 Java 版本不满足要求，其次是没有权限写数据目录。用 war 包方式跑的话，直接在终端看输出更直观。

Q：构建时提示找不到 java / mvn 命令？

Jenkins 服务启动时的 PATH 和你登录 shell 的 PATH 不一样，/usr/local/bin 下的工具经常找不到。解决方式是在任务里用绝对路径，或者在"系统配置 → 全局属性"里补 PATH，或者干脆配好工具路径让 Jenkins 自动管理。

Q：磁盘很快就满了？

Jenkins 默认保留每次构建的历史和产物。在任务配置里可以设置"丢弃旧的构建"，比如"保留最近 10 次"，能大幅降低占用。同时检查 /var/lib/jenkins/jobs/*/builds 的大小，必要时手工清理旧构建目录——删除前确认这些构建不再需要用于回滚。

Q：推送代码后 Jenkins 没有自动构建？

分两种情况：用 Webhook 的话，检查仓库侧能否访问 Jenkins 地址、有没有被防火墙拦；用轮询的话，检查任务是否真的检测到了新提交、cron 表达式是否正确。Jenkins 的"构建触发器"页有个"立即轮询"的按钮，可以手动验证。

Q：多个任务互相影响，同时构建时失败？

那是并发没控制好。在任务配置里取消勾选"必要时执行并发构建"，让同一任务的多次触发排队。如果不同任务抢的是同一个目录或端口，需要用不同的工作区或者引入锁机制。

总结

Jenkins 上手不难，难在长期维护。装机这一步，记住四个关键决定：Java 版本要选对，否则启动就失败；安装方式上，常规生产用发行版包最省心，需要隔离用 Docker；资源要预留够，4 核 8G 加独立数据盘是舒服的起点；插件源在国内必须换镜像或配代理，否则初始化会卡住。

配置层面，凭据系统要真正用起来，别把密码写进脚本；Git 集成本质就是"能拉代码"，把认证配通即可；触发方式按延迟和复杂度取舍，Webhook 最快、轮询最省事、定时最可控。构建任务里最容易被忽略的是工作区清理和旧构建保留策略，这两项直接决定半年后你的 Jenkins 是流畅还是卡顿。

最后提醒一点：Jenkins 自身的配置也需要备份。数据目录（/var/lib/jenkins）里的 jobs、credentials.xml、config.xml 是关键，定期打包归档，万一机器挂了能快速重建。凭据是加密的，还需要同时保管好 secrets 目录和 hudson.util.Secret，否则换了机器解不开。