拓冰网站定制 
先说个我自己的经历。几年前我第一次接触 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 文件夹里。插件PluginJenkins 的扩展包相当于手机应用商店里的 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-port8080/tcp sudo firewall-cmd --reload2.2 路线二Docker 方式部署 Jenkins如果你的服务器已经装了 Docker或者你更习惯用容器管理服务那用 Docker 跑 Jenkins 会更省心升级、迁移都很方便。我自己现在也更推荐这种方式因为环境隔离不会污染宿主机。先拉取官方镜像docker pull jenkins/jenkins:ltslts是长期支持版稳定性有保障。如果你需要特定版本可以到 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:50000Jenkins 主从节点通信端口以后要加 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 的界面布局变化比较大一些小白会卡在找不到对应的菜单。正确操作路径是这样的登录 Jenkins 后点击左侧“Manage Jenkins”管理 Jenkins。在管理页面找到“Plugins”插件入口点击进入。切换到“Available plugins”可用插件标签页。在搜索框输入Localization找到Localization: Chinese (Simplified)勾选后点击“Install without restart”。安装完成后回到首页你会看到界面已经变成中文。如果没有变化手动刷新浏览器页面或者重启 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 版本不兼容。我的排查顺序是先看“Manage Jenkins”首页有没有提示“有新版本 Jenkins 可用”如果有先升级到最新 LTS 版本。在插件管理页面点击“Advanced settings”检查“Update Site”里填的地址能不能正常访问。官方默认地址是https://updates.jenkins.io/update-center.json国内访问不稳定时可以换成清华或华为云的 Jenkins 更新源。清理/var/lib/jenkins/plugins目录下的.tmp后缀文件这些是下载了一半的残片有可能会干扰安装。重启 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”里填仓库地址比如gitgitlab.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 的内置环境变量在任务执行过程中自动注入你可以在构建脚本里直接引用。常用变量说明如下变量名含义示例值JOB_NAME当前任务名称my-projectBUILD_NUMBER当前构建编号42BUILD_ID当前构建 ID42WORKSPACE工作区绝对路径/var/lib/jenkins/workspace/my-projectGIT_COMMIT当前代码的 Git 提交哈希值7f2a3b9cJENKINS_HOMEJenkins 主目录/var/lib/jenkins如何使用比如你想在构建日志里输出当前分支和提交号可以在构建步骤里加一个“Execute shell”输入echo 当前工作区: ${WORKSPACE} echo 当前构建号: ${BUILD_NUMBER} echo 当前提交: ${GIT_COMMIT}还有一种更实用的场景在构建命令里引用自定义参数。任务配置页面勾选“This project is parameterized”添加“String Parameter”比如填BRANCHmain后续在构建脚本里就可以用${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 deploy192.168.1.100:/opt/app/ ssh deploy192.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 deploy192.168.1.100:/opt/app/ sh ssh deploy192.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端口465SSL或587TLS认证填写发件邮箱地址和授权码注意不是 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。我总结了一个排查顺序看是哪个阶段失败的。自由风格任务会显示“构建步骤名称”Pipeline 会精确到stage。看日志中代表异常信息的行比如Could not resolve dependencies是 Maven 依赖问题Permission denied是权限问题Connection refused是网络或服务没起来。根据错误类型对症下药。常见原因无外乎这几类代码本身编译不过源码问题依赖拉不下来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.DISABLEtrue之类的不太相关——不对正确的做法是加 JVM 参数跳过证书校验但 Jenkins 本身并不推荐全局这样干。更合适的做法是在报错的客户端工具里禁用校验比如 Git 命令里加-c http.sslVerifyfalse。不过这只建议在临时排障时用生产环境千万别这么干。第三种确认一下你访问的地址是不是真的需要证书校验。有些内网系统用的是自签名证书而 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 这个东西说简单也简单说复杂也复杂。但本质上它就是一台为你打工的“自动化机器”你给它喂清楚指令它就会老老实实帮你把活干完。希望这篇文章能帮你把第一台机器启动起来早日告别手动部署的苦日子。 Jenkins入门教程：从安装配置到自动化部署实战
先说个我自己的经历。几年前我第一次接触 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 文件夹里。插件PluginJenkins 的扩展包相当于手机应用商店里的 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-port8080/tcp sudo firewall-cmd --reload2.2 路线二Docker 方式部署 Jenkins如果你的服务器已经装了 Docker或者你更习惯用容器管理服务那用 Docker 跑 Jenkins 会更省心升级、迁移都很方便。我自己现在也更推荐这种方式因为环境隔离不会污染宿主机。先拉取官方镜像docker pull jenkins/jenkins:ltslts是长期支持版稳定性有保障。如果你需要特定版本可以到 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:50000Jenkins 主从节点通信端口以后要加 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 的界面布局变化比较大一些小白会卡在找不到对应的菜单。正确操作路径是这样的登录 Jenkins 后点击左侧“Manage Jenkins”管理 Jenkins。在管理页面找到“Plugins”插件入口点击进入。切换到“Available plugins”可用插件标签页。在搜索框输入Localization找到Localization: Chinese (Simplified)勾选后点击“Install without restart”。安装完成后回到首页你会看到界面已经变成中文。如果没有变化手动刷新浏览器页面或者重启 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 版本不兼容。我的排查顺序是先看“Manage Jenkins”首页有没有提示“有新版本 Jenkins 可用”如果有先升级到最新 LTS 版本。在插件管理页面点击“Advanced settings”检查“Update Site”里填的地址能不能正常访问。官方默认地址是https://updates.jenkins.io/update-center.json国内访问不稳定时可以换成清华或华为云的 Jenkins 更新源。清理/var/lib/jenkins/plugins目录下的.tmp后缀文件这些是下载了一半的残片有可能会干扰安装。重启 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”里填仓库地址比如gitgitlab.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 的内置环境变量在任务执行过程中自动注入你可以在构建脚本里直接引用。常用变量说明如下变量名含义示例值JOB_NAME当前任务名称my-projectBUILD_NUMBER当前构建编号42BUILD_ID当前构建 ID42WORKSPACE工作区绝对路径/var/lib/jenkins/workspace/my-projectGIT_COMMIT当前代码的 Git 提交哈希值7f2a3b9cJENKINS_HOMEJenkins 主目录/var/lib/jenkins如何使用比如你想在构建日志里输出当前分支和提交号可以在构建步骤里加一个“Execute shell”输入echo 当前工作区: ${WORKSPACE} echo 当前构建号: ${BUILD_NUMBER} echo 当前提交: ${GIT_COMMIT}还有一种更实用的场景在构建命令里引用自定义参数。任务配置页面勾选“This project is parameterized”添加“String Parameter”比如填BRANCHmain后续在构建脚本里就可以用${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 deploy192.168.1.100:/opt/app/ ssh deploy192.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 deploy192.168.1.100:/opt/app/ sh ssh deploy192.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端口465SSL或587TLS认证填写发件邮箱地址和授权码注意不是 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。我总结了一个排查顺序看是哪个阶段失败的。自由风格任务会显示“构建步骤名称”Pipeline 会精确到stage。看日志中代表异常信息的行比如Could not resolve dependencies是 Maven 依赖问题Permission denied是权限问题Connection refused是网络或服务没起来。根据错误类型对症下药。常见原因无外乎这几类代码本身编译不过源码问题依赖拉不下来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.DISABLEtrue之类的不太相关——不对正确的做法是加 JVM 参数跳过证书校验但 Jenkins 本身并不推荐全局这样干。更合适的做法是在报错的客户端工具里禁用校验比如 Git 命令里加-c http.sslVerifyfalse。不过这只建议在临时排障时用生产环境千万别这么干。第三种确认一下你访问的地址是不是真的需要证书校验。有些内网系统用的是自签名证书而 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 这个东西说简单也简单说复杂也复杂。但本质上它就是一台为你打工的“自动化机器”你给它喂清楚指令它就会老老实实帮你把活干完。希望这篇文章能帮你把第一台机器启动起来早日告别手动部署的苦日子。