1. 课程导论：容器镜像版本控制与自动化回滚的重要性
在云原生与微服务架构快速普及的今天，容器镜像已成为软件交付的核心载体。每一次代码提交、配置变更或依赖更新，最终都会转化为一个不可变的容器镜像。然而，当发布流水线每天处理数百甚至数千个镜像版本时，缺乏规范的版本控制与自动化回滚机制，将直接导致生产事故频发、故障恢复时间（MTTR）急剧上升。
核心认知： 容器镜像版本控制不是简单的“打标签”，而是将镜像的构建元数据、Git 提交哈希、环境标识、部署时间戳等信息进行结构化编码，形成可追溯、可比较、可回滚的版本链。自动化回滚则是基于这一版本链，在检测到发布异常时，由流水线自动触发上一稳定版本的重新部署。
1.1 为什么版本控制与回滚如此重要？
以下表格总结了缺乏规范版本控制与回滚能力时，团队面临的典型痛点：
| 痛点场景 | 后果 | 影响范围 |
|---|---|---|
镜像标签使用 latest 或 v1 等可变标签 |
无法确定线上运行的具体代码版本，回滚时找不到原始镜像 | 全链路可追溯性丧失 |
| 版本号仅包含语义化版本，缺少构建元数据 | 无法区分同一版本号下的多次构建，灰度发布时版本混淆 | 发布准确性下降 |
回滚依赖人工登录服务器执行 kubectl rollout undo |
MTTR 从分钟级延长到小时级，且容易操作失误 | 业务连续性受损 |
| 没有保留历史镜像的清理策略 | 镜像仓库存储成本爆炸，回滚时目标镜像已被删除 | 运维成本与风险双高 |
1.2 课程目标
通过本课程的学习，你将掌握以下核心能力：
- 设计不可变镜像版本规范：基于 Git SHA、构建时间戳、环境标识等元数据，构建全局唯一的镜像标签体系。
- 构建自动化回滚流水线：在 CI/CD 中集成健康检查、金丝雀发布、自动回滚触发与执行机制。
- 实现版本追溯与审计：通过镜像元数据与部署记录的关联，快速定位问题版本并生成回滚报告。
- 制定镜像保留与清理策略：平衡存储成本与回滚窗口，设计基于时间与版本数量的自动清理规则。
学习建议： 本课程包含大量可执行的 YAML 配置与 Shell 脚本示例。建议你准备一个 Kubernetes 测试集群（如 Minikube 或 Kind），并安装 Docker、GitLab CI / GitHub Actions 等 CI 工具，以便同步实践。
1.3 学习路径与知识体系
下图展示了本课程的整体知识结构，以及各章节之间的依赖关系：
1.4 课程章节概览
本课程共分为 5 个章节，每个章节聚焦一个核心主题：
| 章节 | 主题 | 关键产出 |
|---|---|---|
| 第1章 | 课程导论 | 理解版本控制与回滚的价值，明确学习路径 |
| 第2章 | 不可变镜像版本规范设计 | 可落地的镜像标签规范文档与示例 |
| 第3章 | CI 流水线中的版本注入与镜像构建 | GitLab CI / GitHub Actions 流水线配置 |
| 第4章 | 自动化回滚策略与健康检查集成 | 基于 Argo Rollouts 或 Flagger 的回滚配置 |
| 第5章 | 镜像保留策略与版本审计 | 镜像清理脚本与审计报告模板 |
前置知识要求： 本课程假设你已具备以下基础：Docker 镜像构建与推送、Kubernetes 基本概念（Deployment、Service）、Git 版本控制、CI/CD 基础概念。如果你对这些内容尚不熟悉，建议先学习相关入门课程。
1.5 一个典型的版本控制与回滚场景
为了让你更直观地理解本课程要解决的问题，下面展示一个典型的发布与回滚流程：
在这个流程中，版本控制确保了每个镜像都有唯一的标识，使得回滚时能够精确选择目标版本；自动化回滚则通过健康检查结果自动触发，无需人工介入，将故障恢复时间从分钟级压缩到秒级。