云联信息：容器镜像仓库，生产和测试别混在一起

容器化之后，镜像仓库成了新的“代码仓库”。很多团队图省事，测试和生产的镜像放在同一个仓库，用标签区分。等到某次误推，测试版本上了生产，才发现标签根本靠不住。仓库的隔离和权限，是容器化里最容易被跳过的一环。

按环境分仓库或者分命名空间

生产、预发、测试至少三个独立空间，权限分开。用标签区分环境，等于没有隔离。

生产仓库只允许流水线写

人工推送是事故的主要来源。生产仓库的写权限只给 CI 流水线，人只有读权限。

镜像要打不可变标签

latest 这类可变标签，谁都能覆盖，出了问题无法追溯。用提交号或者构建号做标签，并且设置标签不可覆盖。

保留策略要配

镜像越积越多，仓库容量和拉取速度都会受影响。按数量和天数保留，重要的版本单独标记保留。

漏洞扫描接进流水线

镜像构建完先扫一遍，高危漏洞直接阻断。上线后再扫，已经晚了。

基础镜像统一维护

每个团队自己选基础镜像，版本和补丁各不相同。统一维护几个基础镜像，安全和升级都好管。

拉取凭证要管好

凭证写在配置文件里提交到代码库，是常见事故。用密钥管理服务或者节点级别的凭证，别硬编码。

跨地域同步要评估

多地部署需要镜像就近拉取，同步会带来额外的存储和流量成本。按实际部署需求配置。

删除要有审批

误删生产镜像，回滚就没依据了。删除操作加审批和软删除，保留一段时间再彻底清理。

和制品库打通

镜像、依赖包、构建产物放在一起管理，版本能对应上。分散在几个地方，追溯很麻烦。

定期清理无用镜像

长期不用的镜像占空间也占注意力。每季度清一次，把构建失败和临时调试的镜像删掉。

镜像命名要能自解释

仓库名加业务名加服务名，标签带版本和提交号。看一眼就知道是什么、什么时候构建的。

构建环境要固定

同一个提交在不同机器上构建出不同镜像，问题很难复现。用固定的构建环境和基础镜像版本。

镜像大小要控制

几个 G 的镜像拉取慢、启动慢、存储贵。多阶段构建、清理缓存，能把体积压下来一大截。

定期做恢复测试

从仓库拉取历史版本部署一次，确认镜像还能用。只测最新版，回滚时才发现老镜像坏了。

镜像仓库是交付链上的关键一环，隔离、权限、标签、扫描四件事做到位，才能避免“测试上生产”这类事故。云联信息【资深云服务专家微信：cloud7591】，我们做容器化改造时，第一步就是把仓库结构定下来。