多平台构建下无法使用digest时如何稳定引用Docker基础镜像

首先明确基础规则：Docker/OCI镜像标签本质是可修改的指针，没有协议层面的强制不可变约束，只要仓库维护者拥有推送权限，就可以覆盖同标签下的镜像内容。是否能固定引用完全取决于仓库侧的策略——Docker Hub上的官方GCC镜像没有给gcc:11这类大版本滚动标签配置不可变规则，这类标签会随GCC补丁版本发布、底层基础镜像安全更新反复覆盖推送，自然会导致构建缓存意外失效。官方确实没有提供带日期后缀的不可变标签，但有其他方案可以实现稳定引用。

针对你提到的「多平台构建无法使用digest」的认知需要先纠正：多平台镜像对外暴露的是manifest list（也叫fat manifest），它本身拥有全局唯一的digest，这个digest就是类似Git commit hash的固定标识，引用gcc@sha256:<manifest-list-digest>的形式完全支持多平台构建，buildx会自动根据目标架构拉取对应架构的子镜像，内容永远不会变动，这是最可靠的固定引用方式。你可以通过docker buildx imagetools inspect gcc:11命令获取当前大版本标签对应的manifest list digest。

如果你因为某些场景限制确实无法使用digest引用，可以选择以下落地方案：

• 使用精确到补丁版本的官方标签
  GCC官方镜像提供了精确到具体补丁版本的标签，比如gcc:11.4.0，这类标签对应固定的GCC源码构建版本，推送后几乎不会被覆盖，稳定性远高于gcc:11这类滚动大版本标签，不需要额外改造流程就能大幅降低缓存失效概率。注意不要选择带发行版滚动代号后缀的版本（比如gcc:11-bookworm），这类标签还是会随Debian安全更新被覆盖。
• 自行同步固定版本到私有镜像仓库
  第一次拉取到符合预期的GCC基础镜像后，将对应版本的多平台manifest完整同步到你自己的私有镜像仓库，打上自定义的固定标签（比如internal/gcc:11-fixed-20240520），同时在私有仓库侧开启标签不可变策略，后续所有构建都引用私有仓库的这个固定标签即可，完全不受上游官方仓库标签变动的影响，也不需要调整多平台构建的逻辑。
• 调整CI构建的拉取策略
  如果不想维护私有仓库，也可以修改构建流程参数：日常构建不要加--pull参数强制拉取最新基础镜像，只在你主动触发基础镜像更新任务时才执行拉取最新版本的操作，其余场景直接复用本地/CI缓存中已有的基础镜像层，也能避免上游标签更新导致的意外缓存失效。

内容的提问来源于stack exchange，提问作者One Full Time Equivalent