Question

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

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

谢谢！

更新：

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

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

的输出

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

Answer 1

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

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

Answer 2

背景

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

解决方法

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

发生了什么事，罪魁祸首应用程序（在我的情况下为clair-scanner）成功地将几个月的数百笔数据写入了Docker的/diff/tmp的{{1}}子文件夹中

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中删除了这些过时的子文件夹，谨慎地从一个（最旧的）子文件夹开始，并测试对docker引擎的影响（确实需要重新启动[diff/tmp]才能回收磁盘空间）：

systemctl restart docker

我收回了数百GB的磁盘空间，而无需重新安装docker或清除其整个文件夹。必须将所有正在运行的容器都停止在某一点，因为需要重新启动docker daemon来回收磁盘空间，因此请首先确保您的故障转移容器在一个/其他节点上正确运行。我希望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 prune（甚至/diff/tmp）数据（通过另一个开关）。

这是一个已有3年历史的期刊，您可以在Docker论坛上阅读其丰富多彩的历史，在2019年针对该解决方案的应用程序日志提出了一个变体，该变体似乎已在几种设置中起作用：{ {3}}

Answer 3

请勿在生产中使用

@ ravi-luthra给出的答案在技术上是可行的，但存在一些问题！

就我而言，我只是试图恢复磁盘空间。 lib/docker/overlay文件夹占用了30GB的空间，我只定期运行几个容器。看起来docker在数据泄漏方面存在一些问题，并且在容器停止时某些临时数据无法清除。

因此，我继续删除了lib/docker/overlay文件夹的所有内容。之后，我的Docker实例变得无法使用。当我尝试运行或构建任何容器时，它给了我这个错误：

failed to create rwlayer: symlink ../04578d9f8e428b693174c6eb9a80111c907724cc22129761ce14a4c8cb4f1d7c/diff /var/lib/docker/overlay2/l/C3F33OLORAASNIYB3ZDATH2HJ7: no such file or directory

然后通过反复试验，我通过运行

解决了此问题

（警告：这将删除docker卷中的所有数据）

docker system prune --volumes -a

因此，除非您完全了解系统的工作原理，否则不建议执行此类肮脏的清理工作。

Answer 4

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

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

您可以在运行命令行或撰写文件中进行管理。看到那里：Configure logging drivers

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

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

Answer 5

/ 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放在每天/每周的cron作业中，只要您不在所关心的停放的容器和卷上留下即可。最好弄清其增长的原因，并在容器级别进行纠正。

Answer 6

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

docker system prune -a && docker volume prune。

Answer 7

还存在快速增长的<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/2.1.4/jquery.min.js"></script> <div class="mdl-textfield check-modif mdl-js-textfield mdl-textfield--floating-label"> <input class="mdl-textfield__input" type="text" id="check-modif"> <label class="mdl-textfield__label" for="check-modif">Nama atau Kode barang</label> </div> <label class="mdl-radio radio-modif-name mdl-js-radio mdl-js-ripple-effect" for="update-name"> <input type="radio" id="update-name" class="mdl-radio__button" name="options" value="1"> <span class="mdl-radio__label">Nama</span> </label> <label class="mdl-radio radio-modif-description mdl-js-radio mdl-js-ripple-effect" for="update-description"> <input type="radio" id="update-description" class="mdl-radio__button" name="options" value="2"> <span class="mdl-radio__label">Deskripsi</span> </label> <div class="nama mdl-textfield input-modif-name mdl-js-textfield" name="nama"> <input class="mdl-textfield__input" type="text" id="nama" name="nama"> <label class="mdl-textfield__label" for="nama">Nama</label></input> </div> <div class="mdl-textfield input-modif-description mdl-js-textfield deskripsi" name="deskripsi"> <input class="mdl-textfield__input" type="text" id="deskripsi" name="deskripsi"> <label class="mdl-textfield__label" for="deskripsi">Deskripsi</label></input> </div>

问题

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

在我看来，进入docker system prune -a并进行调查可以弄清楚消耗了什么空间。

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

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

所以我用diff来找出容器中的du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmp是被污染的文件夹。

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

cron任务很简单：

/tmp
sudo nano /etc/crontab
*/30 * * * * root rm -rf /tmp/container-data/tmp/*

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

Answer 8

我发现这最适合我：

docker image prune --all

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

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

Answer 9

最近我遇到了类似的问题，overlay2越来越大，但是我不知道是什么占用了大部分空间。

df向我展示了overlay2的大小约为24GB。

我用du来弄清楚是什么占据了空间……并失败了。

差异来自以下事实：已删除的文件（在我的情况下，大多数是日志文件）仍在由进程（Docker）使用。因此，文件不会显示为du，但是文件占用的空间将显示为df。

重新引导主机是有帮助的。重新启动Docker容器可能已经有所帮助... linuxquestions.org上的This article帮助我弄清楚了。

Answer 10

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

du -ahx / var / lib |排序-rh |头-n 30

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

Answer 11

我使用了“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 ..

Answer 12

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

/# 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 / overlay2 /

12 个答案: