家喻户晓，建木在我的项目初期就曾经实现了“自举”，就是应用建木实现本身的全副CI/CD/CO等自动化流程。
另外，因为建木自身和官网反对的节点都是打包为镜像公布到Docker Hub上，后果最近半年咱们频繁碰到如下场景。
场景一
“CI服务的镜像构建步骤又失败了！曾经重试10次了！！”
“什么起因？”
“原始镜像死活下载不下来啊！”
“为什么不必国内的mirror？”
“用了啊！用了反而更慢了！！”
场景二
“新利用明天部署不了啦！”
“why？”
“明天从Docker Hub下载太频繁，曾经触发了Rate limit。6个小时之后再试吧！”
“……”
以上场景并非只有建木会碰到，大部分在国内应用容器镜像的集体或组织都会碰到。尽管能够用各种形式绕过，但体验十分之差。因而，咱们查看了一下根本原因。
起因剖析
-为啥间接从Docker Hub下载会失败？
因为Docker Hub与Github等服务一样宽泛应用了S3和CDN等服务，因而当下载申请被指向某些因为不可知起因而无法访问的网段时，会呈现无奈连贯的状况。
-为啥用国内的Mirror也不行？
国内某些大厂提供的Mirror实质上是个缓存服务，因而当咱们拉取的镜像不是罕用镜像或因为缓存过期曾经被革除时，Mirror会从新从Docker Hub拉取镜像创立缓存，而后再响应下载申请。所以会用户会感觉比间接从Docker Hub下载的速度还要慢……
-从Mirror下载的镜像内容未更新
某些Mirror会连镜像的“Image Manifest/index”文件一起缓存，导致用户曾经更新了Docker Hub上的镜像，但Mirror并未更新。
解决方案
基于以上起因，咱们须要一个能够在国内工作良好的新的公共镜像库。因而，咱们曾经在已有的建木Hub根底上，新增了OCI镜像库的服务模块，并且提供了从代码库中的Dockerfile主动构建镜像的性能(主动构建能力由建木提供)。
留神：是镜像库，不是Mirror
与之前一样，建木本身的镜像发布会先迁徙到本人的镜像库里。同时也为国内用户提供一个代替计划。与Docker Hub一样，用户的公共仓库数量不限，永恒收费。
目前服务还处于公测期间，性能还在陆续迭代中。如果你的我的项目与咱们相似，也须要一个公共仓库公布给国内用户，无妨来试试！
镜像服务体验链接：https://url.dghub.cn/mpmavj
也欢送各位小伙伴给咱们提出意见反馈，微信扫码退出用户群～