Was ist Docker? Einfach erklärt mit echten Messwerten (2026)

Was ist Docker? Docker ist ein Werkzeug, das eine Anwendung zusammen mit allem, was sie zum Laufen braucht, in ein abgeschlossenes Paket steckt: einen Container. Dieses Paket läuft auf jedem Linux-Rechner mit Docker gleich, egal ob auf deinem Laptop, einem günstigen VPS oder einem großen Server im Rechenzentrum. Der berühmte Satz „Bei mir läuft es aber“ verliert damit seinen Schrecken, weil „bei mir“ und „auf dem Server“ dasselbe Paket ist.

Das klingt nach Magie, ist aber erstaunlich bodenständig. Ein Container ist keine kleine virtuelle Maschine, sondern ein ganz normaler Linux-Prozess, dem der Kernel eine eigene Sicht auf Dateien, Netzwerk und Prozesse vorgaukelt. Genau das haben wir auf unserem eigenen Entwicklungsserver nachgemessen, auf dem seit Monaten Docker 2026 in Version 29 läuft: wie schnell ein Container startet, wie wenig Speicher er braucht, warum Daten plötzlich weg sind und wie sich auf demselben Server unbemerkt 26 Gigabyte alter Images angesammelt haben. Dieser Artikel erklärt Docker von Grund auf, mit Zahlen statt Werbeversprechen.

Das Video von KodeKloud (englisch) erklärt in ruhigem Tempo, was Container sind und warum Docker sich durchgesetzt hat. Ein guter Einstieg, bevor wir unten in die eigenen Messungen gehen. KodeKloud verkauft Kurse; das Video selbst ist trotzdem ohne Anmeldung verständlich.

Was ist Docker? Die kurze Antwort

Wenn du nur drei Sätze mitnehmen willst:

• Docker verpackt Software samt Abhängigkeiten (Bibliotheken, Laufzeitumgebung, Konfiguration) in ein sogenanntes Image. Aus einem Image startest du beliebig viele Container.
• Ein Container ist ein isolierter Prozess, keine eigene Maschine. Er teilt sich den Kernel mit dem Host, startet deshalb in Sekundenbruchteilen und braucht kaum Speicher.
• Container sind wegwerfbar. Alles, was du im Container änderst, ist beim Löschen weg, außer du legst es bewusst in ein Volume. Das ist der häufigste Anfängerfehler und gleichzeitig der Grund, warum Docker so zuverlässig ist.

Der Rest dieses Artikels erklärt, was das in der Praxis bedeutet, wo Docker glänzt und wo es dir eher im Weg steht.

Das Problem, das Docker löst

Stell dir vor, du willst eine Webanwendung auf einem Server installieren. Sie braucht PHP in Version 8.3, eine bestimmte Erweiterung für Bildbearbeitung, eine MariaDB-Datenbank und ein paar Systembibliotheken. Auf deinem Server läuft aber schon eine andere Anwendung, die PHP 8.1 braucht. Ohne Docker hast du jetzt ein Problem: Zwei PHP-Versionen gleichzeitig sauber zu betreiben ist möglich, aber fummelig, und bei jedem Update des Betriebssystems kann sich etwas verschieben.

Genau dieses Durcheinander nennt man gern die „Dependency Hell“. Jede Software bringt ihre eigenen Anforderungen mit, und die vertragen sich nicht immer. Früher gab es zwei Lösungen: alles auf einem Server mühsam nebeneinander pflegen, oder für jede Anwendung eine eigene virtuelle Maschine aufsetzen. Die erste Variante ist fehleranfällig, die zweite teuer.

Docker bietet einen dritten Weg. Jede Anwendung bekommt ihren eigenen Container mit genau den Versionen, die sie braucht. Die PHP-8.3-Anwendung und die PHP-8.1-Anwendung laufen nebeneinander, ohne voneinander zu wissen. Auf unserem Entwicklungsserver laufen so gerade zwei Shopware-Testumgebungen in unterschiedlichen Versionen, eine WordPress-Instanz, zwei verschiedene Datenbanken (MariaDB und PostgreSQL) und ein Download-Dienst gleichzeitig, und keine dieser Anwendungen hat auch nur ein einziges Paket auf dem eigentlichen Server installiert.

Container vs. virtuelle Maschine: der wichtigste Unterschied

Die häufigste Verwechslung bei der Frage „Was ist Docker?“ ist die mit virtuellen Maschinen. Beides isoliert Anwendungen voneinander, aber auf völlig unterschiedlichen Ebenen.

Eine virtuelle Maschine simuliert einen kompletten Computer. Sie hat eigene virtuelle Hardware, einen eigenen Kernel und ein vollständiges Betriebssystem, das bootet wie auf echter Hardware. Das ist wie ein eigenes Haus mit eigenem Fundament: sehr gut abgeschirmt, aber schwer. Ein Ubuntu-Server in einer VM braucht schnell ein paar hundert Megabyte RAM, bevor deine eigentliche Anwendung überhaupt startet, und der Bootvorgang dauert Sekunden bis Minuten.

Ein Container simuliert gar nichts. Er nutzt den Kernel des Host-Systems direkt mit. Der Linux-Kernel sorgt über zwei Mechanismen dafür, dass der Prozess im Container sich trotzdem wie allein fühlt:

• Namespaces geben dem Prozess eine eigene Sicht: eigene Prozessliste, eigenes Dateisystem, eigenes Netzwerk, eigener Hostname.
• cgroups (Control Groups) begrenzen, wie viel CPU, Arbeitsspeicher und Festplatten-I/O der Prozess verbrauchen darf.

Das ist eher wie eine Wohnung in einem Mehrfamilienhaus: eigene Tür, eigene Räume, aber gemeinsames Fundament und gemeinsame Leitungen.

Wir haben nachgesehen: Der Kernel ist wirklich derselbe

Das lässt sich in einer Zeile beweisen. Wir haben einen Alpine-Linux-Container gestartet und darin nach Betriebssystem und Kernel gefragt:

docker run --rm alpine:3 sh -c 'cat /etc/os-release | head -2; uname -r'

Ergebnis im Container: NAME="Alpine Linux" und Kernel 6.8.0-124-generic. Auf dem Server selbst läuft Ubuntu 24.04 mit Kernel 6.8.0-124-generic. Der Container sieht aus wie Alpine, weil seine Dateien von Alpine stammen, aber der Kernel darunter ist exakt der des Ubuntu-Hosts. Es gibt keinen zweiten.

Daraus folgen drei Dinge, die jeder Docker-Einsteiger wissen sollte:

1. Linux-Container brauchen einen Linux-Kernel. Auf Windows und macOS läuft Docker Desktop deshalb heimlich eine kleine Linux-VM im Hintergrund (unter Windows über WSL 2). Die Container laufen in dieser VM, nicht direkt auf deinem Windows.
2. Die Isolation ist schwächer als bei einer VM. Eine Sicherheitslücke im Kernel betrifft alle Container gleichzeitig. Für fremden, nicht vertrauenswürdigen Code ist eine VM die sicherere Wahl.
3. Container sind extrem leicht. Kein Boot, kein zweites Betriebssystem im RAM. Das sehen wir gleich in Zahlen.

Was im Container wirklich läuft

In einer VM laufen nach dem Start Dutzende Prozesse: init-System, Logging, Cron, SSH und so weiter. In einem Container läuft genau das, was du startest. Unser Test:

docker run --rm alpine:3 sh -c 'ps'

Die Prozessliste im Container hatte zwei Einträge: die Shell als Prozess Nummer 1 und den ps-Befehl selbst. Mehr nicht. Der Prozess, den du startest, ist der Container. Beendet er sich, ist der Container vorbei. Das erklärt einen typischen Anfängermoment: Man startet einen Container, er ist sofort wieder weg, und man denkt, etwas sei kaputt. Meistens hatte der Hauptprozess einfach nichts mehr zu tun.

Wenn du tiefer in die Frage einsteigen willst, wie Virtualisierung auf Server-Ebene funktioniert, erklärt unser Artikel Was ist ein VPS?, wie ein virtueller Server auf geteilter Hardware entsteht. Die meisten Docker-Setups laufen übrigens genau dort: Container in einer VM, die Hosting-Anbieter als VPS verkaufen.

Die Bausteine von Docker einfach erklärt

Docker hat eine Handvoll Begriffe, die man einmal sauber auseinanderhalten sollte. Danach ist fast jede Anleitung verständlich.

Image: die Vorlage

Ein Image ist eine unveränderliche Vorlage, aus der Container entstehen. Es enthält ein Dateisystem (etwa die Dateien von Alpine oder Debian plus deine Anwendung) und Metadaten, zum Beispiel welcher Befehl beim Start ausgeführt wird. Man kann es sich wie eine Backform vorstellen: Aus einer Form backst du beliebig viele Kuchen, die Form selbst verändert sich dabei nicht.

Images haben Namen und Versionen, sogenannte Tags: postgres:16-alpine heißt „PostgreSQL in Version 16, gebaut auf Alpine Linux“. Ohne Tag nimmt Docker latest, was trotz des Namens nicht zwingend die neueste Version bedeutet, sondern nur den Tag, den der Herausgeber so genannt hat. Für Server gilt deshalb: Immer eine konkrete Version angeben.

Container: die laufende Instanz

Ein Container ist ein gestartetes Image. Docker legt über das schreibgeschützte Image eine dünne, beschreibbare Schicht. Alles, was die Anwendung zur Laufzeit ändert, landet in dieser Schicht. Du kannst aus einem Image zehn Container starten; sie teilen sich die Image-Dateien und haben jeder ihre eigene kleine Änderungsschicht.

Layer: warum Images so klein sein können

Ein Image besteht nicht aus einem großen Block, sondern aus übereinanderliegenden Schichten (Layern). Jede Anweisung im Bauplan erzeugt eine Schicht: „nimm Debian“, „installiere PHP“, „kopiere meinen Code“. Haben zwei Images dieselbe Basis, speichert Docker die gemeinsamen Schichten nur einmal. Das spart enorm Platz und macht Updates schnell, weil nur die geänderten Schichten neu heruntergeladen werden.

Das erklärt auch eine Zahl, die uns beim Nachmessen kurz irritiert hat: Unsere drei Shopware-Testimages sind laut docker images je rund 7,5 GB groß, die Summe aller Images auf dem Server aber nur 30 GB. Die Einzelwerte addieren sich nicht einfach, weil sich viele Schichten überschneiden.

Dockerfile: der Bauplan

Ein Dockerfile ist eine Textdatei mit Anweisungen, wie ein Image gebaut wird. Ein minimales Beispiel für eine kleine Node.js-Anwendung:

FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Mit docker build -t meine-app:1.0 . wird daraus ein Image. Die Reihenfolge ist kein Zufall: Die Abhängigkeiten werden vor dem eigentlichen Code kopiert, damit Docker die teure npm ci-Schicht wiederverwenden kann, solange sich nur dein Code ändert und nicht die Paketliste.

Registry und Docker Hub: das Lager

Fertige Images liegen in einer Registry. Die bekannteste ist Docker Hub, dazu kommen die GitHub Container Registry (ghcr.io), die von Anbietern wie GitLab und die der großen Cloud-Anbieter. docker pull nginx holt ein Image von Docker Hub, docker push lädt eines hoch. Für fast jede bekannte Software gibt es dort offizielle Images, gepflegt vom Hersteller oder vom Docker-Team.

Volume: der Ort, an dem Daten überleben

Ein Volume ist Speicherplatz, der außerhalb der Container-Schicht liegt und unabhängig vom Container existiert. Datenbanken, hochgeladene Dateien, Konfiguration, die sich ändert: All das gehört in ein Volume. Warum das so wichtig ist, zeigt der nächste Abschnitt.

Netzwerk und Ports

Container bekommen standardmäßig ein eigenes, internes Netzwerk. Von außen sind sie nur erreichbar, wenn du einen Port freigibst, etwa mit -p 8080:80. Das heißt: Port 8080 auf dem Server leitet an Port 80 im Container weiter. Hier lauert eine der gefährlichsten Fallen von Docker, zu der wir unten noch kommen.

Unsere Messungen: Wie leicht ist ein Container wirklich?

Werbeversprechen wie „Container starten in Millisekunden“ hört man oft. Wir wollten es für unseren eigenen Server genau wissen. Die Testumgebung: ein VPS mit 12 vCPUs und 23 GB RAM, Ubuntu 24.04, Docker Engine 29.2.1, Speicher-Treiber overlayfs, cgroups Version 2.

Startzeit: rund 0,4 Sekunden

Wir haben fünfmal hintereinander einen Alpine-Container gestartet, der sofort wieder beendet wird, und die Gesamtzeit mit time gemessen, inklusive Anlegen, Starten, Beenden und Löschen:

docker run --rm alpine:3 true

Der erste Lauf ist langsamer, weil Docker noch Dateien in den Cache holen muss. Danach pendelt es sich bei rund 0,4 Sekunden ein. Das ist wohlgemerkt der komplette Lebenszyklus, nicht nur der Start. Zum Vergleich: Eine virtuelle Maschine ist in dieser Zeit nicht einmal mit dem BIOS fertig. Millisekunden, wie manchmal behauptet, sind es auf unserem Server aber nicht. Die ehrliche Größenordnung ist „deutlich unter einer Sekunde“.

Arbeitsspeicher: 348 Kilobyte

Wir haben einen Container gestartet, der nur sleep ausführt, und seinen Speicherverbrauch mit docker stats abgelesen: 348 KiB. Nicht Megabyte, Kilobyte. Ein Container kostet nur den Speicher, den der Prozess darin tatsächlich braucht, plus ein wenig Verwaltung. Es gibt kein Betriebssystem, das nebenher RAM belegt.

Die produktiven Container auf demselben Server zeigen, wie unterschiedlich das je nach Anwendung ausfällt: Eine PostgreSQL-Datenbank im Leerlauf braucht knapp 7 MB, der Download-Dienst rund 8 MB, eine MariaDB 23 MB, eine Shopware-Testumgebung mit PHP und Webserver 140 MB und eine WordPress-Instanz mit Apache 232 MB. Der Container selbst ist fast gratis; teuer ist nur die Anwendung darin.

Image-Größen: von 13 MB bis 7,6 GB

Die Spanne ist riesig. Alpine Linux ist mit 13 MB winzig, weil es auf das Nötigste reduziert ist und eine schlankere C-Bibliothek (musl) verwendet. Ein Entwicklungsimage, das einen kompletten Onlineshop samt Werkzeugen, Datenbank und Beispieldaten enthält, ist 580-mal so groß. Für den eigenen Server heißt das: Wenn es eine -alpine- oder -slim-Variante gibt und deine Anwendung damit läuft, spart sie Download-Zeit, Speicherplatz und Angriffsfläche.

Ressourcen begrenzen: ein Schalter, echte Wirkung

Standardmäßig darf ein Container so viel RAM nehmen, wie der Server hergibt. Das haben wir direkt aus der cgroup im Container ausgelesen:

docker run --rm alpine:3 cat /sys/fs/cgroup/memory.max
# max

docker run --rm -m 64m alpine:3 cat /sys/fs/cgroup/memory.max
# 67108864

Ohne Grenze steht dort max, mit -m 64m exakt 67.108.864 Byte, also 64 MiB. Überschreitet der Prozess das, beendet der Kernel ihn, und nicht irgendeinen anderen Dienst auf dem Server. Bei Anwendungen mit Speicherlecks ist diese eine Option der Unterschied zwischen „ein Container startet neu“ und „der ganze Server hängt“. Wie viel RAM ein Server insgesamt braucht, haben wir übrigens in Wie viel RAM braucht ein Server? aufgeschlüsselt.

Die wichtigste Lektion: Container vergessen alles

Wer Docker zum ersten Mal ernsthaft nutzt, verliert fast immer irgendwann Daten. Das ist kein Fehler von Docker, sondern Absicht. Wir haben es in drei Befehlen nachgestellt:

docker run --name test alpine:3 sh -c 'echo hallo > /daten.txt'
docker rm test
docker run --rm alpine:3 cat /daten.txt
# cat: can't open '/daten.txt': No such file or directory

Die Datei wurde im ersten Container geschrieben. Nach dem Löschen des Containers ist sie weg, und ein neuer Container aus demselben Image beginnt wieder beim sauberen Ausgangszustand. Jeder Container startet frisch aus seinem Image.

Das ist genau das, was Docker so zuverlässig macht: Ein Container kann nicht über Monate „verwildern“, weil jemand darin etwas von Hand geändert hat. Beim nächsten Update wird er gelöscht und neu erstellt, und dann ist er wieder exakt so, wie das Image es vorsieht. Aber es heißt eben auch: Alles, was bleiben soll, muss in ein Volume.

docker volume create meine-daten
docker run --rm -v meine-daten:/daten alpine:3 sh -c 'echo hallo > /daten/datei.txt'
docker run --rm -v meine-daten:/daten alpine:3 cat /daten/datei.txt
# hallo

Diesmal überlebt die Datei, weil sie im Volume liegt und nicht in der Container-Schicht. Bei Datenbanken ist das Pflicht. Ein PostgreSQL- oder MariaDB-Container ohne Volume ist eine Datenbank, die ihr Gedächtnis beim nächsten Update verliert.

Ein weiterer Hinweis, der viele überrascht: Volumes werden nicht automatisch gesichert. Sie liegen auf dem Server unter /var/lib/docker/volumes/ und gehören genauso in dein Backup wie jede andere wichtige Datei.

Docker in der Praxis: die ersten Befehle

Nach der Installation (unter Ubuntu und Debian am saubersten über das offizielle Docker-Repository, nicht über das oft veraltete Paket docker.io) reichen für den Anfang wenige Befehle:

docker run hello-world              # Test: funktioniert Docker?
docker run -d --name web -p 8080:80 nginx:1.27-alpine   # Webserver im Hintergrund
docker ps                           # laufende Container anzeigen
docker ps -a                        # auch beendete Container
docker logs web                     # Ausgaben des Containers ansehen
docker exec -it web sh              # Shell im laufenden Container öffnen
docker stop web && docker rm web    # stoppen und löschen
docker images                       # heruntergeladene Images
docker system df                    # Speicherverbrauch von Docker

Nach dem zweiten Befehl liefert http://server:8080 bereits die Nginx-Willkommensseite aus, ohne dass Nginx auf dem Server installiert wurde.

Thetips4you zeigt in rund zehn Minuten (englisch) die ersten Befehle live im Terminal. Wer lieber zusieht als liest, hat danach die Grundlagen einmal selbst durchgespielt.

Mehrere Container zusammen: Docker Compose

Echte Anwendungen bestehen selten aus einem Container. Ein WordPress braucht eine Datenbank, eine Web-App vielleicht noch Redis als Cache. Statt jeden Container mit einem langen docker run-Befehl zu starten, beschreibt man das Zusammenspiel in einer Datei namens compose.yaml und startet alles mit docker compose up -d. Welche Stolperfallen dabei lauern, etwa warum depends_on nicht auf die Datenbank wartet oder warum ein umbenannter Ordner scheinbar alle Daten löscht, haben wir ausführlich im Docker-Compose-Beispiel nachgemessen. Das ist der logische nächste Schritt nach diesem Artikel.

Die gefährlichste Falle: Docker umgeht deine Firewall

Ein Punkt, den fast jede Einsteiger-Anleitung verschweigt: Wenn du einen Port mit -p 8080:80 freigibst, trägt Docker eigene Regeln direkt in die Firewall-Tabellen des Kernels ein, und zwar vor den Regeln von UFW. Du kannst also in UFW alles außer SSH gesperrt haben, und der Container-Port ist trotzdem aus dem ganzen Internet erreichbar. ufw status zeigt davon nichts an.

Das haben wir im Compose-Artikel mit einem echten Test von außen nachgewiesen: Ein Port in der Form 8412:80 war von einem fremden Server in Helsinki mit HTTP 200 erreichbar, obwohl UFW aktiv war und diesen Port nie freigegeben hatte. Die Lösung ist einfach, man muss sie nur kennen: Ports, die nicht öffentlich sein sollen, an 127.0.0.1 binden.

docker run -d -p 127.0.0.1:5432:5432 postgres:16-alpine

Auf unserem Server sind deshalb alle Container-Ports ausschließlich an 127.0.0.1 gebunden, wir haben es für diesen Artikel mit docker ps noch einmal geprüft. Nach außen spricht nur der Webserver, der als Reverse Proxy die Anfragen an die Container weiterreicht und sich um HTTPS kümmert. Datenbanken sind grundsätzlich nie direkt erreichbar. Wenn du nur eine Regel aus diesem Artikel mitnimmst, dann diese.

Unser Fund beim Nachmessen: 26 GB vergessene Altlasten

Beim Sammeln der Zahlen für diesen Artikel haben wir docker system df auf unserem Server laufen lassen. Das Ergebnis war ehrlich gesagt unangenehm:

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          18        8         30.28GB   26.79GB (88%)
Containers      8         6         835.4MB   12.29kB (0%)
Local Volumes   9         5         2.881GB   1.334GB (46%)
Build Cache     128       0         8.076GB   6.549GB

Von 30 GB an Images werden 88 Prozent von keinem Container mehr benutzt. Dazu kommen 6,5 GB Build-Cache aus längst abgeschlossenen Bauvorgängen und 1,3 GB in Volumes, an denen kein Container mehr hängt. Zusammen gut 34 GB, die niemand braucht und niemand bemerkt hat.

Wie so etwas entsteht, ist ganz unspektakulär: Bei jedem Update eines Images bleibt die alte Version liegen. Testumgebungen werden gestartet, verworfen und vergessen. Jeder docker build legt Cache-Schichten an. Docker räumt davon nichts von selbst auf. Auf einem Server mit großer Festplatte merkt man das monatelang nicht, auf einem kleinen VPS mit 40 GB läuft irgendwann still die Platte voll, und dann fallen Datenbanken und Logs gleichzeitig aus.

Aufräumen geht in Stufen, von vorsichtig bis radikal:

docker image prune          # nur namenlose, verwaiste Images
docker builder prune        # Build-Cache
docker image prune -a       # ALLE Images ohne laufenden oder gestoppten Container
docker volume prune         # Volumes ohne Container – Vorsicht, das sind Daten!

Beim letzten Befehl ist Vorsicht angebracht: Ein Volume ohne Container kann genau die Datenbank sein, deren Container du nur kurz gelöscht hast, um ihn neu zu erstellen. Wir haben für diesen Artikel deshalb bewusst nichts gelöscht, sondern die Liste zuerst durchgesehen. Aufräumen ist eine Entscheidung, keine Routine, die man blind in einen Cronjob schreibt. Ein regelmäßiger Blick auf docker system df gehört aber auf jede Checkliste für Serverpflege.

Wofür Docker sich lohnt und wofür nicht

Docker ist kein Selbstzweck. Nach einigen Jahren im Einsatz sehen wir klare Stärken und ebenso klare Fälle, in denen es mehr Arbeit macht als spart.

Wo Docker glänzt

• Selfhosting fertiger Software. Nextcloud, Vaultwarden, Gitea, Uptime Kuma, Datenbanken: Für fast alles gibt es offizielle Images. Installation ist ein Befehl, ein Update ist „neues Image holen, Container neu erstellen“.
• Mehrere Versionen nebeneinander. Zwei Shop-Versionen, drei PHP-Versionen, zwei Datenbanken, ohne dass sich etwas in die Quere kommt. Genau so testen wir Updates, bevor sie live gehen.
• Entwicklungsumgebungen. Neue Entwickler im Team klonen das Projekt, tippen docker compose up und haben dieselbe Umgebung wie alle anderen.
• Reproduzierbares Deployment. Das Image, das getestet wurde, ist bitgenau das Image, das live geht.
• Wegwerf-Tests. Etwas ausprobieren, Container löschen, und der Server ist sauber wie vorher.

Wo Docker eher stört

• Eine einzige, einfache Anwendung. Eine statische Website oder ein Node-Dienst, der auf einem Server allein läuft, braucht kein Docker. Ein systemd-Dienst direkt auf dem Server ist oft einfacher zu verstehen und zu debuggen. Unser eigener Blog, den du gerade liest, läuft ganz ohne Container.
• Wenn niemand Docker kennt. Eine zusätzliche Schicht, die im Notfall keiner versteht, ist ein Risiko, keine Vereinfachung.
• Grafische Desktop-Anwendungen. Geht, aber umständlich.
• Maximale Leistung bei Festplatten-I/O. Das Overlay-Dateisystem kostet etwas. Datenbanken gehören deshalb ohnehin in Volumes, die diesen Umweg nicht gehen.
• Nicht vertrauenswürdiger Code. Wegen des geteilten Kernels ist eine VM hier die bessere Grenze.

Docker, Podman, Kubernetes: wer ist wer?

Rund um Docker gibt es ein paar Namen, die gern durcheinander geraten.

Docker Engine ist die eigentliche Software auf dem Server: der Dienst dockerd, der Container verwaltet, und das Kommandozeilenwerkzeug docker. Sie ist Open Source und kostenlos.

Docker Desktop ist die grafische Anwendung für Windows und macOS, die im Hintergrund eine Linux-VM betreibt. Für Privatleute, Bildung und kleine Firmen ist sie kostenlos; größere Unternehmen brauchen laut Docker-Lizenz ein kostenpflichtiges Abonnement. Die aktuellen Schwellenwerte stehen auf der Docker-Website und haben sich in der Vergangenheit geändert, deshalb lohnt sich ein Blick vor dem Einsatz im Unternehmen. Auf einem Linux-Server brauchst du Docker Desktop nicht.

Podman ist eine Alternative von Red Hat, die weitgehend dieselben Befehle versteht, aber ohne dauerhaft laufenden Hintergrunddienst auskommt und Container standardmäßig ohne Root-Rechte startet. Unter Fedora und RHEL ist Podman vorinstalliert. Den genauen Vergleich nehmen wir uns in einem eigenen Artikel vor.

Kubernetes verwaltet Container über viele Server hinweg: Es verteilt sie, startet ausgefallene neu und skaliert bei Last. Für einen einzelnen Server ist Kubernetes fast immer überdimensioniert. Die Faustregel: Ein Server, ein paar Dienste, Docker Compose. Dutzende Server, ein Team für den Betrieb, Kubernetes.

Das OCI-Format (Open Container Initiative) sorgt dafür, dass all diese Werkzeuge dieselben Images verstehen. Ein mit Docker gebautes Image läuft auch unter Podman oder Kubernetes.

ByteMonk (englisch) geht vom Container-Grundprinzip bis zu KI-Modellen, die lokal in Docker laufen. Deutlich länger als die beiden anderen Videos und eher etwas für den zweiten Schritt.

Sicherheit: was Docker schützt und was nicht

Docker isoliert Anwendungen voneinander, aber es ist kein Sicherheitsprodukt. Die Punkte, die in der Praxis zählen:

• Ports an 127.0.0.1 binden, siehe oben. Das ist mit Abstand der häufigste Fehler.
• Die Docker-Gruppe ist praktisch Root. Wer Mitglied der Gruppe docker ist, kann einen Container mit dem Dateisystem des Servers starten und hat damit vollen Zugriff. Füge nur Benutzer hinzu, denen du auch Root-Rechte geben würdest.
• Nur Images aus vertrauenswürdigen Quellen. Offizielle Images und die der Hersteller. Ein zufälliges Image von Docker Hub ist fremder Code, der auf deinem Server läuft.
• Images aktuell halten. Ein Container aktualisiert sich nicht von selbst. Sicherheitslücken in der Basis-Distribution bleiben drin, bis du ein neues Image holst und den Container neu erstellst.
• Versionen festnageln. postgres:16-alpine statt postgres:latest, damit ein Update nicht versehentlich eine neue Hauptversion mitbringt, die deine Daten nicht mehr lesen kann.
• Keine Passwörter ins Image. Zugangsdaten gehören in Umgebungsvariablen oder Secrets zur Laufzeit, nicht in ein Image, das vielleicht irgendwann in einer Registry landet.

Grundlagen zur Absicherung eines Servers insgesamt, von SSH-Schlüsseln bis Firewall, stehen in unserem Artikel Linux-Server einrichten. Wie der sichere Fernzugang selbst funktioniert, erklärt Was ist SSH?.

Was wir bewusst nicht behaupten

Unsere Messungen stammen von einem Server mit reichlich Ressourcen und SSD-Speicher. Auf einem kleinen VPS mit langsamerer Festplatte können Startzeiten höher liegen. Die Startzeit haben wir mit einem bereits heruntergeladenen Image gemessen; ein Image zum ersten Mal zu laden, dauert je nach Größe und Leitung Sekunden bis Minuten. Wir haben keine VM auf derselben Maschine parallel gemessen, der Vergleich mit VMs beruht auf dem Funktionsprinzip, nicht auf einem Benchmark. Und die Lizenzbedingungen für Docker Desktop geben wir bewusst ohne feste Zahlen wieder, weil sie sich ändern können.

Fazit: Was ist Docker, in einem Satz?

Docker ist eine Methode, Software samt allem, was sie braucht, in ein leichtes, austauschbares Paket zu stecken, das überall gleich läuft. Container sind keine kleinen VMs, sondern normale Prozesse mit eigener Sicht auf die Welt. Unsere Messungen bestätigen den Ruf: rund 0,4 Sekunden für einen kompletten Container-Lebenszyklus und 348 KB Speicher für einen Container im Leerlauf.

Die drei Dinge, die über Erfolg oder Frust entscheiden, sind aber keine Zahlen: Daten gehören in Volumes, Ports gehören an 127.0.0.1, und alte Images räumen sich nicht von selbst weg. Wer das von Anfang an beherzigt, hat mit Docker ein Werkzeug, das Serverpflege deutlich einfacher macht. Der nächste Schritt ist Docker Compose, und den haben wir im Docker-Compose-Beispiel mit allen Stolperfallen dokumentiert.

Häufige Fragen zu Docker

Was ist Docker einfach erklärt?

Docker ist ein Werkzeug, das Programme mit allem, was sie brauchen, in ein Paket steckt, das auf jedem Linux-Rechner gleich läuft. Man kann es sich wie standardisierte Schiffscontainer vorstellen: Egal was drin ist, jeder Hafen kann sie verladen. Das Paket heißt Image, das laufende Programm daraus Container.

Was ist der Unterschied zwischen Docker und einer virtuellen Maschine?

Eine virtuelle Maschine simuliert einen kompletten Computer mit eigenem Kernel und Betriebssystem. Ein Docker-Container nutzt den Kernel des Hosts mit und isoliert nur den Prozess. Deshalb startet ein Container in Sekundenbruchteilen und braucht kaum Speicher, ist aber weniger stark abgeschottet. In unserem Test lief ein Alpine-Container mit exakt demselben Kernel wie der Ubuntu-Server darunter.

Was ist der Unterschied zwischen einem Image und einem Container?

Ein Image ist die unveränderliche Vorlage, ein Container die laufende Instanz davon. Aus einem Image kannst du beliebig viele Container starten. Vergleichbar mit einer Backform und den Kuchen, die daraus entstehen.

Ist Docker kostenlos?

Die Docker Engine, die auf Linux-Servern läuft, ist Open Source und kostenlos. Docker Desktop für Windows und macOS ist für Privatpersonen, Bildung und kleine Unternehmen kostenlos, größere Firmen brauchen ein Abonnement. Die genauen Grenzen stehen in den aktuellen Lizenzbedingungen auf docker.com.

Warum sind meine Daten nach einem Container-Neustart weg?

Weil alles, was im Container geschrieben wird, in einer temporären Schicht landet, die beim Löschen des Containers verschwindet. Ein reiner Neustart mit docker restart behält die Daten zwar, aber jedes Update erstellt den Container neu. Daten, die bleiben sollen, gehören in ein Volume oder einen Bind Mount.

Läuft Docker auch unter Windows und macOS?

Ja, über Docker Desktop. Da Linux-Container einen Linux-Kernel brauchen, betreibt Docker Desktop im Hintergrund eine kleine Linux-VM, unter Windows über WSL 2. Für die Praxis merkt man davon wenig, nur Dateizugriffe zwischen Windows und Container sind spürbar langsamer.

Brauche ich Docker für meinen Server?

Nicht zwingend. Für mehrere Anwendungen auf einem Server, Selfhosting fertiger Software und Testumgebungen ist Docker sehr hilfreich. Für eine einzelne, einfache Anwendung reicht oft ein systemd-Dienst direkt auf dem Server, der leichter zu verstehen ist.

Ist Docker sicher?

Docker isoliert Anwendungen voneinander, ist aber kein Sicherheitswerkzeug. Die größten Risiken sind Ports, die an alle Schnittstellen gebunden sind und dabei die Firewall umgehen, Benutzer in der Docker-Gruppe (die praktisch Root-Rechte haben) und veraltete Images. Mit Ports an 127.0.0.1, offiziellen Images und regelmäßigen Updates ist Docker für normale Serveranwendungen gut geeignet.

Was ist der Unterschied zwischen Docker und Kubernetes?

Docker startet und verwaltet Container auf einem Rechner. Kubernetes verteilt Container über viele Server, startet ausgefallene automatisch neu und skaliert bei Last. Für einen einzelnen Server mit ein paar Diensten ist Docker mit Docker Compose die einfachere und passendere Wahl.

Wie viel Speicherplatz braucht Docker?

Das hängt stark von den Images ab: Alpine Linux hat 13 MB, WordPress rund 1 GB, große Entwicklungsimages über 7 GB. Wichtiger ist, dass Docker alte Images, Build-Cache und verwaiste Volumes nicht selbst aufräumt. Auf unserem Server waren 88 Prozent der Image-Daten nicht mehr in Gebrauch. docker system df zeigt den Stand, docker image prune und docker builder prune räumen auf.

Was ist ein Dockerfile?

Ein Dockerfile ist der Bauplan für ein eigenes Image. Es beschreibt Schritt für Schritt, auf welcher Basis gebaut wird, welche Pakete installiert, welche Dateien kopiert und welcher Befehl beim Start ausgeführt wird. Mit docker build wird daraus ein Image.