So behebst du den Fehler „Kein Speicherplatz mehr auf dem Gerät” in Docker: Ein kompletter Leitfaden

Der Docker-Fehler „Kein Speicherplatz mehr auf dem Gerät“ kommt meistens genau dann, wenn man ihn am wenigsten gebrauchen kann: mitten in der Bereitstellung, während eines wichtigen Builds oder beim Abrufen eines wichtigen Images. Ich hab diesen Fehler schon ein paar Mal gehabt und kann dir sagen, dass das schnelle Löschen von Dateien ohne richtige Diagnose zu Datenverlust führen kann.

Was diesen Fehler besonders schwierig macht, ist, dass er selten nur eine einzige Ursache hat. Du hast vielleicht mit angesammelten Docker-Images, ausufernden Container-Protokollen, erschöpften Inodes aus Millionen kleiner Dateien oder sogar mit „Phantom“-Speicherplatz zu tun, der von gelöschten Dateien belegt wird, die von laufenden Prozessen noch offen gehalten werden. Jedes Szenario braucht eine andere Lösung.

Deshalb sage ich immer, dass man erst mal die Diagnose stellen sollte, bevor man was unternimmt. Wenn du die Ursache verstehst, kannst du gezielt Lösungen finden und Störungen in deiner Produktionsumgebung vermeiden. In dieser Anleitung zeige ich dir einen systematischen Ansatz zur Diagnose, Behebung und Vermeidung dieses nervigen Problems.

Wenn du noch keine Erfahrung mit Docker hast, empfehle ich dir, unseren praktischen Einführung in Docker zu machen, der alles abdeckt, was du für den Einstieg in die Containerisierung brauchst.

Was ist der Docker-Fehler „Kein Speicherplatz mehr auf dem Gerät“?

Wenn Docker diesen Fehler anzeigt, deutet das auf eines von zwei grundlegenden Problemen mit dem Speicher deines Systems hin:

• Physische Festplattenblöcke sind voll
• Inode-Erschöpfung

Es ist echt wichtig, den Unterschied zwischen diesen Ursachen zu verstehen, um die richtige Lösung zu finden.

Die Hauptgründe für den Fehler „Kein Speicherplatz mehr auf dem Gerät“

Der erste und offensichtlichste Grund ist , dassdie physischen Festplattenblöcke voll sind. Deinem Dateisystem geht der Speicherplatz zum Speichern von Daten aus. Das ist das intuitivere Szenario: Du hast deine Festplatte einfach mit Docker-Images, Containern, Protokollen oder anderen Dateien vollgestopft.

Der zweite, nicht so offensichtliche Grund ist , dassdie Inodes voll sind. Selbst wenn du noch jede Menge Speicherplatz hast, kann dein Dateisystem irgendwann keine Inodes mehr haben (das sind Metadatenstrukturen, die zum Verfolgen von Dateien und Verzeichnissen genutzt werden). Jede Datei und jedes Verzeichnis braucht einen Inode. Also können Programme, die Millionen kleiner Dateien erstellen (wie PHP-Sitzungsdateien oder die Verzeichnisse „ node_modules ” von npm), die Inodes vollmachen, während noch Speicherplatz auf der Festplatte frei ist.

Den Overlay2-Speichertreiber verstehen

Docker nutzt normalerweise den Overlay2-Speichertreiber, der auf Linux OverlayFS basiert. OverlayFS legt mehrere Verzeichnisse auf einem einzigen Host übereinander und zeigt sie als ein einheitliches Dateisystem an. Bildschichten werden als schreibgeschützte untere Verzeichnisse eingebunden, während jeder laufende Container eine dünne beschreibbare obere Schicht hinzufügt. Die zusammengeführte Ansicht wird dem Container als ein einziges Verzeichnis angezeigt.

Der Overlay2-Treiber kann theoretisch bis zu 128 untere OverlayFS-Ebenen nativ unterstützen, aber der Layer-Speicher von Docker begrenzt das auf 125 Basis-Ebenen pro Image. Es macht eine effiziente Bildkomposition möglich und verbessert die Leistung bei Sachen wie „ docker build ” und „ docker commit ”. 

Obwohl Overlay2 so gemacht ist, dass es weniger Inodes verbraucht als frühere Speichertreiber, können Docker-Umgebungen, die immer wieder Images erstellen, Layers abrufen oder Container erstellen, mit der Zeit trotzdem einen erheblichen Druck auf Festplattenblöcke und Inodes ausüben, vor allem wenn Images oder Anwendungsschichten viele kleine Dateien enthalten.

Wie dieser Fehler angezeigt wird, hängt von der Bereitstellungsumgebung ab:

• Auf nativen Linux-Systemen betrifft das das Dateisystem, das /var/lib/docker unterstützt. 

• Bei Docker Desktop für Windows oder macOS gibt's die Einschränkung im Disk-Image der virtuellen Maschine von Docker (wie z. B. einer „ .raw “- oder „ .vhdx “-Datei), was zusätzliche Überlegungen beim Zurückgewinnen oder Anpassen der Speichergröße mit sich bringt.

Schritt 1: Die Ursache finden

Bevor ich irgendwas rausnehme, mach ich immer erst mal eine gründliche Diagnose. Diese Investition von ein paar Minuten kann dir Stunden an Fehlerbehebung sparen und versehentlichen Datenverlust verhindern.

Überprüfe die Kapazität auf Systemebene.

Schau dir erst mal die Festplattennutzung deines Hostsystems mit dem Befehl „ df -H ” an (df steht für „disk free”):

df -H

Kostenlose Festplattenprüfung in WSL

Dieser Befehl zeigt dir die Festplattennutzung in einem leicht verständlichen Format an. Such nach Dateisystemen, die zu 100 % voll sind oder fast voll sind. 

Bei nativen Linux-Installationen solltest du besonders auf die Partition achten, auf der sich „ /var/lib/docker “ befindet. Das ist normalerweise deine Root-Partition (/) oder eine spezielle Docker-Partition. 

Such auf Docker Desktop (Windows/Mac) nach dem Hauptdateisystem-Mount (normalerweise „ /dev/sdf “ oder so ähnlich), wo die Daten der Docker-VM gespeichert sind, statt nach bestimmten „ /var/lib/docker “-Referenzen, weil Docker in einer virtuellen Maschine läuft.

Als Nächstes checkst du, ob die Inodes voll sind, indem du „ df -i “ eingibst:

df -i

Überprüfung auf Inode-Erschöpfung

Wenn du auf einem Dateisystem eine Inode-Auslastung von 100 % siehst (IUse%), hast du dein Problem gefunden. Dieses Szenario kommt überraschend oft auf Build-Servern und in CI/CD-Umgebungen vor, wo Docker immer wieder Container mit vielen kleinen Dateien erstellt und löscht.

Analysiere die Nutzung von Docker

Nachdem wir jetzt wissen, ob es am Speicherplatz oder an den Inodes liegt, schauen wir uns mal genauer an, wie viel Ressourcen Docker verbraucht. Der Befehl „ docker system df “ gibt dir einen guten Überblick, der für alle Docker-Installationen passt:

docker system df

Diese Ausgabe teilt die Speicherplatznutzung in vier Kategorien auf: Bilder, Container, lokale Volumes und Build-Cache.

Die Rubrik „ RECLAIMABLE “ ist echt super. Es zeigt, wie viel Speicherplatz du zurückgewinnen kannst, ohne laufende Container zu beeinträchtigen. Es ist wichtig, den Unterschied zwischen diesen beiden Werten zu verstehen: Der „aktive“ Speicherplatz wird gerade von laufenden Containern genutzt, während der „wiedergewinnbare“ Speicherplatz sicher freigegeben werden kann.

Für genauere Details füge das Flag „verbose“ hinzu:

docker system df -v

Analyse der Docker-Nutzung

Diese ausführliche Ausgabe listet jedes Image, jeden Container und jedes Volume einzeln mit seiner Größe auf und liefert dir so die detaillierte Aufschlüsselung, die du brauchst, um Speicherplatzfresser zu identifizieren. Hier ist, worauf du in jedem Abschnitt achten solltest:

• Bilder: Zeigt die Größe jedes Bildes und ob es gerade benutzt wird. Such nach großen Bildern, die nicht benutzt werden oder mit verschiedenen Tags doppelt vorhanden sind. Bilder, die als „unbenutzt“ markiert sind, kannst du einfach löschen, ohne dass laufende Container davon betroffen sind.

• Container: Zeigt die Größe der beschreibbaren Ebene für jeden Container an. Wenn ein angehaltener Container hier einen hohen Wert für „ SIZE “ hat, hat er Daten in sein Dateisystem geschrieben. Die Rubrik „ CREATED ” hilft dabei, alte Behälter zu finden, die vielleicht vergessen wurden.

• Bände: Zeigt an, wie groß die Volumes sind und ob sie gerade benutzt werden. Bände, die als nicht in Gebrauch markiert sind, können bedenkenlos entfernt werden. Überprüfe aber immer, ob sie keine wichtigen Daten enthalten, bevor du sie löschst.

• Cache erstellen: Oft der größte Verbraucher und trotzdem oft übersehen. Das sind Zwischenschichten von „ docker build “-Operationen, die Docker behält, um spätere Builds schneller zu machen.

Betriebssystemspezifische Befehle

Für Linux-Nutzer, die noch mehr über das Dateisystem wissen wollen, gibt's die Möglichkeit, direkt die Unterverzeichnisse zu checken, um zu sehen, welche davon (overlay2, containers, volumes) am meisten Speicherplatz brauchen:

sudo du -h --max-depth=1 /var/lib/docker | sort -h

Für Leute, die Docker Desktop nutzen, ist /var/lib/docker aber in der versteckten virtuellen Maschine von Docker und nicht direkt erreichbar. Die gute Nachricht ist, dass „ docker system df -v “ alle Infos liefert, die du brauchst, egal welche Plattform du nutzt, und damit der zuverlässigste Diagnoseansatz ist.

Schritt 2: System mit Docker Prune aufräumen 

Nachdem ich rausgefunden habe, wo Speicherplatz verbraucht wird, kann ich ihn mit den integrierten Bereinigungsbefehlen von Docker sicher zurückgewinnen. Diese Vorgänge sind so gemacht, dass nur nicht genutzte Ressourcen entfernt werden, um das Risiko einer Unterbrechung laufender Dienste zu minimieren.

Hängende Ressourcen beschneiden

Docker unterscheidet zwischen „dangling“ und „unused“ Ressourcen. Ein dangling image ist ein Bild ohne Tag und ohne Container-Referenzen. Normalerweise eine Zwischenschicht aus einem Build, der nicht geklappt hat oder ersetzt wurde. Die kann man immer bedenkenlos rausnehmen.

Fang mit dem grundlegenden Befehl „prune“:

docker system prune

Damit werden alle nicht mehr brauchten Container, Netzwerke und hängenden Images gelöscht. Es werden keine markierten Bilder oder Volumes berührt, es sei denn, das wird ausdrücklich angegeben. Docker fragt dich nach einer Bestätigung, bevor es weitermacht.

Um aggressiver vorzugehen und alle ungenutzten Bilder (nicht nur die „dangling images“) zu löschen, füge das Flag „ --all “ hinzu:

docker system prune --all

Docker-System bereinigen

Dieser Befehl löscht alle Images, die gerade nicht mit einem Container verbunden sind. Pass auf: Bei späteren Bereitstellungen musst du die entfernten Images nochmal runterladen.

Wenn du Volumes in die Bereinigung einbeziehen willst (die persistente Daten enthalten), füge das Flag „ --volumes “ hinzu:

docker system prune --all --volumes

Achtung: Das löscht Daten in nicht genutzten Volumes endgültig. Überprüfe immer, ob die Volumes keine wichtigen Daten haben, bevor du dieses Flag benutzt.

Build-Cache verwalten

Jetzt wird's spannend. Der Build-Cache, der Zwischenschichten aus Docker-Build-Operationen speichert, braucht oft am meisten Speicherplatz, aber „ docker system prune ” lässt ihn absichtlich raus, um die Build-Performance zu halten.

Um gezielt auf den Build-Cache zuzugreifen:

docker builder prune

Wenn du selektiv vorgehen und die letzten Cache-Ebenen behalten willst, nimm zeitbasierte Filter:

docker builder prune --filter "until=24h"

Dadurch werden nur Cache-Ebenen gelöscht, die älter als 24 Stunden sind, sodass deine aktuellen Arbeiten erhalten bleiben.

Beseitige Volumes sicher

Bei Volumes muss man besonders vorsichtig sein, weil sie dauerhafte Daten wie Datenbanken, hochgeladene Dateien und den Status von Anwendungen enthalten. Wenn du das falsche Volume löschst, sind deine Daten für immer weg.

Zuerst suchst du nach losen Volumes (die mit keinem Container verbunden sind):

docker volume ls -f dangling=true

Schau dir diese Liste genau an. Wenn du sicher bist, dass diese Volumes nicht gebraucht werden, kannst du sie löschen:

docker volume prune

Docker fragt dich nach Bestätigung, bevor es weitermacht. Wenn du dir nicht sicher bist, mach lieber vorher ein Backup der Volumes, bevor du was löschst.

Schritt 3: Umgang mit dem Auslaufen der Docker-Protokolldatei

Containerprotokolle können unbemerkt riesige Mengen an Speicherplatz verbrauchen, manchmal mehr als 50 GB pro Container.

Identifiziere aufgeblähte Protokolldateien

stderr Der Standard-Logging-Treiber von Docker „ json-file “ speichert alle Container-Informationen und - stdout en in JSON-Dateien. Ohne eine Einstellung für die maximale Größe (Standardwert ist -1, unbegrenzt) werden diese Dateien unbegrenzt groß.

Schau dir die Containergrößen in allen Umgebungen an:

docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Size}}"

So checkst du die Größe der Logdatei eines bestimmten Containers:

ls -lh $(docker inspect --format='{{.LogPath}}' <container-name>)

Nur für native Linux-Systeme: Finde die größten Log-Dateien direkt:

sudo find /var/lib/docker/containers/ -name "*-json.log" -exec du -h {} + | sort -h | tail -10

Wenn „ docker logs “ langsam wird oder Container nicht starten, sind wahrscheinlich zu große Protokolle der Grund dafür. Um das zu regeln, kannst du die Protokolle kürzen.

Protokolle sicher kürzen

Wenn du die Protokolle kürzt, hast du mehr Speicherplatz. Lösch aber niemals Log-Dateien mit „ rm “, wenn Container laufen. Der Docker-Daemon hält offene Datei-Handles zu diesen Protokollen und wenn man sie löscht, entstehen „gelöschte, aber offene“ Dateien, die weiter Speicherplatz belegen, bis der Daemon neu gestartet wird.

Der sichere Weg ist, die Protokolle auf Null zu kürzen:

sudo truncate -s 0 $(docker inspect --format='{{.LogPath}}' <container-name>)

Dadurch wird sofort Speicherplatz freigegeben, ohne dass Datei-Handles kaputtgehen. Der Container schreibt weiter in dieselbe Datei.

Schritt 4: Erweiterte Fehlerbehebung und versteckte Probleme

Wenn die normale Bereinigung nicht klappt, hast du wahrscheinlich mit einem dieser selteneren, aber genauso nervigen Probleme zu tun:

• Inode-Erschöpfung: Dein Dateisystem hat keine Metadatenstrukturen mehr, obwohl du noch freien Speicherplatz hast.

• Gelöschte, aber geöffnete Dateien: Prozesse, die Datei-Handles zu gelöschten Dateien halten und so „Phantom“-Speicherplatz belegen

• Docker Desktop virtuelle Festplatte aufgebläht: Die Host-Datei „ .raw “ oder „ .vhdx “ wird nicht kleiner, nachdem du Daten in der VM gelöscht hast.

Lass uns jedes dieser Szenarien systematisch angehen.

Löse das Problem der Inode-Erschöpfung

Das kann passieren, wenn Apps Millionen kleiner Dateien erstellen, wie PHP-Sessions, npm- node_modules oder Build-Artefakte, die Inodes in alarmierendem Tempo verbrauchen.

Überprüfe zuerst, ob die Inodes voll sind:

df -i

Mit Docker-Befehlen (alle Umgebungen):

docker ps -a | wc -l             # Check container count
docker images | wc -l         # Check image count
docker image prune -a      # Remove unused images to free inodes

Bei Linux-Installationen suchst du Verzeichnisse, die viele Inodes haben:

for dir in /var/lib/docker/*/; do
    echo "$dir: $(sudo find $dir -type f 2>/dev/null | wc -l) files"
done

Das Löschen nicht genutzter Bilder mit „ docker rmi “ schafft auch Speicherplatz auf der Festplatte. Für Probleme auf Anwendungsebene solltest du eine Bereinigung in Containern machen oder Volume-Mounts für temporäre Dateien nutzen.

Lösche Dateien, die geöffnet sind (nur Linux)

Wenn eine Datei gelöscht wird, während sie noch von einem Prozess geöffnet ist, gibt das Dateisystem den Speicherplatz erst frei, wenn der Prozess den Datei-Handle schließt („Phantom“-Speicherplatznutzung).

Linux-Nutzer können überprüfen, ob das passiert, indem sie in der Liste der geöffneten Dateien nach „gelöschten” Einträgen suchen.

Suchen du zuerst diese Dateien:

sudo lsof | grep deleted 

Docker hat Dateien gelöscht

Um Speicherplatz freizugeben, starte den entsprechenden Prozess neu (mit der PID von lsof) oder starte Docker neu. Wenn du das gemacht hast und den Befehl nochmal ausführst, werden die Dateien nicht mehr angezeigt, was bedeutet, dass sie ordnungsgemäß gelöscht wurden.

Schauen wir uns jetzt die letzte fortgeschrittene Strategie zur Fehlerbehebung an, die nur für Docker Desktop gilt: das Verwalten von virtuellen Festplatten.

Verwalten von virtuellen Festplatten in Docker Desktop

Docker Desktop speichert Daten in einer virtuellen Festplattendatei (.raw auf Mac, .vhdx auf Windows), die dynamisch wächst, aber nicht automatisch schrumpft, wenn du Daten löschst. Du verkleinerst Bilder und Container, siehst, wie der freie Speicherplatz in der VM zunimmt, aber deine Host-Festplatte bleibt voll.

Um das hinzukriegen, ist es am sichersten, mit „ fstrim “ die Festplatte zu komprimieren, ohne dass Daten verloren gehen:

docker run --privileged --pid=host alpine nsenter -t 1 -m -u -i -n fstrim /

Dieser Befehl bereinigt das Dateisystem der Docker Desktop-VM und gibt nicht genutzte Blöcke wieder an dein Hostsystem frei. Deine Bilder, Container und Volumes bleiben unangetastet.

Wenn du lieber komplett neu anfangen willst (das löscht alle Daten), kannst du auch Docker Desktop-Einstellungen → Fehlerbehebung → Auf Werkseinstellungen zurücksetzen. 

Achtung: Das ist echt schlimm und löscht alle Bilder, Container, Volumes und Einstellungen. Das sollte nur die letzte Option sein, wenn alles andere nicht klappt.

Auf Werkseinstellungen zurücksetzen

Schritt 5: Verhindere den Docker-Fehler „Kein Speicherplatz mehr auf dem Gerät“

Jetzt, wo wir die akute Krise gemeistert haben, sollten wir strukturelle Änderungen machen, damit so was nicht wieder passiert. Diese Konfigurationen brauchen zwar Planung, bringen aber echt viel für die Stabilität des Systems.

Verschieb das Docker-Stammverzeichnis (nur Linux)

Benutzer von Docker Desktop können den Speicherort des Datenstamms nicht einfach ändern. Stattdessen kannst du:

• Speicherplatz erhöhen: Mach die in Schritt 4 beschriebenen Methoden zur Komprimierung der virtuellen Festplatte.

• Für das WSL2-Backend: Verwalte die Limits über eine „ .wslconfig “-Datei, wie in den Docker Desktop-Einstellungen → Ressourcen gezeigt.

Wenn du aber Linux nutzt und deine Root-Partition knapp ist, du aber eine größere Partition zur Verfügung hast (vielleicht eine eigene Datenfestplatte), ist das Verschieben des Datenverzeichnisses von Docker eine dauerhafte Lösung.

Halt zuerst Docker an:

sudo systemctl stop docker

Bearbeite die Datei „ /etc/docker/daemon.json “, um den neuen Speicherort anzugeben:

{
  "data-root": "/mnt/docker-data"
}

Migriere vorhandene Daten, um deine Bilder und Container zu sichern:

sudo rsync -aP /var/lib/docker/ /mnt/docker-data/

Zum Schluss startest du Docker neu:

sudo systemctl start docker

Docker speichert jetzt alle Daten am neuen Ort. Überprüfe mit „ docker info | grep "Docker Root Dir" “, ob der Pfad zum neuen Verzeichnis stimmt.

Globale Protokollrotation einrichten

Die Protokollrotation ist die effektivste Vorbeugungsmaßnahme, die ich je gemacht habe. Standardmäßig hat der Docker-Treiber „ json-file “ die Option „ max-size: -1 “ (unbegrenzt) aktiviert, was in der Produktion zu Problemen führen kann.

Bei nativen Linux-Installationen musst du die Datei „ /etc/docker/daemon.json “ bearbeiten, um die Beschränkungen global durchzusetzen:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Starte Docker neu, nachdem du die Datei bearbeitet hast.

Als Docker Desktop-Nutzer musst du die Datei „ /etc/docker/daemon.json “ nicht direkt bearbeiten. Stattdessen:

1. Öffne Docker Desktop
2. Geh zu Einstellungen → Docker Engine
3. Du siehst einen JSON-Editor mit der Daemon-Konfiguration.
4. Füge die Einstellungen für die Protokollrotation zum bestehenden JSON hinzu:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Zum Schluss klickst du auf „Übernehmen & neu starten“.

In dieser Beispielkonfiguration wird jeder Container auf drei Logdateien mit jeweils 10 MB begrenzt (insgesamt 30 MB pro Container).

Wichtiger Hinweis: Diese Einstellungen gelten nur für neu erstellte Container. Die vorhandenen Container behalten ihre ursprüngliche Protokollkonfiguration. Du musst die Container neu erstellen, um die neuen Limits anzuwenden.

Für noch bessere Komprimierung und Leistung solltest du den lokalen Protokollierungstreiber in Betracht ziehen:

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  }
}

Außerdem kannst du die Protokolleinstellungen pro Dienst in der Datei „ docker-compose.yml “ überschreiben:

services:
  web:
    image: nginx
    logging:
      driver: "json-file"
      options:
        max-size: "50m"
        max-file: "5"

Wartung automatisieren

Eine andere gute Idee ist, bestimmte Abläufe zu automatisieren. Man sagt oft, dass Vorbeugen besser ist als Krisenmanagement. Deshalb schlage ich vor, die Bereinigung mit einem Cron-Job zu automatisieren, der während der Wartungsfenster läuft:

# Create a cleanup script
sudo cat > /usr/local/bin/docker-cleanup.sh << 'EOF'
#!/bin/bash
docker system prune -f
docker builder prune -f --filter "until=168h"
EOF

sudo chmod +x /usr/local/bin/docker-cleanup.sh

# Add to crontab to run weekly on Sundays at 2 AM
echo "0 2 * * 0 /usr/local/bin/docker-cleanup.sh" | sudo crontab -

Dieses Skript macht eine geplante Aufgabe, die jeden Sonntag um 2 Uhr morgens automatisch gestoppte Container und nicht genutzte Daten löscht. Außerdem werden Cache-Schichten, die älter als eine Woche (168 Stunden) sind, sicher gelöscht, damit der Speicherplatz nicht endlos voll wird.

Optimier deine Dockerfiles zusätzlich mit mehrstufigen Builds, um die Image-Größen zu minimieren. Mit mehrstufigen Builds kannst du eine Stufe zum Kompilieren und Erstellen (mit allen umfangreichen Entwicklungstools) nutzen und dann nur die endgültigen Artefakte in eine saubere, minimale Produktionsstufe kopieren. 

Dadurch werden Build-Abhängigkeiten, Quellcode und Zwischendateien aus deinem endgültigen Image entfernt, was die Größe und Angriffsfläche drastisch reduziert.

# Build stage
FROM node:16 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Production stage
FROM node:16-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]

Dieses Muster macht die Produktionsbildgröße kleiner, indem es Build-Tools und Quellcode rauslässt.

Fazit

Die Behebung des Fehlers „Kein Speicherplatz mehr auf dem Gerät“ läuft immer nach dem gleichen Muster ab: Erst mal checken, ob es um Festplattenblöcke oder Inodes geht, dann sicher bereinigen, um Speicherplatz ohne Datenverlust zurückzugewinnen, und schließlich die Konfiguration optimieren, damit das Problem nicht wieder auftritt.

Durch meine jahrelange Erfahrung mit Docker-Umgebungen habe ich gelernt, dass die Log-Rotation die effektivste Strategie zur Vorbeugung ist. Mit einer einfachen Konfiguration von „ daemon.json “ kannst du die meisten Probleme mit Speicherplatzmangel vermeiden.

Ich empfehle dir, jetzt mal deine „ daemon.json “-Einstellungen zu checken. Wenn du für deinen Logging-Treiber nicht „ max-size ” und „ max-file ” eingestellt hast, mach das bitte sofort. Dein zukünftiges Ich wird dir dankbar sein, wenn du die nächste Platzkrise vermeidest.

Bist du bereit, ein Docker-Profi zu werden? Dann ist der nächste Schritt, sich für unseren Kurs Containerisierung und Virtualisierung mit Docker und Kubernetes, den ich echt empfehlen kann.