GitLab等CI系统中Docker镜像打标策略及最佳实践咨询

适配你团队场景的核心打标规则 #

你们现有的CI双镜像构建流程可以搭配分层标签规则，完全兼容GitLab CI以及其他CI平台，同时适配分支/MR协作模式：

• 基础镜像：因为仅在Dockerfile变更时触发构建，标签直接关联变更标识即可
• 分支构建镜像：标签关联分支名+构建唯一标识，避免不同分支构建的镜像互相覆盖
• MR流程镜像：标签关联MR ID+提交哈希，便于测试和溯源MR对应的变更版本
• 生产发布镜像：标签关联版本号+发布时间，保证生产环境镜像可追溯、可回滚

具体落地执行方案 #

1. 基础镜像打标规则 #

基础镜像因为变更频率极低，不需要冗余标签，推荐两种可选方案：

• 方案1：使用基础镜像名:<变更提交短哈希>打标，同时额外打一个latest标签作为默认拉取标识，每次构建都覆盖这个latest即可。CI中可以通过${CI_COMMIT_SHORT_SHA}内置变量直接获取提交短哈希
• 方案2：如果基础镜像有明确的版本迭代规划，可以使用语义化版本号打标，比如基础镜像名:v1.2.0，每次变更升级对应版本号即可

2. 普通分支构建打标规则 #

针对开发分支、功能分支的日常构建，标签格式统一为：
业务镜像名:<分支名>-<构建ID>-<提交短哈希>

示例：假设分支名为feature/user-login，构建ID为234，提交短哈希为a1b2c3d，标签为app:feature-user-login-234-a1b2c3d

• 分支名中的特殊字符（比如/）可以统一替换为-避免镜像仓库解析异常
• 构建ID和提交哈希双重保证标签唯一，不会出现同分支多次构建互相覆盖的问题
• 不需要长期留存的分支镜像可以配置镜像仓库的自动清理规则，比如分支合并后7天自动删除对应镜像

3. MR流程构建打标规则 #

针对Merge Request流水线产生的镜像，标签格式统一为：
业务镜像名:mr-<MR ID>-<提交短哈希>

示例：MR ID为112，提交短哈希为e4f5g6h，标签为app:mr-112-e4f5g6h

• 测试同学可以直接通过MR ID快速拉取对应版本的镜像进行验证
• MR合并关闭后可以自动清理对应MR的镜像，节约仓库存储空间

4. 主干/生产发布打标规则 #

测试通过后合并到主干、待发布的业务镜像，推荐使用语义化版本号作为核心标签，格式为：
业务镜像名:v<主版本号>.<次版本号>.<修订号>-<发布时间戳>

示例：app:v2.1.0-202405201430

• 语义化版本号方便业务侧识别版本迭代内容，时间戳便于排查发布时间相关的问题
• 同时可以额外打一个stable标签指向最新的生产可用镜像，方便部署脚本默认拉取最新稳定版本

行业通用最佳实践 #

• 禁止全流程仅依赖latest标签：latest是浮动标签，无法保证拉取的版本符合预期，很容易出现测试通过的版本和实际发布的版本不一致的问题
• 所有标签要保证唯一且可溯源：通过标签可以反向查到对应的提交记录、CI流水线记录，出现问题可以快速定位对应变更
• 配置镜像生命周期规则：非生产环境的分支镜像、MR镜像不需要永久留存，设置自动过期清理规则降低存储成本
• 敏感环境的镜像签名：如果是金融、政务等对安全性要求高的场景，生产镜像可以额外搭配镜像签名机制，避免被篡改的镜像被部署到生产环境

内容的提问来源于stack exchange，提问作者szabgab