企业官网建设流程全解析

先说个我自己的经历。几年前我第一次接触 Jenkins 的时候，脑子里只有一个特别朴素的疑问：每次改完代码都要手动打包、传服务器、重启服务，一天重复十几次，能不能有个东西帮我自动干完这些活？后来同事丢给我一个 Jenkins 地址，说“你以后提交代码就不用自己 build 了”，我半信半疑点开那个蓝色界面，从此就再也没回到纯手工部署的日子。

这篇内容就是写给当年那个“小白”的。不管你是刚入行的开发、被分配了部署任务的测试、还是想给团队搭自动化流程的运维新人，Jenkins 大概率是你绕不开的第一个持续集成工具。你不需要先懂什么高深理论，只要有一台能跑 Java 的机器、一个 Git 仓库、一条能跑通的构建命令，就能跟着这篇文章把 Jenkins 从装到用走一遍。我会尽量用大白话解释每个环节在干嘛，也会把那些坑提前摆出来——毕竟这些坑我基本都踩过。

1. 先搞清楚 Jenkins 到底是个什么东西

1.1 用做饭的比喻理解持续集成和持续部署

很多教程一上来就甩“持续集成”“持续交付”“持续部署”这些词，小白很容易被吓退。我换个说法：假设你是一个做饭的厨师，以前每炒一道菜，都要自己洗菜、切菜、开火、调味、装盘，全程手动。现在你雇了一个帮工，你只需要把菜谱丢给他，他会自动去拿菜、洗好切好、按顺序下锅、出锅后装盘，甚至帮你把盘子端到餐桌。这个“帮工”就是 Jenkins。

对应到软件开发里，“炒菜”就是构建和部署。“菜谱”就是你在 Jenkins 里配置的自动化流程：从 Git 拉代码、跑测试、打包、传到服务器、重启服务。你不需要知道帮工内部怎么运作，你只管告诉他“代码一变就开工”，剩下的事他自动处理。这个“代码一变就自动开工”的动作，就是持续集成；如果他还自动把产物发布到测试甚至生产环境，那就是持续部署。Jenkins 的本质，就是把“人肉重复操作”转换成“机器按规则执行”。

1.2 Jenkins 在团队工作流里的位置

一个典型的研发团队，日常流程大概是这样的：开发写代码，推到 Git 仓库；测试或者 CI 工具感知到代码变更，自动拉取最新代码；然后跑单元测试、编译、打包；如果通过，把产物部署到测试环境；测试人员拿到新版本开始测；再往后可能还有自动发布到生产环境的环节。

Jenkins 通常就站在“代码仓库”和“服务器环境”中间，像是一个数据加工厂：输入是源代码，输出是能跑起来的产物，顺带帮你把产物放到该放的地方。它不替代 Git、不替代 Docker、不替代 Kubernetes，但它是把这些东西串起来的那根线。这也是为什么很多公司招聘 JD 里会写“熟悉 Jenkins 或类似 CI/CD 工具”——它几乎是自动化交付链路上绕不开的一环。

1.3 小白必懂的核心概念清单

在开始操作之前，有几个概念必须知道，否则看配置界面会一头雾水：

• 任务（Job）：一个自动化流程的单元，相当于一份“菜谱”。你要构建某个项目，就创建一个任务。
• 构建（Build）：任务每执行一次，就叫一次构建。每次构建有独立编号，比如 #1、#2。
• 工作区（Workspace）：构建时 Jenkins 用来存放代码和临时文件的目录。默认在 Jenkins 安装目录下的 workspace 文件夹里。
• 插件（Plugin）：Jenkins 的扩展包，相当于手机应用商店里的 App。你想支持 Git、Maven、Docker、飞书通知，都需要装对应的插件。
• 节点（Node）：执行任务的计算资源。最简单的情况下，Jenkins 自己就是一个节点；你也可以加其他机器作为 agent，把任务分散到多台机器上跑。
• 流水线（Pipeline）：把构建步骤用代码写成一条流水线，好处是流程可以被版本管理、可复用、更直观。

这些概念第一次接触不需要背，后面操作时反复用到，自然就记住了。

2. 环境准备与安装部署：两条路线实战

安装 Jenkins 之前，先说一个最容易被忽略的前提：Java。不同版本的 Jenkins 要求的 JDK 版本不一样。老版本 Jenkins 用 JDK 8 就能跑，但 Jenkins 2.357 之后的 LTS 版本要求 JDK 11 或 JDK 17；到 2.420 左右的版本，JDK 11 仍然是可用的，但一些新功能和插件开始要求 JDK 17。我的建议是小白直接装 JDK 17，别用 JDK 8，否则后面装新版 Jenkins 时可能直接起不来。

2.1 路线一：CentOS 7 直接安装 Jenkins

如果你手头有一台 CentOS 7 服务器，又不打算用 Docker，最直接的方式是通过系统服务来跑 Jenkins。CentOS 7 默认的yum源里没有 Jenkins，需要先添加 Jenkins 官方仓库。官方的做法是执行两条命令：

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 yum install -y jenkins

但这里有个实际问题：pkg.jenkins.io在某些网络环境下下载很慢，甚至连接超时。如果遇到这种情况，可以换用国内镜像源。比如清华大学的镜像源，把仓库地址改成https://mirrors.tuna.tsinghua.edu.cn/jenkins/redhat-stable/就能明显提速。做法是手动编辑/etc/yum.repos.d/jenkins.repo，把baseurl改成对应镜像地址。

装完之后的目录结构要心里有数：

• /usr/lib/jenkins/jenkins.war：核心程序文件
• /etc/sysconfig/jenkins：配置文件，可以改端口、JVM 参数
• /var/lib/jenkins：默认的工作目录，所有任务配置、构建记录都在这
• /var/log/jenkins/jenkins.log：日志文件

启动和设置开机自启：

sudo systemctl start jenkins sudo systemctl enable jenkins

默认端口是 8080，用http://服务器IP:8080访问。如果打不开，先检查防火墙：

sudo firewall-cmd --permanent --add-port=8080/tcp sudo firewall-cmd --reload

2.2 路线二：Docker 方式部署 Jenkins

如果你的服务器已经装了 Docker，或者你更习惯用容器管理服务，那用 Docker 跑 Jenkins 会更省心，升级、迁移都很方便。我自己现在也更推荐这种方式，因为环境隔离，不会污染宿主机。

先拉取官方镜像：

docker pull jenkins/jenkins:lts

lts是长期支持版，稳定性有保障。如果你需要特定版本，可以到 Docker Hub 查看 tags，比如jenkins/jenkins:2.440.3-lts。需要注意，网络上很多人随便搜到一个jenkins镜像就用，但 Docker Hub 上的jenkins镜像很旧，而且已经停止维护了，一定要用jenkins/jenkins这个官方镜像。

启动容器前，先创建一个目录用来存储 Jenkins 数据，避免容器删了数据全丢：

mkdir -p /data/jenkins_home

然后启动：

docker run -d \ --name jenkins \ -p 8080:8080 \ -p 50000:50000 \ -v /data/jenkins_home:/var/jenkins_home \ -v /var/run/docker.sock:/var/run/docker.sock \ jenkins/jenkins:lts

这里解释一下几个参数：

• -d：后台运行
• --name：容器名字
• -p 8080:8080：映射 Web 访问端口
• -p 50000:50000：Jenkins 主从节点通信端口，以后要加 agent 节点才用得上
• -v /data/jenkins_home:/var/jenkins_home：把 Jenkins 的数据目录挂载到宿主机，这是最关键的挂载
• 最后一个-v /var/run/docker.sock:/var/run/docker.sock：把宿主机的 Docker 套接字共享给容器，这样 Jenkins 里的任务可以直接调起 Docker 容器来构建，属于进阶用法

这里有个特别容易踩的坑：容器里的 Jenkins 默认以jenkins用户运行，UID 是 1000。如果你宿主机上的/data/jenkins_home目录权限不对，容器启动时会报目录不可写。解决办法非常简单：

chown -R 1000:1000 /data/jenkins_home

如果拉镜像遇到问题，大概率是网络原因。可以选择配置 Docker 镜像加速器，比如国内云厂商提供的加速地址，或者到镜像站手动下载镜像包再导入。这一步属于常规环境操作，遇到一次就知道怎么回事了。

2.3 首次启动与解锁

无论用哪种方式安装，第一次访问 Jenkins 页面时都会看到一个“解锁 Jenkins”的界面，让你输入一个初始管理员密码。这是 Jenkins 的安全机制，防止别人直接接管你还没配置好的实例。

获取密码的方式取决于你的安装方式。直接用系统服务安装的：

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

用 Docker 安装的，需要进入容器里看：

docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

输入密码后，Jenkins 会让你选择安装插件的方式。小白建议直接选“安装推荐的插件”，安装过程可能持续几分钟。如果中间有插件装失败，先不要慌，后面可以重新装。跳过这步也可以，但后续很多功能受限，所以还是建议先装上。

3. 初始配置：中文界面、权限与成员管理

3.1 新版本 Jenkins 设置中文的正确方式

很多教程告诉你，在“Manage Jenkins”里的“Plugin Manager”搜“Chinese”插件，然后安装“Localization: Chinese (Simplified)”就好了。这个说法放在老版本上没错，但新版 Jenkins 的界面布局变化比较大，一些小白会卡在找不到对应的菜单。

正确操作路径是这样的：

1. 登录 Jenkins 后，点击左侧“Manage Jenkins”（管理 Jenkins）。
2. 在管理页面找到“Plugins”（插件）入口，点击进入。
3. 切换到“Available plugins”（可用插件）标签页。
4. 在搜索框输入Localization，找到Localization: Chinese (Simplified)，勾选后点击“Install without restart”。
5. 安装完成后，回到首页，你会看到界面已经变成中文。如果没有变化，手动刷新浏览器页面，或者重启 Jenkins 服务。

还有一个小细节：新版 Jenkins 已经内置了语言切换能力，只要安装了对应的语言包，就会根据浏览器语言自动显示中文。所以如果你的浏览器默认语言是英文，装完中文插件也没反应，可以检查一下浏览器语言设置，把中文放到最前面。

3.2 用户、角色与权限配置

装完直接裸奔可不是好习惯。Jenkins 默认开启了一个“显示匿名用户可读权限”的模式，懂行的人拿到你地址就能看到所有任务和构建日志，这在真实环境里非常危险。

配置权限分三步：

第一步，去“Manage Jenkins” -> “Security”（安全），把“Authorization”（授权策略）从“Logged-in users can do anything”改成“Matrix-based security”（矩阵授权策略）。

第二步，在“Manage Jenkins” -> “Users”（用户）里创建普通用户。点“Create User”填写用户名、密码、邮箱即可。

第三步，回到安全配置页面，给不同用户分配权限。比如给开发人员分配Job/Read、Job/Build、Job/Cancel这三项权限，让他能触发构建但不能改配置；给管理员分配Administer全部权限。矩阵授权页面看起来是一堆勾选框，其实横轴是操作类型，纵轴是用户/角色，你只需要在对应交叉位置打勾就行。

这里强烈建议创建一个专用的“只读账号”，给其他同事查看构建状态用。只分配Overall/Read和Job/Read权限，这个账号没法做任何修改操作，非常适合作为查阅入口。

3.3 插件管理基础与插件报错 500 的处理

插件是 Jenkins 的灵魂，没有插件的 Jenkins 就是一个空壳。国内很多团队用的是 GitLab 自建代码仓库，所以除了默认推荐插件外，我建议你登录后再装这几个：Git（一般默认已装）、Maven Integration、Pipeline（默认推荐已包含）、Blue Ocean、Email Extension、飞书插件（如果你用飞书）。

安装插件的路径在“Manage Jenkins” -> “Plugins” -> “Available plugins”，搜索插件名，勾选后点安装。

再说一个很多新手会撞上的问题：进入插件管理页面时，提示“该页面出现错误”，或者安装插件时报 500 错误。看到这个先别慌，绝大多数情况下不是 Jenkins 坏了，而是插件源连接不稳定或者插件版本与当前 Jenkins 版本不兼容。

我的排查顺序是：

1. 先看“Manage Jenkins”首页有没有提示“有新版本 Jenkins 可用”，如果有，先升级到最新 LTS 版本。
2. 在插件管理页面点击“Advanced settings”，检查“Update Site”里填的地址能不能正常访问。官方默认地址是https://updates.jenkins.io/update-center.json，国内访问不稳定时，可以换成清华或华为云的 Jenkins 更新源。
3. 清理/var/lib/jenkins/plugins目录下的.tmp后缀文件，这些是下载了一半的残片，有可能会干扰安装。
4. 重启 Jenkins 服务再试。

sudo systemctl restart jenkins # 或 docker restart jenkins

注意：插件不是装得越多越好。每装一个插件都可能引入新的依赖和兼容性问题，只装你真正用得到的。

4. 第一个自动化任务：从手动构建到一键部署

4.1 创建自由风格任务，配置后端项目 Maven 构建

我先以最常见的场景为例：一个 Maven 后端项目，希望每次代码更新后，Jenkins 自动拉取代码、执行mvn clean package、把打出来的 jar 包上传到服务器并重启服务。

登录 Jenkins 后，点击“New Item”（新建任务），输入任务名称，选择“Freestyle project”（自由风格项目），点击确定。

进入任务配置页面，从上到下依次配置：

第一块是“General”（常规）。可以在“Description”里写清楚这个任务是干什么的，方便别人查看。

第二块是“Source Code Management”（源码管理）。选择 Git，在“Repository URL”里填仓库地址，比如git@gitlab.example.com:group/project.git。如果仓库需要认证，点击“Credentials”旁边的“Add”，选择“Username with password”或“SSH key”，填好后在“Credentials”下拉框里选中。

第三块是“Build”（构建）。点击“Add build step”，选择“Invoke top-level Maven targets”，在“Goals”里填clean package -DskipTests。如果你希望测试也跑一遍，就别加-DskipTests。

这里要注意，如果 “Invoke top-level Maven targets” 这个选项不在下拉列表里，说明你还没安装Maven Integration插件，去插件管理里装上即可。

构建完成后，在“Post-build Actions”（构建后操作）里可以选“Archive the artifacts”，填target/*.jar，这样构建产物会保存到 Jenkins 上，方便下载。

4.2 环境变量的使用与调试

很多第一次接触 Jenkins 的人看不懂构建日志里那一堆BUILD_NUMBER、JOB_NAME、WORKSPACE是什么。这些就是 Jenkins 的内置环境变量，在任务执行过程中自动注入，你可以在构建脚本里直接引用。

常用变量说明如下：

如何使用？比如你想在构建日志里输出当前分支和提交号，可以在构建步骤里加一个“Execute shell”，输入：

echo "当前工作区: ${WORKSPACE}" echo "当前构建号: ${BUILD_NUMBER}" echo "当前提交: ${GIT_COMMIT}"

还有一种更实用的场景：在构建命令里引用自定义参数。任务配置页面勾选“This project is parameterized”，添加“String Parameter”，比如填BRANCH=main，后续在构建脚本里就可以用${BRANCH}来取这个值。这样同一个任务，可以通过传不同参数构建不同分支。

调试环境变量的小技巧：在“Execute shell”里加一行env，执行构建后日志会打印出所有环境变量，你就能看到当前这次构建到底把变量设成了什么值。

4.3 参数化构建与 Webhook 触发

任务配置页面里的“Build Triggers”（构建触发器）决定任务什么时候自动跑。最常见的两种：

一种是“Poll SCM”（轮询）。定时去检查代码仓库有没有变化，如果有就触发构建。比如H/5 * * * *表示每 5 分钟检查一次。这种方式的缺点是有延迟，代码推上去后最多要等一个轮询周期才开始构建。

另一种是“GitHub webhook”或“GitLab webhook”。代码仓库在收到 push 事件时主动通知 Jenkins。但前提是 Jenkins 要能收到仓库发来的请求，网络得通，而且需要配置对应插件。配置思路大致是：先在 Jenkins 任务里拿到 Webhook 地址，再到 Git 仓库的管理页面配置这个地址。如果用的是 GitLab，地址类似http://jenkins地址/project/任务名，再填一个认证令牌。

Webhook 配置好了以后，你会发现一个很爽的效果：代码一提交，Jenkins 自动开始构建，你甚至不用打开 Jenkins 页面，只要盯住机器人通知就行。

不过新手一开始没必要急着上 Webhook，先手动点“Build Now”，把整个构建流程跑通，确认没问题了再考虑自动化触发。不然配置错了，排查起来会同时涉及代码仓库和 Jenkins 两边的问题，容易绕晕。

4.4 部署到远程服务器的几种常见方式

构建只是完成了“打包”，真正要落地还得把产物部署到服务器上。根据团队情况，部署方式有几种：

最原始的方式：通过scp或rsync把构建产物传过去，然后 SSH 远程执行重启命令。这需要 Jenkins 服务器能 SSH 登录目标服务器，建议用密钥登录而不是密码。在 Jenkins 里建一个“SSH server”的凭据，然后在构建后操作或 Pipeline 脚本里引用。

示例的“Execute shell”片段：

scp -i /var/lib/jenkins/.ssh/id_rsa target/app.jar deploy@192.168.1.100:/opt/app/ ssh deploy@192.168.1.100 "systemctl restart app"

听起来很朴素，但确实是最直接可靠的。很多公司生产环境就是这么干的，区别只在于多包了一层脚本。

还有一种更现代的部署方式：构建产物打进 Docker 镜像，推送到镜像仓库，然后在目标服务器上拉镜像并重启容器。这个对小白来说稍微复杂，但如果你已经用 Docker 部署 Jenkins，那再往前走一步也不会太难。

5. Pipeline 和 Blue Ocean：更现代的自动化方式

5.1 声明式 Pipeline 入门

自由风格任务适合快速上手，但一旦流程复杂，配置项堆在页面里会很难维护。Pipeline 的做法是把整个流程写成一个 Jenkinsfile 文件，放进代码仓库里，Jenkins 按照文件内容执行。好处是流程能被 Git 版本化、可评审、可复用，换一台 Jenkins 也能跑。

一个最基础的声明式 Pipeline 长这样：

pipeline { agent any environment { BRANCH = 'main' } stages { stage('拉取代码') { steps { checkout scm } } stage('构建') { steps { sh 'mvn clean package -DskipTests' } } stage('部署') { steps { sh 'scp target/app.jar deploy@192.168.1.100:/opt/app/' sh 'ssh deploy@192.168.1.100 "systemctl restart app"' } } } post { success { echo '构建成功！' } failure { echo '构建失败！' } } }

每一段都很好理解：agent any表示任意可用节点上执行；environment定义环境变量；stages下面按顺序定义各个阶段；steps是具体要执行的命令；post里定义构建成功或失败后要做什么。

创建 Pipeline 任务时，在“Pipeline”配置区域选择“Pipeline script from SCM”，然后填 Git 仓库地址和 Jenkinsfile 在仓库里的路径，比如Jenkinsfile。这样代码提交后，Jenkins 会自动读取最新的 Jenkinsfile 并执行。

5.2 Blue Ocean 提升可视化体验

如果你觉得原生 Jenkins 页面太朴素、看出错不够直观，可以装一个 Blue Ocean 插件。它是 Jenkins 官方推出的现代化 UI，把流水线执行过程渲染成一列彩色的步骤卡片，哪个阶段过了、哪个阶段挂了，一眼就能看到。

安装方式还是在插件管理里搜Blue Ocean，安装后左侧菜单会出现“Open Blue Ocean”入口。打开后，它会自动列出所有 Pipeline 任务，点进去就能看到带颜色标记的流水线图。点击任何一个失败的步骤，可以直接看到那一步的日志，省去在大段日志里翻找的麻烦。

需要注意一点：Blue Ocean 并不是要替代经典界面，很多复杂配置最终还是要在原来的“Manage Jenkins”里完成。它更像是一个观察窗口，专治“构建失败但不知道在哪一步失败”的焦虑。

5.3 Jenkins 和 DevOps 是什么关系

经常会有人问“Jenkins 和 DevOps 是不是一回事”。这其实不是一个维度上的概念。DevOps 是一种文化和协作方式，强调开发、测试、运维之间的沟通和自动化；Jenkins 则是帮你在技术上落地这种文化的一件工具。你可以只用 Jenkins 做每周构建，不碰任何 DevOps 文化；也可以搭一套完整的自动化平台，让 Jenkins 只是其中的一个环节。

对小白来说，不用被这个词吓住。你只需要知道：当别人说“提高 DevOps 成熟度”的时候，大概率就是想让你把更多的手工操作变成自动化，而 Jenkins 就是其中一个很趁手的工具。

6. 构建结果通知：邮件和飞书机器人

6.1 配置邮件通知，解决构建失败时的“提醒”需求

构建失败不可怕，可怕的是构建失败了没人知道，直到半小时后有人发现问题。所以通知机制必须配好。最传统也最通用的就是邮件通知。

邮件配置分两处。第一处是“Manage Jenkins” -> “System”里的“E-mail Notification”，填 SMTP 服务器信息。

用 QQ 邮箱举例：

• SMTP 服务器：smtp.qq.com
• 端口：465（SSL）或587（TLS）
• 认证：填写发件邮箱地址和授权码（注意，不是 QQ 密码，是邮箱设置里生成的授权码）
• 默认收件人：可以先填自己的邮箱

这只是让 Jenkins 具备发邮件的能力。要实现在构建失败时自动发邮件，需要安装Email Extension Plugin，然后在任务的“Post-build Actions”里选择“Editable Email Notification”，填收件人地址，并在“Advanced Settings”里设置触发条件。默认情况下会勾选“Always”和“Failure”，建议保留这些，再加一个“Unstable”，这样测试不通过产生黄色感叹号时也能收到提醒。

邮件模板可以用默认的，也可以自定义。模板里最常引用的两个变量是${BUILD_URL}和${BUILD_LOG}，前者给出构建页面链接，后者把完整日志贴到邮件里。对小白来说，一开始直接用默认模板就行，等熟悉了再慢慢调整。

6.2 飞书机器人通知，团队协作更及时

现在很多公司用飞书或者钉钉，那 Jenkins 构建结果也可以直接推送到群聊机器人里，比邮件更醒目。

飞书机器人配置分两步。第一步，在飞书群里添加一个自定义机器人，拿到机器人的 Webhook 地址。飞书 Webhook 通常长这样：

https://open.feishu.cn/open-apis/bot/v2/hook/xxxx

第二步，在 Jenkins 任务里加一个“Execute shell”步骤，调用飞书机器人接口发消息。因为 Jenkins 本身要发送 JSON 数据，所以推荐在构建后操作里用一段 Python 或 curl 脚本实现。最简单的示例脚本如下：

curl -X POST \ -H "Content-Type: application/json" \ -d '{"msg_type":"text","content":{"text":"构建失败，任务名: '"${JOB_NAME}"', 构建编号: '"${BUILD_NUMBER}"', 详情见: '"${BUILD_URL}"'"}}' \ https://open.feishu.cn/open-apis/bot/v2/hook/xxxx

你可以把这串命令写进 Pipeline 的post { failure { ... } }块里，做到只在构建失败时通知。如果团队用的是钉钉，思路完全一样，只是 Webhook 格式略有差异。

提示：飞书机器人 Webhook 地址属于敏感信息，泄露后别人也能往你的群里发消息。如果你用的是 Pipeline 脚本，建议把 Webhook 地址配置成 Jenkins 的凭据，然后在脚本里引用，不要明文写在仓库里。

7. 常见问题排查实录

7.1 构建失败时的标准排查思路

新手遇到构建失败，第一反应往往是盯着红色日志从头看到尾。其实更高效的做法是倒着看，先看最后几百行，错误原因通常都在那。如果日志太短，或者结尾没有明确报错，再搜关键字ERROR、Exception、FAILURE、BUILD FAILURE。

我总结了一个排查顺序：

1. 看是哪个阶段失败的。自由风格任务会显示“构建步骤名称”，Pipeline 会精确到stage。
2. 看日志中代表异常信息的行，比如Could not resolve dependencies是 Maven 依赖问题，Permission denied是权限问题，Connection refused是网络或服务没起来。
3. 根据错误类型对症下药。

常见原因无外乎这几类：

• 代码本身编译不过（源码问题）
• 依赖拉不下来（Maven 源、网络问题）
• 测试用例挂了（测试环境问题）
• 部署目标机器连不上（SSH 配置、防火墙、认证问题）
• 脚本命令写错（Shell 语法问题）

想要更快定位问题，建议在 Pipeline 里把每个阶段拆细一点，每个阶段只干一件事，这样失败的阶段就是问题区域，查找范围会小很多。

7.2 控制台日志显示不全是怎么回事

有段时间我经常收到同事反馈：构建明明成功了，但控制台日志只有最后十几行，中间过程全不见了。排查了一圈才发现，这不是构建失败，而是 Jenkins 控制台输出的一个显示问题。

原因主要有两个。一个是构建过程输出太多，浏览器一次性加载大量日志时卡住，只渲染了最后一部分。解决办法是在构建日志页面点击右上角的“Follow”按钮实时跟踪日志，或者在构建结束后用“Download console log”下载完整日志查看。

另一个原因是日志输出被包缓冲了。比如在 Pipeline 里用sh执行外部命令时，如果命令输出量特别大，页面默认只保留部分内容。这时候可以去“Manage Jenkins” -> “System” -> “Console Output” 里调整日志行数上限；如果是 Docker 方式部署的，还可以直接看容器日志：

docker logs jenkins | tail -200

日志里真正有用的信息其实往往就在最后几十行，所以如果你只是为了排查问题，先看尾部一般就够了。

7.3 报错 unable to find valid certification path to requested target

这个报错是 SSL 证书校验失败引起的，特别容易出现在 Jenkins 需要访问某个 HTTPS 地址的场景里，比如拉取代码、下载插件、连接私有仓库时。报错的大意是：Jenkins 的 JVM 不认你访问的那个服务器证书。

解决思路有三种，按优先级推荐：

第一种，把目标服务器证书导入到 Jenkins 所在机器的 JVM 信任库。这是最正规的做法。用keytool命令导入：

keytool -import -alias gitlab -keystore $JAVA_HOME/lib/security/cacerts -file certificate.crt

导入时会让你输入信任库密码，默认是changeit，然后问你是否信任，输入yes。

第二种，如果你只是测试环境，不怕安全性降低，可以给 Jenkins 的 JVM 参数加上-Djenkins.security.CSRF.DISABLE=true之类的不太相关——不对，正确的做法是加 JVM 参数跳过证书校验，但 Jenkins 本身并不推荐全局这样干。更合适的做法是在报错的客户端工具里禁用校验，比如 Git 命令里加-c http.sslVerify=false。不过这只建议在临时排障时用，生产环境千万别这么干。

第三种，确认一下你访问的地址是不是真的需要证书校验。有些内网系统用的是自签名证书，而 Jenkins 默认只信任权威 CA 签发的证书。从根上解决，还是把自签证书导入信任库更靠谱。

7.4 安全加固：未授权访问漏洞要提前堵上

网上经常爆出 Jenkins 未授权访问漏洞，本质上是配置不当导致任何人都能访问控制台甚至执行任务。作为使用者，你有必要把最基本的防护做起来。

第一道防线：不要让 Jenkins 直接裸奔在公网上。如果必须开放访问，请加一层反向代理并配置 HTTPS，用 Nginx 做转发是非常常见的做法。

第二道防线：在 Jenkins 系统配置里，把“Allow anonymous read access”（允许匿名用户读取）关掉，这是最常见的安全隐患。

第三道防线：设置 Agent 权限。如果你配置了多个节点，务必确保只有可信的客户端能连接。在“Manage Jenkins” -> “Agents”里给每个 agent 设置独立认证凭据，不要用默认的共享密钥。

第四道防线：注意插件安全问题。Jenkins 插件仓库偶尔会爆出漏洞，定期检查“Manage Jenkins”里的插件更新提示，及时升级插件和 Jenkins 本体。如果某些插件利用率很低，直接卸载，减少攻击面。

还有一个细节：初始管理员密码要在首次配置后尽快修改。“Manage Jenkins” -> “Users”里可以修改当前用户密码，不要一直用初始密码挂着，尤其是公网可达的实例。

最后再分享一点我的个人习惯

从最早手动部署到现在，我养成了一个不算复杂但很有效的习惯：任何改动上线前，先在本机或者测试环境手动把命令敲一遍，确认没问题了，再把这些命令原封不动地搬进 Jenkins。很多人出错，不是因为 Jenkins 配置复杂，而是因为脚本本身就没验证过，还把所有步骤堆在一条命令里，出错了根本看不出是哪一步的问题。

如果你也是第一次用 Jenkins，我的建议是先从最简单的“拉代码 + 跑 Maven 构建 + 看日志”开始，别一上来就追求 Webhook、Pipeline、Docker 全上。先把基础链路跑通，再一点点加东西。每加一个环节，都确保能单独验证成功，再进入下一个环节。这样即使出问题，你也能很快锁定是哪个环节的问题。

Jenkins 这个东西，说简单也简单，说复杂也复杂。但本质上它就是一台为你打工的“自动化机器”，你给它喂清楚指令，它就会老老实实帮你把活干完。希望这篇文章能帮你把第一台机器启动起来，早日告别手动部署的苦日子。