很多团队的镜像管理从一台私有服务器开始。本地构建好的镜像直接推上去，用久了版本对不上，拉取慢，谁能推、谁能拉也说不清。阿里云容器镜像服务（ACR）就是托管的镜像仓库，把这些事情收拢到一个控制台里。下面先说它解决什么问题，再讲推送和拉取的基本操作，最后说多地域同步要留意的地方。
ACR 替你管了什么
镜像仓库看上去只做存储、打版本和分发。到了生产环境，还要回答谁能改、改了能不能查、仓库出问题怎么办。ACR 把这些放在一起，高可用、备份和升级由阿里云负责，团队不必再养一套仓库服务。
如果集群已经跑在 ACK 上，两边配合会更顺。节点和仓库在同一地域时，用内网地址拉镜像，不走公网，扩容节点时的等待时间会短一些，公网流量也省下来。
推送和拉取的基本操作
ACR 的镜像地址由仓库访问域名、命名空间、仓库名和标签组成。登录、打标签、推送的步骤和普通 Docker 仓库一样，区别在于地址和登录凭证要换成控制台里的信息。下面是示例，尖括号里的内容需要按自己的环境替换。
docker login registry.cn-hangzhou.aliyuncs.com
docker tag 本地镜像名:版本 registry.cn-hangzhou.aliyuncs.com/命名空间/仓库名:版本
docker push registry.cn-hangzhou.aliyuncs.com/命名空间/仓库名:版本
docker pull registry.cn-hangzhou.aliyuncs.com/命名空间/仓库名:版本地址里的 cn-hangzhou 要换成仓库所在的地域。把镜像推到华东，再让华北的节点用华东的地址拉取，走的就是跨地域链路，速度和成本都会受影响，这是新手最容易踩的坑。
核心功能怎么用
- 命名空间和仓库：按业务线建命名空间，每个服务一个仓库。订单和支付各自一个仓库，授权时直接按仓库分配。
- 访问控制：用 RAM 账号配合仓库权限，把开发、测试、运维的读写范围分开。开发人员只读生产镜像，CI 账号只负责推送。
- 镜像安全扫描：推送后检测已知漏洞。扫描结果要接进流水线，遇到高危结果时拦住发布，而不是上线后再翻报告。
- 内网拉取：节点与仓库同地域时走内网，适合大批节点同时拉取镜像的场景，比如集中扩容。
- 跨地域同步：把镜像同步到其他地域的仓库，让异地集群就近拉取。
- 自动构建：关联代码仓库，代码提交后触发构建，省掉手动打包和推送这一步。
案例：一家电商团队的发布流程
某电商团队有十几个微服务。以前发布时，工程师在构建机上手动打包，再推到自建仓库，开发环境的镜像偶尔会被误推到生产命名空间。后来他们把流程改成了四步。
- 代码提交后，CI 在测试环境构建镜像。标签使用“分支名加提交哈希”的格式，每个版本都能对应到具体提交。
- 镜像推送到华东地域的测试命名空间，同时开启安全扫描。出现高危漏洞时流水线中止，并通知负责人。
- 测试通过后，运维把镜像从测试命名空间复制到生产命名空间。生产命名空间只允许运维角色写入，开发人员只有读取权限。
- 生产环境分布在华东和华北两个地域，通过跨地域同步，两地集群都从本地仓库拉镜像，发布等待时间比之前短了不少。
上线后最明显的变化是误推的情况少了。环境边界由权限固定，不再靠人记。回滚也简单，改一下部署文件里的标签即可，因为每个标签都能追到提交。
多地域同步要注意什么
同步会带来额外的存储和流量开销，所以先想清楚哪些镜像真的需要就近拉取。核心服务的基础镜像和当前在线版本通常值得同步，临时的测试版本没必要复制到每个地域。
同步也不等于立刻可用。镜像到达目标地域需要一点时间，发布前最好确认目标地域已经能拉到新标签。如果提前部署，节点会因为找不到镜像而报拉取失败，排查时容易误以为是集群问题。
几条实际建议
标签规则尽早定。长期只用 latest，回滚和问题定位都会变难。用版本号或提交哈希，并在流水线里强制检查。
权限按最小范围分配。CI 账号只推送，部署账号只拉取，别让一个账号拥有全部权限。出了问题，责任也更容易查清。
扫描报告要进入发布流程。修复漏洞时，先看组件是否暴露在公网，再看漏洞等级，两个条件都满足的优先处理。
对于使用 ACK 或多地域部署的团队，ACR 能省下不少重复的运维工作。版本差异、配额和计费变化较快，落地前以阿里云官网的最新文档为准，先在小范围验证，再全面推开。
