Docker ist eines dieser Werkzeuge, über das gefühlt jeder in der IT irgendwann stolpert. In Stellenausschreibungen taucht es ständig auf, Entwickler reden darüber, Admins sowieso, und irgendwo fällt dann fast immer der Satz: „Pack das doch einfach in einen Container.“
Spätestens dann kommt die naheliegende Frage: Was ist Docker eigentlich genau? Und direkt danach: Wie funktioniert das technisch – und warum ist das so praktisch?
Genau darum geht es in diesem Beitrag. Du bekommst keine Marketing-Erklärung, sondern ein sauberes, verständliches Bild davon, was Docker ist, wie Container funktionieren, worin der Unterschied zu virtuellen Maschinen liegt und warum Docker den Alltag in Entwicklung und Betrieb so stark verändert hat.
⸻
Docker in einem Satz
Docker ist eine Plattform, mit der Du Anwendungen in isolierten Containern verpacken, starten und verteilen kannst.
Ein Container enthält alles, was eine Anwendung zum Laufen braucht: zum Beispiel den Code, Laufzeitumgebungen, Bibliotheken, Tools und Konfigurationen. Dadurch läuft die Anwendung auf unterschiedlichen Systemen möglichst gleich.
Oder einfacher gesagt:
Docker sorgt dafür, dass eine Software nicht nur auf Deinem Rechner funktioniert, sondern überall reproduzierbar startet.
⸻
Das eigentliche Problem: „Bei mir läuft’s“
Bevor Docker populär wurde, sah der Alltag oft so aus: • Auf dem Entwickler-PC lief die Anwendung. • Auf dem Testsystem gab es plötzlich andere Paketversionen. • Auf dem Server fehlte eine Bibliothek. • Die Produktionsumgebung verhielt sich anders als die lokale Umgebung.
Dann kamen die typischen Aussagen: • „Auf meinem Rechner geht es.“ • „In der Testumgebung lief es noch.“ • „Irgendwas stimmt mit dem Server nicht.“
Das Problem war selten nur der Code. Meist war es die Umgebung: andere Betriebssysteme, andere Versionen, andere Abhängigkeiten, andere Konfigurationen.
Docker setzt genau dort an. Statt nur den Code zu verschieben, verschiebst Du gleich die komplette Anwendungsumgebung mit.
⸻
Was ist ein Container?
Ein Container ist eine leichtgewichtige, isolierte Laufzeitumgebung für eine Anwendung.
Das bedeutet: • Die Anwendung läuft getrennt vom restlichen System. • Sie bringt ihre benötigten Abhängigkeiten mit. • Sie teilt sich zwar den Kernel des Host-Systems, ist aber logisch abgeschottet.
Wichtig ist dabei: Ein Container ist keine virtuelle Maschine.
Ein Container enthält in der Regel nicht ein komplettes eigenes Betriebssystem mit eigenem Kernel. Stattdessen nutzt er den Kernel des Host-Systems mit und kapselt den Rest.
Dadurch sind Container sehr viel schlanker und starten deutlich schneller als klassische VMs.
⸻
Docker ist nicht der Container selbst
Oft werden diese Begriffe durcheinandergeworfen. Deshalb sauber getrennt: • Container ist das Konzept der gekapselten Anwendung. • Docker ist das Werkzeug bzw. die Plattform, mit der Du solche Container baust, startest und verwaltest.
Docker hat Container nicht komplett neu erfunden, aber Docker hat sie massentauglich gemacht. Die Idee der Linux-Container gab es vorher schon. Docker hat sie benutzbar, portabel und praktikabel gemacht.
⸻
Der Unterschied zwischen Docker und virtuellen Maschinen
Der Vergleich hilft enorm, um Docker wirklich zu verstehen.
Virtuelle Maschine
Bei einer virtuellen Maschine läuft auf einem Host-System ein Hypervisor. Darauf starten mehrere VMs. Jede VM bringt ihr eigenes vollständiges Gastbetriebssystem mit.
Das bedeutet: • mehr Ressourcenverbrauch • mehr Speicherbedarf • längere Startzeiten • oft mehr Verwaltungsaufwand
Docker-Container
Bei Docker laufen mehrere Container auf einem Host-System. Alle nutzen denselben Kernel des Hosts, sind aber voneinander isoliert.
Das bedeutet: • deutlich weniger Overhead • schnellere Startzeiten • kleinere Images • einfachere Reproduzierbarkeit
Die praktische Kurzform
Eine VM ist wie ein komplett eigenes Haus. Ein Container ist eher wie eine abgetrennte Wohnung in einem großen Gebäude.
Du hast Deinen eigenen Bereich, aber bestimmte Grundlagen werden gemeinsam genutzt.
⸻
Warum Docker so beliebt ist
Docker hat sich nicht durchgesetzt, weil es „cool“ klingt, sondern weil es echte Probleme löst.
- Gleiche Umgebung überall
Eine Anwendung, die lokal im Container läuft, kann sehr ähnlich auch auf dem Testsystem oder Server laufen.
- Schnelles Aufsetzen
Du musst nicht erst lange Server vorbereiten. Ein passendes Image reicht oft aus, und wenige Sekunden später läuft der Dienst.
- Saubere Isolation
Mehrere Anwendungen können auf demselben Host laufen, ohne sich gegenseitig direkt kaputtzukonfigurieren.
- Einfaches Verteilen
Container lassen sich gut versionieren und weitergeben. Du baust ein Image und kannst genau dieses Image in anderen Umgebungen einsetzen.
- Gute Automatisierung
Docker passt hervorragend zu CI/CD, Testpipelines und Infrastruktur als Code.
⸻
Die wichtigsten Begriffe in Docker
Damit das Ganze greifbar wird, musst Du ein paar Grundbegriffe kennen.
Docker Image
Ein Image ist die Vorlage für einen Container.
Du kannst es Dir wie einen Bauplan oder einen Schnappschuss vorstellen. Darin steht, was alles enthalten ist: Betriebssystem-Basis, Pakete, Laufzeitumgebung, Anwendungscode und Konfiguration.
Ein Image ist unveränderlich. Wenn Du etwas änderst, erzeugst Du normalerweise ein neues Image.
Docker Container
Ein Container ist die laufende Instanz eines Images.
Also vereinfacht: • Image = Vorlage • Container = gestartete Anwendung auf Basis dieser Vorlage
Du kannst aus einem Image mehrere Container starten.
Dockerfile
Ein Dockerfile ist eine Textdatei mit Anweisungen, wie ein Image gebaut werden soll.
Darin steht zum Beispiel: • welches Basis-Image genutzt wird • welche Pakete installiert werden • welche Dateien kopiert werden • welcher Befehl beim Start ausgeführt wird
Docker Registry
Eine Registry ist ein Speicherort für Images.
Die bekannteste ist Docker Hub. Dort liegen fertige Images wie etwa für Nginx, Redis, PostgreSQL oder Ubuntu. Unternehmen betreiben oft auch eigene private Registries.
Volumes
Container sind standardmäßig eher flüchtig. Wenn ein Container gelöscht wird, sind interne Änderungen oft weg.
Volumes lösen genau dieses Problem. Damit kannst Du Daten dauerhaft außerhalb des Containers speichern.
Typische Beispiele: • Datenbankdaten • Uploads • Konfigurationsdateien • Logs
Netzwerke
Docker kann Container in eigene Netzwerke packen. Dadurch können sie miteinander kommunizieren, ohne direkt alles ans Host-System zu hängen.
Das ist wichtig, wenn zum Beispiel: • ein Webserver • eine API • und eine Datenbank
zusammenarbeiten sollen.
⸻
Wie funktioniert Docker technisch?
Jetzt wird es spannend.
Docker nutzt unter Linux im Kern Mechanismen des Betriebssystems, um Prozesse voneinander zu isolieren. Die wichtigsten Ideen dahinter sind:
Namespaces
Namespaces sorgen dafür, dass ein Container nur einen eingeschränkten Blick auf das System hat.
Beispielsweise sieht ein Container: • seine eigenen Prozesse • seine eigene Netzwerksicht • eigene Mountpoints • eigene Hostnamen
Dadurch wirkt es für die Anwendung so, als würde sie in einer eigenen Welt laufen.
Cgroups
Cgroups regeln, wie viele Ressourcen ein Container nutzen darf.
Damit kannst Du festlegen oder begrenzen: • CPU • RAM • I/O • andere Systemressourcen
Das verhindert, dass ein einzelner Container den ganzen Host auffrisst.
Union Filesystem / Layer
Docker-Images bestehen aus Schichten, auch Layers genannt.
Das ist einer der cleversten Punkte an Docker: • Ein Basis-Image bildet die unterste Schicht. • Weitere Befehle im Dockerfile erzeugen zusätzliche Schichten. • Beim Start eines Containers kommt eine beschreibbare Schicht oben drauf.
Der Vorteil: Schichten lassen sich cachen und wiederverwenden. Dadurch werden Builds schneller und Images effizienter verteilt.
Beispiel:
Wenn zehn Container dasselbe Ubuntu-Basis-Image verwenden, muss diese Schicht nicht zehnmal komplett neu gespeichert werden.
⸻
So läuft ein Docker-Container wirklich ab
Nehmen wir an, Du startest einen simplen Webserver mit Docker.
Dann passiert grob Folgendes: 1. Docker prüft, ob das gewünschte Image lokal vorhanden ist. 2. Falls nicht, wird es aus einer Registry geladen. 3. Aus dem Image wird ein Container erzeugt. 4. Docker richtet Dateisystem, Netzwerk und Isolation ein. 5. Der Startbefehl des Containers wird ausgeführt. 6. Die Anwendung läuft als Prozess im Container.
Ganz wichtig dabei: Ein Container lebt in der Regel so lange, wie sein Hauptprozess läuft.
Stoppt dieser Prozess, stoppt meist auch der Container.
Das ist für Einsteiger anfangs ungewohnt, weil man manchmal erwartet, dass ein Container wie ein kompletter Mini-Server dauerhaft „einfach da ist“. In Wahrheit ist ein Container eher an einen Hauptprozess gekoppelt.
⸻
Ein erstes Beispiel
Angenommen, Du willst einen Nginx-Webserver starten. Dann reicht schon so etwas:
docker run -d -p 8080:80 nginx
Was passiert hier? • docker run startet einen Container • -d bedeutet: im Hintergrund laufen • -p 8080:80 verbindet Port 8080 des Hosts mit Port 80 im Container • nginx ist das Image
Danach erreichst Du Nginx im Browser über den Host auf Port 8080.
Das ist einer der Gründe, warum Docker so beliebt ist: Mit einem einzigen Befehl läuft in Sekunden ein Dienst, für dessen manuelle Installation Du sonst deutlich länger brauchen würdest.
⸻
Was steckt in einem Dockerfile?
Sobald Du Deine eigene Anwendung containerisieren willst, arbeitest Du meist mit einem Dockerfile.
Ein einfaches Beispiel für eine Node.js-Anwendung:
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./ RUN npm install
COPY . .
EXPOSE 3000
CMD ["npm", "start"]
Schauen wir uns das an:
FROM
Damit legst Du das Basis-Image fest. Hier ist es ein Node.js-Image auf Alpine-Basis.
WORKDIR
Setzt das Arbeitsverzeichnis im Container.
COPY
Kopiert Dateien vom lokalen Projekt in das Image.
RUN
Führt beim Bauen des Images einen Befehl aus. Hier werden die Abhängigkeiten installiert.
EXPOSE
Dokumentiert, auf welchem Port die Anwendung im Container lauscht.
CMD
Legt fest, welcher Befehl beim Start des Containers standardmäßig ausgeführt wird.
Danach kannst Du das Image bauen:
docker build -t meine-app .
Und starten:
docker run -p 3000:3000 meine-app
⸻
Warum Images geschichtet aufgebaut sind
Das Layer-Prinzip hat in der Praxis enorme Vorteile.
Stell Dir vor, Du änderst in Deinem Projekt nur eine einzige Code-Datei. Dann muss Docker nicht alles komplett neu bauen. Viele Schichten bleiben unverändert und können aus dem Cache übernommen werden.
Deshalb ist die Reihenfolge im Dockerfile wichtig.
Ein typischer Trick ist: 1. zuerst Abhängigkeitsdateien kopieren 2. Pakete installieren 3. erst danach den eigentlichen Anwendungscode kopieren
So werden die teuren Schritte seltener neu ausgeführt.
Bei Node.js also oft so:
COPY package*.json ./ RUN npm install COPY . .
Wenn sich nur der Code ändert, aber nicht package.json, kann Docker die npm install-Schicht weiterverwenden.
⸻
Container sind nicht für dauerhafte Daten gemacht
Ein häufiger Denkfehler bei Anfängern: „Ich installiere alles im Container, ändere dort Dateien und speichere Daten darin.“
Das funktioniert zwar erstmal, ist aber meist der falsche Ansatz.
Container sollten möglichst stateless gedacht werden. Das heißt: • Anwendung im Container • dauerhafte Daten außerhalb des Containers
Dafür gibt es Volumes oder Bind Mounts.
Ein Beispiel mit einem Volume für PostgreSQL:
docker run -d
--name db
-e POSTGRES_PASSWORD=geheim
-v pgdata:/var/lib/postgresql/data
postgres
Hier landen die Datenbankdaten nicht nur im flüchtigen Container-Dateisystem, sondern in einem Volume namens pgdata.
Das ist wichtig, weil Du Container jederzeit neu erzeugen oder austauschen können willst, ohne dabei Daten zu verlieren.
⸻
Docker Compose: mehrere Container zusammen starten
In der Praxis besteht eine Anwendung oft nicht aus genau einem Container.
Typisches Beispiel: • Webanwendung • Datenbank • Redis • Reverse Proxy
Diese Komponenten willst Du nicht einzeln per Hand starten. Genau dafür gibt es Docker Compose.
Damit beschreibst Du mehrere Dienste in einer compose.yaml.
Ein Beispiel:
services: web: build: . ports: - "3000:3000" depends_on: - db
db: image: postgres:16 environment: POSTGRES_PASSWORD: geheim volumes: - dbdata:/var/lib/postgresql/data
volumes: dbdata:
Dann startest Du alles zusammen mit:
docker compose up -d
Das ist extrem praktisch, weil Du damit ganze Anwendungsstapel reproduzierbar definieren kannst.
Gerade in Entwicklung, Testumgebungen und kleinen Deployments ist das Gold wert.
⸻
Ein typischer Ablauf mit Docker im Alltag
Damit es nicht zu abstrakt bleibt, hier ein realistischer Ablauf.
Du entwickelst eine Webanwendung. Lokal brauchst Du: • die App selbst • eine Datenbank • eventuell einen Cache • vielleicht einen Nginx-Proxy
Früher hättest Du auf Deinem Rechner alles einzeln installiert und konfiguriert. Mit Docker definierst Du stattdessen die gesamte Umgebung in Dateien.
Dann passiert Folgendes: 1. Du holst das Projekt aus Git. 2. Du startest die Container mit docker compose up. 3. Alle benötigten Dienste laufen in gleicher oder sehr ähnlicher Form wie bei Kollegen oder in der Testumgebung. 4. Änderungen am Code baust oder mountest Du nach Bedarf neu ein. 5. Für Deployment baust Du ein neues Image und rollst es auf dem Zielsystem aus.
Das reduziert „Umgebungschaos“ massiv.
⸻
Docker im Vergleich zur klassischen Paketinstallation
Stell Dir vor, Du willst auf einem Server drei Anwendungen betreiben: • App A braucht Python 3.10 • App B braucht Python 3.12 • App C braucht eine ganz bestimmte Bibliotheksversion
Ohne Docker wird das schnell unerquicklich. Mit Docker packst Du jede Anwendung in ihren eigenen Container samt passender Laufzeit.
Dadurch beeinflussen sich die Anwendungen weit weniger gegenseitig.
Das ist einer der größten praktischen Vorteile im Betrieb.
⸻
Ist Docker dasselbe wie Kubernetes?
Nein.
Docker und Kubernetes werden oft in einem Atemzug genannt, sind aber nicht dasselbe. • Docker kümmert sich vor allem um das Bauen und Ausführen von Containern. • Kubernetes ist eine Plattform zur Orchestrierung vieler Container auf vielen Systemen.
Einfach gesagt:
Docker hilft Dir, Container zu erstellen und zu starten. Kubernetes hilft Dir, sehr viele Container über mehrere Hosts hinweg automatisiert zu verwalten.
Für kleine und mittlere Setups reicht Docker oft völlig aus. Für große, verteilte Plattformen kommt häufig ein Orchestrierungssystem dazu.
⸻
Sicherheit: Container sind keine magische Sandbox
Ein wichtiger Punkt: Docker bringt Isolation, aber keine absolute Unverwundbarkeit.
Viele Anfänger denken: „Läuft im Container, also komplett sicher.“
So einfach ist es nicht.
Container teilen sich den Kernel des Host-Systems. Wenn dort Schwachstellen vorhanden sind oder Container falsch konfiguriert werden, kann das problematisch werden.
Wichtige Grundregeln: • keine unnötigen Root-Rechte im Container • möglichst kleine Basis-Images verwenden • Images aktuell halten • nur notwendige Ports freigeben • Secrets nicht hart in Images einbauen • offizielle oder vertrauenswürdige Images verwenden • Container-Rechte begrenzen
Docker verbessert Struktur und Isolation, ersetzt aber kein sauberes Sicherheitskonzept.
⸻
Warum kleine Images meistens besser sind
Große Images haben mehrere Nachteile: • längere Build-Zeiten • längere Download-Zeiten • größere Angriffsfläche • mehr Ballast
Deshalb sieht man oft schlanke Basis-Images wie alpine oder sogenannte Multi-Stage-Builds.
Bei einem Multi-Stage-Build baust Du die Anwendung in einer ersten Stage und kopierst nur das Endergebnis in ein möglichst kleines Laufzeit-Image.
Das spart Platz und reduziert unnötige Bestandteile wie Compiler oder Build-Tools im finalen Container.
Ein grob vereinfachtes Beispiel:
FROM golang:1.22 AS builder WORKDIR /src COPY . . RUN go build -o app .
FROM alpine:3.20 WORKDIR /app COPY --from=builder /src/app . CMD ["./app"]
Im finalen Image landet nur die fertige Binärdatei, nicht die komplette Go-Buildumgebung.
⸻
Was Docker besonders gut kann
Docker ist stark, wenn Du: • Entwicklungsumgebungen standardisieren willst • Anwendungen reproduzierbar deployen möchtest • Dienste sauber voneinander trennen willst • lokale Tests schnell aufsetzen musst • CI/CD-Pipelines vereinfachen willst • Legacy-Anwendungen mit festen Abhängigkeiten kapseln willst
Gerade für Teams ist Docker oft ein enormer Produktivitätsgewinn, weil weniger Zeit in „Warum läuft das hier anders?“ verloren geht.
⸻
Wo Docker nicht automatisch jedes Problem löst
Docker ist nützlich, aber kein Allheilmittel.
Docker löst nicht automatisch: • schlechte Architektur • kaputte Deployments • unsaubere Konfiguration • fehlendes Monitoring • fehlende Backups • mangelnde Sicherheit
Und Docker macht manche Dinge auch komplexer: • Netzwerkverständnis wird wichtiger • Persistenz muss bewusst geplant werden • Debugging verhält sich teilweise anders • Logs, Volumes und Container-Lebenszyklen wollen verstanden werden
Wer Docker nutzt, bekommt also nicht „weniger Technik“, sondern oft mehr Struktur. Und genau das ist der Vorteil.
⸻
Was passiert beim Starten und Stoppen eines Containers?
Das ist wichtig für das Verständnis im Betrieb.
Wenn Du einen Container startest, startet Docker den festgelegten Hauptprozess. Wenn dieser Prozess endet, endet der Container.
Beispiele: • Ein Nginx-Container läuft, solange Nginx läuft. • Ein PostgreSQL-Container läuft, solange der Datenbankprozess läuft. • Ein Container mit bash endet oft sofort, wenn die Shell beendet wird.
Darum wirken manche Container auf Anfänger kaputt, obwohl sie nur keinen dauerhaften Vordergrundprozess haben.
⸻
Docker im Entwicklungsalltag
Gerade lokal bringt Docker oft Ordnung in Projekte.
Ein typisches Szenario:
Du steigst in ein neues Projekt ein. Ohne Docker müsstest Du erst herausfinden: • welche Runtime gebraucht wird • welche Versionen nötig sind • welche Datenbank lokal laufen muss • welche Zusatzdienste gebraucht werden • welche Umgebungsvariablen gesetzt werden müssen
Mit Docker ist vieles davon im Projekt definiert. Du startest die Umgebung und kannst deutlich schneller loslegen.
Besonders angenehm ist das bei: • Microservices • Projekten mit vielen Abhängigkeiten • Mischumgebungen mit verschiedenen Sprachen • älteren Anwendungen mit heiklen Versionen
⸻
Docker in Produktion: sinnvoll, aber bewusst
Auch in Produktion ist Docker sehr verbreitet. Aber dort zählt nicht nur, ob ein Container startet, sondern ob das Gesamtsystem sauber aufgebaut ist.
Wichtige Themen im Produktivbetrieb sind unter anderem: • Logging • Monitoring • Health Checks • Restart-Strategien • Geheimnisverwaltung • Ressourcenbegrenzung • Backups • Updates und Rollbacks
Ein Container ersetzt keinen Betrieb. Er ist nur ein sehr gutes Verpackungsformat für Anwendungen.
⸻
Ein einfaches Bild für das Gesamtverständnis
Wenn Du Dir nur ein einziges Modell merken willst, dann dieses:
Ein Docker-Image ist das Rezept. Ein Docker-Container ist das fertig gekochte Gericht.
Das Rezept beschreibt, wie etwas gebaut wird. Das Gericht ist die laufende Instanz.
Und Docker ist die Küche mit den Werkzeugen, die dafür sorgt, dass das Ergebnis überall möglichst gleich entsteht.
⸻
Die häufigsten Anfängerfehler
Wer mit Docker anfängt, stolpert oft über dieselben Dinge.
„Ich behandle den Container wie einen Server“
Ein Container ist normalerweise kein Haustier, sondern eher Wegwerf-Infrastruktur. Du baust neu, statt per Hand im laufenden Container herumzuschrauben.
„Meine Daten sind weg“
Dann lagen die Daten vermutlich im Container-Dateisystem statt in einem Volume.
„Der Container stoppt sofort“
Dann endet wahrscheinlich der Hauptprozess direkt nach dem Start.
„Ich packe alles in einen riesigen Container“
Besser ist meist eine saubere Trennung nach Verantwortlichkeiten.
„Ich nutze root und öffne alle Ports“
Das mag erstmal bequem sein, ist aber selten eine gute Idee.
⸻
Für wen Docker besonders interessant ist
Docker ist nicht nur etwas für große Plattformteams.
Es lohnt sich für: • Entwickler, die reproduzierbare Umgebungen wollen • Admins, die Dienste sauber kapseln möchten • DevOps-Teams, die Build- und Deploy-Prozesse standardisieren wollen • Tester, die schnell komplette Umgebungen starten müssen • Unternehmen, die weniger Umgebungsdrift haben wollen
Gerade wenn mehrere Menschen an denselben Anwendungen arbeiten, macht Docker oft sehr schnell einen Unterschied.
⸻
Die ehrliche Antwort auf „Brauche ich Docker?“
Nicht zwingend immer.
Für ein kleines Skript auf Deinem Einzelplatzrechner ist Docker oft unnötig. Für eine ernsthafte Anwendung mit Abhängigkeiten, mehreren Diensten, Teamarbeit oder Deployment-Anforderungen ist Docker dagegen oft sehr sinnvoll.
Die Frage ist also weniger: „Ist Docker modern?“
Sondern eher: „Hilft Docker dabei, meine Anwendung sauberer, reproduzierbarer und einfacher betreibbar zu machen?“
Wenn die Antwort darauf ja ist, lohnt sich Docker meistens.
⸻
Fazit
Docker ist im Kern ein Werkzeug, um Anwendungen konsistent, isoliert und portabel auszuführen.
Statt nur Code zu verschieben, verschiebst Du die Umgebung gleich mit. Dadurch werden Entwicklung, Test und Deployment deutlich berechenbarer.
Die wichtigsten Punkte noch einmal auf den Punkt gebracht: • Docker arbeitet mit Containern, nicht mit klassischen virtuellen Maschinen • Container sind leichtgewichtig und starten schnell • Images dienen als Vorlage für Container • Dockerfiles beschreiben reproduzierbar, wie Images gebaut werden • Volumes speichern dauerhafte Daten • Compose hilft beim Start mehrerer zusammengehöriger Dienste • Docker schafft Struktur, ersetzt aber kein solides Betriebs- und Sicherheitskonzept
Wer Docker einmal sauber verstanden hat, merkt schnell: Es geht nicht darum, „ein neues Tool zu lernen“. Es geht darum, Anwendungen so zu verpacken, dass sie berechenbar laufen.
Und genau deshalb ist Docker in so vielen Projekten praktisch unverzichtbar geworden.