简介
最新进展 才云基于 Harbor 的企业级镜像仓库高可用实践
作用
Docker registry,目前他更名为 Distribution。它做的主要事情就是把这些 images 按照 blob 一层一层地存到文件系统里面,每一个 blob 的 name 都是一长串的数字,这数字是根据文件的内容算出来的;甚至它一些描述信息,也是通过 blob 的方式存起来的。然后它提供了一套比较完备的 API 供你去调用,你可以知道这里面有哪些 image 是你可以 pull 或者 push
Harbor做的事情就是说它在原生的一个 Docker registry 的基础上提供了下面这些 features。所以先学习下registry 的基本原理很重要 关于docker image的那点事儿
- 图形界面
- Image Replication
- Access Control
- Operation Auditing,所有的操作都会有一个日志来记录
- Image Vulnerability Scanning,如果镜像里面 CentOS 有个漏洞,那么这个镜像在任何一个地方部署,漏洞也是一直存在的。
harbor原理(待充实)
从架构上看,harbor 是基于 docker registry 做的。harbor做的一个核心的工作主要是 Core services 和 Job services 这两块
- Core services,提供ui 管理与权限控制
- Job services,镜像复制,镜像安全扫描等
其它
Deleting repositories First ,delete a repository in Harbor’s UI. This is soft deletion. Next, delete the actual files of the repository using the garbage collection in Harbor’s UI.
高可用可以做的一些思路:
- 有状态的话要挂盘,或者说用原生的一个集群来保证它的高可用;
- 那无状态的话,你要考虑是不是可以直接伸缩扩容,如果不能的话这个再另想办法。
碰到的问题
删除镜像
2018.12.7 harbor 1.4.0 版本
当你在ui 或者使用 registry restful api 删除某个layer时
- delete 操作只是软删,文件真正删除要等到gc 时
- delete 操作(甚至gc操作)后一段时间内,依然可以通过registry api 查到layer 信息,但无法真正下载
- GoogleContainerTools/jib 类的镜像制作工具push layer 时会先查询 layer 是否在registry 中存在,若存在则放弃push。
- 因为Content Addressable Storage (CAS),所以当你delete 某个镜像后,一样的内容再改个image名字 重新push 是没有用的(还是会拉不到image),因为Content Address 是一样的,Content Address 对应的manifest 还是被软删的状态,却被jib 视为已经存在。
无论新增还是删除镜像,harbor ui的展示都有延迟
拉取镜像
docker pull 时出现 Unexpected EOF
docker pull on a pull through cache fails: Unexpected EOF after some image blobs are expired 文中分析这个现象的原因是:
- docker distribution(也就是docker registry)的Repository 都有一个TTL,默认是7天
- 假设你第一天
docker pull localhost:5000/library/python
,第三天docker pull localhost:5000/library/node
,node 镜像依赖 python 镜像 - 7天后,python镜像过期, node 镜像还没有,再执行
docker pull localhost:5000/library/node
便会出现 Unexpected EOF
另外一种类似的原因是,layer已经被 delete,但仍然可以从harbor 上拉到layer的数据,当真正去下载layer时,出现 Unexpected EOF 。
其它资料 HTTP Cache Headers