先说一个事故案例：

场景：某大型互联网电商公司，使用一个镜像仓库管理所有Docker镜像。开发者打出的镜像上传到唯一的镜像库，测试通过后，运维环境的 Kubernetes 直接从这个库里拉取镜像，所有人对镜像库都有 CRUD 的权限。

事故：由于镜像存储容量过大，开发者打算清理下Snapshot 的镜像，在镜像清理的时候，误将生产环境的镜像进行了删除，导致上线出现问题。本质是镜像缺乏成熟度的区分管理，

解决办法：为通一个项目的镜像通过升级，放在3个镜像仓库内，开发库，测试库，生产库。不同的镜像库对应管理不同成熟度的镜像。

从上图可以看到，Michael Huttermann 在2012年展示的流水线质量关卡的概念。上图的意思，是每个流水线必须具备一定的质量关卡，特别是在测试环境，也就是说，未经自动化测试的Docker 镜像，是不能被放到线上环境运行的。为了区分不同成熟度的制品，需要为不同成熟度阶段的制品建立不同的制品仓库，也就是开发库，测试库，生产库。

根据镜像成熟度区分的原则，我推荐上图的镜像存储方式。我们为开发者提供镜像的开发库，供他们将打好的镜像 Push 到开发库，推送到镜像库之后，即开始开发者自我验证功能。自我验证通过后，镜像仓库会复制（也叫Promote升级）到测试库，随后调用测试环境的 Jenkins 流水线，执行自动化测试案例，当测试完成后，记录测试结果的关键信息到该镜像的元数据上。同时通知测试人员进行 UAT 测试，待所有的测试（人工+自动化）完成之后，边将该镜像升级到发布库，也叫生产库。

现在我们为每个项目建立了三个镜像仓库，那么你可能会问，难道我需要配置3个镜像仓库地址吗？这里我们推荐下面的镜像仓库工作模型。

来看看上述模型的工作原理：

首先需要有一个虚拟仓库（Virtual Repository）来聚合三个本地仓库（Local）和远程仓库（Remote）。目前JFrog Artifactory支持了虚拟仓库，为研发团队提供唯一的 Docker 镜像中心访问地址，而不需要在多个镜像中心之间切换。

开发者通过远程仓库用于代理和缓存 DockerHub 的官方镜像源。

镜像通过 Jenkins流水线，在三个本地仓库之间进行升级。

终端用户，例如生产环境的 Docker 客户端，访问 Docker 生产环境的虚拟仓库，该仓库提供对外的服务。

好的，了解了镜像升级，虚拟仓库的概念之后，你可能会问，如何做这些仓库的权限配置呢？

我画了下面的表格，来帮助你理解不同团队对不同成熟度的镜像仓库应该基本什么样的权限。

开发只对开发库有CRUD权限，对生产库无权限，这样就能避免开发对生产库的误操作。测试团队只接受通过开发自测，升级到测试库的镜像，这样降低测试团队的无效测试率。运维对生产库有CRUD 的权限。那么这里你可能注意到了 CI 服务器对三个仓库都有权限，那是应为镜像的跨仓库复制，打标签，都是通过CI 服务器自动化完成的。

总结

通过开发，测试，生产的三库分离设置，来存放不同成熟度的 Docker 镜像，这样方便做镜像仓库的清理，只清理开发库的镜像，同时，生产库只有CI 服务器能上传，运维只接受生产库里的镜像，进行镜像漏洞扫描，部署到生产环境。有什么问题欢迎留言讨论。