Co powoduje, że kontener zapełnia dysk systemowy, gdy jego dane znajdują się gdzie indziej?

Kontener może zapełnić dysk systemowy, gdy logi, pamięci podręczne, pliki tymczasowe lub przypadkowo zapisane dane pozostają w lokalnej pamięci Dockera.

Przeniesienie biblioteki multimediów lub woluminu bazy danych do innej puli nie przenosi obrazu kontenera, warstwy zapisywalnej, dziennika JSON, pamięci podręcznej BuildKit, metadanych ani żadnej ścieżki pominiętej na liście montowania. Nieudane montowanie zewnętrznego zasobu może również pozostawić oczekiwany katalog hosta pusty, powodując zapis nowych danych na dysku systemowym bez wyraźnego błędu.

Zmierz katalog główny Dockera przed sprawdzeniem danych aplikacji

Sprawdź system plików zawierający katalog główny danych Dockera i porównaj rozmiary katalogów hosta z informacjami o wykorzystaniu obrazów, kontenerów, woluminów i pamięci podręcznej kompilacji przez Dockera. Zapisz stan wykorzystania przed usunięciem czegokolwiek.

Użytkownik Cloudron odkrył, że /var/lib/docker/overlay2 zajmował więcej miejsca niż wszystkie widoczne dane aplikacji, co pokazuje, dlaczego katalog główny pamięci Dockera należy mierzyć niezależnie od zewnętrznych bibliotek.

Jeśli dysk systemowy jest pełny, ale na zewnętrznej puli jest wolne miejsce, ustal, czy przyrost znajduje się w kontenerach, warstwach overlay, woluminach, obrazach czy pamięci podręcznej kompilacji. Nie uruchamiaj ogólnego czyszczenia, dopóki aktywne i możliwe do odzyskania dane nie zostaną sklasyfikowane.

Sprawdź, czy dzienniki JSON kontenerów nie rosną bez ograniczeń

Sprawdź sterownik logów oraz rozmiar pliku dziennika każdego kontenera. Usługa może przechowywać główne dane w innym miejscu, podczas gdy komunikaty stdout i stderr będą bez końca rosnąć w lokalnym katalogu kontenerów Dockera.

Code Maven opisuje przypadek, w którym docker system df nie ujawniło głównego problemu, ponieważ domyślny plik dziennika stale rósł poza zakresem tego podsumowania. Ukrytym źródłem problemu był stale rosnący dziennik kontenera.

Znajdź i napraw błąd głośnej aplikacji, zanim obrócisz lub skrócisz dzienniki. Skonfiguruj ograniczoną rotację dzienników dla przyszłych kontenerów i sprawdź, czy nowe pliki przestają rosnąć po osiągnięciu oczekiwanego limitu.

Znajdź dane zapisane w zapisywalnej warstwie kontenera

Porównaj zamierzone ścieżki trwałego przechowywania z rzeczywistymi katalogami pamięci podręcznej, transkodowania, pobierania, bazy danych, miniatur, kopii zapasowych i plików tymczasowych używanymi przez aplikację. Każdy niezmontowany zapis pozostaje w zapisywalnej warstwie kontenera na dysku systemowym.

Wyjaśnienie na forum Dockera wskazuje, że zapisy i zmienione pliki obrazu są przechowywane w zapisywalnej warstwie, a duże, nieobracane dzienniki znajdują się w metadanych kontenera. Oba te elementy mogą sprawić, że jeden kontener zużyje niemal całe lokalne miejsce mimo zewnętrznego woluminu danych.

Użyj raportowania rozmiaru poszczególnych kontenerów i sprawdź największe zmienione ścieżki wewnątrz kontenera. Dodaj jawne montowania bind lub nazwane woluminy tylko dla danych, które muszą być trwałe, a następnie odtwórz kontener, aby usunąć nieaktualną zawartość zapisywalnej warstwy po wykonaniu kopii zapasowej wszystkiego, co wartościowe.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Zweryfikuj, czy zewnętrzne montowanie było aktywne podczas uruchamiania kontenera

Sprawdź, czy dysk SSD, udział NAS lub pula pamięci masowej były zamontowane w oczekiwanej ścieżce hosta przed uruchomieniem kontenera przez Dockera. Porównaj tożsamość urządzenia i wynik montowania z katalogiem widzianym przez kontener.

Gdy zewnętrzne montowanie jest nieaktywne, podstawowy pusty katalog w systemie plików systemu może nadal istnieć. Kontener może normalnie zapisywać dane w tym katalogu awaryjnym, powodując wzrost zajętości dysku systemowego, podczas gdy zewnętrzna pula pozostaje nietknięta.

Zatrzymaj kontener przed ponownym zamontowaniem pamięci masowej w miejscu zawierającym dane zapisane w katalogu awaryjnym. Bezpiecznie przenieś lub uzgodnij ukryte pliki, dodaj zależności montowania lub kontrole uruchamiania i blokuj start aplikacji, gdy oczekiwane urządzenie jest niedostępne.

Sprawdź warstwy obrazów, pamięć podręczną kompilacji i porzucone obiekty

Przejrzyj nieużywane obrazy, zatrzymane kontenery, anonimowe woluminy i pamięć podręczną BuildKit. Częste aktualizacje lub lokalne kompilacje mogą gromadzić wiele warstw, nawet gdy trwałe dane aplikacji są prawidłowo zamontowane w innym miejscu.

Wyjaśnienie na forum projektu Moby wskazuje, że montowania overlay mogą utrudniać interpretację informacji o zajętości dysku i że wykorzystanie bazowego systemu plików należy analizować ostrożnie. W osobnym przypadku dotyczącym Home Assistant również zaobserwowano z czasem wzrost overlay2 spowodowany logami i warstwami.

Usuwaj wyłącznie obiekty potwierdzone jako nieużywane przez bieżące projekty Compose i kopie zapasowe. Nigdy nie usuwaj ręcznie pojedynczych katalogów overlay2, ponieważ odwołania w metadanych Dockera mogą stać się niespójne.

Potwierdź rozwiązanie za pomocą pomiarów wzrostu

Po skorygowaniu odpowiedzialnej ścieżki zapisuj w regularnych odstępach wykorzystanie katalogu głównego Dockera, rozmiary dzienników, rozmiary zapisywalnych warstw kontenerów oraz wykorzystanie zewnętrznej puli podczas obciążenia, które wcześniej powodowało wzrost.

Procedura ZimaSpace dotycząca przygotowania dużego transferu do serwera NAS zapewnia powtarzalne obciążenie umożliwiające potwierdzenie, że dane trafiają do właściwej puli.

Problem jest rozwiązany dopiero wtedy, gdy wzrost zajętości dysku systemowego odpowiada oczekiwanemu zachowaniu obrazów i logów, trwałe dane aplikacji rosną na zewnętrznej puli, a brak zewnętrznego montowania powoduje bezpieczne przerwanie uruchamiania zamiast cichych zapisów w głównym systemie plików.