5 Docker-Befehle, die du vielleicht noch nicht kennst
Jonas Scholzdocker build, run und logs kennst du schon? Mit diesen fünf Befehlen findest du schneller heraus, was Docker gerade macht. Du siehst den Speicherverbrauch, begrenzt einen Build-Worker und holst Dateien aus Containern.
1. docker system df
Images, gestoppte Container, Volumes und Build-Cache können viel Platz belegen. Schau zuerst nach, wo der Platz bleibt:
docker system df
docker system df -v
Die ausführliche Variante zeigt die einzelnen Objekte hinter den Summen. Images können sich Layer teilen. Addier deshalb nicht einfach alle Image-Größen.
Willst du aufräumen, lies vor dem Bestätigen, was der Prune-Befehl löscht. docker system prune --all entfernt gestoppte Container, ungenutzte Netzwerke, ungenutzte Images und Build-Cache. Dazu können auch Images gehören, die du für einen Rollback behalten willst. Volumes löscht der Befehl erst, wenn du das zusätzlich anforderst. Die Docker-Anleitung zum Pruning zeigt, was die einzelnen Befehle entfernen.
2. docker stats
So siehst du CPU, RAM, Netzwerk- und Block-I/O deiner laufenden Container:
docker stats
Willst du nur eine Momentaufnahme für einen Container, nutze:
docker stats --no-stream myapp
Das hilft zum Beispiel, wenn ein Container plötzlich viel RAM braucht. Du siehst die aktuellen Werte. Für Probleme, die nur ab und zu auftreten, brauchst du eine Aufzeichnung über längere Zeit.
3. Die CPU-Nutzung eines BuildKit-Workers begrenzen
Im ursprünglichen Beitrag stand docker build --cpu-quota. Das gehört zum alten Builder und funktioniert nicht allgemein mit BuildKit. Für BuildKit kannst du einen eigenen Buildx-Builder mit dem Treiber docker-container anlegen. Dann begrenzt du den Worker-Container:
docker buildx create --name limited-builder --driver docker-container --driver-opt cpu-period=100000,cpu-quota=200000
docker buildx build --builder limited-builder --load -t myapp .
Mit einer Periode von 100000 und einer Quote von 200000 bekommt der Worker höchstens die Rechenzeit von zwei CPUs. Zwei Kerne exklusiv reserviert er damit nicht. Pass die Quote an deinen Rechner an. Bei Docker Desktop gelten zusätzlich die Limits der Linux-VM.
--load lädt das Ergebnis eines Builds für eine Plattform in deinen lokalen Docker-Image-Speicher. Der Builder nutzt einen eigenen Cache. Brauchst du ihn nicht mehr, entferne ihn mit docker buildx rm limited-builder. Dabei wird auch sein verwalteter Zustand gelöscht. Weitere Optionen findest du in der Dokumentation zum Docker-Container-Treiber.
4. docker cp
So kopierst du eine Datei aus einem Container. Zusätzliche Tools im Image brauchst du dafür nicht:
docker cp myapp:/app/output.json ./output.json
In die andere Richtung geht es genauso:
docker cp ./input.json myapp:/app/input.json
Der Container darf dabei auch gestoppt sein. Prüf den Zielpfad und die Rechte. Änderst du eine Datei im beschreibbaren Container-Layer, bleibt das Image unverändert. Sollen die Daten dauerhaft bleiben, nutze ein Volume oder einen anderen persistenten Speicher.
5. docker top
Welche Prozesse laufen im Container? Das zeigt dir:
docker top myapp
So siehst du, was dein CMD gestartet hat. Vielleicht läuft vor deinem Prozess noch eine Shell oder ein Paketmanager. Um das zu prüfen, musst du kein ps im Image installieren.
Mehr Beispiele findest du in unseren Anleitungen zu docker stats und docker cp. Ist die App bereit für ein Deployment, kann Sliplane sie aus deinem Repository bauen und starten.
