容器镜像服务 ACR 实践：千里达票务系统镜像构建与分发
迁到 ACK 之后，新的问题来了：每次发版，几十个 Pod 都从公有 Docker Hub 拉镜像，国内拉取慢还经常超时，高峰期新扩 Pod 卡在拉镜像。而且镜像里带了配置文件（数据库密码），裸放到公网仓库风险大。接入阿里云容器镜像服务 ACR 后，镜像构建、扫描、分发全在国内闭环。
一、要解决什么
- 国内拉镜像快；
- 镜像安全扫描（有没有漏洞）；
- 多地域集群就近分发；
- 私有仓库，不公开。
二、架构
开发机推送镜像 → ACR 企业版(杭州)
├─ ACK 杭州集群直接拉
└─ ACR 复制到北京 → ACK 北京集群就近拉
CI流水线自动构建 → 扫描漏洞 → 打 tag → 推 ACR
三、关键实现
3.1 镜像仓库命名
registry.cn-hangzhou.aliyuncs.com/ticket/order:1.4.2
registry.cn-hangzhou.aliyuncs.com/ticket/pay:2.1.0
按业务分命名空间，按服务分仓库。
3.2 安全扫描
ACR 内置漏洞扫描，镜像推上去自动扫，高危漏洞阻断发布。早期扫出来基础镜像里有个 Log4j 漏洞，及时升了版本。
3.3 构建加速
- 用 ACR 的云原生构建（Buildx），GitHub 提交代码自动构建镜像；
- 构建缓存分层，下次只变了哪层重建哪层；
- 新扩 Pod 拉镜像用 P2P 加速，不用每个节点都去仓库拉。
四、踩坑复盘
- 镜像过大：一个镜像 1.2GB，因为把整个 JDK 和源码都打进去了。解决：多阶段构建，运行时只留 JRE；
- 密码硬编码：早期 CI 脚本里写了 ACR 账号密码。解决：用 RAM Role + 临时凭证；
- 跨地域拉取慢：北京集群从杭州拉镜像，5 秒变 30 秒。解决：ACR 跨地域复制镜像；
- tag 混乱：早期用 latest 做 tag，回滚时找不到具体版本。解决：强制用 git commit id 做 tag。
五、效果与总结
ACR 上线后，发版时间从 10 分钟缩到 2 分钟，节假日新扩 Pod 再也没卡在拉镜像。容器化的最后一公里不是 K8s，是镜像仓库：构建快、拉取快、安全扫描到位，CI/CD 才真的顺。
