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

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


更新:

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

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

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


当前回答

在我的例子中,systemctl stop docker然后systemctl start docker以某种方式自动释放空间/var/lib/docker/*

其他回答

我使用了“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分区。在这种情况下,我发现下面的命令非常有趣,要弄清楚是什么在消耗我的/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.

不要在生产环境中这样做

@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

所以不建议做这样的脏清理,除非你完全了解系统是如何工作的。

/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作业中,只要你不留下你所关心的停止的容器和卷。最好是找出它增长的原因,并在容器级别上纠正它们。