清洁安全吗docker/overlay2/
Is it safe to clean docker/overlay2/
我在 AWS EC2 上安装了一些 docker 容器 运行，/var/lib/docker/overlay2 文件夹的磁盘大小增长非常快。
我想知道删除它的内容是否安全？
或者如果 docker 有某种命令来释放一些磁盘使用量。
更新：
我实际上已经尝试 docker system prune -a，回收了 0Kb。
我的 /docker/overlay2 磁盘大小也比 docker system df
的输出大得多
阅读 docker 文档和 BMitch 的回答后，我认为触摸这个文件夹是一个愚蠢的想法，我会尝试其他方法来回收我的磁盘 space。
Docker 使用 /var/lib/docker 来存储您的图像、容器和本地命名卷。删除它可能会导致数据丢失，并可能从 运行 停止引擎。 overlay2 子目录专门包含图像和容器的各种 filesystem layers。
要清理未使用的容器和图像，请参阅 docker system prune。也有删除卷甚至标记图像的选项，但由于数据丢失的可能性，它们在默认情况下未启用：
$ docker system prune --help
Usage: docker system prune [OPTIONS]
Remove unused data
Options:
-a, --all Remove all unused images not just dangling ones
--filter filter Provide filter values (e.g. 'label=<key>=<value>')
-f, --force Do not prompt for confirmation
--volumes Prune volumes
prune 永远不会删除的内容包括：
- 运行 个容器（用
docker ps 列出它们）
- 这些容器上的日志（有关限制日志大小的详细信息，请参阅
）
- 这些容器所做的文件系统更改（
docker diff可见）
此外，在此垃圾回收期间，docker 可能看不到在正常 docker 文件夹之外创建的任何内容。这可能来自写入此目录的其他应用程序，或 docker 引擎的先前配置（例如，从 AUFS 切换到 overlay2，或者可能在启用用户命名空间之后）。
如果忽略此建议并从该文件系统中删除单个文件夹（如 overlay2），会发生什么情况？容器文件系统由文件系统层的集合组装而成，overlay2 文件夹是 docker 执行其中一些挂载的地方（当容器 运行).在使用时删除其中一些会从 运行 容器中删除文件系统的块，并且可能会破坏从受影响的图像启动新容器的能力。请参阅 this question 以了解许多可能的结果之一。
要完全刷新docker到一个干净的状态，你可以删除整个目录，不仅仅是像overlay2这样的子目录:
# danger, read the entire text around this code before running
# you will lose data
sudo -s
systemctl stop docker
rm -rf /var/lib/docker
systemctl start docker
exit
引擎将在完全空的状态下重新启动，这意味着您将失去所有：
- 图片
- 容器
- 命名卷
- 用户创建的网络
- 集群状态
我用 "docker system prune -a" 它清除了卷和 overlay2 下的所有文件
[root@jasontest volumes]# docker system prune -a
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all images without at least one container associated to them
- all build cache
Are you sure you want to continue? [y/N] y
Deleted Images:
untagged: ubuntu:12.04
untagged: ubuntu@sha256:18305429afa14ea462f810146ba44d4363ae76e4c8dfc38288cf73aa07485005
deleted: sha256:5b117edd0b767986092e9f721ba2364951b0a271f53f1f41aff9dd1861c2d4fe
deleted: sha256:8c7f3d7534c80107e3a4155989c3be30b431624c61973d142822b12b0001ece8
deleted: sha256:969d5a4e73ab4e4b89222136eeef2b09e711653b38266ef99d4e7a1f6ea984f4
deleted: sha256:871522beabc173098da87018264cf3e63481628c5080bd728b90f268793d9840
deleted: sha256:f13e8e542cae571644e2f4af25668fadfe094c0854176a725ebf4fdec7dae981
deleted: sha256:58bcc73dcf4050a4955916a0dcb7e5f9c331bf547d31e22052f1b5fa16cf63f8
untagged: osixia/openldap:1.2.1
untagged: osixia/openldap@sha256:6ceb347feb37d421fcabd80f73e3dc6578022d59220cab717172ea69c38582ec
deleted: sha256:a562f6fd60c7ef2adbea30d6271af8058c859804b2f36c270055344739c06d64
deleted: sha256:90efa8a88d923fb1723bea8f1082d4741b588f7fbcf3359f38e8583efa53827d
deleted: sha256:8d77930b93c88d2cdfdab0880f3f0b6b8be191c23b04c61fa1a6960cbeef3fe6
deleted: sha256:dd9f76264bf3efd36f11c6231a0e1801c80d6b4ca698cd6fa2ff66dbd44c3683
deleted: sha256:00efc4fb5e8a8e3ce0cb0047e4c697646c88b68388221a6bd7aa697529267554
deleted: sha256:e64e6259fd63679a3b9ac25728f250c3afe49dbe457a1a80550b7f1ccf68458a
deleted: sha256:da7d34d626d2758a01afe816a9434e85dffbafbd96eb04b62ec69029dae9665d
deleted: sha256:b132dace06fa7e22346de5ca1ae0c2bf9acfb49fe9dbec4290a127b80380fe5a
deleted: sha256:d626a8ad97a1f9c1f2c4db3814751ada64f60aed927764a3f994fcd88363b659
untagged: centos:centos7
untagged: centos@sha256:2671f7a3eea36ce43609e9fe7435ade83094291055f1c96d9d1d1d7c0b986a5d
deleted: sha256:ff426288ea903fcf8d91aca97460c613348f7a27195606b45f19ae91776ca23d
deleted: sha256:e15afa4858b655f8a5da4c4a41e05b908229f6fab8543434db79207478511ff7
Total reclaimed space: 533.3MB
[root@jasontest volumes]# ls -alth
total 32K
-rw------- 1 root root 32K May 23 21:14 metadata.db
drwx------ 2 root root 4.0K May 23 21:14 .
drwx--x--x 14 root root 4.0K May 21 20:26 ..
警告：请勿在生产系统中使用
/# 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 的内部数据库将无法找到任何这些叠加层，这可能会导致意想不到的后果。
我遇到了这个问题...是日志太大了。日志在这里：
/var/lib/docker/containers/<container id>/<container id>-json.log
您可以在 运行 命令行或撰写文件中进行管理。看那里：Configure logging drivers
我个人将这 3 行添加到我的 docker-compose.yml 文件中：
my_container:
logging:
options:
max-size: 10m
也有快速增长的问题overlay2
/var/lib/docker/overlay2 - 是一个文件夹，docker 为您的容器存储可写层。
docker system prune -a - 仅当容器停止并移除时才可能工作。
通过进入 overlay2 并进行调查，我能够弄清楚是什么消耗了 space。
该文件夹包含其他哈希命名的文件夹。每个都有几个文件夹，包括 diff 文件夹。
diff 文件夹 - 包含由具有与您的容器完全相同的文件夹结构的容器写入的实际差异（至少在我的情况下是这样 - ubuntu 18...）
所以我用 du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmp 弄清楚容器内的 /tmp 是被污染的文件夹 .
因此，作为解决方法，我使用 docker run 命令的 -v /tmp/container-data/tmp:/tmp 参数将内部 /tmp 文件夹映射到主机，并在主机上设置 cron 以清理该文件夹。
cron 任务很简单：
sudo nano /etc/crontab*/30 * * * * root rm -rf /tmp/container-data/tmp/*save and exit
注意：overlay2 是系统 docker 文件夹，他们可能随时更改其结构。以上所有内容均基于我在那里看到的内容。必须进入 docker 文件夹结构只是因为系统完全超出 space 甚至不允许我通过 ssh 进入 docker 容器。
我发现这最适合我：
docker image prune --all
默认情况下 Docker 不会删除已命名的图像，即使它们未被使用。此命令将删除未使用的图像。
请注意图像中的每一层都是 /usr/lib/docker/overlay2/ 文件夹中的一个文件夹。
背景
这个问题的责任可以分为我们对容器卷的错误配置，以及 docker 泄漏（未能释放）临时数据写入这些卷的问题。我们应该映射（到主机文件夹或其他持久存储声明）所有容器的临时/日志/临时文件夹，我们的应用程序经常在这些文件夹中写入and/or。 Docker 不负责清理默认位于 /var/lib/docker/overlay2/*/diff/* 中的所有自动创建的所谓 EmptyDirs。这些 "non-persistent" 文件夹的内容应该在容器停止后由 docker 自动清除，但显然不是（如果容器仍然 运行，它们甚至可能无法从主机端清除- 一次可以 运行 几个月）。
解决方法
解决方法需要仔细的手动清理，虽然已在其他地方进行了描述，但您仍然可以从我的案例研究中找到一些提示，我试图尽可能地使它具有指导性和普遍性。
所以发生的事情是罪魁祸首应用程序（在我的例子中 clair-scanner）在几个月内成功地将数百个数据写入 docker 的 /diff/tmp 子文件夹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] 以回收磁盘space):
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 的磁盘 space，而无需重新安装 docker 或清除其整个文件夹。所有 运行 容器确实必须在某一时刻停止，因为 docker 守护进程需要重新启动才能回收磁盘 space，因此请首先确保您的故障转移容器 运行 正确开启an/other node/s)。我希望 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
不要在生产中这样做
@ravi-luthra 给出的答案在技术上可行，但存在一些问题！
就我而言，我只是想恢复磁盘 space。 lib/docker/overlay 文件夹占用了 30GB 的 space，而我通常只 运行 几个容器。看起来 docker 存在一些数据泄漏问题，一些临时数据在容器停止时未被清除。
所以我继续删除了 lib/docker/overlay 文件夹中的所有内容。在那之后，我的 docker 实例变得无法使用。当我尝试 运行 或构建任何容器时，它给了我这个错误：
failed to create rwlayer: symlink ../04578d9f8e428b693174c6eb9a80111c907724cc22129761ce14a4c8cb4f1d7c/diff /var/lib/docker/overlay2/l/C3F33OLORAASNIYB3ZDATH2HJ7: no such file or directory
然后经过反复试验，我通过 运行ning
解决了这个问题
（警告：这将删除 docker 卷内的所有数据）
docker system prune --volumes -a
因此，除非您完全了解系统的工作原理，否则不建议进行此类脏清理。
/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 system prune -a -f 放在 daily/weekly cron 作业上，只要您不留下您关心的已停止的容器和卷即可。最好找出它增长的原因，并在容器级别进行更正。
我最近遇到了类似的问题，overlay2 越来越大，但我无法弄清楚是什么消耗了大部分 space。
df 显示 overlay2 的大小约为 24GB。
使用 du 我试图弄清楚是什么占据了 space… 但失败了。
不同之处在于删除的文件（在我的例子中主要是日志文件）仍然被进程使用 (Docker)。因此，该文件不会以 du 显示，但它占用的 space 将以 df.
显示
主机重启有帮助。重新启动 docker 容器可能已经有所帮助了……
This article 在 linuxquestions.org 上帮助我解决了这个问题。
添加到上面的评论中，其中人们建议 p运行e 系统，如清除悬空卷、图像、退出容器等，有时您的应用程序成为罪魁祸首，它在一个小文件中生成了太多日志时间，如果您使用空目录卷（本地卷），这会填充 /var 分区。在那种情况下，我发现下面的命令非常有趣，我的 /var 分区磁盘上正在消耗 space。
du -ahx /var/lib | sort -rh | head -n 30
此命令将列出前 30 个，它们在单个磁盘上消耗最多 space。意味着如果您在容器中使用外部存储，运行 du 命令会消耗大量时间。此命令不会计算安装卷。而且速度要快得多。您将得到消耗 space 的确切 directories/files。然后您可以转到这些目录并检查哪些文件有用或无用。如果需要这些文件，那么您可以通过更改应用程序以对该位置使用持久性存储或更改该文件的位置，将它们移动到某个持久性存储。为了休息，您可以清除它们。
朋友们，要保持一切干净，你可以使用 de 命令：
docker system prune -a && docker volume prune
Docker 显然为 运行 容器保留旧版本图像的图像层。如果您更新 运行 容器的图像（相同标签）而不停止它，则可能会发生这种情况，例如：
docker-compose pull
docker-compose up -d
运行 docker-compose down 在更新之前解决了它，停机时间对我来说不是问题。
我遇到了同样的问题，在我的例子中是因为'var/lib/docker'目录被挂载到运行容器（在我的例子中是google/cadvisor）因此它阻塞了docker 从清理文件夹中删除。停止容器，运行 docker 修剪 - 然后重新运行 容器解决了问题。
docker system prune -af && docker image prune -af
“官方”回答，使用“prune”命令清理，实际上并没有清理 overlay2 文件夹中的垃圾。
所以，要回答原来的问题，可以做的是：
免责声明：应用时请小心。这可能会破坏您的 Docker object!
- 在
overlay2 中列出文件夹名称（散列）
- 检查您需要的 Docker objects（图像、容器...）（已停止的容器或当前不在任何容器内的图像并不意味着您不需要他们）。
- 当您检查时，您会看到它为您提供了与您的 object 相关的哈希值，包括
overlay2 的文件夹。
- 对
overlay2 的文件夹执行 grep
- 记下找到的所有文件夹
grep
- 现在您可以删除
overlay2 中未被您需要的 Docker object 引用的文件夹。
示例：
假设您的 overlay2 目录中有这些文件夹，
a1b28095041cc0a5ded909a20fed6dbfbcc08e1968fa265bc6f3abcc835378b5
021500fad32558a613122070616963c6644c6a57b2e1ed61cb6c32787a86f048
你只有一张ID为c777cf06a6e3的图片。
然后，这样做：
docker inspect c777cf06a6e3 | grep a1b2809
docker inspect c777cf06a6e3 | grep 021500
想象一下，第一个命令发现了一些东西，而第二个命令什么都没有。
然后，您可以删除 overlay2:
的 0215... 文件夹
rm -r 021500fad32558a613122070616963c6644c6a57b2e1ed61cb6c32787a86f048
回答问题标题：
- 是的，如果您发现 overlay2 文件夹未被使用，直接删除它是安全的。
- 不行，如果你发现它正在使用或者不确定，直接删除是不安全的。
如果您的系统还用于构建映像，您可能会看看清理构建器使用以下方法创建的垃圾：
docker buildx prune --all
和
docker builder prune --all
也许这个文件夹不是你的问题，不要将df -h的结果与docker一起使用。
使用以下命令查看每个文件夹的大小：
echo; pwd; echo; ls -AlhF; echo; du -h --max-depth=1; echo; du-sh
我在 AWS EC2 上安装了一些 docker 容器 运行，/var/lib/docker/overlay2 文件夹的磁盘大小增长非常快。
我想知道删除它的内容是否安全？ 或者如果 docker 有某种命令来释放一些磁盘使用量。
更新：
我实际上已经尝试 docker system prune -a，回收了 0Kb。
我的 /docker/overlay2 磁盘大小也比 docker system df
阅读 docker 文档和 BMitch 的回答后，我认为触摸这个文件夹是一个愚蠢的想法，我会尝试其他方法来回收我的磁盘 space。
Docker 使用 /var/lib/docker 来存储您的图像、容器和本地命名卷。删除它可能会导致数据丢失，并可能从 运行 停止引擎。 overlay2 子目录专门包含图像和容器的各种 filesystem layers。
要清理未使用的容器和图像，请参阅 docker system prune。也有删除卷甚至标记图像的选项，但由于数据丢失的可能性，它们在默认情况下未启用：
$ docker system prune --help
Usage: docker system prune [OPTIONS]
Remove unused data
Options:
-a, --all Remove all unused images not just dangling ones
--filter filter Provide filter values (e.g. 'label=<key>=<value>')
-f, --force Do not prompt for confirmation
--volumes Prune volumes
prune 永远不会删除的内容包括：
- 运行 个容器（用
docker ps列出它们） - 这些容器上的日志（有关限制日志大小的详细信息，请参阅
- 这些容器所做的文件系统更改（
docker diff可见）
此外，在此垃圾回收期间，docker 可能看不到在正常 docker 文件夹之外创建的任何内容。这可能来自写入此目录的其他应用程序，或 docker 引擎的先前配置（例如，从 AUFS 切换到 overlay2，或者可能在启用用户命名空间之后）。
如果忽略此建议并从该文件系统中删除单个文件夹（如 overlay2），会发生什么情况？容器文件系统由文件系统层的集合组装而成，overlay2 文件夹是 docker 执行其中一些挂载的地方（当容器 运行).在使用时删除其中一些会从 运行 容器中删除文件系统的块，并且可能会破坏从受影响的图像启动新容器的能力。请参阅 this question 以了解许多可能的结果之一。
要完全刷新docker到一个干净的状态，你可以删除整个目录，不仅仅是像overlay2这样的子目录:
# danger, read the entire text around this code before running
# you will lose data
sudo -s
systemctl stop docker
rm -rf /var/lib/docker
systemctl start docker
exit
引擎将在完全空的状态下重新启动，这意味着您将失去所有：
- 图片
- 容器
- 命名卷
- 用户创建的网络
- 集群状态
我用 "docker system prune -a" 它清除了卷和 overlay2 下的所有文件
[root@jasontest volumes]# docker system prune -a
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all images without at least one container associated to them
- all build cache
Are you sure you want to continue? [y/N] y
Deleted Images:
untagged: ubuntu:12.04
untagged: ubuntu@sha256:18305429afa14ea462f810146ba44d4363ae76e4c8dfc38288cf73aa07485005
deleted: sha256:5b117edd0b767986092e9f721ba2364951b0a271f53f1f41aff9dd1861c2d4fe
deleted: sha256:8c7f3d7534c80107e3a4155989c3be30b431624c61973d142822b12b0001ece8
deleted: sha256:969d5a4e73ab4e4b89222136eeef2b09e711653b38266ef99d4e7a1f6ea984f4
deleted: sha256:871522beabc173098da87018264cf3e63481628c5080bd728b90f268793d9840
deleted: sha256:f13e8e542cae571644e2f4af25668fadfe094c0854176a725ebf4fdec7dae981
deleted: sha256:58bcc73dcf4050a4955916a0dcb7e5f9c331bf547d31e22052f1b5fa16cf63f8
untagged: osixia/openldap:1.2.1
untagged: osixia/openldap@sha256:6ceb347feb37d421fcabd80f73e3dc6578022d59220cab717172ea69c38582ec
deleted: sha256:a562f6fd60c7ef2adbea30d6271af8058c859804b2f36c270055344739c06d64
deleted: sha256:90efa8a88d923fb1723bea8f1082d4741b588f7fbcf3359f38e8583efa53827d
deleted: sha256:8d77930b93c88d2cdfdab0880f3f0b6b8be191c23b04c61fa1a6960cbeef3fe6
deleted: sha256:dd9f76264bf3efd36f11c6231a0e1801c80d6b4ca698cd6fa2ff66dbd44c3683
deleted: sha256:00efc4fb5e8a8e3ce0cb0047e4c697646c88b68388221a6bd7aa697529267554
deleted: sha256:e64e6259fd63679a3b9ac25728f250c3afe49dbe457a1a80550b7f1ccf68458a
deleted: sha256:da7d34d626d2758a01afe816a9434e85dffbafbd96eb04b62ec69029dae9665d
deleted: sha256:b132dace06fa7e22346de5ca1ae0c2bf9acfb49fe9dbec4290a127b80380fe5a
deleted: sha256:d626a8ad97a1f9c1f2c4db3814751ada64f60aed927764a3f994fcd88363b659
untagged: centos:centos7
untagged: centos@sha256:2671f7a3eea36ce43609e9fe7435ade83094291055f1c96d9d1d1d7c0b986a5d
deleted: sha256:ff426288ea903fcf8d91aca97460c613348f7a27195606b45f19ae91776ca23d
deleted: sha256:e15afa4858b655f8a5da4c4a41e05b908229f6fab8543434db79207478511ff7
Total reclaimed space: 533.3MB
[root@jasontest volumes]# ls -alth
total 32K
-rw------- 1 root root 32K May 23 21:14 metadata.db
drwx------ 2 root root 4.0K May 23 21:14 .
drwx--x--x 14 root root 4.0K May 21 20:26 ..
警告：请勿在生产系统中使用
/# 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 的内部数据库将无法找到任何这些叠加层，这可能会导致意想不到的后果。
我遇到了这个问题...是日志太大了。日志在这里：
/var/lib/docker/containers/<container id>/<container id>-json.log
您可以在 运行 命令行或撰写文件中进行管理。看那里：Configure logging drivers
我个人将这 3 行添加到我的 docker-compose.yml 文件中：
my_container:
logging:
options:
max-size: 10m
也有快速增长的问题overlay2
/var/lib/docker/overlay2 - 是一个文件夹，docker 为您的容器存储可写层。
docker system prune -a - 仅当容器停止并移除时才可能工作。
通过进入 overlay2 并进行调查，我能够弄清楚是什么消耗了 space。
该文件夹包含其他哈希命名的文件夹。每个都有几个文件夹，包括 diff 文件夹。
diff 文件夹 - 包含由具有与您的容器完全相同的文件夹结构的容器写入的实际差异（至少在我的情况下是这样 - ubuntu 18...）
所以我用 du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmp 弄清楚容器内的 /tmp 是被污染的文件夹 .
因此，作为解决方法，我使用 docker run 命令的 -v /tmp/container-data/tmp:/tmp 参数将内部 /tmp 文件夹映射到主机，并在主机上设置 cron 以清理该文件夹。
cron 任务很简单：
sudo nano /etc/crontab*/30 * * * * root rm -rf /tmp/container-data/tmp/*save and exit
注意：overlay2 是系统 docker 文件夹，他们可能随时更改其结构。以上所有内容均基于我在那里看到的内容。必须进入 docker 文件夹结构只是因为系统完全超出 space 甚至不允许我通过 ssh 进入 docker 容器。
我发现这最适合我：
docker image prune --all
默认情况下 Docker 不会删除已命名的图像，即使它们未被使用。此命令将删除未使用的图像。
请注意图像中的每一层都是 /usr/lib/docker/overlay2/ 文件夹中的一个文件夹。
背景
这个问题的责任可以分为我们对容器卷的错误配置，以及 docker 泄漏（未能释放）临时数据写入这些卷的问题。我们应该映射（到主机文件夹或其他持久存储声明）所有容器的临时/日志/临时文件夹，我们的应用程序经常在这些文件夹中写入and/or。 Docker 不负责清理默认位于 /var/lib/docker/overlay2/*/diff/* 中的所有自动创建的所谓 EmptyDirs。这些 "non-persistent" 文件夹的内容应该在容器停止后由 docker 自动清除，但显然不是（如果容器仍然 运行，它们甚至可能无法从主机端清除- 一次可以 运行 几个月）。
解决方法
解决方法需要仔细的手动清理，虽然已在其他地方进行了描述，但您仍然可以从我的案例研究中找到一些提示，我试图尽可能地使它具有指导性和普遍性。
所以发生的事情是罪魁祸首应用程序（在我的例子中 clair-scanner）在几个月内成功地将数百个数据写入 docker 的 /diff/tmp 子文件夹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] 以回收磁盘space):
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 的磁盘 space，而无需重新安装 docker 或清除其整个文件夹。所有 运行 容器确实必须在某一时刻停止，因为 docker 守护进程需要重新启动才能回收磁盘 space，因此请首先确保您的故障转移容器 运行 正确开启an/other node/s)。我希望 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
不要在生产中这样做
@ravi-luthra 给出的答案在技术上可行，但存在一些问题！
就我而言，我只是想恢复磁盘 space。 lib/docker/overlay 文件夹占用了 30GB 的 space，而我通常只 运行 几个容器。看起来 docker 存在一些数据泄漏问题，一些临时数据在容器停止时未被清除。
所以我继续删除了 lib/docker/overlay 文件夹中的所有内容。在那之后，我的 docker 实例变得无法使用。当我尝试 运行 或构建任何容器时，它给了我这个错误：
failed to create rwlayer: symlink ../04578d9f8e428b693174c6eb9a80111c907724cc22129761ce14a4c8cb4f1d7c/diff /var/lib/docker/overlay2/l/C3F33OLORAASNIYB3ZDATH2HJ7: no such file or directory
然后经过反复试验，我通过 运行ning
解决了这个问题（警告：这将删除 docker 卷内的所有数据）
docker system prune --volumes -a
因此，除非您完全了解系统的工作原理，否则不建议进行此类脏清理。
/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 system prune -a -f 放在 daily/weekly cron 作业上，只要您不留下您关心的已停止的容器和卷即可。最好找出它增长的原因，并在容器级别进行更正。
我最近遇到了类似的问题，overlay2 越来越大，但我无法弄清楚是什么消耗了大部分 space。
df 显示 overlay2 的大小约为 24GB。
使用 du 我试图弄清楚是什么占据了 space… 但失败了。
不同之处在于删除的文件（在我的例子中主要是日志文件）仍然被进程使用 (Docker)。因此，该文件不会以 du 显示，但它占用的 space 将以 df.
主机重启有帮助。重新启动 docker 容器可能已经有所帮助了…… This article 在 linuxquestions.org 上帮助我解决了这个问题。
添加到上面的评论中，其中人们建议 p运行e 系统，如清除悬空卷、图像、退出容器等，有时您的应用程序成为罪魁祸首，它在一个小文件中生成了太多日志时间，如果您使用空目录卷（本地卷），这会填充 /var 分区。在那种情况下，我发现下面的命令非常有趣，我的 /var 分区磁盘上正在消耗 space。
du -ahx /var/lib | sort -rh | head -n 30
此命令将列出前 30 个，它们在单个磁盘上消耗最多 space。意味着如果您在容器中使用外部存储，运行 du 命令会消耗大量时间。此命令不会计算安装卷。而且速度要快得多。您将得到消耗 space 的确切 directories/files。然后您可以转到这些目录并检查哪些文件有用或无用。如果需要这些文件，那么您可以通过更改应用程序以对该位置使用持久性存储或更改该文件的位置，将它们移动到某个持久性存储。为了休息，您可以清除它们。
朋友们，要保持一切干净，你可以使用 de 命令：
docker system prune -a && docker volume prune
Docker 显然为 运行 容器保留旧版本图像的图像层。如果您更新 运行 容器的图像（相同标签）而不停止它，则可能会发生这种情况，例如：
docker-compose pull
docker-compose up -d
运行 docker-compose down 在更新之前解决了它，停机时间对我来说不是问题。
我遇到了同样的问题，在我的例子中是因为'var/lib/docker'目录被挂载到运行容器（在我的例子中是google/cadvisor）因此它阻塞了docker 从清理文件夹中删除。停止容器，运行 docker 修剪 - 然后重新运行 容器解决了问题。
docker system prune -af && docker image prune -af
“官方”回答，使用“prune”命令清理，实际上并没有清理 overlay2 文件夹中的垃圾。
所以，要回答原来的问题，可以做的是：
免责声明：应用时请小心。这可能会破坏您的 Docker object!
- 在
overlay2 中列出文件夹名称（散列）
- 检查您需要的 Docker objects（图像、容器...）（已停止的容器或当前不在任何容器内的图像并不意味着您不需要他们）。
- 当您检查时，您会看到它为您提供了与您的 object 相关的哈希值，包括
overlay2的文件夹。 - 对
overlay2的文件夹执行grep - 记下找到的所有文件夹
grep - 现在您可以删除
overlay2中未被您需要的 Docker object 引用的文件夹。
示例：
假设您的 overlay2 目录中有这些文件夹，
a1b28095041cc0a5ded909a20fed6dbfbcc08e1968fa265bc6f3abcc835378b5
021500fad32558a613122070616963c6644c6a57b2e1ed61cb6c32787a86f048
你只有一张ID为c777cf06a6e3的图片。
然后，这样做：
docker inspect c777cf06a6e3 | grep a1b2809
docker inspect c777cf06a6e3 | grep 021500
想象一下，第一个命令发现了一些东西，而第二个命令什么都没有。
然后，您可以删除 overlay2:
rm -r 021500fad32558a613122070616963c6644c6a57b2e1ed61cb6c32787a86f048
回答问题标题：
- 是的，如果您发现 overlay2 文件夹未被使用，直接删除它是安全的。
- 不行，如果你发现它正在使用或者不确定，直接删除是不安全的。
如果您的系统还用于构建映像，您可能会看看清理构建器使用以下方法创建的垃圾：
docker buildx prune --all
和
docker builder prune --all
也许这个文件夹不是你的问题，不要将df -h的结果与docker一起使用。
使用以下命令查看每个文件夹的大小：
echo; pwd; echo; ls -AlhF; echo; du -h --max-depth=1; echo; du-sh