上周跟南京几个做技术的朋友凑在新街口喝咖啡，聊到最近各家都在推的容器化迁移中的镜像治理，十个人里有八个吐槽，说这事儿比当初把应用从物理机迁到虚拟机麻烦十倍。
其中一个做政务系统的负责人说，上个月他们花了三周把12个核心业务系统全迁到K8s上，当时只顾着让应用跑通，没管镜像的事，结果上线前一统计，所有镜像加起来占了217G的存储，测试环境拉个新镜像要等十分钟，开发同事天天在群里抱怨发布太慢。回头算下来，光后面清理冗余镜像的时间，比当初迁应用的时间还长。
最先踩的坑是把镜像当安装包存
真的离谱。
很多团队刚接触容器的时候，对镜像的认知还停留在“把应用打包成可运行的安装包”，打镜像的时候图省事，直接把原来虚拟机里的整个运行目录全拷进去——什么编译用的gcc、平时排查问题留的测试脚本、甚至开发阶段留下的几百兆日志文件，全都往镜像里塞。一个镜像动不动几个G，还觉得挺正常。
镜像和传统安装包的核心区别是，它是分层存储的，每多塞一层没用的东西，所有基于这个基础镜像构建的后续镜像，都会带着这层冗余跑。就像你在共享的文件柜里放了个没用的大箱子，后面所有用这个柜子的人，每次拿东西都得绕着这个箱子走，时间久了整个柜子的空间全被占满。
刚才说的那个政务项目的负责人，翻了下他们用的基础镜像，里面居然留了个20多G的Oracle客户端安装包，实际运行的时候根本用不到，就是当初打镜像的开发同事图省事，直接把整个安装目录全拷进去了。后来他们用多阶段构建重新裁剪镜像，把编译阶段的依赖全删掉，最终把18个G的基础镜像压到了400多M，拉取时间直接从十分钟降到了二十秒。
别等迁完了才想起做镜像扫描
太常见了。
大部分团队做容器化迁移的节奏，都是先把应用跑起来，再补安全流程。结果等所有服务都迁完，准备上线的时候才统一扫一遍镜像，一查吓一跳：基础镜像里的openssl有三个高危漏洞，有的镜像里带了公开的SSH密钥，甚至有开发同事把硬编码的数据库密码直接打进了镜像层。
我见过最夸张的一个团队，迁了80多个服务，上线前统一扫镜像，结果60%的镜像都有中高危漏洞，回退重做花了整整两周，本来提前一周能上线的项目，硬生生拖了三周。
镜像扫描一定要前置到迁移的镜像构建阶段，而不是等整个迁移流程走完再补做。把扫描规则嵌到CI流水线里，只要有新的镜像要推到正式仓库，系统自动扫漏洞，高危问题没修复的直接拦截，根本不给流到后面流程的机会。
有人会说，这样会不会拖慢迁移的进度？其实不会。你在构建镜像的时候多花十秒钟扫一遍，总比等所有服务都迁完了，再挨个拆镜像补漏洞要快得多。更别说如果带着漏洞上线，后面出了安全问题，要花的时间成本根本不是一个量级的。
镜像仓库的权限比你想的重要
很多团队一开始搭镜像仓库，图省事，给所有人开全局的推送、删除权限，甚至为了方便跨团队拉测试镜像，直接把仓库设成了公网可匿名访问。
说白了，镜像仓库就是你整个容器环境的“软件源头”。如果有人不小心把带敏感信息的镜像推上去，或者被人恶意替换了基础镜像，那整个集群的安全边界直接就破了。之前有个做零售的团队，为了让外包团队能拉测试环境的镜像，开了三个月的匿名拉取权限，后来被人爬了仓库，在基础镜像里加了挖矿程序，等发现的时候，程序已经跑了快半个月，占了近30%的集群计算资源。
迁移阶段就要把镜像仓库的权限颗粒度落到团队级，甚至到具体的镜像仓库项目，明确谁能推、谁能拉、谁能删，别图省事开全局权限。比如每个业务团队单独划一个仓库项目，团队成员只能往自己的项目里推镜像，别的项目只能拉正式版本的镜像，没有删除和修改的权限。这样就算出了问题，也能快速追溯到具体是哪个团队推的镜像，不会乱成一团。
经常有人问我，做镜像治理是不是要搞一套复杂的全生命周期管理系统，写几十页的管理规则才能落地？其实根本没那么玄。一开始就抓三个最核心的规则：第一，打镜像的时候用多阶段构建，只留运行必需的依赖，别把编译工具、日志文件这些没用的东西塞进去；第二，把漏洞扫描嵌到CI流程里，有高危问题的镜像不准进正式仓库；第三，把仓库权限按团队划细，别给所有人开全局权限。就这三条，比写几十页的制度有用多了。
上周那个做政务系统的朋友给我发消息，说现在他们的镜像仓库总存储已经从200多G降到了30多G，发布速度快了三倍，也没再出过安全漏洞。他说最庆幸的就是没等迁完再补这些治理的活，不然后面测试环境卡的根本没法用，再回头补的话，成本至少是现在的五倍。
容器化迁移从来不是把虚拟机上的东西搬到容器里就完事了。那些你在迁移过程中偷的懒，最后都会变成后面运维要填的坑。