Czy czyszczenie dockera / overlay2 /

109

Mam kilka kontenerów docker działających na AWS EC2, folder / var / lib / docker / overlay2 bardzo szybko rośnie pod względem rozmiaru dysku.

Zastanawiam się, czy można bezpiecznie usunąć jego zawartość? lub jeśli docker ma jakieś polecenie, aby zwolnić trochę miejsca na dysku.


AKTUALIZACJA:

Właściwie docker system prune -ajuż próbowałem , co pozwoliło odzyskać 0Kb.

Również rozmiar mojego dysku / docker / overlay2 jest znacznie większy niż wynik z pliku docker system df

Po przeczytaniu dokumentacji dockera i odpowiedzi BMitcha uważam, że dotknięcie tego folderu jest głupim pomysłem i spróbuję innych sposobów na odzyskanie miejsca na dysku.

qichao_he
źródło
czy znalazłeś na to odpowiedź? Nadal mam ten sam problem.
Saurabh_Jhingan
1
Pobiegłem docker image prune --alli wtedy docker system prune -a. Zwolniło to miejsce na dysku o około 50 GB, które zostało zużyte przez pliki w / var / lib / docker / overlay2. Ale docker system prune -awystarczyłoby. Również moi specyfika konfiguracji to: OS: Ubuntu 20,Docker : 19.03.12
Binita Bharati

Odpowiedzi:

73

Docker używa / var / lib / docker do przechowywania obrazów, kontenerów i lokalnych nazwanych woluminów. Usunięcie tego może spowodować utratę danych i prawdopodobnie zatrzymać działanie silnika. Podkatalog overlay2 zawiera w szczególności różne warstwy systemu plików dla obrazów i kontenerów.

Aby wyczyścić nieużywane pojemniki i obrazy, zobacz docker system prune. Istnieją również opcje usuwania woluminów, a nawet oznaczonych obrazów, ale nie są one domyślnie włączone ze względu na możliwość utraty danych.

BMitch
źródło
1
Odpowiedź jest taka sama (z wyjątkiem tego, że możesz wykluczyć woluminy). Jeśli usuniesz tam rzeczy i zepsujesz je, zachowasz obie części. Użyj narzędzi przewidzianych do tego zadania.
BMitch
1
Folder overlay2 powinien zawierać warstwy systemu plików potrzebne dla twoich obrazów i kontenerów. Możesz zignorować tę radę, ale nie pytaj mnie o radę, jak odzyskać uszkodzony system po jego zepsuciu, zwłaszcza, że ​​dałem Ci obsługiwany sposób czyszczenia systemu plików.
BMitch
21
Próbowałem docker system prune -a, co pozwoliło odzyskać przestrzeń 0kb. W tej chwili sprawa dla mnie jest taka, że ​​rozmiar dysku / docker / overlay2 jest znacznie większy niż wynik z pliku docker system df. To jest powód, dla którego wciąż kopie ten problem. Jeszcze raz dziękuję za odpowiedź. Chyba muszę przeczytać więcej o dokumentacji dockera lub prawdopodobnie całkowicie wymazać dockera i uruchomić go ponownie. Mam tylko bazę danych postgres, którą muszę zachować, i zamontowałem ją
qichao_he
9
Powiem, że „obsługiwany” sposób też nie działa dla mnie. Wykonanie wszystkich operacji czyszczenia w systemie docker -a, czyszczenia woluminu dockera, czyszczenia obrazu dockera i czyszczenia kontenera dockera nadal powoduje, że 80% mojego dysku jest używane przez platformę Docker. To z zatrzymanymi wszystkimi kontenerami.
Craig Brett
1
@franzisk, aby wyczyścić wszystko, co chcesz usunąć, /var/lib/dockera nie pojedynczy podkatalog, który pozostawiłby go w niespójnym stanie.
BMitch
52

Uważam, że to działa najlepiej dla mnie:

docker image prune --all

Domyślnie Docker nie usuwa nazwanych obrazów, nawet jeśli są nieużywane. To polecenie usunie nieużywane obrazy.

Zwróć uwagę, że każda warstwa obrazu jest folderem w /usr/lib/docker/overlay2/folderze.

Sarke
źródło
3
„image prune” działało znacznie lepiej niż „system prune”. Dzięki!
DavidG
Ostrzeżenie! Jest to dość opisowe, ponieważ usuwa wszystkie obrazy niedziałających kontenerów. Będziesz je odbudowywać przez wiele godzin, jeśli są twoje i nie zostały jeszcze umieszczone w rejestrze. Ale to wciąż nie może wykraczać poza zakres docker system dfprzedsięwzięć (być może jeszcze z miejsca i że zło overlay2potrzeb wysypisko śmieci mają być nuked ręcznie.
mirekphd
Cóż, tak, usuwa obrazy.
Sarke
Uwaga: w moim przypadku, w którym użyłem docker swarm, usunął również wszystkie oznaczone obrazy, nawet dla uruchomionych kontenerów
velop
To zadziałało, ale kupujący uważaj, usuwa WSZYSTKO, czego nie ma w pojemniku.
jimh
30

Miałem ten problem ... To był kłód, który był ogromny. Dzienniki są tutaj:

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

Możesz zarządzać tym w linii poleceń uruchamiania lub w pliku redagowania. Zobacz tam: Skonfiguruj sterowniki logowania

Osobiście dodałem te 3 wiersze do mojego pliku docker-compose.yml:

my_container:
  logging:
    options:
      max-size: 10m
Tristan
źródło
2
Czy możesz dodać kilka wierszy z linku do odpowiedzi?
RtmY
Byłoby miło również uzyskać informacje, jak zidentyfikować, który kontener jest tym z gigantycznym plikiem dziennika. Mam kilka kontenerów i plików dziennika, niektóre są ogromne, inne są małe.
Micah Zoltu
Jak to odpowiada na pytanie OP ?!
Slavik Meltser
2
Ta odpowiedź jest częściową odpowiedzią, zwłaszcza jeśli problemem były „logi” (może możemy to poprawić, wprowadzając pewne zmiany?). Dopóki nie zobaczyłem tej odpowiedzi, miałem zamiar zacząć losowo usuwać duże katalogi z mojego zbyt pełnego overlay2. W moim przypadku, całkowita pojemność /var/lib/dockerto 50GB i 36GB z było spożywane przez jednego pliku: /var/lib/docker/overlay2/<container id>/diff/var/log/faillog. Zakładając, że ten plik nie jest kluczowy dla utrzymania wszystkiego w ruchu, moim krótkoterminowym hackiem jest po prostu jego usunięcie (i może też dostosuję docker-compose).
D. Woods,
19

miał też problemy z szybko rosnącym overlay2

/var/lib/docker/overlay2- to folder, w którym docker przechowuje warstwy z możliwością zapisu dla Twojego kontenera. docker system prune -a- może działać tylko wtedy, gdy pojemnik jest zatrzymany i usunięty.

w moim byłem w stanie dowiedzieć się, co pochłania przestrzeń, wchodząc overlay2i badając.

ten folder zawiera inne foldery o nazwie hash. każdy z nich ma kilka folderów, w tym difffolder.

diff folder - zawiera rzeczywistą różnicę zapisaną przez kontener z dokładną strukturą folderów jak Twój kontener (przynajmniej tak było w moim przypadku - ubuntu 18 ...)

więc kiedyś du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmpodkryłem, że /tmpw moim kontenerze znajduje się folder, który zostaje zanieczyszczony .

aby obejść ten problem, użyłem -v /tmp/container-data/tmp:/tmpparametru docker runpolecenia do mapowania /tmpfolderu wewnętrznego na hosta i skonfigurowania crona na hoście, aby wyczyścić ten folder.

zadanie crona było proste:

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

UWAGA: overlay2to systemowy folder dokowany i mogą w dowolnym momencie zmienić jego strukturę. Wszystko powyżej jest oparte na tym, co tam widziałem. Musiałem wejść w strukturę folderów dockera tylko dlatego, że w systemie brakowało miejsca i nawet nie pozwolił mi na ssh do kontenera docker.

user2932688
źródło
Dzięki za tę odpowiedź umieściliśmy w kontenerach starą bazę danych / aplikację, która generuje wiele plików /var/log/apache2/error.log. Zresetowałem error.log i access.log i dodałem nowy wolumin, aby
ułatwić
6

Backgroud

Winę za ten problem można podzielić między błędną konfigurację woluminów kontenerów i problem z wyciekiem Dockera (brakiem możliwości zwolnienia) tymczasowych danych zapisanych w tych woluminach. Powinniśmy mapować (do folderów hosta lub innych trwałych roszczeń do przechowywania) wszystkich folderów tymczasowych / dzienników / magazynów z naszego kontenera, w których nasze aplikacje często i / lub intensywnie piszą. Docker nie bierze odpowiedzialności za czyszczenie wszystkich automatycznie tworzonych tak zwanych EmptyDirs, które domyślnie znajdują się w /var/lib/docker/overlay2/*/diff/*. Zawartość tych "nietrwałych" folderów powinna być czyszczona automatycznie przez docker po zatrzymaniu kontenera, ale najwyraźniej nie jest (może być nawet niemożliwe do wyczyszczenia po stronie hosta, jeśli kontener nadal działa - i może działać przez miesiące na czas).

Obejście problemu

Obejście wymaga starannego ręcznego czyszczenia i chociaż zostało już opisane w innym miejscu, nadal możesz znaleźć kilka wskazówek z mojego studium przypadku, które starałem się uczynić jak najbardziej pouczającymi i uogólniającymi.

Więc co się stało, to aplikacja winowajcy (w moim przypadku clair-scanner) zdołała zapisać w ciągu kilku miesięcy setki gigabajtów danych do /diff/tmppodfolderu dockeraoverlay2

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

271G total

Ponieważ wszystkie te podfoldery /diff/tmpbyły dość oczywiste (wszystkie miały formę clair-scanner-*i miały przestarzałe daty utworzenia), zatrzymałem powiązany kontener ( docker stop clair) i ostrożnie usunąłem te przestarzałe podfoldery z diff/tmp, zaczynając ostrożnie od jednego (najstarszego) i testowanie wpływu na silnik Dockera (który wymagał ponownego uruchomienia [ systemctl restart docker] w celu odzyskania miejsca na dysku):

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)

Odzyskałem setki gigabajtów miejsca na dysku bez konieczności ponownej instalacji dockera lub czyszczenia całych folderów. Wszystkie uruchomione kontenery musiały zostać zatrzymane w pewnym momencie, ponieważ ponowne uruchomienie demona Dockera było wymagane do odzyskania miejsca na dysku, więc najpierw upewnij się, że kontenery przełączania awaryjnego działają poprawnie na / innym węźle / węzłach). Chciałbym jednak, aby docker prunepolecenie obejmowało również przestarzałe /diff/tmp(lub nawet /diff/*) dane (za pośrednictwem jeszcze innego przełącznika).

To już 3-letnie wydanie, o jego bogatej i barwnej historii można przeczytać na forach Dockera, gdzie wariant mający na celu logi aplikacji powyższego rozwiązania został zaproponowany w 2019 roku i wydaje się działać w kilku konfiguracjach: https: // forums.docker.com/t/some-way-to-clean-up-identify-contents-of-var-lib-docker-overlay/30604

mirekphd
źródło
5

OSTRZEŻENIE: NIE UŻYWAĆ W SYSTEMIE PRODUKCYJNYM

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

Ok, najpierw spróbujmy przycinać system

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

Nie tak świetnie, wygląda na to, że wyczyścił kilka megabajtów. Zaszalejmy teraz:

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

Miły! Pamiętaj tylko, że NIE jest to zalecane na żadnym serwerze, z wyjątkiem serwera jednorazowego użytku. W tym momencie wewnętrzna baza danych Dockera nie będzie w stanie znaleźć żadnej z tych nakładek i może to spowodować niezamierzone konsekwencje.

Ravi Luthra
źródło
Całkowite zamknięcie /var/lib/dockerkatalogu (podczas gdy demon jest zatrzymany i zakładając, że katalog nie zawiera żadnych specjalnych montowań systemu plików lub podobnych) w rzeczywistości jest poprawnym, szybkim sposobem na powrót do punktu wyjścia. Nie jestem pewien, dlaczego otrzymujesz wszystkie głosy przeciw. Docker stara się samonaprawiać i rozpoznaje utratę wszelkiej nadziei i w /var/lib/dockerrazie potrzeby ponownie inicjuje katalog.
L0j1k
Holy **** w końcu działająca odpowiedź. Przycinałem i robiłem rzeczy przez 4 godziny, ale powinienem był po prostu zatrzymać usługę dockera, umieścić wszystko w koszu i ponownie uruchomić.
Osi
To działa , ale też po prostu usuwa WSZYSTKO że Docker został wyprodukowany. Więc nie jest to dobre rozwiązanie, per se.
Akito
2

NIE ROBIĆ TEGO W PRODUKCJI

Odpowiedź udzielona przez @ ravi-luthra technicznie działa, ale ma pewne problemy!

W moim przypadku próbowałem tylko odzyskać miejsce na dysku. lib/docker/overlayFolderu brał 30GB przestrzeni i tylko uruchomić kilka pojemników regularnie. Wygląda na to, że docker ma problem z wyciekiem danych i niektóre tymczasowe dane nie są czyszczone po zatrzymaniu kontenera.

Więc poszedłem dalej i usunąłem całą zawartość lib/docker/overlayfolderu. Potem moja instancja dockera stała się nieużyteczna. Kiedy próbowałem uruchomić lub zbudować dowolny kontener, dał mi ten błąd:

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

Następnie metodą prób i błędów rozwiązałem ten problem, uruchamiając

(OSTRZEŻENIE: spowoduje to usunięcie wszystkich danych z woluminów Dockera)

docker system prune --volumes -a

Dlatego nie zaleca się robienia takich brudnych porządków, chyba że całkowicie rozumiesz, jak działa system.

Shankar Thyagarajan
źródło
1

Wszystko w / var / lib / docker to systemy plików kontenerów. Jeśli zatrzymasz wszystkie swoje pojemniki i je przycinasz, powinieneś skończyć z pustym folderem. Prawdopodobnie tak naprawdę tego nie chcesz, więc nie usuwaj tam przypadkowo rzeczy. Nie usuwaj rzeczy bezpośrednio w / var / lib / docker. Czasami może ci się to udać, ale jest to niewskazane z wielu powodów.

Zrób to zamiast tego:

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

To, co zobaczysz, to największe pliki pokazane na dole. Jeśli chcesz, dowiedz się, w jakich kontenerach znajdują się te pliki, wprowadź te kontenery docker exec -ti containername -- /bin/shi usuń niektóre pliki.

Możesz również docker system prune -a -fwykonać codzienne / cotygodniowe zadanie cron, o ile nie pozostawiasz zatrzymanych kontenerów i woluminów, na których Ci zależy. Lepiej jest dowiedzieć się, dlaczego się rozwija, i poprawić je na poziomie kontenera.

Jason Hughes
źródło
0

Niedawno miałem podobny problem, nakładka 2 stawała się coraz większa, ale nie mogłem dowiedzieć się, co pochłania większość miejsca.

df pokazał mi, że overlay2 ma rozmiar około 24 GB.

Z du Próbowałem dowiedzieć się, jakie zajęli miejsca ... i nie.

Różnica wynikała z faktu, że usunięte pliki (w moim przypadku głównie pliki dziennika) były nadal używane przez proces (Docker). W ten sposób plik nie pojawia się z, duale miejsce, które zajmuje, będzie widocznedf .

Pomogło ponowne uruchomienie komputera hosta. Ponowne uruchomienie kontenera dockera prawdopodobnie już by pomogło… Ten artykuł na linuxquestions.org pomógł mi to zrozumieć.

mhe
źródło
0

dodając do powyższego komentarza, w którym ludzie sugerują przycinanie systemu, takiego jak wyczyszczenie wiszących woluminów, obrazów, kontenerów wyjściowych itp., Czasami twoja aplikacja staje się winowajcą, generuje zbyt dużo dzienników w krótkim czasie i jeśli używasz pustego woluminu bezpośredniego (woluminy lokalne ) wypełnia partycje / var. W takim przypadku znalazłem poniższe polecenie bardzo interesujące, aby dowiedzieć się, co zajmuje miejsce na dysku z partycją / var.

du -ahx / var / lib | sort -rh | głowa -n 30

To polecenie wyświetli listę 30 najlepszych, które zajmują najwięcej miejsca na jednym dysku. Oznacza to, że jeśli korzystasz z zewnętrznej pamięci masowej ze swoimi kontenerami, wykonanie polecenia du zajmuje dużo czasu. To polecenie nie liczy woluminów zamontowanych. I jest dużo szybszy. Otrzymasz dokładne katalogi / pliki, które zajmują miejsce. Następnie możesz przejść do tych katalogów i sprawdzić, które pliki są przydatne, a które nie. jeśli te pliki są wymagane, możesz przenieść je do jakiegoś trwałego magazynu, wprowadzając zmianę w aplikacji, aby używać trwałego magazynu dla tej lokalizacji lub zmienić lokalizację tych plików. A do odpoczynku możesz je wyczyścić.

Amit Bondwal
źródło
0

Możesz wyczyścić folder nakładki Dockera bez wpływu na instalacje Dockera za pomocą poniższych poleceń.

sudo systemctl stop docker
sudo rm -r /var/lib/docker/overlay2
sudo mkdir /var/lib/docker/overlay2
sudo systemctl start docker
SaiPawan
źródło
-5

Użyłem "docker system prune -a", które wyczyściło wszystkie pliki w woluminach i 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 ..
user1681424
źródło
3
To polecenie nie daje odpowiedzi na pytanie. Proponowane polecenie jest nawet zapisane w tekście pytania ..
MBT
więc jest to głosowanie negatywne na popiół, ale ta sama dokładna odpowiedź poniżej jest głosowana za 41 razy. Ta strona jest zepsuta.
Adam Zahran