Jenkins 2.361 实战部署与自动化配置全解析：从零到精通

对于许多刚接触持续集成/持续交付（CI/CD）的开发者来说，Jenkins 就像一座功能强大但结构复杂的自动化工厂。你或许听说过它能自动拉取代码、编译、测试、部署，但当你真正打开官方文档，面对五花八门的安装包、插件和配置项时，很容易感到无从下手。特别是当你需要在生产环境的 Linux 服务器上，部署一个稳定、可控的特定版本时，这个过程充满了细节陷阱。今天，我们就以 Jenkins 2.361 LTS（长期支持）版本为例，抛开那些泛泛而谈的教程，深入每一个操作环节，不仅告诉你“怎么做”，更解释“为什么这么做”，并分享我在多次部署中积累的实战技巧和避坑指南。无论你是要为团队搭建第一套 CI/CD 流水线，还是需要升级或迁移现有 Jenkins 环境，这篇指南都将为你提供一条清晰、可靠的路径。

1. 环境准备与核心依赖部署

在将 Jenkins 安装包扔进服务器之前，我们必须先为其搭建一个稳固的“地基”。这个地基就是运行环境和必要的构建工具。很多初学者会直接安装 Jenkins，然后发现无法编译 Java 项目，问题根源往往就在这里。

首先，我们需要一个合适的 Java 环境。Jenkins 2.361 版本基于 Java 8 或 Java 11 运行。虽然它支持更高版本的 Java，但为了最佳的兼容性，特别是与众多插件的配合，我推荐使用 OpenJDK 11。它开源、免费，并且被大多数 Linux 发行版官方仓库支持。

通过 SSH 连接到你的目标服务器（假设是一台干净的 CentOS 7 或 Rocky Linux 8 服务器），开始我们的准备工作。

# 更新系统包管理器缓存
sudo yum update -y

# 安装 OpenJDK 11 开发套件
sudo yum install -y java-11-openjdk-devel

安装完成后，验证一下是否成功：

java -version

你应该能看到类似 openjdk version "11.0.xx" 的输出。接下来是 Maven。Jenkins 本身不负责编译 Java 代码，它需要调用外部的 Maven 来完成这项工作。我们将手动安装一个特定版本的 Maven，以便于版本控制。

# 进入常用的软件安装目录
cd /usr/local/src

# 下载 Apache Maven 3.8.8（一个稳定且兼容性好的版本）
sudo wget https://archive.apache.org/dist/maven/maven-3/3.8.8/binaries/apache-maven-3.8.8-bin.tar.gz

# 验证文件完整性（可选但推荐）
sudo wget https://archive.apache.org/dist/maven/maven-3/3.8.8/binaries/apache-maven-3.8.8-bin.tar.gz.sha512
sudo sha512sum -c apache-maven-3.8.8-bin.tar.gz.sha512

# 解压到 /usr/local 目录
sudo tar -xzf apache-maven-3.8.8-bin.tar.gz -C /usr/local/

现在，我们需要让系统知道 Java 和 Maven 的位置。编辑全局环境变量配置文件：

sudo vim /etc/profile.d/my_java_env.sh

在这个新文件中添加以下内容（使用 vim 的 i 键进入插入模式）：

# 设置 JAVA_HOME， 使用 which java 和 dirname 找到的真实路径可能更准确
# 但通过 rpm/deb 包安装的 OpenJDK 通常在此路径
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk

# 设置 MAVEN_HOME
export MAVEN_HOME=/usr/local/apache-maven-3.8.8

# 将它们的可执行文件目录加入 PATH
export PATH=$JAVA_HOME/bin:$MAVEN_HOME/bin:$PATH

保存退出（按 Esc 键，然后输入 :wq 回车）。让配置立即生效：

source /etc/profile.d/my_java_env.sh

再次验证，这次两个工具都应该能正确识别：

java -version
mvn -v

注意：将环境变量设置在 /etc/profile.d/ 下的独立 .sh 文件中，是一种更清晰、更易于管理的方式，避免了直接修改 /etc/profile 主文件可能带来的风险。这对于后续维护和排查问题非常有帮助。

至此，我们的“地基”已经打牢。你可能会问，为什么不用 Docker 来安装 Jenkins？确实，容器化部署更快捷。但对于需要深度定制、与宿主机紧密交互（比如调用宿主机 Docker 引擎、使用特定硬件资源）的生产环境，以及作为初学者理解其完整架构，原生安装方式仍然是不可替代的一课。

2. Jenkins 2.361 LTS 的安装与初始化

有了稳固的基础，现在可以开始安装 Jenkins 本体了。我们选择 2.361 这个 LTS 版本，因为它经过了更长时间的测试，拥有更好的稳定性和插件兼容性，非常适合生产环境。

Jenkins 官方为 Red Hat 系系统（如 CentOS, RHEL, Fedora）提供了便捷的 RPM 仓库。我们将通过仓库安装，这比手动下载 RPM 包更能方便未来升级。

# 导入 Jenkins 官方 GPG 密钥，用于验证软件包完整性
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io-2023.key

# 添加 Jenkins 官方稳定版仓库
sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo

但是，仓库默认会安装最新的 LTS 版本。我们需要指定安装 2.361 版本。一种方法是直接下载该版本的 RPM 包进行安装。我们先查看仓库中可用的版本：

# 清理 yum 缓存并重新建立
sudo yum clean all
sudo yum makecache

# 搜索所有可用的 Jenkins 版本（可能需要启用相关插件）
sudo yum list jenkins --showduplicates | sort -r

如果列表中有 2.361 版本，可以直接指定安装：

sudo yum install -y jenkins-2.361

如果仓库中没有，我们可以从官方存档直接下载 RPM 包安装：

cd /tmp
# 下载特定版本的 RPM 包
sudo wget https://archives.jenkins.io/redhat-stable/jenkins-2.361-1.1.noarch.rpm

# 安装该 RPM 包及其依赖
sudo yum localinstall -y jenkins-2.361-1.1.noarch.rpm

安装完成后，我们需要对 Jenkins 进行一些关键配置。编辑其主配置文件：

sudo vim /etc/sysconfig/jenkins

在这个文件里，有几个参数我强烈建议你修改：

  • JENKINS_USER: 默认是 jenkins。在某些需要更高权限访问 Docker 套接字或特定目录的场景下，你可以考虑将其改为 root，但这会带来安全风险。对于大多数情况，保持 jenkins 用户，并通过正确的组权限管理是更佳实践。
  • JENKINS_PORT: 默认是 8080。如果这个端口已被占用，或者你想使用标准的 80 端口（需配合反向代理），可以在这里修改。
  • JENKINS_HOME: 这是 Jenkins 所有数据（任务配置、构建日志、插件）的存储目录。默认是 /var/lib/jenkins。确保这个目录所在的磁盘有充足的空间，因为构建日志和工件（Artifacts）会占用大量空间。

保存配置后，启动 Jenkins 服务并设置开机自启：

# 重载 systemd 配置
sudo systemctl daemon-reload

# 启动 Jenkins 服务
sudo systemctl start jenkins

# 设置开机自启
sudo systemctl enable jenkins

# 查看服务状态，确认运行正常
sudo systemctl status jenkins

如果状态显示 active (running)，恭喜你，Jenkins 服务已经跑起来了。现在打开浏览器，访问 http://你的服务器IP:8080。你会看到经典的“解锁 Jenkins”页面，要求你输入初始管理员密码。

这个密码在哪里呢？回到服务器终端：

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

复制那一长串密码，粘贴到 Web 页面中，点击“继续”。接下来，你会进入“自定义 Jenkins”页面，提示你安装插件。

提示：这里我推荐选择 “安装推荐的插件”。对于新手，这个选项会安装一套最常用、最稳定的插件组合，包括 Git、Pipeline、邮件通知等，足以应对大多数场景。虽然网络因素可能导致部分插件安装失败，但我们可以稍后在管理界面中重试或手动安装，这比一个插件都没有的“裸奔”状态要好得多。

插件安装过程可能需要一段时间，取决于你的网络速度。安装完成后，系统会提示你创建第一个管理员用户。务必认真填写并记住这个账户信息，这是你日后管理 Jenkins 的钥匙。之后是配置实例 URL，一般保持默认的 http://你的服务器IP:8080 即可。

点击“保存并完成”，然后“开始使用 Jenkins”。至此，Jenkins 的安装和初始化已经全部完成，一个干净的 Jenkins 仪表板呈现在你面前。但这只是一个开始，要让 Jenkins 真正为你工作，关键的配置还在后面。

3. 插件生态与核心工具配置

Jenkins 的强大，一半源于其核心调度引擎，另一半则归功于其庞大的插件生态系统。初始安装的插件只是基础，我们需要根据实际工作流安装和配置更多插件。同时，要让 Jenkins 能执行构建任务，必须告诉它 JDK 和 Maven 在哪里。

首先，我们来安装几个构建 Java Web 项目必不可少的插件。进入 Jenkins 管理后台：点击左侧菜单栏的 “Manage Jenkins” -> “Manage Plugins”。

在“Available”标签页中，在右上角的过滤框里搜索并勾选以下插件：

  1. Maven Integration: 让 Jenkins 原生支持 Maven 项目，自动解析 pom.xml。
  2. Deploy to container: 允许将构建好的 WAR 包自动部署到 Tomcat、JBoss 等 Servlet 容器。
  3. Publish Over SSH: 这是实现自动化部署的关键。它允许 Jenkins 通过 SSH 协议将文件传输到远程服务器，并执行远程命令。
  4. GitHub Integration 或 GitLab Plugin: 根据你的代码仓库选择，可以实现 Webhook 自动触发构建。
  5. Pipeline: 现代 Jenkins 的灵魂，支持用代码（Jenkinsfile）来定义整个构建、测试、部署流程。
  6. Blue Ocean: 提供更直观、现代化的流水线可视化界面，对新手非常友好。

勾选后，点击页面底部的“Install without restart”。安装过程中可能会失败一两个，这通常是网络波动造成的，可以等页面自动刷新后，在“Installation progress”页面点击重试按钮。

注意：Jenkins 插件中心服务器在国外，国内访问可能缓慢或不稳定。如果反复安装失败，可以考虑更换为国内镜像源。方法是：在“Manage Plugins” -> “Advanced”标签页中，将“Update Site”的 URL 替换为清华大学镜像站地址：https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json，然后提交并重试。

插件安装好后，需要配置全局工具。回到“Manage Jenkins” -> “Global Tool Configuration”。

配置 JDK： 在 “JDK” 部分，点击 “Add JDK”。取消勾选 “Install automatically”。因为我们已经手动安装了 OpenJDK 11，所以只需要告诉 Jenkins 它的路径。

  • Name: 输入一个标识，如 OpenJDK-11。
  • JAVA_HOME: 填写我们之前设置的路径 /usr/lib/jvm/java-11-openjdk。 点击“保存”。

配置 Maven： 在 “Maven” 部分，点击 “Add Maven”。同样取消 “Install automatically”。

  • Name: 输入一个标识，如 Maven-3.8.8。
  • MAVEN_HOME: 填写 /usr/local/apache-maven-3.8.8。

配置完成后，一定要滚动到页面最下方，点击“保存”按钮。现在，Jenkins 就知道了如何调用 Java 和 Maven 来编译你的项目了。

4. 构建 SSH 可信通道：免密登录详解

自动化部署的精髓在于“无人值守”。我们不可能每次部署都手动输入远程服务器的密码。SSH 密钥对认证是实现这一目标的标准方式。其原理是：在 Jenkins 服务器上生成一对密钥（公钥和私钥），将公钥“锁”放在目标服务器上，而私钥“钥匙”留在 Jenkins 手中。这样，Jenkins 就可以无需密码直接访问目标服务器。

这个过程看似简单，但权限和用户上下文是最大的坑。请严格按照以下步骤操作。

第一步：在 Jenkins 服务器上生成密钥对

关键点：必须以 Jenkins 进程运行用户的身份来生成密钥。默认情况下，Jenkins 服务以 jenkins 系统用户运行。我们需要切换到该用户：

# 切换到 jenkins 用户，并启动一个登录 shell 以加载其环境变量
sudo su - jenkins

你会看到命令行提示符变成 -bash-4.2$，表示你现在是 jenkins 用户了。然后生成 SSH 密钥对：

ssh-keygen -t rsa -b 4096 -C "jenkins@your_jenkins_server"

执行命令后，它会询问你密钥的保存路径，直接按回车使用默认路径（/var/lib/jenkins/.ssh/id_rsa）。接着询问“passphrase”（密码短语），为了完全自动化，这里直接按两次回车，设置为空。生成成功后，查看公钥内容：

cat ~/.ssh/id_rsa.pub

复制输出的全部内容，从 ssh-rsa 一直到注释文字结束。这就是你的公钥。

第二步：将公钥部署到目标服务器

假设你的应用要部署到一台 IP 为 192.168.1.100 的服务器，上面运行着 Tomcat。你需要将上一步复制的公钥，添加到这台服务器的 ~/.ssh/authorized_keys 文件中。

在目标服务器（192.168.1.100）上操作：

# 1. 确保目标服务器存在 .ssh 目录，权限为 700
mkdir -p ~/.ssh
chmod 700 ~/.ssh

# 2. 将 Jenkins 的公钥添加到 authorized_keys 文件
# 你可以用 vi 编辑器手动粘贴，或者通过 echo 命令（这里用 echo 示例）
# 注意：将 YOUR_PUBLIC_KEY 替换为你刚才复制的整行公钥字符串
echo "ssh-rsa AAAAB3NzaC1yc2E...（很长一串）... jenkins@your_jenkins_server" >> ~/.ssh/authorized_keys

# 3. 设置 authorized_keys 文件的权限为 600
chmod 600 ~/.ssh/authorized_keys

第三步：在 Jenkins 中配置 SSH 私钥

现在回到 Jenkins 的 Web 界面。进入 “Manage Jenkins” -> “Manage Credentials”。

  1. 在 “Stores scoped to Jenkins” 下，点击 “System”。
  2. 点击 “Global credentials (unrestricted)”。
  3. 点击左侧的 “Add Credentials”。
  4. 按照下表配置：
字段值说明
KindSSH Username with private key选择凭据类型
ScopeGlobal全局可用
IDjenkins-to-app-server一个唯一的标识符，后面会用到
Description连接应用部署服务器的密钥可选描述
Usernameroot 或你的部署用户目标服务器上拥有部署权限的用户名
Private KeyEnter directly选择直接输入
Key粘贴私钥内容回到 Jenkins 服务器终端，以 jenkins 用户执行 cat ~/.ssh/id_rsa，复制全部输出内容，包括 -----BEGIN RSA PRIVATE KEY----- 和 -----END RSA PRIVATE KEY----- 行。

点击“创建”。这样，Jenkins 就安全地存储了访问目标服务器的“钥匙”。

第四步：配置 Publish Over SSH 插件

进入 “Manage Jenkins” -> “Configure System”，页面滚动到 “Publish over SSH” 部分。

  1. 点击 “Add” 按钮，新增一个 SSH Server。
  2. Name: 输入一个易记的名字，如 Production_App_Server。
  3. Hostname: 目标服务器的 IP 地址或域名，如 192.168.1.100。
  4. Username: 保持为空（因为我们在凭据里已经指定了）。
  5. 点击 “Advanced” 按钮，可以配置端口（默认22）、超时时间等。
  6. 最关键的一步：在 “Credentials” 下拉框中，选择我们刚才创建的 jenkins-to-app-server 凭据。
  7. 点击右下角的 “Test Configuration” 按钮。如果看到绿色的 “Success” 提示，说明 SSH 连接配置成功！

至此，Jenkins 到目标服务器的自动化 SSH 通道已经建立。在后续的 Job 配置中，你就可以使用 “Send build artifacts over SSH” 或 “Execute shell script on remote host using ssh” 等步骤，轻松实现文件的传输和远程命令的执行，为自动化部署铺平了道路。

5. 实战：构建你的第一个 Maven 项目流水线

理论配置已经完成，是时候真刀真枪地跑一个项目了。我们将创建一个自由风格的软件项目，它从 Git 仓库拉取一个简单的 Spring Boot 应用代码，用 Maven 编译打包，然后通过 SSH 部署到远程 Tomcat 服务器。

第一步：创建新的 Item 在 Jenkins 首页点击 “New Item”。

  • 输入一个任务名称，例如 My-First-Maven-Deploy。
  • 选择 “Freestyle project”，点击 “OK”。

第二步：源码管理 在配置页面，找到 “Source Code Management” 部分，选择 “Git”。

  • Repository URL: 填入你的 Git 仓库地址，例如 https://github.com/yourname/simple-springboot-app.git。如果是私有仓库，需要在 “Credentials” 处添加你的 Git 用户名密码或 SSH 密钥。
  • Branches to build: 指定要构建的分支，例如 */main 或 */master。

第三步：构建触发器 这里我们可以设置自动构建。例如，选择 “Poll SCM”，并设置日程表 H/5 * * * *，这表示每5分钟检查一次代码仓库是否有更新。更高级的用法是使用 GitLab/GitHub Webhook，实现代码一推送就立即构建。

第四步：构建环境 暂时可以跳过，或根据需要勾选 “Delete workspace before build starts” 以保证构建环境清洁。

第五步：构建 这是核心步骤。点击 “Add build step”，选择 “Invoke top-level Maven targets”。

  • Maven Version: 选择我们之前配置的 Maven-3.8.8。
  • Goals: 输入 clean package。这个命令会清理旧构建，并打包项目（生成 WAR 或 JAR 文件）。

第六步：构建后操作：SSH 部署 构建成功后，我们需要将产物发送到应用服务器。点击 “Add post-build action”，选择 “Send build artifacts over SSH”。

  • SSH Server: 选择我们配置好的 Production_App_Server。
  • Transfers:
    • Source files: 填写构建产物的路径。对于 Maven 项目，WAR 包通常在 target/ 目录下，例如 target/*.war。
    • Remove prefix: 填写 target/。这样传输到远程服务器时，会去掉 target/ 前缀。
    • Remote directory: 填写远程服务器上的目标目录，例如 /opt/deploy/。这个目录需要事先存在，并且 SSH 用户有写权限。
    • Exec command: 填写部署脚本命令。例如，一个简单的 Tomcat 部署脚本可能是：
      #!/bin/bash
DEPLOY_DIR=/opt/deploy
WEBAPPS_DIR=/usr/local/tomcat/webapps
APP_NAME=myapp.war

# 停止旧应用（根据实际情况调整，热部署可能不需要）
# systemctl stop tomcat

# 备份旧war包（可选）
cp $WEBAPPS_DIR/$APP_NAME $WEBAPPS_DIR/$APP_NAME.bak.$(date +%Y%m%d%H%M%S) 2>/dev/null || true

# 复制新war包
cp $DEPLOY_DIR/*.war $WEBAPPS_DIR/$APP_NAME

# 启动Tomcat（如果停止了的话）
# systemctl start tomcat

# 检查Tomcat日志（简单示例）
tail -20 /usr/local/tomcat/logs/catalina.out
      你可以将这段脚本保存到远程服务器的 /opt/scripts/deploy.sh，并赋予执行权限 (chmod +x)，然后这里的 Exec command 就只需写 /opt/scripts/deploy.sh。

配置完成后，点击页面底部的 “Save”。

第七步：立即构建 回到项目主页面，点击左侧的 “Build Now”。你会看到左下角出现一个构建队列，然后开始第一次构建。点击构建编号（如 #1），再点击 “Console Output”，你可以实时查看整个构建和部署的日志输出。

当你在日志最后看到 Finished: SUCCESS 时，你的第一个自动化构建部署流水线就已经成功运行了！代码从提交到部署到服务器的全过程，已经实现了自动化。

在这个过程中，你可能会遇到诸如“权限被拒绝”、“找不到文件”之类的错误。请仔细查看控制台输出的错误信息，它们会精确地指出问题所在，通常是路径错误、权限不足或环境变量未正确设置。解决这些问题，正是你从“会用”到“精通”的必经之路。记住，每一个成功的构建背后，都可能藏着几次失败的尝试，而控制台日志就是你最好的调试伙伴。

Logo
乐奇 Rokid 开放社区

更多推荐

cover

小钱袋：说一句「午饭十八块五」，账单就记录到Rokid AI眼镜上啦

avatar 乐奇 Rokid 开放社区
cover

基于Rokid AIUI实现眼镜上的倒数日

avatar 乐奇 Rokid 开放社区
cover

从挥手到转头：【游戏大师】用 AIUI 绝对方向传感器在 Rokid Glasses 上做头部准星切水果

avatar 乐奇 Rokid 开放社区