2. 镜像版本管理：版本号规范、标签策略与元数据管理
镜像版本管理这事儿，说白了就是给每个镜像一个“身份证”。
我见过太多团队，镜像名就叫 app:latest，一用就是半年。等线上出问题想回滚，根本不知道哪个版本是好的。嗯，这就是我们今天要聊的核心——怎么管好版本，让回滚的时候不抓瞎。
2.1 语义化版本号：给镜像一个清晰的“身份证”
我个人习惯，镜像版本号必须遵循语义化版本规范。为什么？因为一看版本号，你就知道这个改动有多大。
语义化版本号格式很简单：MAJOR.MINOR.PATCH，比如 1.4.2。
- MAJOR（主版本号）：做了不兼容的 API 修改。比如从 v1 升到 v2，接口全变了。
- MINOR（次版本号）：向下兼容的功能新增。比如加了新接口，旧接口还能用。
- PATCH（修订号）：向下兼容的问题修复。比如修了个 bug，功能没变。
我在项目中遇到过，有人把版本号写成 v1.2.3.4 或者 20231001。这种版本号，你根本看不出改动范围。回滚的时候，你只能靠猜。
核心原则：版本号必须能反映变更的“破坏性”程度。这样回滚时，你才知道该选哪个版本。
举个例子，一个 Java 应用的镜像版本：
# 初始版本
myapp:1.0.0
# 修复了一个空指针异常
myapp:1.0.1
# 新增了用户登录功能，旧接口兼容
myapp:1.1.0
# 重构了核心 API，旧接口不再支持
myapp:2.0.0
你看，从 1.0.1 回滚到 1.0.0，风险很小。但从 2.0.0 回滚到 1.1.0，数据结构和接口都可能不兼容，必须谨慎。
2.2 镜像标签策略：latest、stable、canary 怎么用？
版本号是给机器看的，标签是给人看的。标签策略，说白了就是给镜像打上“环境标签”和“质量标签”。
我建议，标签体系分三层：
| 标签类型 | 用途 | 更新频率 | 回滚风险 |
|---|---|---|---|
latest |
开发环境默认使用，指向最新提交 | 每次构建 | 高（可能不稳定） |
stable |
经过测试验证的稳定版本 | 每次发布 | 低 |
canary |
金丝雀发布，灰度测试用 | 按需更新 | 中（需要监控） |
我曾经犯过一个错：把 latest 标签直接部署到生产环境。结果开发一提交代码，生产就崩了。后来我强制规定：生产环境只能用 stable 标签。
避坑指南：latest 标签是“移动靶”，每次构建都会覆盖。千万不要在生产环境用 latest。我曾经亲眼看到有人因为 latest 被覆盖，回滚时找不到旧版本，只能重新构建——那叫一个惨。
具体怎么用？我给你一个实战策略：
- 开发环境：用
latest，随时拉取最新代码。 - 测试环境：用
canary，先让少量流量验证。 - 预发布环境：用
stable，验证通过后打上stable标签。 - 生产环境：用
stable+ 具体版本号（如stable-1.2.3）。
你想想看，如果生产环境只用 stable，回滚的时候只需要把 stable 标签指回上一个版本号就行。多简单。
2.3 镜像仓库的元数据管理：让镜像“会说话”
版本号和标签是“身份证”，元数据就是“简历”。
元数据包括：构建时间、Git 提交 ID、构建者、代码分支、测试结果、安全扫描报告等。这些信息，在回滚决策时至关重要。
我习惯在构建镜像时，把元数据写入镜像的 LABEL 字段：
# Dockerfile 示例
FROM openjdk:11-jre-slim
LABEL \
org.opencontainers.image.created="2024-01-15T10:30:00Z" \
org.opencontainers.image.version="1.2.3" \
org.opencontainers.image.revision="a1b2c3d4e5f6" \
org.opencontainers.image.source="https://github.com/myorg/myapp" \
org.opencontainers.image.title="myapp" \
org.opencontainers.image.description="用户服务镜像" \
org.opencontainers.image.authors="devops@myorg.com" \
org.opencontainers.image.licenses="MIT"
COPY target/myapp.jar /app/myapp.jar
CMD ["java", "-jar", "/app/myapp.jar"]
为什么要这么做？因为回滚的时候，你需要知道：
- 这个镜像是什么时候构建的？（
created） - 对应哪个 Git 提交？（
revision） - 是谁构建的？（
authors） - 代码仓库在哪里？（
source）
我在项目中遇到过，生产环境出了个 bug，需要回滚到三天前的版本。结果镜像仓库里只有 latest 和 stable，根本不知道哪个版本是三天前的。后来我们强制要求：每个镜像必须包含构建时间和 Git 提交 ID。
小技巧：可以用 docker inspect 命令查看镜像的 LABEL 信息。比如 docker inspect myapp:1.2.3 | jq '.[0].Config.Labels'。这样回滚前，你就能快速确认这个镜像是不是你要的那个。
2.4 知识体系总览：一张图看懂镜像版本管理
下面这张图，把版本号、标签、元数据的关系串起来了。你一看就明白。
2.5 实战建议：从混乱到有序
如果你现在的镜像管理还是一团乱麻，我建议你按这个顺序来：
- 先定版本号规范：强制要求所有镜像使用
MAJOR.MINOR.PATCH格式。 - 再定标签策略：至少区分
latest和stable，生产环境只用stable。 - 最后加元数据：在 CI/CD 流水线中，自动注入构建时间、Git 提交 ID 等信息。
嗯，这里要注意：元数据不是写给人看的，是写给自动化工具看的。回滚脚本、监控系统、审计系统，都需要这些信息。
我曾经帮一个团队做镜像治理，他们之前连版本号都没有。我帮他们搭了一套规范，三个月后，线上回滚的成功率从 60% 提升到了 95%。说白了，版本管理不是技术问题，是习惯问题。