容器化迁移中的镜像治理 别把镜像仓库做成无人看管的垃圾场

上周跟南京某制造企业的运维团队聊迁移进度，对方说花了三个月把两百多套应用塞进容器，本来以为能松口气，结果打开镜像仓库直接傻了——累计存了1200多个镜像，大半是测试阶段随便打了标就传上去的，有的甚至连基础系统版本都没写清楚。

很多团队对容器化迁移的认知，到把应用跑在K8s上就停了。没人算过后续的账。

迁移前拍脑袋的坑，迁移后要花三倍力气填

最常见的操作就是，把原来虚拟机里跑的应用环境，直接整个打包成镜像，根本不做裁剪。有人觉得镜像大点没关系，现在存储便宜。结果呢？跨可用区拉镜像的带宽费每个月多花好几万，安全扫描跑一遍，半仓库的镜像都带Log4j这类老漏洞，藏在角落没人发现，直到等保检查被点名。

说白了，大家从一开始就没把镜像当需要长期运维的生产资产，只当是临时的压缩包，用完就扔在仓库里，谁也不记挂。

之前跟一个金融行业的运维负责人聊，他们做全量迁移的时候赶进度，三个月迁了300多套应用，全程没设任何镜像准入规则，连最基础的安全扫描都没开。迁移完半年做仓库盘点，发现有近70%的镜像，从上传之后就没被拉取过，有的是开发为了测个小功能临时打了传上去，测完就忘了删。更离谱的是，有个镜像里面打包了完整的生产数据库备份文件，占了18G的空间，就那么安安静静躺在仓库里，谁也不知道它是怎么被传上去的。

别等镜像爆仓了才想起做分层治理

治理不是等仓库满了再组织人搞一次大扫除，是要从迁移的第一步就嵌进流程里的。第一层要先把基础镜像的统一基线卡死，所有对外提供服务的业务镜像，必须从运维团队维护的、经过全量安全扫描的标准基础镜像派生，不准随便从公共仓库拉不知名的镜像当基础层，更不准直接把整个操作系统镜像打包进去当应用层。

我见过最离谱的案例，一个团队的Java应用镜像，基础层用的是某个博主2021年传在公共仓库的JDK11镜像，里面藏了个挖矿程序，整整跑了四个月才被发现，电费都烧了小两万。真的。

很多团队做治理容易走极端，要么啥都不管，要么上来就把所有超过30天的镜像全删了，结果删完第二天就有业务团队找上门，说某个应急版本的镜像找不到了，要回滚都没东西用。麻烦在于，镜像的保留策略从来不是拍脑袋定的，要跟业务的实际回滚周期对齐。核心交易系统的镜像，至少保留最近6个版本的全量内容；非核心的内部工具类镜像，保留最近2个版本就行；测试环境的镜像，上传超过7天没被拉取过的，自动归档到冷存储，既不占主仓库的拉取带宽，真要找的时候也能调回来。

不过话说回来，也不能为了省存储就瞎删。元数据的校验是最基础的——每个进仓库的镜像，必须填清楚对应的应用版本、负责人、基础镜像版本、计划保留周期，缺一项就直接打回，不准进正式仓库。没有这些信息的镜像，本质上就是仓库里的垃圾，你连找它的人都找不到，留着干嘛。

那些被刻意绕开的治理细节

不少团队花大价钱买了商用的镜像仓库产品，觉得功能全，就能自动把治理做好。结果呢？规则配了一堆，实际上根本没人执行。扫描出的高危漏洞，告警发了几百条，全被运维团队点了“已忽略”，因为修复要改应用代码，开发嫌麻烦，就一直搁着。还有的团队，镜像标签随便用，今天打个v1，明天打个v2，后天直接打个latest，最后谁也说不清哪个latest对应哪个版本的代码，上线的时候拉错镜像，直接把测试版本推到生产环境，对吧？这种事每个月都能在不同的公司发生。

之前接触过的一个电商团队，去年大促之前做迁移，因为latest标签的镜像没有做版本锁定，发布的时候自动拉了最新的测试版镜像，导致支付接口报错，停了四十多分钟，损失算下来够买三年的商用镜像仓库license。

正式仓库的写权限，只有经过审批的CI流水线能有，开发个人不准直接往正式仓库推镜像。所有进仓库的镜像，必须经过漏洞扫描、配置合规检查、元数据校验这三关，过不了的直接拦截，连仓库的门都进不来。

很多人觉得做镜像治理会拖慢迁移进度，本来一周能迁完10个应用，加了校验规则之后要多花两天填元数据、等扫描，进度慢了一半。但你算过没有？如果迁移完之后因为镜像问题出一次生产事故，要花的时间、要承担的损失，够你把所有规则跑顺三遍。

上周再跟之前那个制造企业的运维团队聊，他们花了两周时间把仓库里的冗余镜像清了一遍，又把基础镜像的统一基线搭起来，现在镜像仓库的拉取速度比之前快了60%，每月的跨区带宽费省了近两万。他们说一开始觉得做镜像治理是额外的负担，现在才反应过来——容器化迁移不是把东西从虚拟机搬到容器里就完事，你搬过去的每一个镜像，都是要跟着业务跑好几年的生产资产，你一开始对它不上心，后面迟早要为这份偷懒买单。