背景
- harbor版本 1.6。
- distribution（原来的名字叫registry）版本为2.7.1，存储后端对接ceph （s3），线上环境ceph存储性能一般。
- 应用会定期删除不需要的镜像，每个镜像只保留一定个数的tag数。
- harbor的bucket占用了52T的存储容量。
- 执行gc，耗时过长。
针对以上问题，需要深入研究distribution gc的原理和s3相关的接口，进而优化gc代码，理想目标是gc在8个小时以内。
镜像仓库中的相关概念
-
registry
docker的镜像管理工具，负责对接各种不同的存储后端，后来改名为distribution。
distribution的github链接 -
harbor
开源的私有仓库管理工具，在distribution的基础上增加了ui、认证、配额等等功能。
harbor的github链接 -
manifest
镜像的描述文件，如镜像的配置信息，数据信息（layers）
manifest官方解释 -
blob
blob这个词应该是参考自mysql中的数据类型blob，在distribution中表示一个存储数据的文件。
GC逻辑简介
在1.6版本的harbor中，暂时还没有GC的概念，所以这里个GC是指对于镜像仓库（distribution）的GC。下面简单介绍下GC的逻辑。
- 将仓库设置为只读
- 遍历distribution的存储目录，获取到镜像列表。
- 遍历镜像的revisions目录，获取镜像的不同版本号的manifest文件。
- 根据3中的manifest，标记blob信息，保存到markSet（字典结构），可以索引到的blob就可以认为不能删除。
- 遍历所有blob文件，如果blob不在markSet中，则认为该blob无镜像引用，加入到deleteSet中
- 遍历deleteSet，调用存储接口挨个删除blob数据，完成镜像仓库的清理。
GC的delete-untagged参数
harbor [ / ]$ registry_DO_NOT_USE_GC garbage-collect --help
`garbage-collect` deletes layers not referenced by any manifests
Usage:
registry garbage-collect <config> [flags]
Flags:
-m, --delete-untagged=false: delete manifests that are not currently referenced via tag
-d, --dry-run=false: do everything except remove the blobs
-h, --help=false: help for garbage-collect
通过查询相关文档，并没有查看到具体的解释，通过梳理代码流程，这个参数的作用是清理以下两种情况下的镜像。
- 使用相同的镜像tag推送不同的镜像内容，之前的镜像就不能再通过tag的方式拉取。
docker tag centos:7 myos:v1
docker push myos:v1 # 生成一个sha256值
docker tag ubuntu:20 myos:v1
docker push myos:v1 # 生成一个sha256值
经过上诉步骤后，使用docker pull myos:v1只能拉取到ubuntu的镜像，但是centos:7这个镜像并没有被删除，可以通过centos:7的sha256值的方式进行拉取。
- 如果通过
sha256的方式删除镜像，那么此sha256对应镜像的tag将无法被拉取。
docker push myos:v2 # 生成一个sha256值，比如是987654321
docker tag myos:v2 centos:7
docker push centos:7
docker tag myos:v2 ubuntu:20
docker push ubuntu:20
docker remove remote myos@987654321
经过上诉步骤后，centos:7和````ubuntu:20``均无法被拉取。
优化思路
了解原有gc速度慢是因为ceph性能低的原因后，就可以做针对性的优化。
1、通过s3 list 遍历获取镜像列表 改为 从pgsql中中获取镜像列表
2、去掉stat获取key的状态。
3、遍历blob，不需要遍历到data文件。
4、去掉删除函数中的list操作。
5、合并删除请求，挨个删除blob数据，修改为每500个blob（这个量要控制一下，防止ceph崩溃和其他影响），调用s3接口删除一次。
6、为方便观察GC效率，增加GC记录信息，每隔5分钟输出一次剩余的待删除layers的数据。
GC优化流程图.png
总结
相关代码就不展示了，需要的同学可以私信获取。优化的第一步就是要了解到性能慢的细节和代码执行的完整步骤，在有限的条件下思考每个步骤是否有优化的空间。本次优化，将GC时间从原来的至少两天缩短到了不到3个小时，性能提升了20多倍。
