团队的镜像一多，问题通常是慢慢冒出来的。今天一个测试版本，明天一个临时修复，等某次扩容拉不下镜像，才有人想起该整理仓库了。阿里云镜像仓库（阿里云容器镜像服务，即 ACR）就是用来把这件事管起来的托管服务。这篇文章先讲它是什么，再用两个实际案例说明团队里怎么用，最后给一份可以照着做的流程。
先搞清楚它是什么
镜像仓库可以理解成存放容器镜像的地方，作用和代码仓库差不多。构建好的镜像推上去，测试和生产环境再从这里拉下来。阿里云镜像仓库兼容 Docker Registry V2 协议，原来用的 docker push、docker pull 基本不用改，迁移时的改动通常不大。
服务分个人版和企业版。个人版够学习和小项目用；如果团队里有人需要细分权限，镜像涉及敏感业务，或者部署地域比较分散，就该看企业版了。选之前可以问自己三件事：团队有多少人在碰镜像，哪些镜像不能外泄，线上服务分布在几个地域。三个问题的答案基本能定下来。
几个功能怎么落到实际里
功能列表看多了容易混，这里按使用场景说一下。
- 命名空间和仓库：按业务线或团队建命名空间，一个应用对应一个仓库。名字起清楚，之后做权限分配会省很多事。
- 访问控制：给 CI 或开发者配 RAM 子账号，再在仓库级别授权。比如某个开发者只能推测试环境的镜像，碰不到生产仓库。
- 版本标记：用 tag 标记版本，可以按时间，也可以按语义化版本号回溯。要回退时，靠的就是这些 tag。
- 安全扫描（企业版）：推送后检测镜像里的漏洞，尤其是基础镜像自带的已知风险。最好在上线前发现，而不是等线上告警。
- 跨地域同步：把镜像复制到其他地域的仓库，让各地节点就近拉取，延迟和失败率都会下降。
- 内网访问：同地域的 ECS 或 ACK 集群用 VPC 内网地址拉镜像，速度更快，也不占公网流量。
案例一：电商团队的多地域发布
某电商团队的主站在华东，海外站点在新加坡。以前每次发版，新加坡节点都要直接从国内拉镜像。平时还好，流量高峰或扩容的时候，拉取超时就频繁出现。
后来他们在企业版仓库里开启跨地域同步，把生产环境的正式版本自动复制到新加坡的仓库，新加坡的 Kubernetes 集群改成拉本地仓库的镜像。同一批次扩容的耗时，从原来的十几分钟降到几分钟。团队还约定，只有通过安全扫描的镜像才能进入同步流程，风险在出口就被拦下来。
这里有个容易忽略的地方：同步的应该是经过验证的正式版本，而不是每一次构建的产物。如果所有测试镜像都同步过去，仓库很快就会堆满，清理和排查都会变麻烦。
案例二：让集群走内网拉镜像
一家做在线教育的公司，测试集群和生产集群都在同一地域的 ACK 里。最开始，所有节点走公网地址拉镜像。每个月的公网流量费用不算小，而且公网链路偶尔抖动，新 Pod 就起不来。
调整并不复杂。把集群里所有镜像地址换成 VPC 内网地址，同时在 CI 流水线里统一使用同一个地址模板，避免有人手写旧地址又混回公网。改完之后，镜像拉取稳定了，公网流量支出也随之下降。这类改动不碰业务代码，所以很容易被忽略，但它对稳定性的影响比想象中大。
一套可以照着做的流程
- 在控制台创建命名空间，按环境或业务线划分，不要把所有镜像都堆在一个空间里。
- 给 CI 账号单独建一个 RAM 子账号，只授予目标仓库的推送权限。权限越小，误操作的影响越可控。
- 镜像 tag 使用语义化版本号或 Git 提交哈希。尽量别直接用 latest，否则很难确认线上跑的到底是哪一版。
- 在流水线推送前加入安全扫描步骤，高危漏洞直接阻断发布。刚开始可能会卡住一些构建，但比事后补救省事。
- 生产集群统一使用内网地址拉取。跨地域部署时，再配置镜像同步。
- 定期清理过期的测试镜像。存储成本一般不会一下子涨上来，但长期不清理，账单和排查难度都会慢慢变高。
凭证和公开仓库要多留意
权限配置做好了，最容易出问题的反而是凭证。推送用的密码或临时令牌，不要写进代码仓库，通过 CI 平台的密钥功能注入会更稳妥。另外，如果仓库是公开的，镜像里的环境变量、配置文件，甚至某个中间层里残留的敏感信息，都可能被别人看到。公开前把镜像内容从头检查一遍，花的时间不多，却能避开很大的麻烦。
如果团队刚开始用，可以先从命名空间规划和内网拉取做起，流程跑顺了再加安全扫描和跨地域同步。规模小的时候，不必一上来就把所有功能都配齐。
