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 -a
już 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.
docker
docker-compose
docker-machine
qichao_he
źródło
źródło
docker image prune --all
i wtedydocker 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. Aledocker system prune -a
wystarczyłoby. Również moi specyfika konfiguracji to:OS: Ubuntu 20
,Docker : 19.03.12
Odpowiedzi:
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.źródło
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 plikudocker 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ą/var/lib/docker
a nie pojedynczy podkatalog, który pozostawiłby go w niespójnym stanie.Uważam, że to działa najlepiej dla mnie:
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.źródło
docker system df
przedsięwzięć (być może jeszcze z miejsca i że złooverlay2
potrzeb wysypisko śmieci mają być nuked ręcznie.Miałem ten problem ... To był kłód, który był ogromny. Dzienniki są tutaj:
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:
źródło
overlay2
. W moim przypadku, całkowita pojemność/var/lib/docker
to 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
).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
overlay2
i badając.ten folder zawiera inne foldery o nazwie hash. każdy z nich ma kilka folderów, w tym
diff
folder.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/tmp
odkryłem, że/tmp
w moim kontenerze znajduje się folder, który zostaje zanieczyszczony .aby obejść ten problem, użyłem
-v /tmp/container-data/tmp:/tmp
parametrudocker run
polecenia do mapowania/tmp
folderu 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:
overlay2
to 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.źródło
/var/log/apache2/error.log
. Zresetowałem error.log i access.log i dodałem nowy wolumin, abyBackgroud
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/tmp
podfolderu dockeraoverlay2
Ponieważ wszystkie te podfoldery
/diff/tmp
był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 zdiff/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):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 prune
polecenie 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
źródło
OSTRZEŻENIE: NIE UŻYWAĆ W SYSTEMIE PRODUKCYJNYM
Ok, najpierw spróbujmy przycinać system
Nie tak świetnie, wygląda na to, że wyczyścił kilka megabajtów. Zaszalejmy teraz:
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.
źródło
/var/lib/docker
katalogu (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/docker
razie potrzeby ponownie inicjuje katalog.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/overlay
Folderu 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/overlay
folderu. Potem moja instancja dockera stała się nieużyteczna. Kiedy próbowałem uruchomić lub zbudować dowolny kontener, dał mi ten błąd: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)
Dlatego nie zaleca się robienia takich brudnych porządków, chyba że całkowicie rozumiesz, jak działa system.
źródło
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:
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/sh
i usuń niektóre pliki.Możesz również
docker system prune -a -f
wykonać 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.źródło
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,
du
ale 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ć.
źródło
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ć.
źródło
Możesz wyczyścić folder nakładki Dockera bez wpływu na instalacje Dockera za pomocą poniższych poleceń.
źródło
Użyłem "docker system prune -a", które wyczyściło wszystkie pliki w woluminach i overlay2
źródło