Dlaczego obraz Dockera zajmuje moje miejsce na dysku, które nie jest używane przez platformę Docker

Mam konfiguratora docker i użyłem zupełnie innego urządzenia blokowego do przechowywania danych systemowych dockera:

[root@blink1 /]# cat /etc/sysconfig/docker
# /etc/sysconfig/docker

other_args="-H tcp://0.0.0.0:9367 -H unix:///var/run/docker.sock -g /disk1/docker"

Zwróć uwagę, że /disk/1jest to zupełnie inny dysk twardy/dev/xvdi

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.8G  5.1G  2.6G  67% /
devtmpfs        1.9G  108K  1.9G   1% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
/dev/xvdi        20G  5.3G   15G  27% /disk1
/dev/dm-1       9.8G  1.7G  7.6G  18% /disk1/docker/devicemapper/mnt/bb6c540bae25aaf01aedf56ff61ffed8c6ae41aa9bd06122d440c6053e3486bf
/dev/dm-2       9.8G  1.7G  7.7G  18% /disk1/docker/devicemapper/mnt/c85f756c59a5e1d260c3cdb473f3f4d9e55ac568967abe190eeaf9c4087afeac

Problem polega na tym, że kiedy kontynuuję pobieranie obrazów dockera i uruchamiam kontenery dockerowe, wydaje się, że drugi dysk twardy /dev/xvda1również jest zużyty.

Mogę zweryfikować ten problem, usuwając niektóre obrazy dockera. Po usunięciu niektórych obrazów dockera /dev/xvda1ma teraz trochę dodatkowej przestrzeni.

Czy coś mi brakuje?

Moja wersja dockera:

[root@blink1 /]# docker info
Containers: 2
Images: 42
Storage Driver: devicemapper
 Pool Name: docker-202:1-275421-pool
 Pool Blocksize: 64 Kb
 Data file: /disk1/docker/devicemapper/devicemapper/data
 Metadata file: /disk1/docker/devicemapper/devicemapper/metadata
 Data Space Used: 3054.4 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 4.7 Mb
 Metadata Space Total: 2048.0 Mb
Execution Driver: native-0.2
Kernel Version: 3.14.20-20.44.amzn1.x86_64
Operating System: Amazon Linux AMI 2014.09

Jest to problem z jądrem w devicemapper, który wpływa na rodzinę systemów operacyjnych RedHat (RedHat, Fedora, CentOS i Amazon Linux). Usunięte kontenery nie zwalniają zmapowanego miejsca na dysku. Oznacza to, że w systemach operacyjnych, których dotyczy problem, powoli zabraknie miejsca podczas uruchamiania i ponownego uruchamiania kontenerów.

Projekt Docker jest tego świadomy, a jądro jest podobno naprawione w upstream ( https://github.com/docker/docker/issues/3182 ).

Sposób obejścia tego problemu polega na przydzieleniu Dockerowi własnego woluminu do zapisu ( „Gdy Docker zajmie miejsce na dysku” ). To w rzeczywistości nie powstrzymuje go przed zjadaniem miejsca, po prostu przed zniszczeniem innych części twojego systemu po tym.

Moim rozwiązaniem było odinstalowanie Dockera, usunięcie wszystkich jego plików, a następnie ponowna instalacja:

sudo yum remove docker
sudo rm -rf /var/lib/docker
sudo yum install docker

To zwróciło moją przestrzeń, ale niewiele różni się od zwykłego uruchomienia instancji zastępczej. Nie znalazłem ładniejszego rozwiązania.

Usunięcie całego / var / lib / docker nie jest dla mnie w porządku. Oto bezpieczniejsze sposoby:

Rozwiązanie 1:

Poniższe polecenia z wydania zwalniają dla mnie miejsce i jest to o wiele bezpieczniejsze niż usuwanie / var / lib / docker lub w przypadku systemu Windows sprawdź tutaj lokalizację obrazu dysku .

Przed:

docker info

Przykładowe dane wyjściowe:

Metadata file: 
Data Space Used: 53.38 GB
Data Space Total: 53.39 GB
Data Space Available: 8.389 MB
Metadata Space Used: 6.234 MB
Metadata Space Total: 54.53 MB
Metadata Space Available: 48.29 MB

Polecenie w nowszych wersjach Dockera, np. 17.x +

docker system prune -a

Pokaże ci ostrzeżenie, że usunie wszystkie zatrzymane kontenery, sieci, obrazy i pamięć podręczną kompilacji. Ogólnie rzecz biorąc, można to bezpiecznie usunąć. (Następnym razem, gdy uruchomisz kontener, może on pobrać z rejestru platformy Docker)

Przykładowe dane wyjściowe:

Total reclaimed space: 1.243GB

Następnie możesz ponownie uruchomić informacje Dockera, aby zobaczyć, co zostało wyczyszczone

docker info

Rozwiązanie 2:

Oprócz tego upewnij się, że Twoje programy w kontenerze Dockera nie zapisują wielu / ogromnych plików w systemie plików.

Sprawdź rozmiar wykorzystania miejsca w uruchomionym procesie docker

docker ps -s #may take minutes to return

lub dla wszystkich kontenerów, nawet opuszczonych

docker ps -as #may take minutes to return

Następnie możesz usunąć obraźliwy kontener / i

docker rm <CONTAINER ID>

Znajdź potencjalnego winowajcę, który może wykorzystywać gigantyczne ilości przestrzeni

docker exec -it <CONTAINER ID> "/bin/sh"
du -h

W moim przypadku program zapisywał gigantyczne pliki tymczasowe.

( Nathaniel Waisbrot wspomniał w zaakceptowanej odpowiedzi na ten problem i otrzymałem kilka informacji z numeru)

LUB

Polecenia w starszych wersjach Dockera, np. 1.13.x (uruchom jako root, a nie sudo):

# Delete 'exited' containers
docker rm -v $(docker ps -a -q -f status=exited)

# Delete 'dangling' images (If there are no images you will get a docker: "rmi" requires a minimum of 1 argument)
docker rmi $(docker images -f "dangling=true" -q)

# Delete 'dangling' volumes (If there are no images you will get a docker: "volume rm" requires a minimum of 1 argument)
docker volume rm $(docker volume ls -qf dangling=true)

Po :

> docker info
Metadata file: 
Data Space Used: 1.43 GB
Data Space Total: 53.39 GB
Data Space Available: 51.96 GB
Metadata Space Used: 577.5 kB
Metadata Space Total: 54.53 MB
Metadata Space Available: 53.95 MB

Przenieś /var/lib/dockerkatalog.

Zakładając, że /datakatalog ma wystarczająco dużo miejsca, jeśli nie, zastąp taki, który ma,

sudo systemctl stop docker

sudo mv /var/lib/docker /data


sudo ln -s /data/docker /var/lib/docker

sudo systemctl start docker

W ten sposób nie musisz ponownie konfigurować dockera.

Miałem ten sam problem. W moim scenariuszu w mojej vboxie kończyło się miejsce. Po dochodzeniu okazało się, że moje lokalne wolumeny Dockera pochłaniały 30 GB. Host Ubuntu 16.04.

Aby dowiedzieć się swojego.

docker system df

TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              3                   0                   1.361GB             1.361GB (100%)
Containers          0                   0                   0B                  0B
Local Volumes       7                   0                   9.413GB             9.413GB (100%)
Build Cache                                                 0B                  0B



docker system prune --volumes


  WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all volumes not used by at least one container
        - all dangling images
        - all build cache
Are you sure you want to continue? [y/N]

Zwalnia to miejsce na dysku z nieużywanych woluminów lokalnych. W moim scenariuszu zwolniono 20 GB przestrzeni dyskowej. Upewnij się, że kontenery, które chcesz zachować, są uruchomione, zanim to zrobisz, jeśli chcesz je zachować, ponieważ spowoduje to usunięcie wszystkich zatrzymanych kontenerów.

Miałem podobny problem i myślę, że dzieje się tak, gdy na dysku nie ma wystarczającej ilości miejsca na wszystkie obrazy dockera. Miałem zarezerwowane 6 GB na obrazy dockera, co w moim przypadku okazało się niewystarczające. W każdym razie usunąłem wszystkie obrazy i pojemniki, a dysk nadal wyglądał na pełny. Większość miejsca zajmowały / var / lib / docker / devicemapper i / var / lib / docker / tmp.

To polecenie nie działa dla mnie:

# docker ps -qa | xargs docker inspect --format='{{ .State.Pid }}' | xargs -IZ fstrim /proc/Z/root/

Najpierw zatrzymałem usługę dockera:

sudo service docker stop

Następnie usunąłem / var / lib / docker:

Potem zrobiłem to, co ktoś zasugerował tutaj w https://github.com/docker/docker/issues/18867#issuecomment-232301073

• Usuń istniejące wystąpienie metadanych dockera rm -rf / var / lib / docker

  sudo rm -rf / var / lib / docker

• Przekaż następujące opcje do demona Dockera: -s devicemapper --storage-opt dm.fs = xfs --storage-opt dm.mountopt = discard

• Uruchom demona Dockera.

Na ostatnie dwa kroki biegnę:

sudo dockerd -s devicemapper --storage-opt dm.fs=xfs --storage-opt dm.mountopt=discard

Docker prune domyślnie nie usuwa woluminów,

możesz spróbować czegoś takiego

docker volume prune -f

Jak wspomniano w numerze 18867 - Usunięcie danych w kontenerze devicemapper nie może zwolnić zajętego miejsca z Github.com

Spróbuj uruchomić poniższe polecenie:

# docker ps -qa | xargs docker inspect --format='{{ .State.Pid }}' | xargs -IZ fstrim /proc/Z/root/

Używa tego fstrimnarzędzia do przycinania cienko alokowanego dysku devicemapper.

może możesz spróbować docker system pruneusunąć wszystkie obrazy, które nie są ważne

Dla tych, którzy napotkali ten problem w systemie MacOS, rozwiązaniem, które zadziałało, było poszukanie pliku Docker.raw, który jest tym, którego Docker używa do zarezerwowania miejsca logicznego na hoście, a następnie usunięcia. Jeśli masz Docker Desktop, możesz:

Preferences -> Resources -> Advanceda następnie spójrz pod Disk image locationzakładką.

Przejdź do tego folderu w terminalu i po prostu usuń Docker.rawplik ( $ rm -rf Docker.raw)

Ważna uwaga : zrób to tylko wtedy, gdy nie potrzebujesz żadnych istniejących obrazów ani woluminów.

Tak, Docker używa folderu / var / lib / docker do przechowywania warstw. Istnieją sposoby na odzyskanie miejsca i przeniesienie magazynu do innego katalogu.

Możesz zamontować większą przestrzeń dyskową i przenieść zawartość / var / lib / docker do nowej lokalizacji montowania i utworzyć dowiązanie symboliczne.

Istnieje szczegółowe wyjaśnienie, jak wykonać powyższe zadanie.

http://www.scmtechblog.net/2016/06/clean-up-docker-images-from-local-to.html

Możesz również usunąć warstwy pośrednie.

https://github.com/vishalvsh1/docker-image-cleanup