警告:不要在生产系统中使用

/# df
...
/dev/xvda1      51467016 39384516   9886300  80% /
...

好的，让我们先尝试系统修剪

#/ docker system prune --volumes
...
/# df
...
/dev/xvda1      51467016 38613596  10657220  79% /
...

不太好，好像清理了几兆。让我们疯狂起来吧:

/# sudo su
/# service docker stop
/# cd /var/lib/docker
/var/lib/docker# rm -rf *
/# service docker start
/var/lib/docker# df
...
/dev/xvda1      51467016 8086924  41183892  17% /
...

好了! 只需要记住，除了一次性服务器，不建议使用这种方法。此时，Docker的内部数据库将无法找到任何这些覆盖，这可能会导致意想不到的后果。

我发现这个方法最适合我:

docker image prune --all

默认情况下，Docker不会删除已命名的图像，即使它们未使用。该命令将删除未使用的映像。

注意，图像中的每一层都是/usr/lib/docker/overlay2/文件夹中的一个文件夹。

Docker显然为运行的容器保留了映像的旧版本的映像层。如果你更新运行中的容器的镜像(相同的标签)而没有停止它，可能会发生这种情况，例如:

docker-compose pull
docker-compose up -d

在更新之前运行docker-compose down解决了它，停机时间在我的情况下不是一个问题。

不要在生产环境中这样做

@ravi-luthra给出的答案在技术上是有效的，但它有一些问题!

在我的例子中，我只是试图恢复磁盘空间。lib/docker/overlay文件夹占用了30GB的空间，我只定期运行几个容器。看起来docker有一些数据泄漏的问题，一些临时数据在容器停止时没有被清除。

所以我删除了lib/docker/overlay文件夹的所有内容。在那之后，我的docker实例变得不可用。当我试图运行或构建任何容器时，它给了我这个错误:

failed to create rwlayer: symlink ../04578d9f8e428b693174c6eb9a80111c907724cc22129761ce14a4c8cb4f1d7c/diff /var/lib/docker/overlay2/l/C3F33OLORAASNIYB3ZDATH2HJ7: no such file or directory

经过反复试验，我通过跑步解决了这个问题

(警告:这将删除docker卷内的所有数据)

docker system prune --volumes -a

所以不建议做这样的脏清理，除非你完全了解系统是如何工作的。

“官方”回答，用“修剪”命令清理，实际上不清理overlay2文件夹中的垃圾。

所以，要回答最初的问题，我们可以做的是:

免责声明:应用此功能时请小心。这可能会导致Docker对象中断!

List folder names (hashes) in overlay2 Inspect your Docker objects (images, containers, ...) that you need (A stopped container or an image currently not inside any container do not mean that you do not need them). When you inspect, you will see that it gives you the hashes that are related with your object, including overlay2's folders. Do grep against overlay2's folders Note all folders that are found with grep Now you can delete folders of overlay2 that are not referred by any Docker object that you need.

例子:

假设在overlay2目录中有这些文件夹，

a1b28095041cc0a5ded909a20fed6dbfbcc08e1968fa265bc6f3abcc835378b5
021500fad32558a613122070616963c6644c6a57b2e1ed61cb6c32787a86f048

您只有一个ID为c777cf06a6e3的图像。

然后，这样做:

docker inspect c777cf06a6e3 | grep a1b2809
docker inspect c777cf06a6e3 | grep 021500

想象一下，第一个命令找到了一些东西，而第二个命令什么也没有。

然后，您可以删除0215…overlay2文件夹:

rm -r 021500fad32558a613122070616963c6644c6a57b2e1ed61cb6c32787a86f048

回答问题的题目:

是的，如果你发现它没有被使用，直接删除overlay2文件夹是安全的。 不，如果你发现它正在被使用或者你不确定，直接删除它是不安全的。

我最近遇到了一个类似的问题，overlay2变得越来越大，但我不知道是什么消耗了大量的空间。

df告诉我overlay2的大小大约是24GB。

对于du，我试图找出是什么占据了空间，但失败了。

区别来自于删除的文件(在我的情况下主要是日志文件)仍然被一个进程(Docker)使用。因此，文件不会显示du，但它占用的空间将显示df。

重新启动主机有帮助。重新启动docker容器可能已经有所帮助了…… org上的这篇文章帮助我找到了答案。