学习：企业标准的容器化 CI，CD 发布流程

文章目录

• 背景：
• 1.流程说明：
• 2.CI/CD流水线工具
• [3. Docker 容器引擎](#3. Docker 容器引擎)
• [4. 镜像仓库](#4. 镜像仓库)
• [5. Kubernetes (简称 K8s)](#5. Kubernetes (简称 K8s))
• 完整流程（从代码到部署上线）
• • 1.开发人员
  • 2.运维人员
  • 3.正式部署
  • • • [步骤 1：【手动触发 / 自动触发】启动流水线](#步骤 1：【手动触发 / 自动触发】启动流水线)
      • [步骤 2：流水线从「代码仓库」拉取最新的项目源码](#步骤 2：流水线从「代码仓库」拉取最新的项目源码)
      • [步骤 3：流水线对源码做「编译 / 构建」](#步骤 3：流水线对源码做「编译 / 构建」)
      • [步骤 4：流水线调用「Docker」，将项目打包成「Docker 镜像」](#步骤 4：流水线调用「Docker」，将项目打包成「Docker 镜像」)
      • [步骤 5：流水线将打好的「Docker 镜像」推送到「镜像仓库」](#步骤 5：流水线将打好的「Docker 镜像」推送到「镜像仓库」)
      • [步骤 6：流水线自动更新「K8s 的部署配置文件 (yaml 文件)」](#步骤 6：流水线自动更新「K8s 的部署配置文件 (yaml 文件)」)
      • [步骤 7：流水线给「K8s 集群」发送「部署指令」](#步骤 7：流水线给「K8s 集群」发送「部署指令」)
      • [步骤 8：K8s 集群「自动完成项目的启动和运行」](#步骤 8：K8s 集群「自动完成项目的启动和运行」)
  • 核心概念
  • • [1. 流水线的 CI 和 CD 到底是什么？（你说的流水线就是这个）](#1. 流水线的 CI 和 CD 到底是什么？（你说的流水线就是这个）)
    • [2. Docker 镜像 和 K8s Pod / 容器 的关系？](#2. Docker 镜像 和 K8s Pod / 容器 的关系？)
    • [3. K8s 里的 Deployment 是干嘛的？（新手最容易忽略的核心）](#3. K8s 里的 Deployment 是干嘛的？（新手最容易忽略的核心）)

背景：

由于开发一个独立的项目，然后要部署到正式环境，但是部署过程中，很多同事说的专业名词不理解，还有代码的正式的部署流程也不是很清楚，为了更好的理解一个项目从开始开发到最终部署上线要经历的过程，这里总结了项目发版的完整流程，用于自己学习和理解。我们公司使用的是k8s部署的项目（本人是个新手）。

1.流程说明：

• 代码仓库拉取代码 → 自动化流水线(CI/CD)构建打包 → K8s集群运行项目
• 从远程代码仓库拉取最新的项目源码，通过自动化流水线完成「代码编译、打包成镜像、推送镜像」的全部操作，最后通过 K8s 这个容器编排平台，拉取镜像并启动项目容器，对外提供服务

代码工具

• 代表工具 ：GitLab、Gitee(码云)、GitHub、阿里云代码仓库（云校）
• 核心操作 ：开发写完代码后，会把代码push(推送)到这个仓库，流水线会从这个仓库pull(拉取/克隆)最新的代码，做后续操作。
• 个人操作：通过拉取远程仓库的代码，然后（拉取 pull、提交 push、分支 branch）。

2.CI/CD流水线工具

• 代表工具 ：Jenkins（90% 的公司在用，最主流、最核心，你大概率用的就是它）、GitLab CI（和 GitLab 代码仓集成一体，不用额外部署）、GitHub Actions、阿里云效 / 腾讯云流水线、GitLab Runner

• 工具定位 ：整个发布流程的「总指挥 + 自动化工人」，是连接「代码」和「K8s」的核心桥梁，没有它，所有操作都需要你手动做，效率极低还容易出错。

• 名字解释 ：你听到的「流水线」就是CI/CD，是两个概念的合称，新手不用记复杂定义，只需要懂：

  -- CI：代码拉取后，自动做编译、打包、镜像构建、推送镜像 （给 K8s 准备好运行的「物料」）

  -- CD：打包完成后，自动把项目部署到 K8s 集群 ，启动 / 更新服务

  -- 一句话：流水线帮你把「拉代码→打包→部署」的所有手动操作，变成「点一下按钮 / 代码提交后自动触发」的自动化流程

3. Docker 容器引擎

• 作用：所有项目的部署的位置，解决了本地可以跑，其他地方不能跑的问题。

4. 镜像仓库

• 代表工具 ：Harbor（企业内部最主流，私有仓库）、Docker Hub（公有仓库）、阿里云镜像仓库、腾讯云镜像仓库
• 工具定位 ：存放 Docker 镜像的「仓库」，和「代码仓库存代码」是一个逻辑。
• 你的场景作用 ：流水线用 Docker 把项目打包成镜像后，这个镜像会保存在流水线的服务器上，K8s 集群是另一台 / 一组独立的服务器，没法直接读取流水线服务器的镜像，所以必须把镜像推送 (push) 到这个「镜像仓库」里，然后 K8s 集群再从这个仓库拉取 (pull) 镜像启动项目。

5. Kubernetes (简称 K8s)

• 工具定位 ：项目的「最终运行环境 + 保姆」 ，是整个流程的终点。你的项目最终不是跑在普通服务器上，而是跑在 K8s 集群里。
• 核心作用 ：K8s 不会自己写代码、不会打包镜像，它只做一件核心事：从镜像仓库拉取打好的项目镜像，然后创建容器、启动容器、保障容器一直正常运行、出问题自动重启、支持扩容缩容、支持无缝更新。
• 新手灵魂拷问解答 ：为什么不用「普通服务器直接跑项目」，非要用 K8s？
  → 普通服务器跑项目：项目挂了不会自动重启、扩容要手动配置、多台服务器部署要手动操作每一台、出问题排查麻烦；
  → K8s 跑项目：全自动运维，项目挂了秒级重启、扩容只需要改个数字、多台服务器统一管理、更新项目不会停机，这就是企业用 K8s 的核心原因。

完整流程（从代码到部署上线）

1.开发人员

• 开发人员写好本地代码，并进行代码的推送到git上，然后部署到测试环境，经过测试人员的验证是否可以发到正式。
• 注意：代码和配置文件都要进行提交，分别为正式配置文件和测试配置文件，这个配置文件，个人当时上线的时候由于网络配置的有误，导致可以部署成功，但是接口服务一直不通，最后查看日志，发现前端的调用根本就没有到达后端服务，在gateway转发的地址有误，发生了内外网的通信错误。

2.运维人员

• 需要准备CI/CD的流水线。

3.正式部署

步骤 1：【手动触发 / 自动触发】启动流水线

• 操作人：开发 / 运维

• 操作：在 Jenkins（流水线工具）的页面上，点击「构建」按钮，触发一次流水线任务；

  ✔ 进阶：企业里一般是「代码提交自动触发」，比如你往 GitLab 的 master 分支推了代码，流水线会自动启动，不用手动点，更高效。

• 目的：告诉流水线「我要发新版本了，开始干活」。

步骤 2：流水线从「代码仓库」拉取最新的项目源码

• 执行者：流水线 (Jenkins)
• 操作：流水线通过 Git 命令，自动连接代码仓库，把最新的项目代码「克隆 / 拉取」到流水线自己的服务器上；
• 注意：可以发版的代码都要进行合并到主分支上，以及不要在主分支上开发。
• 目的：流水线拿到最新的代码，才能做后续的打包操作，保证部署的是最新版本。

步骤 3：流水线对源码做「编译 / 构建」

• 执行者：流水线 (Jenkins)

• 操作：流水线会根据你的项目类型，自动执行编译命令，把源码变成可运行的程序包：

  • 如果是 Java 项目：执行 mvn clean package 打包成 jar 包 /war 包；
  • 如果是 Go 项目：执行 go build 编译成可执行二进制文件；
  • 如果是前端 Vue/React 项目：执行 npm run build 打包成 dist 静态资源包；
  • 如果是 Python 项目：无需编译，直接打包即可。

• 目的：源码是「人类能看懂的文本」，电脑 / K8s 看不懂，必须编译成「机器能运行的程序包」。

步骤 4：流水线调用「Docker」，将项目打包成「Docker 镜像」

• 执行者：流水线 (Jenkins) + Docker
• 操作：流水线自动执行 docker build -t 镜像名称:版本号 . 命令，结合项目里的「Dockerfile」文件，把编译好的程序包 + 运行环境（比如 Java 的 JDK、Go 的运行环境、Nginx）一起打包成一个「Docker 镜像」；
• ✔ 新手关键知识点：镜像 = 项目运行需要的「所有东西」的集合 → 程序包 + 运行环境 + 配置文件 + 依赖包，镜像打出来后，就是一个「独立的、完整的、可移植的包」，在任何有 Docker/K8s 的环境里，都能直接运行，不会出现「本地能跑、服务器跑不了」的问题，这是 Docker 的核心价值。
• 目的：把项目变成 K8s 能识别的「镜像格式」，为部署到 K8s 做准备。

步骤 5：流水线将打好的「Docker 镜像」推送到「镜像仓库」

• 执行者：流水线 (Jenkins) + Docker
• 操作：流水线执行 docker push 镜像仓库地址/镜像名称:版本号 命令，把刚打好的镜像，推送到提前搭建好的「镜像仓库 (Harbor)」里；
• 目的：镜像现在在流水线的服务器上，K8s 集群是另一组独立的服务器，K8s 访问不到流水线服务器的镜像，必须把镜像放到「镜像仓库」这个公共的「中转站」，K8s 才能拉取到。

步骤 6：流水线自动更新「K8s 的部署配置文件 (yaml 文件)」

• 执行者：流水线 (Jenkins)
• 操作：这是流水线「CD 环节」的核心操作，流水线会自动修改 K8s 的核心配置文件（yaml 文件），把文件里的「镜像地址 + 版本号」更新成刚推送的镜像地址和新版本号；
• ✔ 新手关键知识点：K8s 的所有操作都靠「yaml 配置文件」，这个文件里写了：要拉取哪个镜像、启动几个容器、项目的端口号、内存 / CPU 限制、挂载的文件等，K8s 完全按照这个文件的配置来运行项目，改配置文件就是改项目的运行规则。
• 目的：告诉 K8s「我要部署新版本的项目了，你去拉取这个新镜像」。

步骤 7：流水线给「K8s 集群」发送「部署指令」

• 执行者：流水线 (Jenkins) → K8s 集群
• 操作：流水线执行 kubectl apply -f xxx.yaml 这个核心命令，把更新后的配置文件发送给 K8s 集群，K8s 接收到指令后，立刻开始执行部署操作；
• ✔ 新手备注：kubectl是操作 K8s 的「命令行工具」，所有对 K8s 的操作（部署、重启、查看日志、扩容）都靠这个工具，流水线帮你自动执行了这个命令。

步骤 8：K8s 集群「自动完成项目的启动和运行」

• 执行者：K8s 集群（核心环节，你看不到操作，但这是项目真正启动的过程）

• 操作：K8s 收到部署指令后，会按顺序做这些事，全程自动化，出问题会自动重试：

  ① K8s 从「镜像仓库」拉取最新的项目镜像到自己的节点服务器；

  ② K8s 基于镜像，创建「Pod」（K8s 里最小的运行单元，你的项目容器就跑在 Pod 里）；

  ③ K8s 通过「Deployment」控制器，保障 Pod 的数量（比如你配置启动 2 个 Pod，K8s 会确保一直有 2 个 Pod 在运行，挂了就自动重建）；

  ④ K8s 创建「Service」服务，给 Pod 分配一个访问地址，让项目能被内部 / 外部访问到；

• ✔ 新手灵魂拷问：K8s 启动的是「容器」，不是「项目」？

  → 是的！你的项目被打包成 Docker 镜像后，运行镜像就是启动一个「容器」，K8s 管理的就是这些容器，容器里跑的就是你的项目，对外提供接口 / 页面服务。

• 目的：最终把项目启动起来，对外提供服务，完成整个发布流程。

核心概念

1. 流水线的 CI 和 CD 到底是什么？（你说的流水线就是这个）

• CI（持续集成）：流水线的「前半段」→ 拉代码、编译、打包镜像、推镜像，核心是「把代码变成镜像」，给部署做准备；
• CD（持续部署 / 持续交付）：流水线的「后半段」→ 更新 K8s 配置、发部署指令，核心是「把镜像部署到 K8s」，让项目跑起来；
• 一句话总结：CI 做打包，CD 做部署，合起来就是流水线。

2. Docker 镜像 和 K8s Pod / 容器 的关系？

• 镜像：是「静态的安装包」，是打包好的文件，不运行、不占内存，只是一个文件；
• 容器：是「镜像运行起来的实例」，镜像运行后就是容器，容器占内存、占 CPU，里面跑着你的项目；
• Pod：是 K8s 里「容器的载体」，K8s 不直接管理容器，而是把容器放到 Pod 里管理，一个 Pod 里可以放 1 个或多个容器（一般是 1 个）；
• 关系：镜像 → 运行镜像 → 容器 → 容器放在Pod里 → K8s管理Pod。

3. K8s 里的 Deployment 是干嘛的？（新手最容易忽略的核心）

你可以把 Deployment 理解为「Pod 的保姆」，它的核心作用是：

• 保障 Pod 的数量：你配置启动 2 个 Pod，Deployment 就确保一直有 2 个，少了就补，多了就删；
• 自愈能力：Pod 挂了、服务器宕机重启，Deployment 会自动重建 Pod；
• 滚动更新：最重要的一点 ，更新项目时，Deployment 会先启动新的 Pod，再删除旧的 Pod，全程不会停机，用户无感知，这就是企业里「无缝发版」的核心实现；
• 回滚：如果新版本出问题，Deployment 可以一键回滚到上一个正常版本，非常方便。