清理docker / overlay2 /是否安全?


109

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

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


更新:

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

而且我的/ docker / overlay2磁盘大小比来自的输出大得多 docker system df

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


您找到任何答案了吗?我仍然遇到同样的问题。
Saurabh_Jhingan

1
我跑了docker image prune --all然后docker system prune -a。它已回收了大约50 GB的磁盘空间,该空间已被/ var / lib / docker / overlay2下的文件占用。但是,docker system prune -a就足够了。另外,我的配置细节是:OS: Ubuntu 20Docker : 19.03.12
Binita Bharati

Answers:


73

Docker使用/ var / lib / docker来存储您的映像,容器和本地命名卷。删除它可能会导致数据丢失,并有可能使引擎停止运行。overlay2子目录专门包含图像和容器的各种文件系统层

要清除未使用的容器和图像,请参阅docker system prune。还有一些选项可以删除卷甚至是已标记的图像,但是由于可能会丢失数据,因此默认情况下未启用它们。


1
答案是相同的(除了可以排除卷)。如果您删除其中的内容并将其破坏,则可以保留这两部分。使用为此工作提供的工具。
BMitch

1
overlay2文件夹应包含图像和容器所需的文件系统层。您可以随意忽略此建议,但是请不要向我寻求有关在中断系统后如何恢复故障系统的建议,尤其是因为我为您提供了一种支持的方法来清理文件系统。
BMitch

21
我尝试了docker system prune -a,它恢复了0kb的空间。现在,对我而言,/ docker / overlay2磁盘大小比的输出大得多docker system df。这就是为什么我一直在研究这个问题的原因。再次感谢您的回复,先生。我想我需要阅读有关Docker文档的更多信息,或者可能完全删除Docker并重新启动它。我只需要保留一个postgres数据库,就挂载了它
qichao_he 17-10-10,23

9
我会说“受支持”的方式对我也不起作用。进行所有docker系统修剪-a,docker卷修剪,docker映像修剪和docker容器修剪仍使我有80%的磁盘被Docker使用。所有的容器都停止了。
Craig Brett

1
@franzisk清除所有内容,您将删除所有内容,/var/lib/docker而不是将其置于不一致状态的单个子目录。
BMitch

52

我发现这最适合我:

docker image prune --all

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

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


3
“图像修剪”比“系统修剪”要好得多。谢谢!
DavidG

警告!这是非常说明性的,因为它会删除所有未运行容器的映像。如果它们是您的并且尚未推送到注册表,则将在数小时内重新构建它们。但是它仍然不能超出docker system df显示的范围(您可能仍然没有足够的空间,邪恶的overlay2垃圾场需要手动操作。)
mirekphd

是的,它会删除图像。
萨尔克(Sarke)

注意:在我使用docker swarm的情况下,它也删除了所有已标记的图像,即使是正在运行的容器
velop'Oct 18'20

此方法有效,但买家请注意,这会删除容器中没有的所有物品。
jimh

30

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

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

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

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

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

2
您可以在链接到答案中添加几行吗?
RtmY

还将很高兴获得有关如何识别带有巨型日志文件的容器的信息。我有一堆容器和日志文件,有些很大,有些很小。
Micah Zoltu

那如何回答OP问题?
Slavik Meltser

2
这个答案是部分答案,特别是如果“日志”是问题所在(也许我们可以通过一些编辑来改善它?)。在我看到这个答案之前,我将要开始从我的过分完整目录中随机删除大目录overlay2。以我/var/lib/docker为例,该文件的总容量为50GB,其中一个文件占用了36GB的空间/var/lib/docker/overlay2/<container id>/diff/var/log/faillog。假设此文件对于保持一切正常运行并不重要,那么我的短期破解就是将其删除(也许我也将对其进行调整docker-compose)。
D. Woods,

19

也有快速增长的问题 overlay2

/var/lib/docker/overlay2-是一个文件夹,其中docker为您的容器存储可写层。 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容器。


感谢您提供此答案,我们将一个旧的数据库/应用程序放入容器中,该数据库/应用程序会生成很多/var/log/apache2/error.log。我重置error.log和access.log并添加新卷以实现最简单的管理
bcag2

6

背景

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

解决方法

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

所以发生了什么事?罪魁祸首的应用程序(以我为例clair-scanner)成功地在几个月内将数百千兆字节的数据写入了/diff/tmpdocker的子文件夹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)

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


5

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

/# 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目录(在守护程序停止并且假定目录不包含任何特殊文件系统挂载或类似文件的情况下),实际上是一种有效的快捷方法,可以恢复到原来的状态。我不确定为什么你会得到所有的反对意见。Docker试图自我修复,它将识别出失去所有希望的时刻,并/var/lib/docker根据需要重新初始化目录。
L0j1k

圣****终于是一个可行的答案。我已经修剪和处理了4个小时的东西,但是我应该已经停止了docker服务,将所有内容都扔进了垃圾箱,然后重新启动它。
奥西

可以工作,但它也只是删除Docker生产的一切。因此,这不是一个好的解决方案。
Akito

2

请勿在生产中这样做

@ 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

因此,除非您完全了解系统的工作方式,否则建议不要进行此类肮脏的清理。


1

/ 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工作,只要您不在所关心的容器和容器周围停下即可。最好弄清其增长的原因,并在容器级别进行纠正。


0

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

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

随着du我试图找出占用的空间......而失败。

区别在于删除的文件(在我的情况下,大多数是日志文件)仍在由进程(Docker)使用。因此,文件不会显示为,du但文件占用的空间将显示为df

主机重启有助于。重新启动Docker容器可能已经有所帮助…… linuxquestions.org上的这篇文章帮助我弄清楚了这一点。


0

除了上面的注释外,人们建议修剪诸如清晰的悬挂卷,图像,出口容器等系统。有时您的应用程序会成为罪魁祸首,它会在很短的时间内生成太多日志,并且如果您使用空的直接卷(本地卷) ),将其填充到/ var分区中。在那种情况下,我发现下面的命令非常有趣,可以弄清楚我的/ var分区磁盘上正在消耗什么空间。

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

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


0

您可以使用以下命令在不影响docker安装的情况下清理docker overlay文件夹。

sudo systemctl stop docker
sudo rm -r /var/lib/docker/overlay2
sudo mkdir /var/lib/docker/overlay2
sudo systemctl start docker

-5

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

3
该命令不提供问题的答案。建议的命令甚至写在问题文本中
。.– MBT

因此,这被灰化为灰烬,但下面相同的确切答案被投票41次。这个网站坏了。
亚当·扎赫兰
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.