前言:
最好不要做registry的数据清理,最好不要做registry的数据清理,最好不要做registry的数据清理!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
踩坑记录:
registry后端数据大小1.2P,清理被标记delete的数据
详情:
由于后端registry多年未做镜像的清理,倒是底层镜像的数据巨大,达到了1.2P的数据量,每月的存储费用巨高,所以想要通过镜像标记删除的方式,来清理镜像,释放磁盘空间
操作:
操作之前,查询了网上的诸多文章,发现都千遍一律,没有什么问题,也没有任何的坑的记录,所以开始做数据的标记及清理
操作步骤:
1)curl 127.0.0.1:5000/v2/_catalog (查镜像)
2)curl 127.0.0.1:5000/v2/nginx-xctest/tags/list (查标签)
3)curl -i -sS -H 'Accept: application/vnd.docker.distribution.manifest.v2+json' 127.0.0.1:5000/v2/nginx-xctest/manifests/v4 (超sha256的值)
4)curl -X DELETE 127.0.0.1:5000/v2/nginx-xctest/manifests/sha256:0ad4dc606173faf65f9e64fd05f74629d34d2957fdbb06996526e3006839a442 (数据标记delete)
5)docker exec registry bin/registry garbage-collect /etc/docker/registry/config.yml(docker私有镜像仓库垃圾回收)(这是巨坑的一步)
6)重启registry
registry镜像仓库垃圾回收的过程分析如下:
1)查询所有镜像仓库的镜像层的link (我们1.2P的数据量,这一过程经过了大概10天的时间)
2)对统计标记的delete的镜像层做数据清理
故障分析:
registry在手动垃圾回收期间,会首先筛选并标记所有的link层,然后统一进行删除,当处于标记期间,push镜像,由于push的操作是分层push,当push完成后才会形成link记录,所以,恰巧处以标记期间的镜像,就会由于没有link信息被误认为是删除标记的镜像,从而被默认标记为删除状态,当进行到垃圾回收的第二个步骤(数据清理之后),就会对线上的部分误标记的镜像层做清理,从而导致镜像缺失或manifest不存在
数据清理的最好的方法:
1)对于小于40个T的数据,可以在夜间通过将registry的readonly=true打开,重启registry生效后,然后做数据清理 (8个小时基本可以跑完)
2)对于大于40个T的数据,放弃第一种方式,重新搭建registry仓库,将用的的镜像push到新的镜像仓库,并行一段时间,切换镜像仓库