共计 1002 个字符，预计需要花费 3 分钟才能阅读完成。
家喻户晓，建木在我的项目初期就曾经实现了“自举”，就是应用建木实现本身的全副 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
也欢送各位小伙伴给咱们提出意见反馈，微信扫码退出用户群～
