为什么长时间运行的 docker 实例会填满我的磁盘空间？答案

【问题标题】：Why does a long running docker instance fill up my disk space?为什么长时间运行的 docker 实例会填满我的磁盘空间？
【发布时间】：2021-05-26 02:39:56
【问题描述】：

当我启动一台新的 Ubuntu 机器 (EC2) 并下载一个运行了很长时间的 docker 映像时，几周后磁盘就会填满。如何防止这种情况发生？

我在网上找到的所有内容都在谈论运行 docker prune，但我的问题与大量杂散的 docker 图像或周围的卷无关。此 EC2 实例下载单个映像并仅启动一次（并使其永远运行，这是一个 CI 运行程序）。

这里有一些线索：

主机和docker镜像都是Ubuntu 20.04
我的 EC2 实例有一个 10 GB 的卷
当我docker pull 时，图像只有 2.5 GB（这是一个 ubuntu 最小图像）
引导脚本使用以下命令启动 docker：

docker run -it -d --rm --shm-size=2gb --env --user root --name running-docker-ci ghcr.io/secret/docker-ci:latest start

这是我所做的诊断：

$ df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/root       10098432 10082048         0 100% /
devtmpfs         8192212        0   8192212   0% /dev
tmpfs            8198028        0   8198028   0% /dev/shm
tmpfs            1639608   164876   1474732  11% /run
tmpfs               5120        0      5120   0% /run/lock
tmpfs            8198028        0   8198028   0% /sys/fs/cgroup
/dev/loop0         34176    34176         0 100% /snap/amazon-ssm-agent/3552
/dev/loop1         56832    56832         0 100% /snap/core18/1988
/dev/loop4         33152    33152         0 100% /snap/snapd/11588
/dev/loop5         56832    56832         0 100% /snap/core18/1997
/dev/loop6         72192    72192         0 100% /snap/lxd/19647
/dev/loop7         69248    69248         0 100% /snap/lxd/20326
/dev/loop2         32896    32896         0 100% /snap/snapd/11841
tmpfs            1639604        0   1639604   0% /run/user/1000

经常运行 du 导致我发现这是我最大的文件夹：

/var/lib/docker$ sudo du -s * | sort -nr | head -50
13842100    overlay2
14888   image
128 containers
72  buildkit
56  network
28  volumes
20  plugins
20  builder
4   trust
4   tmp
4   swarm
4   runtimes

有什么帮助吗？我被难住了。

添加更多细节：

larsks 建议可能这是在容器内。它似乎不是。我没有运行任何生成文件的东西。奇怪的是，我注意到df 显示overlay 文件系统使用了 8 个演出：

$ df
Filesystem     1K-blocks    Used Available Use% Mounted on
overlay          8065444 8049060         0 100% /
tmpfs              65536       0     65536   0% /dev
tmpfs            8198028       0   8198028   0% /sys/fs/cgroup
shm              2097152      16   2097136   1% /dev/shm
/dev/root        8065444 8049060         0 100% /etc/hosts
tmpfs            8198028       0   8198028   0% /proc/acpi
tmpfs            8198028       0   8198028   0% /proc/scsi
tmpfs            8198028       0   8198028   0% /sys/firmware

但是当在目录树上执行du 时，它不会加起来接近 8 个演出。我从正在运行的容器内的文件系统的根目录运行它：

$ sudo du -s * | sort -nr | head -50

3945724 home
1094712 usr
254652  opt
151984  var
3080    etc
252     run
192     tmp
24      root
16      dev
4       srv
4       mnt
4       media
4       boot
0       sys
0       sbin
0       proc
0       libx32
0       lib64
0       lib32
0       lib
0       bin

【问题讨论】：

看起来您的图像正在运行在文件系统中生成输出的东西。它是什么？如果你在容器内运行du，哪个目录占用了空间？
这是你的图像产生的东西，很可能是日志。如果你再深入一点overlay2 目录，你会发现到底是什么。我推荐这个序列du -sch /var/lib/docker/overlay2/* | sort -h | tail 进行进一步调查。
@larsks 它似乎不是容器内部的文件系统。它没有产生任何实际输出并运行du 证实了这一点。但是，我确实发现du 和df 之间存在奇怪的差异。我在上面的帖子中添加了详细信息。
我不确定我们还能从这里提供多少帮助。如果磁盘使用量在增长，您可以检查 overlay2 目录中的文件和目录以识别使用磁盘空间的文件和目录。它要么是不断增长的容器日志，要么是写入容器文件系统的文件。由于覆盖文件系统的工作方式，容器内的 df 只是报告父文件系统的可用空间。
@KeithSchacht : 请在执行docker run 时添加--read-only 标志，如果它确实没有生成任何文件，那么这不会对您产生任何影响，它可能会给我们一个更好的线索在哪里看。

标签： docker ubuntu amazon-ec2

【解决方案1】：

OverlayFS 的部分工作原理似乎是删除操作并不总是释放文件系统中的空间。来自the docs：

删除文件和目录：

当在容器中删除文件时，会在容器中创建一个空白文件（上层目录）。镜像层（lowerdir）中文件的版本不会被删除（因为lowerdir是只读的）。但是，whiteout 文件阻止它对容器可用。

当在容器中删除目录时，会在容器中创建一个不透明的目录（上层目录）。这与 whiteout 文件的工作方式相同，并且有效地防止目录被访问，即使它仍然存在于映像 (lowerdir) 中。

在不了解您的 CI 程序的情况下，很难准确地说出，但重点是，如果您认为要删除文件，则文件系统很可能会保留其中的部分或全部内容。

顺便说一句，既然您提到您在 AWS 上，您可能会考虑使用无服务器 CI 部署，以便您的容器在每次运行时都从头开始。

【讨论】：