清理回收空间的问题

[fsword]

应该是没有综合考虑镜像和标签的关系，会出现下面两个错误：

• 不能删除整个镜像（只能删除某个标签）
• 当镜像的所有标签都删除后，理论上镜像已经不能再pull了，但是界面上还是能显示镜像，并继续提示 实际上无法执行的 docker pull 命令

[fsword]

进一步测试表明，对于删除掉所有标签的镜像，再次push时发现layer还是存在的，如果不做完整清理，用户使用过程中空间会持续增长而无法释放

[qinix]

这个需要仔细讨论如何实现，因为需要在 registry 的服务中运行一个命令去做垃圾收集，registry 没有提供 API 去做这件事。

Useful links:

• Garbage collector on API #1515
• docs-garbage-collection for registry
• 删除Docker Registry里的镜像怎么那么难

[qinix]

registry 有挺多不完善的地方，把一个镜像的所有 tag 都删除后获取所有镜像列表的 API 仍会返回这个镜像，如果要实现镜像删除功能只能在数据库中加一个 is_deleted 字段去判断镜像是否已被删除，同时在新建镜像时再进行必要处理

[fsword]

是的，harbor的做法就是提供一个GC定时去做

[qinix]

@fsword harbor 是没有做GC的，需要停掉所有服务后用命令手动完成：https://github.com/vmware/harbor/blob/master/docs/user_guide.md#deleting-repositories

[fsword]

想了一下，registry 那些不完善的地方可能不是缺点，可以看做是对此类问题的必要设计，一个好处是避免不必要的重复push

相应的，比较好的做法是在管理系统中进行软删除标记，确保镜像和tag的一致性也要在这个层面解决。

另外，GC工作不是必须shutdown系统，主要是要拒绝push，所以可以有一个系统GC的时间点，这个时间点可以由管理员设置，用户自己注意不要push即可

[qinix]

想了一下，在设置里面定义固定的 GC 时间段不太可行，要考虑各种周期，而且管理员去主动配合这个周期也不太现实。并且按照 Registry 的设计方式来说，GC 应该是频率很低的。

感觉更好的方案是直接在系统设置中加上一个是否允许用户 push，管理员在 GC 前去开启这个选项，GC 结束后再去关闭这个选项可能会更好一点。

[fsword]

人工设定不允许push和自动在GC前禁止push是一样的效果，反而前者更啰嗦，而且两种做法都不能避免有人正在push的时候进行GC

[qinix]

但是自动在GC前禁止push是很难实现的

[fsword]

这个问题依赖于registry本身的调整，目前先把issue的名字修改得符合实际，根据registry后续变化再说