17  Docker Basics

TipLernziele

Nach diesem Kapitel können Sie:

• Docker als Deployment-Werkzeug erklären
• Images und Container unterscheiden
• Container starten und verwalten
• Volumes einsetzen
• Docker Compose verwenden

17.1 Einführung

17.1.1 Wichtige Begriffe

OT	Operational Technology
IT	Information Technology
Edge System	Industrie-PC oder Edge Gateway
Deployment	Bereitstellung einer Anwendung

17.1.2 Ein typisches Problem aus der Praxis

Stellen wir uns eine moderne Produktionsanlage vor:

Ein Industrie PC (Edge Device) sammelt Prozessdaten aus mehreren Maschinen. Die Daten werden über MQTT übertragen, von einer Middleware verarbeitet, in einer Datenbank gespeichert und anschliessend visualisiert. Technisch besteht das System aus mehreren Anwendungen:

• MQTT Broker
• Node-RED
• Datenbank
• Dashboard

Während der Entwicklung auf dem Engineering-Laptop funktioniert alles problemlos. Bei der Inbetriebnahme auf dem Industrie-PC treten jedoch die ersten Schwierigkeiten auf:

• Die benötigte Python-Version fehlt.
• Bibliotheken besitzen andere Versionsstände.
• Eine Datenbank wurde anders konfiguriert.
• Nach einem Betriebssystemupdate funktioniert die Anwendung nicht mehr wie erwartet.

Je mehr Softwarekomponenten beteiligt sind, desto schwieriger wird die Bereitstellung und Wartung solcher Systeme.

17.1.3 Warum dieses Dokument?

Docker löst genau dieses Problem. Anstatt nur die eigentliche Anwendung auszuliefern, wird die komplette Laufzeitumgebung mitgeliefert. Dadurch kann dieselbe Anwendung auf unterschiedlichen Systemen mit identischem Verhalten betrieben werden. Ein Container, der auf dem Entwicklungslaptop funktioniert, verhält sich auf dem Industrie-PC oder in der Cloud gleich.

Dieses Dokument beschreibt Docker aus Sicht eines Automationsingenieurs. Ziel ist nicht die vollständige Beschreibung aller Docker-Funktionen, sondern das Verständnis von Docker als Werkzeug zur reproduzierbaren Bereitstellung von Software in der vertikalen Integration.

Viele Beispiele orientieren sich deshalb an typischen OT-Anwendungen wie:

• Node-RED
• MQTT Broker
• Historian-Systeme
• Datenbanken
• Dashboards
• Edge Gateways

17.2 Docker installieren

Bevor wir mit Docker arbeiten können, muss Docker auf dem lokalen System installiert werden.

Die folgenden Schritte beschreiben die Installation unter Windows. Für Linux und macOS stehen entsprechende Installationspakete auf der Docker Webseite zur Verfügung Docker Installation

Hinweis: Für Linux muss nicht zwingend Docker Desktop genutzt werden. Die normale Docker Engine reicht völlig.

17.2.1 Voraussetzungen für Docker Desktop Windows

Docker Desktop benötigt:

• Windows 10 (Version 2004 oder neuer)
• Windows 11

Zusätzlich wird das Windows Subsystem for Linux (WSL) verwendet.

17.2.2 WSL installieren

Öffnen Sie eine Eingabeaufforderung als Administrator und führen Sie folgenden Befehl aus:

wsl --install

Starten Sie anschliessend den Computer neu.

Note

WSL (Windows Subsystem for Linux) ermöglicht die Ausführung einer Linux-Umgebung innerhalb von Windows und dient Docker als Laufzeitumgebung.

17.2.3 Docker Desktop installieren

Laden Sie Docker Desktop herunter:

https://www.docker.com/products/docker-desktop/

Während der Installation:

• WSL 2 als Backend verwenden
• Standardoptionen übernehmen
• Es ist kein Docker-Konto erforderlich

Nach der Installation neustarten - Docker sollte automatisch gestartet werden.

17.2.4 Installation überprüfen

Öffnen Sie eine Eingabeaufforderung und führen Sie folgenden Befehl aus:

docker run hello-world

Docker lädt dabei automatisch ein Test-Image herunter und startet einen Container. Bei erfolgreicher Installation erscheint eine Meldung ähnlich zu:

Hello from Docker!
This message shows that your installation appears to be working correctly.

17.2.5 Docker Version prüfen

Die installierte Docker-Version kann mit folgendem Befehl angezeigt werden:

docker version

Zusätzliche Informationen zum Docker-System:

docker info

17.2.6 Häufige Probleme

17.2.6.1 Docker startet nicht

Prüfen:

• Ist Docker Desktop gestartet?
• Läuft WSL korrekt?
• Wurde der Rechner nach der Installation neu gestartet?

17.2.6.2 Der Befehl docker wird nicht gefunden

Prüfen:

• Docker Desktop wurde korrekt installiert.
• Ein neues Terminal wurde geöffnet.
• Docker Desktop läuft im Hintergrund.

17.3 Warum Docker?

Nachdem wir das Problem kennen, stellt sich die Frage:

Warum werden heute für solche Anwendungen zunehmend Container eingesetzt?

17.3.1 Moderne Anwendungen bestehen aus mehreren Diensten

Früher bestand eine Anwendung häufig aus einem einzigen Programm (Monolith). Heute werden Anwendungen meist in mehrere spezialisierte Dienste aufgeteilt.

Ein typisches Beispiel aus dem Automatisierungsumfeld:

Feldgeräte
     │
 MQTT Broker
     │
 Node-RED
     │
 Datenbank
     │
 Dashboard

Jede Komponente besitzt ihre eigene Aufgabe - Nach diesem Aufbau könnte z.B. ein Roboter Staubsauger funktionieren. Was auffällt: Es sind vorallem IT-Anwendungen. Denken wir an Steuerungssoftware ist diese oft noch als Monolith konzipiert - Natürlich ist der echtzeitfähige Teil in der Steuerung gelöst, genauso aber die Kommunikation zum Leitsystem oder die Datensammlung für eine Condition Monitoring Anwendung.

Durch die Aufteilung entstehen Vorteile:

• Komponenten können unabhängig aktualisiert werden.
• Fehler bleiben auf einzelne Dienste begrenzt.
• Systeme werden einfacher skalierbar.
• Einzelne Komponenten können bei Bedarf ersetzt werden.
• Fachpersonen einzelner Komponenten könnten ihr System optimal designen
• …

Gleichzeitig steigt jedoch die Komplexität der Bereitstellung.

17.3.2 Klassische Bereitstellung

Bei einer klassischen Installation muss jede Anwendung manuell installiert werden.

Dazu gehören oft:

• Betriebssystempakete
• Bibliotheken
• Laufzeitumgebungen
• Konfigurationsdateien
• Benutzerkonten

Bereits kleine Unterschiede zwischen Entwicklungs- und Zielsystem können zu Problemen führen.

Der bekannte Satz:

“Auf meinem Rechner funktioniert es.”

ist häufig das Ergebnis unterschiedlicher Laufzeitumgebungen.

17.3.3 Container als Lösung

Container verfolgen einen anderen Ansatz. Anstatt nur die Anwendung bereitzustellen, wird die komplette Laufzeitumgebung paketiert.

Ein Container enthält beispielsweise:

• die Anwendung
• benötigte Bibliotheken
• Konfigurationen
• Werkzeuge
• Laufzeitumgebung

Dadurch entsteht eine reproduzierbare Umgebung. Der Container verhält sich unabhängig vom Zielsystem immer gleich. Dies vereinfacht

• Entwicklung
• Test
• Inbetriebnahme
• Wartung
• Updates

erheblich.

17.3.4 Warum nicht einfach virtuelle Maschinen?

Virtuelle Maschinen lösen ein ähnliches Problem. Auch sie isolieren Anwendungen voneinander und ermöglichen den Betrieb mehrerer Systeme auf einer gemeinsamen Hardware.

Eine virtuelle Maschine ist im Grunde ein vollständiger Computer, der in Software nachgebildet wird. Auf einem einzigen physischen Computer lassen sich so mehrere voneinander unabhängige Systeme betreiben – jedes mit eigenem Betriebssystem, eigenen Treibern und eigenem Kernel. Eine Hypervisor-Schicht (z.B. VMware, Hyper-V oder VirtualBox) übernimmt dabei die Aufgabe, die physischen Ressourcen aufzuteilen und den virtuellen Maschinen zugänglich zu machen.

Physischer Host
│
|─ VM 1
│   |─ Betriebssystem
│
|─ VM 2
│   |─ Betriebssystem
│
|─ VM 3
    |─ Betriebssystem

Der Preis dafür ist der Ressourcenbedarf. Jede VM trägt ihr vollständiges Betriebssystem mit sich – inklusive aller Systemdienste, die beim Start mitgestartet werden, unabhängig davon ob sie gebraucht werden oder nicht. Eine VM, die nur einen einzigen Dienst betreibt, belegt damit trotzdem mehrere Gigabyte RAM und Speicherplatz. Auf einem Industrie-PC mit 4 GB RAM lassen sich auf diese Weise kaum sinnvoll mehrere Dienste parallel betreiben. Hinzu kommt, dass VMs typischerweise Minuten zum Starten benötigen – für dynamischere Deployment-Szenarien ein spürbarer Nachteil.

Container teilen sich hingegen den Kernel des Hostsystems.

Physischer Host mit Linux Betriebssystem
│
|─ Container 1
|─ Container 2
|─ Container 3
│
|─ Gemeinsamer Kernel

Dadurch benötigen Container deutlich weniger Speicher und starten innerhalb weniger Sekunden. Für typische Edge-Anwendungen ist dies häufig ausreichend und deutlich effizienter.

NoteVMs und Container sind keine Konkurrenten

Virtuelle Maschinen und Container lösen unterschiedliche Probleme. VMs bieten eine stärkere Isolation und eignen sich besonders für unterschiedliche Betriebssysteme oder streng getrennte Umgebungen.

Container eignen sich hervorragend für die Bereitstellung einzelner Dienste und Anwendungen.

In vielen Produktionsumgebungen werden beide Technologien gemeinsam eingesetzt.

17.3.5 Wo Docker heute eingesetzt wird

Docker stammt ursprünglich aus der IT-Welt. Heute wird Docker jedoch zunehmend auch in der OT eingesetzt.

Typische Anwendungsfälle sind:

• MQTT Broker
• Node-RED
• OPC-UA Gateways
• Historian-Systeme
• Datenbanken
• Dashboards
• Analyse- und KI-Anwendungen
• Edge Computing

Gerade auf Industrie-PCs und Edge-Systemen hat sich Docker als Standardwerkzeug für die Bereitstellung solcher Anwendungen etabliert.

17.3.6 Wie weiter…

Nachdem nun klar ist, warum Docker eingesetzt wird, betrachten wir im nächsten Kapitel die grundlegenden Bausteine von Docker.

Dabei lernen wir die wichtigsten Konzepte kennen:

• Images
• Container
• Volumes
• Netzwerke
• Docker Compose

Diese fünf Bausteine bilden die Grundlage für nahezu jede Docker-Anwendung.

TipMerke

Docker ist keine Anwendung zur Entwicklung von Software.

Docker ist ein Werkzeug zur reproduzierbaren Bereitstellung von Software.

Genau deshalb spielt Docker heute eine zentrale Rolle in der vertikalen Integration zwischen OT und IT.

17.4 Docker verstehen

Docker wird häufig als kompliziert wahrgenommen. Tatsächlich bestehen die meisten Installationen lediglich aus einigen wenigen Bausteinen. Für den tägliche Einsatz von Docker genügt es 6 Begriffe zu verstehen:

Image	Vorlage eines Containers
Container	Laufende Instanz eines Images
Volume	Persistenter Datenspeicher
Netzwerk	Kommunikation zwischen Containern und nach aussen
Compose	Beschreibung eines Gesamtsystems
Registry	Speicherort für Images

Wer diese 6 Konzepte verstanden hat, kann bereits die meisten Docker-Anwendungen betreiben und Fehler analysieren.

17.4.1 Die Docker Engine

Ein typischer Docker-Host könnte folgendermassen aussehen:

Docker Host

|- Docker Engine
│
|- Container Node-RED
|- Container InfluxDB
|- Container Grafana
│
|- Netzwerk
│
|- Volumes

Die Docker Engine verwaltet alle Container, Netzwerke und Volumes auf dem System. Die einzelnen Anwendungen laufen dabei als eigenständige Container. Sie wird in der Regel durch ein CLI (Command Line Interface) angesprochen. Anwendungen wie Portainer oder Docker Desktop liefern aber auch GUI Varianten dazu.

17.4.2 Images

Ein Image ist die Vorlage eines Containers. Man kann sich ein Image wie einen Bauplan vorstellen.

Das Image beschreibt:

• Welche Software installiert ist
• Welche Bibliotheken benötigt werden
• Welche Konfiguration vorhanden ist
• Welcher Prozess gestartet werden soll

Ein Image wird selbst niemals ausgeführt. Es dient lediglich als Vorlage zur Erzeugung eines Containers.

TipVergleich mit OOP

In einem Vergleich mit Objekt Orientierter Programmierung ist das Image die Klasse, woraus Objekte (Container) instanziert werden können.

17.4.3 Container

Ein Container ist eine laufende Instanz eines Images. Beim Start erstellt Docker eine isolierte Laufzeitumgebung.

Diese besitzt:

• eigene Prozesse
• eigenes Dateisystem
• eigene Netzwerkschnittstelle
• eigene Benutzer

Dadurch werden Anwendungen voneinander getrennt. Aus Sicht der Anwendung wirkt der Container wie ein eigenständiges System. Technisch laufen die Prozesse jedoch direkt auf dem Hostsystem.

17.4.3.1 Warum Container?

Container besitzen mehrere Vorteile:

• schnelle Startzeiten
• geringer Ressourcenbedarf
• reproduzierbare Umgebung
• einfache Verteilung

Für typische OT-Anwendungen bedeutet dies: Ein Container kann auf dem Engineering-Laptop entwickelt und anschliessend unverändert auf einem Industrie-PC oder Edge Gateway betrieben werden.

17.4.4 Volumes

Container sollten grundsätzlich als temporär betrachtet werden. Ein Container kann jederzeit gelöscht und neu erstellt werden. Wichtige Daten dürfen deshalb nicht ausschliesslich im Container gespeichert werden. Docker stellt dafür sogenannte Volumes bereit. Ein Volume ist ein Speicherbereich ausserhalb des Containers.

Typische Daten in Volumes:

• Konfigurationsdateien
• Datenbanken
• Zertifikate
• Benutzerdaten
• Logdateien

Wird ein Container gelöscht, bleiben die Daten im Volume erhalten.

17.4.5 Netzwerke

Container besitzen standardmässig ihre eigene Netzwerkschnittstelle. Docker stellt verschiedene Netzwerkmechanismen zur Verfügung.

Dadurch können Container:

• miteinander kommunizieren
• auf das Internet zugreifen
• Dienste für andere Systeme bereitstellen

Die Kommunikation erfolgt dabei häufig vollständig innerhalb eines Docker-Netzwerks. Dadurch müssen nicht alle Dienste nach aussen veröffentlicht werden.

17.4.5.1 Ports

Soll ein Dienst von ausserhalb des Containers erreichbar sein, muss ein Port veröffentlicht werden.

Beispiel:

docker run -p 1880:1880 image

Dabei gilt:

HostPort : ContainerPort

In diesem Beispiel wird Port 1880 des Containers auf Port 1880 des Hosts veröffentlicht.

17.4.6 Compose

Sobald mehrere Container zusammenarbeiten, werden einzelne Docker-Befehle schnell unübersichtlich.

Stellen wir uns folgendes System vor:

• MQTT Broker
• Node-RED
• InfluxDB
• Grafana

Für jeden Container müssten:

• Ports
• Volumes
• Netzwerke
• Umgebungsvariablen

konfiguriert werden.

Docker Compose ermöglicht es, diese Beschreibung in einer einzigen Datei abzulegen.

Eine Compose-Datei beschreibt das gesamte System deklarativ.

services:

  mqtt:
    image: eclipse-mosquitto

  nodered:
    image: nodered/node-red

  grafana:
    image: grafana/grafana

Das komplette System kann anschliessend mit einem einzigen Befehl gestartet werden.

docker compose up -d

17.4.7 Registries

Images werden typischerweise nicht lokal erstellt, sondern aus einer Registry heruntergeladen. Eine Registry ist vergleichbar mit einem Paketdepot für Container-Images.

Bekannte Beispiele sind:

• Docker Hub
• GitHub Container Registry
• GitLab Container Registry
• Private Unternehmensregistries

Der Docker Hub stellt beispielsweise Images für:

• Node-RED
• Grafana
• InfluxDB
• Eclipse Mosquitto

bereit.

17.5 Der Lebenszyklus eines Containers

Bisher haben wir die wichtigsten Docker-Bausteine kennengelernt. Bevor wir den ersten Container starten, betrachten wir den typischen Lebenszyklus eines Containers. Die folgenden Befehle zeigen dazu die wichtigsten Funktionen.

Hinweis: Container können in diesen Befehlen mittels Name oder der Container ID angesprochen werden. Bei der ID müssen nur soviele Zeichen eingegeben werden, bis diese eineindeutig von den anderen vorhandenen Containern unterschieden werden kann.

17.5.1 Container erstellen und starten

Der Befehl docker run erstellt einen neuen Container aus einem Image und startet ihn unmittelbar.

docker run image

Existiert das Image noch nicht lokal, wird es automatisch heruntergeladen.

17.5.2 Laufende Container anzeigen

docker ps
docker ps -a

Nur laufende Container werden angezeigt. Mit der Option -a werden alle angezeigt.

17.5.3 Container stoppen

docker stop <container>

Der Container bleibt erhalten, wird jedoch nicht mehr ausgeführt.

17.5.4 Container starten

docker start <container>

Ein bereits vorhandener Container wird erneut gestartet.

17.5.5 Container löschen

docker rm <container>

Dadurch wird der Container entfernt. Volumes bleiben dabei erhalten.

TipWichtig

Ein Container ist nicht dasselbe wie ein Image.

Ein Container kann gelöscht werden, ohne dass das zugrunde liegende Image verloren geht.

17.6 Der erste Container

Nachdem die Grundlagen bekannt sind, starten wir nun den ersten konkreten Container. Als Beispiel verwenden wir Node-RED.

17.6.1 Container starten

docker run -d --name nodered -p 1880:1880 nodered/node-red

Docker führt dabei automatisch mehrere Schritte aus:

1. Image suchen
2. Image herunterladen
3. Container erstellen
4. Netzwerk konfigurieren
5. Anwendung starten

17.6.2 Container anzeigen

docker ps

17.6.3 Anwendung öffnen

http://localhost:1880

Node-RED sollte nun erreichbar sein.

17.6.4 Logs anzeigen

docker logs -f nodered

Logs sind häufig die erste Anlaufstelle bei Problemen.

17.6.5 Shell öffnen

docker exec -it nodered sh

Nun befindet man sich direkt innerhalb des Containers in der Standard Shell

17.6.6 Container stoppen

docker stop nodered

17.6.7 Container starten

docker start nodered

17.6.8 Container löschen

docker rm -f nodered

Die Option -f steht für Force. Dies zwingt Docker den Container zu entfernen auch wenn dieser noch laufen würde.

17.6.9 Was haben wir gelernt?

• Image verwenden
• Container starten
• Logs lesen
• Container betreten
• Container stoppen
• Container löschen

17.7 Persistente Daten mit Volumes

Container sind grundsätzlich temporär. Wird ein Container gelöscht, gehen alle innerhalb des Containers gespeicherten Daten verloren. Ein klassischer Anwendungsfall: von einer Anwendung gibt es eine neue Image Version und ich möchte diese nutzen, mit meiner bestehenden Konfiguration. In diesem Fall sollte die Konfiguration persistent in einem Volume ausserhalb des Containers gespeichert werden, so dass der neue Container lediglich auf den gleichen Speicherbereich zeigen muss.

17.7.1 Named Volume erstellen

Bei einem Named Volume wie nodered-data übernimmt Docker den effektiven Speicherort. Der angegebene Text dient als Referenz zu diesem Speicher Ort. Im folgenden wird spezifisch ein Volume erstellt. Dies geht genauso beim Aufruf direkt in einem Container Kommando.

docker volume create nodered-data

Im folgenden Beispiel wird das Volume nodered-data auf den Ordner /data im Container gemappt.

docker run -d \
  --name nodered \
  -p 1880:1880 \
  -v nodered-data:/data \
  nodered/node-red

Hinweis: Wird das Volume neu erzeugt, wird Initial der Inhalt des verlinkten Ordners im Container an den Speicherort auf dem Hostsystem kopiert. Dies ist besonders praktisch wenn der Hersteller eine Default Konfiguration anbietet, die ich gerne selbst modifizieren möchte.

17.7.2 Bind Mounts

Alternativ kann ein bestehender Ordner eingebunden werden. Die dabei angegebenen Paramter hostpfad:contianerpfadsind effektive Dateipfade.

Linux:

docker run -v /opt/config:/config image

Windows:

docker run -v C:\config:/config image

17.8 Container Netzwerk

Container arbeiten selten alleine. Typischerweise kommunizieren mehrere Dienste miteinander.

17.8.1 Bridge Netzwerk

Standardmässig verwendet Docker ein Default Bridge Netzwerk. Dieses Netzwerk kann man sich wie ein Switch vorstellen, an dem alle Container und ein virtuelles Interface des Hosts angeschlossen ist. Das Default Bridge Netzwerk erlaubt Kommunikation per IP zwischen den Teilnehmern. In dieser Bridge ist die Kommunikation per Hostnamen (DNS) nicht möglich.

Die erstellen Netzwerke haben ein NAT zum eigentlichen Host Interface, wodurch von Aussen nur die Host IP, nicht aber die Container IP sichtbar ist.

Container A
      │
      ▼
Docker Bridge
      ▲
      │
Container B

17.8.2 Eigenes Netzwerk erstellen

In Docker können eigene Netzwerke erstellt und den Containern entsprechend zugewiesen werden. Es existieren mehrere Adaptertypen wie z.B: Bridge, Host usw., per Default wird aber immer Bridge genutzt.

Hinweis: Ein User Bridge Netzwerk funktioniert gleich wie das Default Bridge Netzwerk, jedoch ist darin die Nutzung von DNS möglich.

docker network create fhnw-net

17.8.3 Container verbinden

docker run -d \
  --name influxdb \
  --network fhnw-net \
  influxdb:2.7

docker run -d \
  --name nodered \
  --network fhnw-net \
  nodered/node-red

17.8.4 Ports veröffentlichen

Das veröffentlichen von Ports ist eine Dockeranweisung an die Firewall, den entsprechenden Port verfügbar zu machen.

Dieses Beispiel erlaubt den Zugriff auf den Port 1880 auf dem Host auf allen verfügbaren Schnittstellen:

docker run -p 1880:1880 image

Nur lokal:

docker run -p 127.0.0.1:1880:1880 image

17.9 Mehrere Container mit Compose

Sobald mehrere Container verwendet werden, wird die Konfiguration schnell unübersichtlich.

Docker Compose beschreibt ein gesamtes System in einer Datei.

17.9.1 Beispiel

services:

  mosquitto:
    image: eclipse-mosquitto

  nodered:
    image: nodered/node-red
    ports:
      - "1880:1880"

17.9.2 Starten

docker compose up -d

17.9.3 Status

docker compose ps

17.9.4 Logs

docker compose logs -f

17.9.5 Stoppen

docker compose down

17.9.6 Warum Compose?

Vorteile:

• Dokumentation der Infrastruktur
• Reproduzierbare Deployments
• Versionskontrolle
• Einfaches Update von Diensten

17.10 Troubleshooting

17.10.1 Container startet nicht

Logs prüfen:

docker logs <container>

17.10.2 Port nicht erreichbar

Prüfen:

docker ps

17.10.3 Container findet anderen Container nicht

Netzwerk prüfen:

docker network ls

Container prüfen:

docker inspect <container>

17.10.4 Volume funktioniert nicht

Volumes anzeigen:

docker volume ls

Details:

docker volume inspect <volume>

17.10.5 Allgemeine Diagnose

docker stats

docker inspect <container>

docker logs -f <container>

17.11 Docker Cheat Sheet

17.11.1 Container

docker ps                    # Laufende Container
docker ps -a                 # Alle Container
docker run                   # Container starten
docker start <name>          # Gestoppten Container starten
docker stop <name>           # Container stoppen
docker restart <name>        # Container neustarten
docker rm <name>             # Container löschen
docker exec -it <name> sh    # Shell im Container öffnen
docker inspect <name>        # Details anzeigen
docker stats                 # CPU/RAM-Auslastung

17.11.2 Images

docker images                # Lokale Images
docker pull <image>          # Image herunterladen
docker build -t <name> .     # Image bauen
docker rmi <image>           # Image löschen
docker save -o out.tar <img> # Image exportieren
docker load -i out.tar       # Image importieren

17.11.3 Logs

docker logs <name>           # Logs anzeigen
docker logs -f <name>        # Logs live verfolgen
docker logs --tail 50 <name> # Letzte 50 Zeilen

17.11.4 Volumes

docker volume ls
docker volume create <name>
docker volume inspect <name>
docker volume prune

17.11.5 Netzwerke

docker network ls
docker network create <name>
docker network connect <net> <container>

17.11.6 Compose

docker compose up -d         # Stack starten
docker compose down          # Stack stoppen, Container entfernen
docker compose down -v       # + Volumes löschen
docker compose ps            # Status
docker compose logs -f       # Live-Logs
docker compose pull          # Neue Images holen
docker compose up -d --build # Neu bauen und starten

17.11.7 Aufräumen

docker image prune           # Ungenutzte Images
docker container prune       # Gestoppte Container
docker volume prune          # Ungenutzte Volumes
docker system prune -a       # Alles Ungenutzte
docker system df             # Speicherverbrauch