我在AWS EC2上运行了一些docker容器,/var/lib/docker/overlay2文件夹的磁盘大小增长得非常快。

我想知道删除它的内容是否安全? 或者如果docker有某种命令来释放一些磁盘使用。


更新:

我实际上已经尝试了docker系统prune -a,它回收了0Kb。

此外,我的/docker/overlay2磁盘大小比docker系统df的输出大得多

在阅读docker文档和BMitch的回答后,我相信触摸这个文件夹是一个愚蠢的想法,我会尝试其他方法来回收我的磁盘空间。


当前回答

我导航到包含overlay2的文件夹。使用du -shc overlay2/*,我发现overlay2中有25G的垃圾。运行docker系统prune -af显示总回收空间:1.687MB,所以我认为它未能清理它。然而,我然后再次运行du -shc overlay2/*,只看到overlay2只有80K,所以它确实工作。

小心,docker撒谎:)。

其他回答

朋友们,为了保持一切清洁,你可以使用命令:

docker system prune -a && docker volume prune

/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分区。在这种情况下,我发现下面的命令非常有趣,要弄清楚是什么在消耗我的/var分区磁盘上的空间。

du -ahx /var/lib | sort -rh | head -n 30

This command will list top 30, which is consuming most space on a single disk. Means if you are using external storage with your containers, it consumes a lot of time to run du command. This command will not count mount volumes. And is much faster. You will get the exact directories/files which are consuming space. Then you can go to those directories and check which files are useful or not. if these files are required then you can move them to some persistent storage by making change in app to use persistent storage for that location or change location of that files. And for rest you can clear them.

我导航到包含overlay2的文件夹。使用du -shc overlay2/*,我发现overlay2中有25G的垃圾。运行docker系统prune -af显示总回收空间:1.687MB,所以我认为它未能清理它。然而,我然后再次运行du -shc overlay2/*,只看到overlay2只有80K,所以它确实工作。

小心,docker撒谎:)。

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

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

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

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

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