Ist es sicher, Docker / Overlay2 / zu reinigen?

Ich habe einige Docker-Container unter AWS EC2 ausgeführt. Der Ordner / var / lib / docker / overlay2 wächst sehr schnell.

Ich frage mich, ob es sicher ist, seinen Inhalt zu löschen? oder wenn Docker einen Befehl hat, um die Festplattennutzung freizugeben.

AKTUALISIEREN:

Ich habe es tatsächlich docker system prune -aschon versucht , was 0 KB zurückforderte.

Auch meine / docker / overlay2-Festplattengröße ist viel größer als die Ausgabe von docker system df

Nachdem ich die Docker-Dokumentation und die Antwort von BMitch gelesen habe, halte ich es für eine dumme Idee, diesen Ordner zu berühren, und ich werde andere Möglichkeiten ausprobieren, um meinen Speicherplatz zurückzugewinnen.

Docker verwendet / var / lib / docker, um Ihre Bilder, Container und lokal benannten Volumes zu speichern. Das Löschen kann zu Datenverlust führen und möglicherweise den Motor am Laufen halten. Das Unterverzeichnis overlay2 enthält speziell die verschiedenen Dateisystemebenen für Bilder und Container.

Informationen zum Bereinigen nicht verwendeter Container und Bilder finden Sie unter docker system prune. Es gibt auch Optionen zum Entfernen von Volumes und sogar mit Tags versehenen Bildern, die jedoch aufgrund der Möglichkeit eines Datenverlusts nicht standardmäßig aktiviert sind.

Ich fand, dass dies für mich am besten funktionierte:

docker image prune --all

Standardmäßig entfernt Docker benannte Bilder nicht, auch wenn sie nicht verwendet werden. Dieser Befehl entfernt nicht verwendete Bilder.

Beachten Sie, dass jede Ebene in einem Bild ein Ordner innerhalb des /usr/lib/docker/overlay2/Ordners ist.

Ich hatte dieses Problem ... Es war das Protokoll, das riesig war. Protokolle sind hier:

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

Sie können dies in der Befehlszeile run oder in der Erstellungsdatei verwalten. Siehe dort: Konfigurieren Sie die Protokollierungstreiber

Ich persönlich habe diese 3 Zeilen zu meiner Datei docker-compose.yml hinzugefügt:

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

hatte auch Probleme mit schnell wachsenden overlay2

/var/lib/docker/overlay2- ist ein Ordner, in dem Docker beschreibbare Ebenen für Ihren Container speichert. docker system prune -a- funktioniert möglicherweise nur, wenn der Behälter angehalten und entfernt wird.

In meinem konnte ich herausfinden, was Platz verbraucht, indem ich overlay2nachforschte.

Dieser Ordner enthält andere Ordner mit Hash-Namen. Jeder von diesen hat mehrere Ordner einschließlich diffOrdner.

diff Ordner - enthält den tatsächlichen Unterschied, der von einem Container mit der genauen Ordnerstruktur als Container geschrieben wurde (zumindest in meinem Fall - Ubuntu 18 ...)

Also habe ich immer du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmpherausgefunden, dass sich /tmpin meinem Container der Ordner befindet, der verschmutzt wird .

Als Problemumgehung habe ich -v /tmp/container-data/tmp:/tmpParameter für den docker runBefehl verwendet, um den inneren /tmpOrdner dem Host zuzuordnen und einen Cron auf dem Host einzurichten, um diesen Ordner zu bereinigen.

Die Cron-Aufgabe war einfach:

• sudo nano /etc/crontab
• */30 * * * * root rm -rf /tmp/container-data/tmp/*
• save and exit

HINWEIS: overlay2ist ein System-Docker-Ordner und kann jederzeit geändert werden. Alles oben basiert auf dem, was ich dort gesehen habe. Musste nur in die Docker-Ordnerstruktur gehen, weil das System keinen Platz mehr hatte und ich nicht einmal in den Docker-Container ssh konnte.

Hintergrund

Die Schuld für das Problem kann zwischen unserer Fehlkonfiguration von Containervolumes und einem Problem mit Docker-Lecks (die nicht freigegeben werden) temporärer Daten, die auf diese Volumes geschrieben wurden, aufgeteilt werden. Wir sollten alle temporären / logs / Scratch-Ordner unseres Containers (entweder Host-Ordnern oder anderen dauerhaften Speicheransprüchen) zuordnen, in denen unsere Apps häufig und / oder stark schreiben. Docker übernimmt keine Verantwortung für die Bereinigung aller automatisch erstellten sogenannten EmptyDirs, die sich standardmäßig in befinden /var/lib/docker/overlay2/*/diff/*. Der Inhalt dieser "nicht persistenten" Ordner sollte nach dem Stoppen des Containers automatisch vom Docker gelöscht werden, ist dies aber anscheinend nicht (es kann sogar unmöglich sein, ihn von der Hostseite zu löschen, wenn der Container noch ausgeführt wird - und er kann monatelang ausgeführt werden zu einem Zeitpunkt).

Problemumgehung

Eine Problemumgehung erfordert eine sorgfältige manuelle Bereinigung, und obwohl sie bereits an anderer Stelle beschrieben wurde, finden Sie möglicherweise noch einige Hinweise aus meiner Fallstudie, die ich so lehrreich und verallgemeinerbar wie möglich zu gestalten versuchte.

Was also passiert ist, ist, dass die Täter-App (in meinem Fall clair-scanner) es geschafft hat, über einige Monate Hunderte von Datenmengen in den /diff/tmpUnterordner von Docker zu schreibenoverlay2

du -sch /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp

271G total

Da alle diese Unterordner /diff/tmpziemlich selbsterklärend waren (alle hatten die Form clair-scanner-*und veraltete Erstellungsdaten), stoppte ich den zugehörigen Container ( docker stop clair) und entfernte diese veralteten Unterordner diff/tmpvorsichtig aus , wobei ich vorsichtig mit einem einzigen (ältesten) begann, und Testen der Auswirkungen auf die Docker-Engine (für die ein Neustart [ systemctl restart docker] erforderlich war , um Speicherplatz zurückzugewinnen):

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)

Ich habe Hunderte von GB Speicherplatz zurückgefordert, ohne Docker neu installieren oder die gesamten Ordner löschen zu müssen. Alle ausgeführten Container mussten an einem Punkt gestoppt werden, da ein Neustart des Docker-Daemons erforderlich war, um Speicherplatz zurückzugewinnen. Stellen Sie daher zunächst sicher, dass Ihre Failover-Container auf einem / anderen Knoten ordnungsgemäß ausgeführt werden. Ich wünschte jedoch, dass der docker pruneBefehl auch die veralteten /diff/tmp(oder sogar /diff/*) Daten abdecken könnte (über einen weiteren Schalter).

Es ist jetzt eine 3 Jahre alte Ausgabe. Sie können die reichhaltige und farbenfrohe Geschichte in Docker-Foren lesen, in denen 2019 eine Variante vorgeschlagen wurde, die auf Anwendungsprotokolle der oben genannten Lösung abzielt und anscheinend in mehreren Setups funktioniert hat: https: // forums.docker.com/t/some-way-to-clean-up-identify-contents-of-var-lib-docker-overlay/30604

WARNUNG: NICHT IN EINEM PRODUKTIONSSYSTEM VERWENDEN

/# df
...
/dev/xvda1      51467016 39384516   9886300  80% /
...

Ok, versuchen wir zuerst, das System zu beschneiden

#/ docker system prune --volumes
...
/# df
...
/dev/xvda1      51467016 38613596  10657220  79% /
...

Nicht so toll, scheint ein paar Megabyte aufgeräumt zu haben. Lass uns jetzt verrückt werden:

/# 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% /
...

Nett! Denken Sie daran, dass dies nur auf einem Wegwerfserver empfohlen wird. Zu diesem Zeitpunkt kann die interne Datenbank von Docker keine dieser Überlagerungen finden, was zu unbeabsichtigten Konsequenzen führen kann.

TUN SIE DAS NICHT IN DER PRODUKTION

Die Antwort von @ ravi-luthra funktioniert technisch, hat aber einige Probleme!

In meinem Fall habe ich nur versucht, Speicherplatz wiederherzustellen. Der lib/docker/overlayOrdner benötigte 30 GB Speicherplatz und ich führe nur wenige Container regelmäßig aus. Anscheinend hat Docker ein Problem mit Datenlecks und einige der temporären Daten werden nicht gelöscht, wenn der Container stoppt.

Also habe ich den gesamten Inhalt des lib/docker/overlayOrdners gelöscht . Danach wurde meine Docker-Instanz nicht mehr verwendbar. Als ich versuchte, einen Container auszuführen oder zu erstellen, gab es diesen Fehler:

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

Dann habe ich dieses Problem mit einigem Ausprobieren durch Ausführen gelöst

(WARNUNG: Dadurch werden alle Ihre Daten in Docker-Volumes gelöscht.)

docker system prune --volumes -a

Es wird daher nicht empfohlen, solche schmutzigen Aufräumarbeiten durchzuführen, es sei denn, Sie verstehen vollständig, wie das System funktioniert.

Alles in / var / lib / docker sind Dateisysteme von Containern. Wenn Sie alle Ihre Container anhalten und sie beschneiden, sollte der Ordner leer sein. Sie wollen das wahrscheinlich nicht wirklich, also löschen Sie die Inhalte dort nicht zufällig. Löschen Sie keine Dinge in / var / lib / docker direkt. Sie können manchmal damit durchkommen, aber es ist aus so vielen Gründen nicht ratsam.

Tun Sie dies stattdessen:

sudo bash
cd /var/lib/docker
find . -type f | xargs du -b  | sort -n

Was Sie sehen werden, sind die größten Dateien, die unten angezeigt werden. Wenn Sie möchten, finden Sie heraus, in welchen Containern sich diese Dateien befinden, geben Sie diese Container ein docker exec -ti containername -- /bin/shund löschen Sie einige Dateien.

Sie können auch docker system prune -a -feinen täglichen / wöchentlichen Cron-Job ausführen, solange Sie keine gestoppten Container und Volumina in der Nähe lassen, die Ihnen wichtig sind. Es ist besser, die Gründe für das Wachstum herauszufinden und sie auf Containerebene zu korrigieren.

Ich hatte kürzlich ein ähnliches Problem, Overlay2 wurde immer größer, aber ich konnte nicht herausfinden, was den größten Teil des Speicherplatzes beanspruchte.

df zeigte mir, dass Overlay2 etwa 24 GB groß war.

Mit duversuchte ich herauszufinden, was den Raum einnahm ... und scheiterte.

Der Unterschied ergab sich aus der Tatsache, dass gelöschte Dateien (in meinem Fall meistens Protokolldateien) noch von einem Prozess (Docker) verwendet wurden. Daher wird die Datei nicht mit angezeigt, dusondern der Speicherplatz , mit dem sie belegt ist df.

Ein Neustart des Host-Computers hat geholfen. Ein Neustart des Docker-Containers hätte wahrscheinlich schon geholfen ... Dieser Artikel auf linuxquestions.org hat mir geholfen, das herauszufinden.

Hinzufügen zu dem obigen Kommentar, in dem Leute vorschlagen, das System wie klar baumelnde Volumes, Bilder, Exit-Container usw. zu beschneiden. Manchmal wurde Ihre App zum Schuldigen, sie erzeugte in kurzer Zeit zu viele Protokolle und wenn Sie ein leeres Directy-Volume (lokale Volumes) verwenden ) dies füllt die / var Partitionen. In diesem Fall fand ich den folgenden Befehl sehr interessant, um herauszufinden, was Speicherplatz auf meiner / var-Partitionsfestplatte verbraucht.

du -ahx / var / lib | sort -rh | Kopf -n 30

Dieser Befehl listet die Top 30 auf, die den meisten Speicherplatz auf einer einzelnen Festplatte beanspruchen. Wenn Sie mit Ihren Containern externen Speicher verwenden, nimmt die Ausführung des Befehls viel Zeit in Anspruch. Dieser Befehl zählt keine Mount-Volumes. Und ist viel schneller. Sie erhalten die genauen Verzeichnisse / Dateien, die Speicherplatz beanspruchen. Dann können Sie in diese Verzeichnisse gehen und prüfen, welche Dateien nützlich sind oder nicht. Wenn diese Dateien erforderlich sind, können Sie sie in einen dauerhaften Speicher verschieben, indem Sie in der App Änderungen vornehmen, um den dauerhaften Speicher für diesen Speicherort zu verwenden, oder den Speicherort dieser Dateien ändern. Und zur Ruhe können Sie sie löschen.

Ich habe "Docker System Prune -a" verwendet, um alle Dateien unter Volumes und Overlay2 zu bereinigen

    [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 ..