也有快速增长的覆盖2的问题

/var/lib/docker/overlay2 -是docker存储容器可写层的文件夹。 只有当容器停止并删除时，Docker系统修剪-a才能工作。

在我的作品中，我能够通过研究overlay2来计算出什么占用了空间。

该文件夹包含其他命名为哈希的文件夹。每个都有几个文件夹，包括diff文件夹。

Diff文件夹——包含一个容器所写的实际差异，该容器具有与你的容器相同的文件夹结构(至少在我的情况下- ubuntu 18…)

所以我用du -hsc /var/lib/docker/overlay2/ longhashhhhhhh /diff/tmp来找出我的容器中的/tmp是被污染的文件夹。

因此，作为一个解决方案，我已经使用-v /tmp/container-data/tmp:/tmp参数为docker运行命令来映射内部/tmp文件夹到主机，并在主机上设置一个cron来清理该文件夹。

Cron任务很简单:

Sudo nano /etc/crontab */30 * * * * root rm -rf /tmp/container-data/tmp/* .使用实例 保存并退出

注意:overlay2是系统docker文件夹，他们可以随时改变它的结构。以上一切都是基于我在里面看到的。不得不进入docker文件夹结构，因为系统完全没有空间，甚至不允许我ssh进入docker容器。

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

/# 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/文件夹中的一个文件夹。

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

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

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

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

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

也许这个文件夹不是你的问题，不要用docker的df -h的结果。 使用下面的命令查看每个文件夹的大小:

echo; pwd; echo; ls -AlhF; echo; du -h --max-depth=1; echo; du-sh

/var/lib/docker中的所有内容都是容器的文件系统。如果你停止所有的容器并修剪它们，你应该以文件夹为空结束。你可能并不想那样做，所以不要随意删除里面的内容。不要直接删除/var/lib/docker中的内容。有时你可能会侥幸逃脱，但出于很多原因，这是不可取的。

你可以这样做:

sudo bash
cd /var/lib/docker
find . -type f | xargs du -b  | sort -n

您将看到的是底部显示的最大文件。如果你想，找出这些文件在什么容器里，用docker exec -ti containername——/bin/sh输入这些容器，然后删除一些文件。

你也可以把docker系统prune -a -f放在每日/每周的cron作业中，只要你不留下你所关心的停止的容器和卷。最好是找出它增长的原因，并在容器级别上纠正它们。