Zeżre każdą ilość dysku, jaką będziemy mieli.

Wpis dedykuję programistom, którzy nie muszą na co dzień ogarniać dockera i problemów bliższych administracji, a czasami walą głową w mur.

Problemacik

Taki mały, maleńki, maciupci można by powiedzieć. Przy próbie wystartowania kontenera ten się zbiesił i stwierdził, że nie ma zamiaru startować, ponieważ nie ma miejsca na dysku. W tym momencie miałem takie małe „kurwa, ale jak to nie ma miejsca”. W dużym uproszczeniu rozbiłem się o klasyczny błąd związany z instalacją dowolnego Linuxa.

Mając do dyspozycji dysk o pojemności 1TB warto podzielić go na mniejsze partycje. Wszystkie tutoriale koncentrują się jednak na podziale pod standardowego użytkownika. W efekcie mamy wydzieloną partycje dla /boot, /, /boot/efi, /var, /home i swap. Wszystkie poza /home są stosunkowo małe. Od 1GB dla partycji /boot i /boot/efi, po 25GB dla / i /var. Ta ostatnia partycja jest kluczowa dla działania dockera, ale o tym za chwilę. Przestrzeń wymiany jest w proporcji 1:1 do RAMu. Katalogi domowe zajmują całą resztę.

Taki układ generalnie działa. Nie będzie się psuł i wynika z doświadczenia pokoleń administratorów. Problemem jest jednak docker.

Źródło

W domyślnej konfiguracji Docker przechowuje wszystkie swoje dane, tzn. obrazy, kontenery, wolumeny itd. w katalogu /var/lib/docker.. Trafia tam wszystko, więc w naturalną koleją rzeczy jest, że katalog ten będzie puchł. Z czasem zbierają się w nim stare obrazy i nieużywane wolumeny. Koniec końców przy 25GB przestrzeni na dysku osiągniemy koniec. Co z tym fantem zrobić?

Quickfix – który nie działa

Po pierwsze dbać o higienę. Regularnie usuwać nieużywane kontenery, obrazy, wolumeny i sieci. Proste polecenie, które pozwala na sprzątniecie wszystkiego:

$ docker volume prune;  docker system prune; docker image prune; docker container prune; docker network prune
WARNING! This will remove all local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all dangling images
  - all dangling build cache

Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
WARNING! This will remove all custom networks not used by at least one container.
Are you sure you want to continue? [y/N] y

Tylko że jest jeden mały problem. Nie odzyskaliśmy miejsca. Oczywiście przy odrobinie szczęścia uda Ci się odzyskać 1-2GB. Jednak to jest quickfix, który rzadko działa, a w dodatku, o ile zadziała, to niewiele daje. Jeszcze gorzej będzie jeżeli symbolicznie zalinkujesz wyżej wymieniony folder do miejsca, w którym jest dużo miejsca. Tu mogą zacząć się dziać naprawdę dziwne rzeczy.

Podejście prawidłowe

Prawidłowe podejście do rozwiązania tego problemu jest trochę bardziej złożone. Po pierwsze zatrzymaj i usuń wszystkie kontenery. Nie ma co płakać nad danymi. Co najwyżej potrenujesz przywracanie backupów. Następnie utwórz plik /etc/docker/daemon.json, w którym umieścisz następujący wpis:

{
   "data-root": "DOCELOWA ŚCIEŻKA"
}

Zrestartuj dockera:

$ sudo systemctl restart docker.socket 
$ sudo systemctl restart docker

I teraz ważna uwaga. Usługa docker.socket zarządza całym tym dockerowym burdelem i to właśnie na niej operujemy w pierwszej kolejności. Inaczej zaczną się pojawiał jakieś głupie błędy związane z zależnościami pomiędzy usługami.

Podsumowanie

Szukam jakiegoś dobrego dysku na m.2 PCIE co najmniej 6TB pojemności. Potrzebuję dwie sztuki.