最近，公司的技术平台，运维的破事儿颇多。Jira无法访问，ES堆内存不足，Jenkins频繁不工作。。等等等，让我这个刚入门的小兵抓心脑肝，夜不能寐，关键时刻方恨经验薄弱呀！！一波未平，一波又起，这不，Harbor镜像库又无法访问了。查了下磁盘，发现/data目录已经占用了99%，这还怎么愉快的工作了。搞他就是了！
使用Harbor API删除镜像
网上找了太多的文章都是通过Python或者shell脚本写的，因为自身没弄过python，shell脚本也不熟，而且大多不符合我的特殊需求。所以我打算直接使用Spring boot ，并利用Quartz做定时任务检查，调用Harbor API，完成镜像的删除。由于harbor镜像库保存了公司所有项目的镜像，有些仓库下的镜像比较少，时间也比较久远，不少镜像都是继承的关系，不能单一的按照时间和数量做删除。这里我的策略是每个镜像仓库至少保留5个Tag；如果多于5个，则只保留最近15天的Tag。
完整代码我已贴到Github上，如果大家需要的话可以在文末找到。
Harbor镜像占用过多磁盘
docker镜像是分层的，registry在存储镜像的时候，将docker镜像分成了2部分：
docker/registry/v2/repositories目录中，在这里会看到registry上的项目、项目中的镜像、镜像到Layer的索引信息。docker/registry/v2/blobs目录中，在这里按00-ff分目录存储了所有镜像的layer。如果有2个镜像使用了同一个基础镜像，那么在registry上存储的时候，blobs只有一份数据，而镜像元数据中两个镜像各自的索引都有一部分layer指向相同的layer。
举个例子。
初始状态，A、B两个镜像，都是基于layer a所做的镜像；A引用a,b，B引用a,c。
A -----> a <----- B
\--> b |
c <--/
之后删掉B镜像（通过Harbor的web，或者通过api）
A -----> a B
\--> b
c
此时layer c实际已经没人用了，但是registry在删除B镜像时，只是会删除B的元数据，并不会主动删除layer c。
layer c就是无人照看的孤儿待回收的垃圾，需要GC。
果然 /data/registry/docker/registry这个目录占了600多GB，我们抓到了真凶。
GC回收
使用API，删掉镜像，UI上确实看不见了，但是我们发现磁盘并未释放，还需要回收GC。
使用docker ps, 我们可以看见harbor相关的9个容器。
进入镜像存储位置，我们使用 docker exec -it 3501 /bin/bash，进到registry这个容器里
df -h查看剩余空间
先dry-run一下，看看待删除的报告，此步不会真正执行删除。
registry garbage-collect --dry-run /etc/registry/config.yml
可以清理的blobs还是挺多的。去掉dry-run，实际跑一下
registry garbage-collect /etc/registry/config.yml
GC效果还可以，清理出来500GB左右的空间。
这里如果执行删除时提示对/storage/docker/registry/v2/blobs/sha256/5e/5e526656b6e423eb836829b95951913719a48efa2649189f0a039b068eb59e10/data 没有权限，在容器外执行
chmod -R 777 /data/registry/docker/registry/v2
给整个目录授权即可
Harbor API删除镜像代码，可以扫描下方二维码，关注，并私信，获取Github链接，还望兄弟们帮忙支持公号。
< END >
如果您喜欢这篇文章，还希望帮忙点赞分享，让更多的朋友能够参与其中，分享各自的感悟；也欢迎下方留言，和小伙伴一起探讨职场人生。 小墨唯一公众号 《DevOps特种部队》，分享我在国企数字化转型中，DevOps领域所有相关技术栈，也包含职场的苦与乐，希望各位老哥搜索或者扫描下方图片一键关注，给个支持！
