清洁docker/overlay2 /是否安全

Question

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

我想知道删除其内容是否安全？或者如果docker有某种命令来释放一些磁盘使用量.

谢谢!

---

更新:

我实际上docker system prune -a已经尝试了,它回收了0Kb.

我的/ docker/overlay2磁盘大小也远大于输出 docker system df

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

Answer 1

如果您的系统还用于构建图像，您可能会使用以下方法来清理构建器创建的垃圾：

docker buildx prune --all

和

docker builder prune --all

Answer 2

Docker使用/ var/lib/docker存储图像,容器和本地命名卷.删除此操作可能会导致数据丢失,并可能导致引擎无法运行.overlay2子目录专门包含图像和容器的各种文件系统层.

要清理未使用的容器和图像,请参阅docker system prune.还有删除卷甚至标记图像的选项,但由于数据丢失的可能性,默认情况下不会启用它们.

Answer 3

朋友们，为了保持一切干净，你可以使用 de 命令：

docker system prune -a && docker volume prune

Answer 4

背景

这个问题的责任可以分为我们对容器卷的错误配置，以及 docker 泄漏（未能发布）写入这些卷的临时数据的问题。我们应该映射（到主机文件夹或其他持久存储声明）我们的应用程序频繁和/或大量写入的所有容器的临时/日志/暂存文件夹。Docker 不负责清理所有自动创建的所谓的 EmptyDirs 默认位于/var/lib/docker/overlay2/*/diff/*. 这些“非持久性”文件夹的内容应该在容器停止后由 docker 自动清除，但显然不是（如果容器仍在运行，它们甚至可能无法从主机端清除 - 它可以运行数月一次）。

解决方法

解决方法需要仔细的手动清理，虽然已经在其他地方进行了描述，但您仍然可以从我的案例研究中找到一些提示，我试图使其尽可能具有指导性和概括性。

所以发生的事情是罪魁祸首应用程序（在我的情况下clair-scanner）设法在几个月内将数百个演出数据写入/diff/tmpdocker's的子文件夹overlay2

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

271G total

因此，由于 中的所有子文件夹/diff/tmp都是不言自明的（所有这些子文件夹都是形式clair-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)

我回收了数百个磁盘空间，无需重新安装 docker 或清除其整个文件夹。所有正在运行的容器都必须在某一时刻停止，因为需要 docker daemon restart 来回收磁盘空间，因此首先确保您的故障转移容器在一个/其他节点上正确运行）。我希望该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

Answer 5

“官方”答案，使用“ prune”命令进行清理，实际上并没有清理overlay2文件夹中的垃圾。

因此，要回答原来的问题，可以做的是：

免责声明：应用时要小心。这可能会导致破坏您的 Docker 对象！

• 列出文件夹名称（哈希值）overlay2
• 检查您需要的 Docker 对象（映像、容器等）（停止的容器或当前不在任何容器内的映像并不意味着您不需要它们）。
• 当您检查时，您将看到它为您提供与您的对象相关的哈希值，包括 的overlay2文件夹。
• grep对overlay2的文件夹执行操作
• 记下通过以下命令找到的所有文件夹grep
• 现在，您可以删除overlay2您需要的任何 Docker 对象未引用的文件夹。

例子：

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

a1b28095041cc0a5ded909a20fed6dbfbcc08e1968fa265bc6f3abcc835378b5
021500fad32558a613122070616963c6644c6a57b2e1ed61cb6c32787a86f048

而你只有一张带有 ID 的图像c777cf06a6e3。

然后，执行以下操作：

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

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

然后，您可以删除 0215... 文件夹overlay2：

rm -r 021500fad32558a613122070616963c6644c6a57b2e1ed61cb6c32787a86f048

回答问题标题：

• 是的，如果您发现 dxidirectly Overlay2 文件夹未被使用，则删除该文件夹是安全的。
• 不，如果您发现它正在使用或不确定，直接删除它是不安全的。

Answer 6

警告：请勿在生产系统中使用

/# 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 的内部数据库将无法找到任何这些叠加层，并且可能会导致意想不到的后果。

Answer 7

也有快速增长的问题 overlay2

/var/lib/docker/overlay2-是一个文件夹，码头工人在其中存储容器的可写层。 docker system prune -a-仅在停止并卸下容器后才能工作。

在我的研究中，我能够弄清楚是什么消耗了空间overlay2。

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

diff 文件夹-包含由具有与您的容器完全相同的文件夹结构的容器写入的实际差异（至少在我的情况下-ubuntu 18 ...）

所以我曾经du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmp弄清楚/tmp容器内是被污染的文件夹。

因此，作为一种解决方法，我使用了-v /tmp/container-data/tmp:/tmp用于docker run命令的参数来将内部/tmp文件夹映射到主机，并在主机上设置cron以清理该文件夹。

cron任务很简单：

• sudo nano /etc/crontab
• */30 * * * * root rm -rf /tmp/container-data/tmp/*
• save and exit

注意：overlay2是系统docker文件夹，他们可以随时更改其结构。以上所有内容均基于我在其中看到的内容。只能进入docker文件夹结构是因为系统完全没有空间，甚至不允许我使用ssh进入docker容器。

Answer 8

我遇到了这个问题。。。是很大的日志。日志在这里：

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

您可以在运行命令行或撰写文件中进行管理。在那里查看：配置日志记录驱动程序

我个人将这3行添加到了docker-compose.yml文件中：

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

Answer 9

我发现这最适合我：

docker image prune --all

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

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

Answer 10

添加到上面的评论，其中人们建议修剪系统，例如清除悬空卷、图像、退出容器等，有时您的应用程序成为罪魁祸首，它会在短时间内生成太多日志，并且如果您使用空目录卷（本地卷）这会填充 /var 分区。在这种情况下，我发现下面的命令非常有趣，可以弄清楚什么在消耗我的 /var 分区磁盘上的空间。

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

此命令将列出前 30 个，它们消耗单个磁盘上的空间最多。意味着如果您的容器使用外部存储，则运行 du 命令会消耗大量时间。此命令不会计算安装卷数。而且速度要快得多。您将获得消耗空间的确切目录/文件。然后您可以转到这些目录并检查哪些文件有用或无用。如果需要这些文件，那么您可以通过在应用程序中进行更改以使用该位置的持久存储或更改该文件的位置，将它们移动到某个持久存储。至于休息，你可以清除它们。