Błąd dokera: brak miejsca na urządzeniu

Zainstalowałem dokera na maszynie Debian 7 w następujący sposób

$ echo deb http://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list
$ sudo apt-get update
$ curl -sSL https://get.docker.com/ubuntu/ | sudo sh

Po tym, jak po raz pierwszy spróbowałem utworzyć obraz, wystąpił błąd z następującym błędem

 time="2015-06-02T14:26:37-04:00" level=info msg="[8] System error: write /sys/fs/cgroup/docker/01f5670fbee1f6687f58f3a943b1e1bdaec2630197fa4da1b19cc3db7e3d3883/cgroup.procs: no space left on device"

Oto informacje o dokerze

Containers: 2
Images: 21
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 25
Dirperm1 Supported: true
Execution Driver: native-0.2
Kernel Version: 3.16.0-0.bpo.4-amd64
Operating System: Debian GNU/Linux 7 (wheezy)
CPUs: 2
 Total Memory: 15.7 GiB


WARNING: No memory limit support
 WARNING: No swap limit support

Jak mogę zwiększyć pamięć? Gdzie są przechowywane konfiguracje systemu?

Z sugestii Kal:

Kiedy pozbyłem się wszystkich obrazów i kontenerów, zwolniło to trochę miejsca, a kompilacja obrazu działała dłużej, zanim zakończyła się tym samym błędem. Pytanie brzmi: do której przestrzeni to odnosi się i jak ją skonfigurować?

Miałem ten sam błąd i rozwiązałem go w ten sposób:

1. Usuń osierocone woluminy w Dockerze, możesz użyć wbudowanego polecenia woluminu dokera. Wbudowane polecenie usuwa również każdy katalog w / var / lib / docker / woluminach, który nie jest woluminem, więc upewnij się, że nie wstawiłeś tam niczego, co chcesz zapisać.

Ostrzeżenie, bądź bardzo ostrożny, jeśli masz jakieś dane, które chcesz zachować

Sprzątać:

$ docker volume rm $(docker volume ls -qf dangling=true)

Dodatkowe polecenia:

Lista wiszących woluminów:

$ docker volume ls -qf dangling=true

Wyświetl wszystkie tomy:

$ docker volume ls

2) Rozważ również usunięcie wszystkich nieużywanych obrazów.

Najpierw pozbądź się <none>obrazów (czasami są one generowane podczas budowania obrazu i jeśli z jakiegoś powodu tworzenie obrazu zostało przerwane, pozostają tam).

oto fajny skrypt, którego używam do ich usunięcia

docker rmi $(docker images | grep '^<none>' | awk '{print $3}')

Następnie, jeśli używasz Docker Compose do tworzenia obrazów lokalnie dla każdego projektu. Skończysz z wieloma obrazami zwykle o nazwie tak jak twój folder (na przykład jeśli folder projektu o nazwie Witaj, znajdziesz nazwę zdjęć Hello_blablabla). więc rozważ również usunięcie wszystkich tych obrazów

możesz edytować powyższy skrypt, aby je usunąć lub usunąć ręcznie za pomocą

docker rmi {image-name}

AKTUALIZACJA
Poniższe polecenia stały się hackami, gdy Docker stał się bardziej rozwinięty. Obecna najlepsza praktyka to

docker system prune

Spowoduje to usunięcie:

- all stopped containers
- all volumes not used by at least one container
- all networks not used by at least one container
- all dangling images

Jak poniżej, to jest nuklearne.

Aby wyczyścić system, najpierw usuń pojemniki

$ docker rm $(docker ps -aq)

następnie usuń obrazy

$ docker rmi $(docker images -q)

Jest to oczywiście kwestia nuklearna i usunie wszystkie pojemniki i wszystkie obrazy. Możesz je usunąć pojedynczo za pomocą docker rm #CONTAINER_ID#i docker rmi #IMAGE_ID.

Sprawdź, czy masz wolne miejsce w / var, ponieważ Docker domyślnie przechowuje pliki obrazów (w / var / lib / docker).

Najpierw posprzątaj rzeczy za pomocą, docker ps -aaby wyświetlić listę wszystkich pojemników (w tym zatrzymanych) i docker rmusunąć je; następnie użyj, docker imagesaby wyświetlić listę wszystkich zapisanych obrazów i docker rmije usunąć.

Następnie zmień miejsce przechowywania za pomocą opcji -g na demonie dokera lub edytując /etc/default/dockeri dodając -gopcję do DOCKER_OPTS. -gokreśla lokalizację „środowiska wykonawczego Docker”, które jest w zasadzie wszystkim, co Docker tworzy podczas budowania obrazów i uruchamiania kontenerów. Wybierz lokalizację z dużą ilością miejsca, ponieważ używane miejsce na dysku będzie z czasem rosło. Jeśli edytujesz /etc/default/docker, musisz ponownie uruchomić demona dokera, aby zmiana zaczęła obowiązywać.

Teraz powinieneś być w stanie utworzyć nowy obraz (lub pobrać go z Docker Hub) i powinieneś zobaczyć kilka plików tworzonych w katalogu określonym opcją -g.

Jak już wspomniano

docker system prune

pomaga, ale z Dockerem 17.06.1 i nowszymi bez przycinania nieużywanych woluminów. Od wersji Docker 17.06.1 następujące polecenie również przycina woluminy:

docker system prune --volumes

Z dokumentacji Docker: https://docs.docker.com/config/pruning/

Polecenie przycinania systemu dokowania to skrót, który przycina obrazy, kontenery i sieci. W Docker 17.06.0 i wcześniejszych woluminy są również przycinane. W Docker 17.06.1 i nowszych wersjach należy określić flagę --volumes dla systemu dokowania przycinaj woluminy.

Jeśli chcesz przyciąć woluminy i zachować obrazy i kontenery:

docker volume prune

Jeśli jest to tylko instalacja testowa Dockera (tj. Nieprodukcyjna), a nie obchodzi Cię czyszczenie nuklearne, możesz:

wyczyść wszystkie pojemniki: docker ps -a | sed '1 d' | awk '{print $1}' | xargs -L1 docker rm

wyczyść wszystkie obrazy: docker images -a | sed '1 d' | awk '{print $3}' | xargs -L1 docker rmi -f

Ponownie używam tego w moich instancjach ec2 podczas opracowywania Dockera, a nie na poważnej kontroli jakości lub ścieżce produkcyjnej. Wspaniałą rzeczą jest to, że jeśli masz plik (i) Docker, łatwo go odbudować i lub docker pull.

aby usunąć wszystkie nieużywane kontenery, woluminy, sieci i obrazy jednocześnie ( https://docs.docker.com/engine/reference/commandline/system_prune/#related-commands ):

docker system prune -a -f --volumes

jeśli to nie wystarczy, najpierw można usunąć działające kontenery:

docker rm -f $(docker ps -a -q)
docker system prune -a -f --volumes

zwiększenie / var / lib / docker lub użycie innej lokalizacji z większą ilością miejsca jest również dobrą alternatywą, aby pozbyć się tego błędu (zobacz Jak zmienić katalog instalacyjny obrazu dokera? )

Docker na komputery Mac

Tak docker system prunei docker system prune --volumeszasugerowałem w innych odpowiedziach za każdym razem zwalniając trochę miejsca, ale ostatecznie za każdym razem, gdy coś uruchomiłem, pojawiał się błąd.

Tym, co faktycznie rozwiązało problem z rootem, było usunięcie Docker.rawpliku, którego Docker dla komputerów Mac używa do przechowywania, i zrestartowanie go.

Aby znaleźć ten plik, otwórz Docker na Maca i przejdź do *

Preferences > Resources > Advanced > Disk Image Location

* dotyczy to wersji 2.2.0.5, ale w starszych wersjach powinno być podobnie

W nowszych wersjach Docker na komputery Mac ** pokazuje rzeczywisty rozmiar tego pliku na dysku w interfejsie użytkownika, a także jego maksymalny przydzielony rozmiar. Prawdopodobnie zobaczysz, że jest ogromny. Na przykład na moim komputerze było to 41 GB !

** W starszych wersjach nie pokazuje rzeczywistego użycia dysku w interfejsie użytkownika, a MacOS Finder zawsze pokazuje rozmiar pliku jako maksymalny przydzielony rozmiar. Możesz sprawdzić rzeczywisty rozmiar na dysku, otwierając katalog w terminalu i uruchamiającdu -h Docker.raw

Usunąłem Docker.raw, ponownie uruchomiłem Docker na Maca, a plik został automatycznie utworzony ponownie i wrócił do 0 GB .

Wszystko działało tak jak wcześniej , choć oczywiście straciłem pamięć podręczną Dockera. Zgodnie z oczekiwaniami, po uruchomieniu kilku poleceń Dockera plik zaczął się ponownie wypełniać kilkoma GB rzeczy, ale nigdzie blisko 41 GB .

Aktualizacja

_{Kilka miesięcy później mój Docker.rawznów się napełnił do podobnego rozmiaru. Ta metoda zadziałała, ale musi się powtarzać co kilka miesięcy. Dla mnie to w porządku.}

_{Uwaga na temat tego, dlaczego to działa - muszę założyć, że jest to błąd w Docker na Maca. Wygląda na to, że powinien docker system prune/ docker system prune --volumespowinien całkowicie wyczyścić zawartość tego pliku, ale wygląda na to, że plik gromadzi inne rzeczy, których nie można usunąć za pomocą tych poleceń. W każdym razie usunięcie go ręcznie rozwiązuje problem!}

Docker pozostawia wiszące wokół zdjęcia, które mogą zająć miejsce. Aby wyczyścić po Docker, uruchom następujące czynności:

docker image prune [-af if you want to force remove all images]

lub ze starszymi wersjami Dockera:

docker rm $(docker ps -q -f 'status=exited')
docker rmi $(docker images -q -f "dangling=true")

Spowoduje to usunięcie opuszczonych i wiszących obrazów, co, miejmy nadzieję, wyczyści przestrzeń urządzenia.

1. Wyczyść zwisające obrazy docker rmi $(docker images -f "dangling=true" -q)
2. Usuń niechciane woluminy
3. Usuń nieużywane obrazy
4. Usuń nieużywane pojemniki

możesz także użyć:

docker system prune

lub tylko dla tomów:

docker volume prune

W moim przypadku instalacja Ubuntu-server 18.04.1 [z jakiegoś dziwnego powodu] stworzyła wolumin logiczny LVM o wielkości zaledwie 4 GB zamiast 750 GB. Dlatego podczas ciągnięcia obrazów pojawia się błąd „brak miejsca na urządzeniu”. Poprawka jest prosta:

lvextend -l 100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

Ten problem również napotkałem na maszynie RHEL. Nigdzie nie znalazłem żadnego rozwiązania apt na przepełnieniu stosu i społeczności dokerów-hubów. Jeśli napotykasz ten problem, nawet po wykonaniu poniższego polecenia:

przycinanie systemu dokerów - wszystkie

Rozwiązanie, które w końcu zadziałało:

1. informacje o dokerze
   • Aby sprawdzić bieżący sterownik magazynu dokerów
   • Mój był: Storage Driver: devicemapper; Jeśli masz sterownik pamięci jako nakładkę2, nie musisz się martwić. Rozwiązanie będzie nadal działać dla Ciebie.
2. df -h
   • Ma to na celu sprawdzenie dostępnych systemów plików na komputerze i ścieżki, w której są zamontowane. Dwie zamontowane ścieżki do notatki:
   • / dev / mapper / rootvg-var 7.6G 1.2G 6.1G 16% / var
   • / dev / mapper / rootvg-apps 60G 9.2G 48G 17% / apps
   • Uwaga - Domyślnie ścieżka pamięci dokera to / var / lib / docker. Ma dostępną przestrzeń ~ 6 GB, a zatem wszystkie problemy związane z przestrzenią. Zasadniczo muszę przenieść pamięć domyślną do innej pamięci, w której jest więcej dostępnego miejsca. Dla mnie jest to ścieżka do pliku „/ dev / mapper / rootvg-apps”, która jest zamontowana na / apps. Teraz zadaniem jest przeniesienie / var / lib / docker do czegoś takiego jak / apps / newdocker / docker.
3. mkdir / apps / newdocker / docker
4. chmod -R 777 / apps / newdocker / docker
5. Zaktualizuj plik docker.serive w systemie Linux, który znajduje się w katalogu: / usr / lib / systemd / system
   • vi /usr/lib/systemd/system/docker.service
6. jeśli urządzenie pamięci jest devicemapper, skomentuj istniejącą linię ExecStart i dodaj poniżej w [Service]:
   • ExecStart =
   • ExecStart = / usr / bin / dockerd -s devicemapper --storage-opt dm.fs = xfs --storage-opt dm.basesize = 40 GB -g / apps / newdocker / docker --exec-opt native.cgroupdriver = cgroupfs
7. Lub jeśli urządzenie pamięci masowej jest nałożone2:
   • po prostu dodaj -g / apps / newdocker / docker do istniejącej instrukcji ExexStart.
   • Coś w stylu ExecStart = / usr / bin / dockerd -g / apps / newdocker / docker -H fd: // --containerd = / run / containerd / containerd.sock
8. rm -rf / var / lib / docker (Usunie wszystkie istniejące dane dokera)
9. doker systemctl stop
10. ps aux | grep -i docker | grep -v grep
    • Jeśli powyższe polecenie nie wygenerowało danych wyjściowych, załaduj ponownie demona systemd, wykonując poniższe polecenie.
11. systemctl daemon-reload
12. systemctl start docker
13. informacje o dokerze
    • Sprawdź dostępną przestrzeń danych: 62,15 GB po moutowaniu do dokera do nowego systemu plików.
14. GOTOWY

Wyczyść Docker za pomocą następującego polecenia:

docker images --no-trunc | grep '<none>' | awk '{ print $3 }' \
| xargs docker rmi

Twoje grupy mają cpusetwłączony kontroler. Ten kontroler jest najbardziej użyteczny w środowisku NUMA, gdzie pozwala dokładnie określić, który procesor / bank pamięci mogą być uruchamiane twoje zadania.

Domyślnie obowiązkowe cpuset.memsi cpuset.cpusnie są ustawione, co oznacza, że ​​„nie ma już miejsca” na twoje zadanie, stąd błąd.

Najłatwiejszym sposobem, aby to naprawić, jest włączenie cgroup.clone_children1 w głównej grupie cg. W twoim przypadku tak powinno być

echo 1 > /sys/fs/cgroup/docker/cgroup.clone_children

Zasadniczo poinstruuje system, aby automatycznie inicjował kontener cpuset.memsi cpuset.cpusod jego nadrzędnej grupy.

Jeśli używasz obrazu boot2docker za pośrednictwem Docker Toolkit, problem wynika z faktu, że na maszynie wirtualnej boot2docker zabrakło miejsca.

Po wykonaniu docker importlub dodaniu nowego obrazu obraz zostanie skopiowany do tego, /mnt/sda1który mógł być pełny.

Jednym ze sposobów sprawdzenia, ile miejsca masz na obrazie, jest ssh do vm i uruchomienie df -hi sprawdzenie pozostałej przestrzeni w / mnt / sda1

Komenda ssh to docker-machine ssh default

Gdy masz pewność, że rzeczywiście jest to problem z miejscem, możesz albo wyczyścić zgodnie z instrukcjami w niektórych odpowiedziach na to pytanie, albo możesz zmienić rozmiar samego obrazu boot2docker, zwiększając przestrzeń na /mnt/sda1

Możesz wykonać instrukcje tutaj, aby zmienić rozmiar obrazu https://gist.github.com/joost/a7cfa7b741d9d39c1307

Jeśli używasz Docker Desktop, możesz zwiększyć rozmiar obrazu dysku w Ustawieniach zaawansowanych , przechodząc do Preferencji Dockera .

Oto zrzut ekranu z systemu macOS:

Może to być spowodowane domyślnym miejscem do przechowywania ustawionym na 40 GB (domyślna ścieżka, / var / lib / docker)

możesz zmienić wolumin pamięci, aby wskazywał inną ścieżkę

• edytuj plik -> / etc / sysconfig / docker-storage
• aktualizuj poniżej linii (dodaj, jeśli nie istnieje)

DOCKER_STORAGE_OPTIONS = '- sterownik pamięci = nakładka --graph = CUSTOM_PATH'

• Zrestartuj okno dokowane systemctl zatrzymaj okno dokowane systemctl demon-przeładuj systemctl start docker

jeśli uruchomisz informacje o oknie dokowanym (powinien pokazać sterownik pamięci jako nakładkę)

Wydaje się, że może to nastąpić na kilka sposobów. Problemem było to, że obraz dysku dokującego osiągnął maksymalny rozmiar (Docker Whale -> Preferencje -> Dysk, jeśli chcesz zobaczyć, jaki rozmiar jest w OSX).

Przekroczyłem limit i byłem gotowy do startu. Jestem pewien, że oczyszczenie nieużywanych obrazów również by działało.

Uruchamiam poniższe polecenia.

Nie ma potrzeby późniejszej odbudowy zdjęć.

docker rm $(docker ps -qf 'status=exited')
docker rmi $(docker images -qf "dangling=true")
docker volume rm $(docker volume ls -qf dangling=true)

Usuwają one wychodzące / wiszące pojemniki i wiszące woluminy.

Dla mnie docker system prunezałatwił sprawę. Mam Mac OS.

$ docker rm $(docker ps -aq)

To zadziałało dla mnie

docker system prune 

wydaje się być lepszą opcją w najnowszej wersji