Docker 镜像仓库为何要分库分权限？

先说一个事故案例：

场景：某大型互联网电商公司，使用一个镜像仓库管理全部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 服务器能上传，运维只接受生产库里的镜像，进行镜像漏洞扫描，部署到生产环境。有什么问题欢迎留言讨论。