问题

有很多人抱怨说[Docker Registry的删除功能并不会真正地释放空间](https://github.com/docker/distribution/issues/1183)。虽然官方提供了API,但那些都是软删除(soft delete),只是把二进制和镜像的关系解除罢了,并不是真正的删除。真正的删除有那么困难吗?

目前docker官方提供了如下3个软删除的方法:
  1. DELETE:/v2/<name>/manifests/<reference>:这个API是软删除一个清单(manifest),但是真正占用存储空间的层还在。
  2. DELETE:/v2/<name>/blobs/<digest>:这个API类似上面那个,只不过它要软删除的对象是层(layer)罢了。
  3. DELETE:/v2/<name>/blobs/uploads/<uuid>:这个只是取消掉另一个上传的进程罢了。

##
难点

为了删除不需要的数据,腾出磁盘空间,我们希望有删除功能。但是如果一个不健全的删除功能不小心把有用的数据给删了,那还不如没有这个功能呢。在这个逻辑前提下,docker团队选择了不删除数据。除此之外,还有一个考虑:删除功能是需要很大工作量的。大家知道程序员们的价格是比较高的,以相对便宜的磁盘空间为代价,在眼下先节省这笔人工费开销,并把它投入到更有价值的地方去,不是更有意义么。

那为什么删除功能需要很大的工作量呢?这是因为删除有一个大坑。首先我们来看一下存储模型:所有的数据都被存放到VFS之上,它提供了最终一致性,但是可能需要较长时间才能达到一致。再看镜像的数据结构:一个docker镜像包含了3个概念:标签(tag)、清单(manifest)和层(layer)。标签被关联到清单上,而清单则被关联到层上,就像下图一样:

[![](https://qinghua.github.io/img/docker-image.jpg)](https://qinghua.github.io/img/docker-image.jpg)

其实单说删除本身其实是比较容易的事情,就像现在的垃圾收集算法一样。一个是根搜索法,从根节点开始计算,若某对象不可达,则表明不被用到,可删之。在docker镜像中并没有“根层”的概念,所以需要循环所有的清单来看是否有哪些层不被用到。还有一个是引用计数法,它为每一个对象添加一个引用计数器,为0则表明不被用到。实现起来比较简单,但是很难删除掉循环引用。在docker镜像中,因为它是一个[有向无环图(DAG)](https://en.wikipedia.org/wiki/Directed_acyclic_graph),所以并不会有“循环引用”,正是解决这个问题的极佳方案之一。那么这个大坑在哪里呢?问题在于并发。想象一下,如果在删除某层的过程中,有另外一个push的线程误认为此层已经存在,就会在删除之后导致第二个线程push的镜像不能正常工作。

##
方案

目前docker官方有几个数据删除的方案(但是还没有实现):
  1. 引用计数法:如上文所述是垃圾收集算法的一种。需要维护引用计数器,对于已经存在着的docker registry来说需要数据迁移。
  2. 全局锁:引入GC线程来做删除。删除的时候不能写入。实现简单,但是影响性能。
  3. 新老代:也是引入GC线程来做删除。将存储分为年轻年老两代,GC线程删除某一代的时候允许同时写入另一代。避免了全局锁的性能问题但是实现起来比较麻烦。
  4. 数据库:引入一个数据库,用事务来解决并发的问题。

    如果你等不及docker官方的实现,并且对自己的私有库的控制力比较强,不需要考虑并发,可以使用这个脚本来彻底删除,记得先把registry停掉,或者是设置为只读模式以避免并发哦。设置一个cron任务,每天凌晨停止服务一小段时间,然后运行脚本,再启动服务就好了。

    如果你也认为磁盘空间是比较廉价的,那么使用软删除,也就是上文介绍的官方删除API应该能够符合需求。虽然磁盘空间并没有真正地释放出来,但是删除之后镜像真的就不能再被pull下来了。记得要把delete的设置打开,否则会得到The operation is unsupported的异常信息。

    如果不想使用那些感觉上奇奇怪怪的脚本,还有一个选择是设置两套docker registry,比较稳定的镜像版本放在其中一个库里,不稳定的开发版放另一个库里。每天凌晨把不稳定的版本库清空。这样的话就不会让稳定的版本库的磁盘消耗增长太快,但是也增加了一些管理的难度。没有两全其美的事啊。

    写完这篇博客后不久,一个gc的commit被合并到了主干,有望在docker registry的2.4版本提供官方的删除功能。不过,它跟上面脚本的思路类似,也需要停止服务或者设置只读模式,并不能完美解决这个问题。抛开解决方案,就删除功能而言,我在测试过程中也发现了一个缺陷,需要使用docker 1.10版和registry 2.3版才能解决。

##
v1 vs v2

Docker Registry的老版本v1是用python写的,源码在[这里](https://github.com/docker/docker-registry)。新版本v2是用go写的,源码在[这里](https://github.com/docker/distribution)。它们的模型略有变化。老版本v1是个链表,A层链接到B层,B层链接到C层,层层组织起来一个镜像,每一层的ID都是随机生成的。这样一来浪费空间,不能实现层存储的共享,二来有安全隐患,如果不停地提交,会造成ID冲突概率提升。但也正因如此,删除的时候完全没有顾忌,真是成也萧何败也萧何啊。新版本v2的ID是对内容进行sha256哈希之后的结果,所以相同内容的层ID一定是相同的,很好地解决了v1的问题,就是删除功能需要仔细地设计才能实现。除此之外还有鉴权等其他改动,有兴趣的话可以参考[这篇文章](http://www.csdn.net/article/2015-09-09/2825651)。

题外话:有些人看英文容易把registry和repository搞混。在docker的领域内,repository就是相同名字镜像的集合,比如tomcat的docker repository。而registry就是提供repository服务的系统,比如Docker Hub或者是自己使用Docker Registry安装的私有库等。

转自:[https://qinghua.github.io/docker-registry-delete/](https://qinghua.github.io/docker-registry-delete/)