容器化迁移中的镜像治理别等镜像堆成山才动手

上周跟几个在制造行业做IT架构的朋友吃饭，聊到去年赶工完成的容器化迁移项目，几个人同时骂娘。当初为了抢新系统的上线节点，把所有跑在虚拟机里的应用一股脑打包成镜像丢进私有仓库，现在算下来仓库里的镜像快破PB了。拉一个业务镜像要二十分钟，跑起来还动不动跳高危漏洞告警，每次季度安全扫描都能揪出一堆没人维护的旧基础镜像，半夜被叫起来改配置、补漏洞是常事。

最先爆雷的从来不是迁移工具

很多团队启动容器化迁移项目的时候，把所有精力都放在了迁移工具的选型上。要适配虚拟机的网络规则，要打通存储权限，要调整调度策略，前前后后准备了小半年，总觉得把应用成功跑在容器节点上就算大功告成。结果真跑了三个月才发现，真正拖慢效率、制造风险的，从来不是迁移的流程，是堆在仓库里没人管的镜像。

有的团队打包镜像的时候图省事，直接把整个虚拟机的根文件系统打进去，一个镜像快10G，里面一半是根本用不上的系统工具、临时日志、早就弃用的测试依赖。这些镜像传到节点上，会快速占满本地存储，集群的存储配额没用半年就见了底。

麻烦在于，这些镜像从上传进仓库的那天起就没人做登记。有的是半年前测试环境临时调试用的版本，早就没人记得是谁传的、跑的什么应用，算下来这类无主镜像能占近60%的仓库存储空间。真要清理的时候没人敢下手——万一哪个业务偷偷跑在上面呢？删错了出故障，谁来担这个责？

镜像治理不是事后补的流程

很多团队对镜像治理的认知存在偏差。总觉得等迁移全部完成，再找个扫描工具扫一遍漏洞，把明显没用的镜像删一删，就算把治理做了。

不对的。

这事没那么玄。

说白了，从你决定把第一个应用迁到容器平台的那天，就得把镜像的规则嵌进迁移的每一步，而不是等问题堆成山了再回头补。比如打包镜像的环节，强制要求用经过安全校验的精简基础镜像，别上来就用带完整操作系统的通用镜像包，能做分层的就拆分层，把应用依赖和系统基础层分开。这样下次升级基础镜像的时候，不用重新打整个包，镜像拉取速度能快好几倍。

还有，每个传进仓库的镜像，必须打明确的标签，标清楚对应的业务线、负责人、正式版本号。禁止把latest这种模糊标签用在生产环境的镜像上。之前接触过的一个团队，就因为所有人图省事都用latest标签当生产版本，新上传的测试镜像直接覆盖了旧的生产版本，半夜业务全崩了，运维找了俩小时才定位到是镜像被覆盖的问题。

更省成本的做法，是把漏洞扫描的步骤直接嵌到CI构建流水线里。不是等镜像传到仓库了再统一扫，而是在开发人员提交代码、触发镜像构建的那一刻，就自动扫描镜像里的依赖漏洞，发现高危问题直接拦截构建流程，不让带风险的镜像进仓库，从源头把门槛卡死。

别追求一步到位的完美规则

不少团队刚启动镜像治理的时候，总想着定一套覆盖所有场景的完美规则。比如要求所有镜像大小不能超过200M，中危以上漏洞一律不许上线，所有镜像必须保留180天的留存周期。规则写了几十页，贴在wiki最显眼的位置，结果推行的时候根本没人配合。

老业务的镜像本来就存在了五六年，依赖一堆早就停止维护的开源组件，你要求人家两周内把所有镜像调整到符合标准，业务线的开发团队根本抽不出人手做改造。最后规则就成了摆设，没人真的照着执行。

实际做下来更有效的路径，是先从最影响业务效率的部分切入。先把仓库里那些超过90天没被拉取过、标签里连负责人信息都没有的孤儿镜像清出去，这部分往往能占一半的存储空间，清完之后仓库的镜像拉取速度马上就能提上来。然后把生产环境正在运行的几百个镜像的基础镜像统一到同几个经过校验的版本，别一个应用配一个独立的基础镜像，今天这个打个补丁，明天那个升个版本，运维根本管不过来。等这些基础的清理工作做完，再慢慢把标签规范、扫描规则、权限控制一点点加上，每加一条规则，都要算清楚一线团队的执行成本，别让大家觉得这是在凭空加负担。

上周再跟那个做制造行业架构的朋友通电话，他说他们花了三周时间，没买什么昂贵的商业治理工具，就清了清无主的孤儿镜像，统一了生产环境在用的基础镜像版本，仓库的存储占用直接降了40%，拉镜像的平均速度从18秒降到3秒，这周的季度安全扫描，发现的高危漏洞数量比上个月少了七成。

说起来也没什么惊天动地的操作。很多人总觉得容器化迁移是一锤子买卖，迁完上线就可以收工了，却忘了那些丢在仓库里的镜像，就像办公室角落堆的旧纸箱。你不整理，它就会慢慢把整个空间占满，等真要找东西的时候，翻半天都找不到。