/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作业中，只要你不留下你所关心的停止的容器和卷。最好是找出它增长的原因，并在容器级别上纠正它们。

我有这样的问题…那是一根巨大的木头。日志如下:

/var/lib/docker/containers/<container id>/<container id>-json.log

您可以在运行命令行或撰写文件中进行管理。参见:配置日志记录驱动程序

我个人将这3行添加到我的docker-compose中。Yml文件:

my_container:
  logging:
    options:
      max-size: 10m

我也有同样的问题，在我的实例中，这是因为' var/lib/docker '目录被挂载到一个运行的容器(在我的情况下谷歌/cadvisor)，因此它阻止了docker修剪清理文件夹。停止容器，运行docker prune -然后重新运行容器解决了问题。

背景

The blame for the issue can be split between our misconfiguration of container volumes, and a problem with docker leaking (failing to release) temporary data written to these volumes. We should be mapping (either to host folders or other persistent storage claims) all of out container's temporary / logs / scratch folders where our apps write frequently and/or heavily. Docker does not take responsibility for the cleanup of all automatically created so-called EmptyDirs located by default in /var/lib/docker/overlay2/*/diff/*. Contents of these "non-persistent" folders should be purged automatically by docker after container is stopped, but apparently are not (they may be even impossible to purge from the host side if the container is still running - and it can be running for months at a time).

解决方案

解决方案需要仔细的手动清理，虽然已经在其他地方描述过，但您仍然可以从我的案例研究中找到一些提示，我试图使其尽可能具有启发性和普遍性。

所以发生的事情是罪魁祸首应用程序(在我的案例中是claire -scanner)设法在几个月内向docker的overlay2的/diff/tmp子文件夹写入了数百gb的数据

du -sch /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp

271G total

因此，由于/diff/tmp中的所有子文件夹都是相当自解释的(都是克莱尔-scanner-*的形式，并且有过时的创建日期)，我停止了相关的容器(docker stop clair)，并小心地从diff/tmp中删除了这些过时的子文件夹，谨慎地从一个(最古老的)单一文件夹开始，并测试了对docker引擎的影响(这需要重新启动[systemctl restart docker]来回收磁盘空间):

rm -rf $(ls -at /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp | grep clair-scanner | tail -1)

我回收了数百gb的磁盘空间，而不需要重新安装docker或清除它的整个文件夹。所有正在运行的容器都必须在某一时刻停止，因为需要重新启动docker守护进程来回收磁盘空间，因此首先要确保您的故障转移容器在某个/其他节点上正确运行。我希望docker的prune命令也能覆盖过时的/diff/tmp(甚至/diff/*)数据(通过另一个开关)。

这是一个有3年历史的问题，你可以在Docker论坛上阅读它丰富多彩的历史，其中针对上述解决方案的应用程序日志的变体在2019年被提出，并且似乎在几个设置中起了作用:https://forums.docker.com/t/some-way-to-clean-up-identify-contents-of-var-lib-docker-overlay/30604

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

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