90DaysOfDevOps 第 71 天：什么是 Jenkins？——从 CI 工具定位到 Kubernetes 集群部署实战

• 文档/教程

本篇文章以 90DaysOfDevOps 2022 年度课程 Day 71 的韩文讲义（2022/ko/Days/day71.md）为骨架，系统讲解 Jenkins 在持续集成（CI）体系中的定位：它为什么能取代"夜间构建"这种古老的代码整合方式，其核心特性、流水线工作方式与七步 CI 架构是如何运作的。同时结合本仓库 2022/Days/CICD/Jenkins 目录下的 Helm 部署文件与 Jenkinsfile 示例，给出在 Minikube/Kubernetes 集群中落地 Jenkins 的完整实战路径。读完本文，你将理解 CI 服务器解决问题的本质，并能独立完成一次"代码提交 → 触发构建 → 自动化测试 → 发布部署"的最小闭环演练。

Jenkins 是什么：持续集成（CI）的核心角色

Jenkins 是一个持续集成工具，它允许对新建代码进行持续的开发、测试和部署。通俗地说，它承担了"CI 服务器"这一角色，负责接管开发团队中最重复、最耗时的环节：拉取新提交的代码、执行单元测试、构建软件产物，并把结果反馈给开发者。

围绕"如何整合团队代码"，讲义对比了两种截然不同的模式：

模式一：夜间构建（Nightly Builds）——传统的代码整合方式

开发者在白天围绕各自任务持续开发，到当天工作结束时统一把变更推送到源码仓库；到了夜间，系统统一运行单元测试并构建软件。这种方式把所有代码整合动作集中到一个固定时间点，一旦某个开发者的提交存在问题，可能要等到次日清晨才能暴露。

模式二：持续开发（Continuous Development）——更受青睐的方式

开发者仍然随时向源码仓库提交变更，但区别在于：每当一次代码提交完成，构建过程便立刻启动，不再等待固定的时间窗口。

讲义特别指出这种模式的价值：当开发团队分布在全球各地时，不可能要求所有人每天在同一时刻停止提交代码。持续集成的方式让"提交即构建、随时可集成"成为可能，而 Jenkins 正是执行这套测试与构建流程的 CI 服务器。

CI 工具生态对比：为什么要关注 Jenkins

讲义在聚焦 Jenkins 之前，先列出同领域的其他 CI 工具，帮助读者建立横向认知，理解 Jenkins 在整体流行度背后的差异点：

在此之上，Jenkins 与上述工具一样是开源的，但它是一个用 Java 编写的自动化服务器，通过持续集成自动化软件开发流程，并为持续交付（Continuous Delivery）提供支撑。需要说明的是，讲义中"Jenkins 是最流行的"属于作者个人的观察性表述，作为技术文章我们只把它视为作者观点的转述，而非可量化的项目事实。

Jenkins 的核心特性

讲义总结了 Jenkins 覆盖多个领域的五大特性，这些特性共同构成了它在 CI/CD 工具链中"事实标准"式的基础能力：

• 简易安装（Easy Installation）：Jenkins 是一个自包含的、基于 Java 的程序，开箱即用，为 Windows、macOS 和 Linux 操作系统提供安装包。
• 简易配置（Easy Configuration）：通过 Web 界面即可完成设置与配置，界面内置错误检查与帮助提示。
• 插件（Plug-ins）：更新中心（Update Centre）提供大量插件，可与 CI/CD 工具链中的众多工具集成。
• 可扩展（Extensible）：在现成插件之外，插件架构允许对 Jenkins 进行二次扩展，使其用途近乎无限。
• 分布式（Distributed）：Jenkins 可以轻松将任务分发到多台机器上执行，从而跨多个平台加速构建、测试与部署。

Jenkins Pipeline：从提交到发布的自动化链路

"Pipeline（流水线）"这个词在讲义中被放在更广泛的语境下讨论，它并不绑定于某个特定工具。在 Jenkins 的语境下，其含义是：开发者把代码提交给 Jenkins 后，Jenkins 会构建出应用程序，并跑完所有自动化测试；当每个阶段都完成后，再发布并部署这段代码。Jenkins 正是让这条链路全自动化的引擎。

在本仓库 2022/Days/CICD/Jenkins/Pipeline 目录中，就保存着一个与这条流水线配套的实战示例，包含Jenkinsfile、Dockerfile与index.html，我们在后文会结合它进行剖析。

Jenkins 架构：从代码提交到生产发布的七步流程

讲义以一张架构图拆解了一次典型的 CI 闭环，虽然本仓库图片列表中对应的架构图（2022/Days/Images/Day71_CICD5.png）在视觉上被归纳为六个核心环节，但讲义文字明确给出如下七个步骤：

1. Step 1：开发者将变更提交到源码仓库。
2. Step 2：Jenkins 按固定时间间隔轮询仓库，拉取任何新代码。
3. Step 3：构建服务器把代码构建成可执行产物——本示例使用 Maven 作为知名构建服务器（这也是需要另行学习的领域）。
4. Step 4：如果构建失败，反馈立即回传给开发者。
5. Step 5：Jenkins 将构建好的应用部署到测试服务器——本示例使用 Selenium 作为知名测试服务器（同样值得深入学习）。
6. Step 6：如果测试失败，反馈传递给开发者。
7. Step 7：如果测试全部成功，则可将代码发布到生产环境。

讲义强调，这个循环是连续的，这正是应用能够在"几分钟"而不是"几小时、几天、几个月甚至几年"内完成更新的根本原因。

在架构层面，讲义还补充了两个值得关注的延伸点：

• Master-Slave 能力：Jenkins 的架构远比图中展示的复杂，其 master-slave 机制允许主节点（master）把任务分发到从节点（slave）的 Jenkins 环境中执行，这正是"分布式特性"的架构实现。
• CloudBees 企业版：由于 Jenkins 是开源的，大量需要商业支持的企业会选择 CloudBees——这是 Jenkins 的企业级版本，为付费企业客户提供支持与其他附加功能（讲义以 Bosch 作为客户案例，原文附有案例 PDF，此处不再输出外部链接）。

在 Kubernetes（Minikube）中部署 Jenkins：仓库实操

讲义明确规划了后续的落地方向：将 Jenkins 安装到 Minikube 集群中，模拟向 Kubernetes 部署的过程。本仓库 2022/Days/CICD/Jenkins 目录完整保留了这一实践的产物，包括部署步骤记录steps.md以及四个 Kubernetes/Helm 资源清单。

部署步骤全览（源自 steps.md）

2022/Days/CICD/Jenkins/steps.md 按顺序记录了完整流程，核心命令如下：

# 1. 启动本地 Kubernetes 集群 minikube start # 2. 创建 jenkins 命名空间（两种方式任选其一） kubectl create namespace jenkins # 或：kubectl create -f jenkins-namespace.yml kubectl get namespaces # 3. 添加并更新 Jenkins 官方 Helm 仓库 helm repo list helm repo add jenkinsci https://charts.jenkins.io helm repo update # 4. 应用持久卷与服务账号（RBAC）资源 kubectl apply -f jenkins-volume.yml kubectl apply -f jenkins-sa.yml # 5. 使用 Helm 安装 Jenkins（以本地 values 文件覆盖默认值） chart=jenkinsci/jenkins helm install jenkins -n jenkins -f jenkins-values.yml $chart # 6. 进入 Minikube 节点修正持久卷目录属主（jenkins 以 UID 1000 运行） minikube ssh sudo chown -R 1000:1000 /data/jenkins-volume # 7. 重建首个 Pod 以正常挂载权限修正后的卷 kubectl delete pod jenkins-0 -n jenkins # 8. 观察 Pod 状态直至就绪 kubectl get pods -n jenkins -w # 9. 从 Kubernetes Secret 中读取初始管理员密码 kubectl exec --namespace jenkins -it svc/jenkins -c jenkins -- /bin/cat /run/secrets/chart-admin-password && echo # 10. 端口转发并在浏览器登录 kubectl --namespace jenkins port-forward svc/jenkins 8080:8080 # 浏览器访问 http://localhost:8080，登录后执行插件更新

配套资源清单解读

• 2022/Days/CICD/Jenkins/jenkins-namespace.yml：定义一个名为jenkins的 Kubernetes Namespace，作为所有 Jenkins 相关资源（Pod、Service、PVC、Secret 等）的逻辑隔离边界，apiVersion: v1、kind: Namespace。

• 2022/Days/CICD/Jenkins/jenkins-volume.yml：声明一个hostPath类型的 PersistentVolume，路径为/data/jenkins-volume/，容量 20Gi、访问模式ReadWriteOnce、回收策略Retain、storageClassName: jenkins-pv。它对应了步骤 6 中需要在 Minikube 节点上修正属主的那个数据目录。

• 2022/Days/CICD/Jenkins/jenkins-sa.yml：依次定义 ServiceAccount、ClusterRole 与 ClusterRoleBinding。ClusterRole 授权了statefulsets、pods、pods/log、pods/exec、persistentvolumes、deployments、configmaps、secrets等资源的create/get/watch/list/patch/update/delete权限，这是 Jenkins 得以在集群内动态调度 agent Pod、读写编排资源的 RBAC 基础。

• 2022/Days/CICD/Jenkins/jenkins-values.yml：官方 Helm Chart 的值覆盖文件，是本次部署的配置核心，几个关键段如下：

  • controller 段：指定镜像jenkins/jenkins（tagLabel: jdk11）、runAsUser: 1000、fsGroup: 1000（与步骤 6 的 chown 目标一致）；默认管理员用户admin，密码由adminSecret: true自动生成并存入 Secret；serviceType: ClusterIP、servicePort: 8080（讲义与 steps.md 的场景面向 Minikube，若在真实集群可按注释改用 NodePort 或 LoadBalancer）。
  • installPlugins 段：预装 Kubernetes（kubernetes:1.31.3）、workflow-aggregator:2.6、git:4.10.2、configuration-as-code:1.55.1四个核心插件，其中 kubernetes 插件正是后续 Jenkinsfile 中podTemplate动态调度 agent Pod 的基础。
  • JCasC 段：securityRealm使用本地用户并读取${chart-admin-username}/${chart-admin-password}，authorizationStrategy为"登录用户可执行任意操作"，同时关闭匿名读权限。
  • agent 段：启用jenkins/inbound-agent（tag4.11.2-4）作为默认 agent，containerCap: 10限制最大并发 agent 数，podRetention: "Never"表示构建完成后回收 Pod。
  • persistence 段：enabled: true、storageClass: jenkins-pv、accessMode: ReadWriteOnce、size: 8Gi，与前面手动创建的 PV 相衔接。

用 Jenkinsfile 定义流水线：仓库示例剖析

部署完成后，如何让 Jenkins 真正执行"构建 → 测试 → 发布"？仓库给出了一个最小可读的声明式示例 2022/Days/CICD/Jenkins/Pipeline/Jenkinsfile，它的核心是 Kubernetes 插件提供的podTemplate：

podTemplate(yaml: ''' apiVersion: v1 kind: Pod spec: containers: - name: maven image: maven:3.8.1-jdk-8 command: - sleep args: - 99d - name: kaniko image: gcr.io/kaniko-project/executor:debug command: - sleep args: - 9999999 volumeMounts: - name: kaniko-secret mountPath: /kaniko/.docker restartPolicy: Never volumes: - name: kaniko-secret secret: secretName: dockercred items: - key: .dockerconfigjson path: config.json ''') { node(POD_LABEL) { stage('Clone Repository') { git url: 'https://github.com/MichaelCade/Jenkins-HelloWorld.git', branch: 'main' container('maven') { stage('Build Image') { sh ''' echo "Tests passed" ''' } } } stage('Test Image') { container('kaniko') { stage('Build Hello World App') { sh ''' /kaniko/executor --context `pwd` --destination michaelcade1/helloworld:1.0 ''' } } } } }

这段流水线清晰地对应了讲义中的 CI 七步模型：

• Clone Repository 阶段：克隆示例代码仓库（Jenkins-HelloWorld，main 分支），即"Step 1/2——提交与拉取代码"。
• Build Image 阶段：在maven容器内执行测试（此处为占位回显echo "Tests passed"），对应"Step 3——构建服务器构建"。
• Build Hello World App 阶段：在kaniko容器内使用/kaniko/executor在 Kubernetes 集群内直接构建并推送容器镜像（--destination指定目标镜像），这对应"Step 5 之后——产出可发布产物"。

值得说明的是：podTemplate中的dockercred是一个名为dockercred的 Kubernetes Secret，用于存放 Docker Registry 凭据（items中把.dockerconfigjson映射为/kaniko/.docker/config.json），实际使用前需要先在集群中创建该 Secret。

配套的 2022/Days/CICD/Jenkins/Pipeline/Dockerfile 定义了最终交付物——一个基于busybox:latest的轻量静态 Web 容器：通过ENV PORT=8000设置监听端口，把index.html放入/www/index.html，最终由httpd启动一个极简 Web 服务器。它展示了"构建产物 → 容器镜像 → 可部署应用"的完整链路（文件内的HEALTHCHECK与启动命令以.md前缀占位形式出现，属于仓库中的教学示例写法，实际运行时应替换为有效的 busybox 命令，请以仓库原文件为准）。

总结与下一步

Day 71 完成了 Jenkins 的概念筑基：它从"夜间构建"的痛点出发，以"提交即触发"的持续集成模型接管构建、测试与反馈闭环；它的插件体系、分布式 master-slave 架构与开源生态，使其成为 CI/CD 工具链中的关键枢纽。本仓库同时给出了从 Minikube + Helm 部署到 Jenkinsfile 流水线的完整落地素材，你可以沿着 steps.md 的步骤在本地复现整套环境。

按课程安排，后续（Day 72）将用一个逐步示例演示 Jenkins 的实际使用，并把它与 ArgoCD、GitHub Actions 等其他工具串联起来，形成完整的交付链条。在动手实践时，建议重点体会两个闭环：一是"提交 → 构建 → 测试 → 反馈"的 CI 闭环，二是"构建产物 → 容器镜像 → 集群内部署"的交付闭环——理解了这两条链路，也就理解了 Jenkins 在整个 DevOps 体系中不可替代的位置。

• 文档/教程