Docker oder Kubernetes? In 9 von 10 Fällen: Docker reicht.
Kubernetes wird oft als Ziel verkauft, Docker als Pflichtübung davor. Kommt aus der Cloud-Ecke, wird überall als „Modern Standard“ gehandelt. Im Alltag? Für viele kleine bis mittlere Webprojekte einfach zu viel Ballast. Wer nicht gerade ein halbes Dutzend Microservices mit mehreren Teams orchestriert, bleibt besser bei Docker. Kein Cluster-Zoo, kein YAML-Gewitter, kein Overhead. PHP-Anwendung? Node.js-Stack? Läuft auch ohne das ganz große Besteck stabil.
Das Hauptziel: Entwicklung und Produktion laufen gleich. Docker bekommt das mit erstaunlich wenig Aufwand hin. Auf dem eigenen Rechner das Gleiche wie später auf dem Server – das war früher ein Problem. Heute: Docker Compose, paar Zeilen, fertig. Alles andere ist für die meisten Projekte Overengineering.
Images: Basis, Stolperstein und Performance-Bremse
Images sind die Blaupause. Da steckt alles drin: System, Runtime (z.B. PHP 8.3, Node.js 20), Abhängigkeiten, Sourcecode. Das Versprechen: Einmal bauen, überall starten. Funktioniert – wenn das Image schlank gehalten wird. In Agenturen sieht man oft Images mit 600 MB oder mehr. Klar, die Standard-Varianten werden einfach übernommen. Alpine oder Slim sparen locker 100–200 MB. Das merkt man spätestens beim Deployment. Dauert sonst ewig.
Ein häufiger Fehler: Im Dockerfile werden Dinge ständig neu gebaut oder installiert, die sich selten ändern. Wer Layers clever sortiert (z.B. erst System, dann Abhängigkeiten, dann Source), spart Zeit beim Build. Der Cache ist nicht nur Deko, sondern macht den Unterschied zwischen 10 und 2 Minuten Buildzeit.
Container: Sandbox, aber kein Selbstzweck
Ein Container ist einfach das Image in Aktion. Eigene Prozesse, eigenes Dateisystem – alles isoliert. Reicht für fast alle Projekte. Docker Compose regelt das Zusammenspiel: Webserver, Datenbank, Caching, alles in eigenen Containern, ein Befehl und der ganze Stack fährt hoch. Kubernetes? Braucht hier niemand. Die meisten Projekte haben nicht mal fünf Services parallel laufen.
Alltag: Container abschießen, neu bauen, wieder starten. Fehler? Meistens sofort im Container zu finden. Logs direkt abrufen, nicht erst in irgendeinem Monitoring-Tool suchen. Saubere Trennung spart Ärger – aber nur, wenn die Daten nicht versehentlich im Container landen.
Volumes: Daten sichern – oder halt verlieren
Container sind Wegwerfware. Volumes nicht. Wer Daten (Datenbanken, Uploads, Logs) im Container speichert, verliert sie beim nächsten Rebuild. Klassiker in Agenturen: Daten sind weg nach "docker-compose down" – schon gesehen, öfter als einem lieb ist.
Volumes werden in der docker-compose.yml definiert. Nicht schwer, aber gerne vergessen. Backups laufen außerhalb des Containers, meist per Script oder Cronjob. Wichtig: Pfade klar halten, sonst sucht man stundenlang nach den Daten.
Meine Einschätzung nach 30 Jahren Webentwicklung
Docker hat das Leben in Agenturen und für Einzelkämpfer einfacher gemacht. Früher: "Läuft nur bei mir"-Debatten, produktive Umgebung abweichend, Fehler schwer zu reproduzieren. Jetzt? Gleicher Stack überall. Kubernetes ist für kleine Teams oder Einzelentwickler meist einfach zu viel. Macht erst Sinn, wenn fünf Teams gleichzeitig an 20 Services schrauben – dann vielleicht.
In Agenturen mit fünf bis zehn Leuten: Docker Compose reicht für Staging, Tests und Deployment. Einstieg ist schnell gemacht, Wartung bleibt überschaubar. Aber: Volumes gehören immer auf die Backup-Liste. Kein Backup, keine Daten. So einfach ist das leider immer noch.
Selbstständige mögen Docker besonders. Kein Overhead, keine Extra-Tools, kein Frickeln. Container starten, fertig. Kubernetes ist spannend für die Hipster-Fraktion, bringt aber meistens mehr Ärger als Nutzen, wenn’s nur um eine Handvoll Projekte geht. Die Erfahrung der letzten Jahre: Wer Docker versteht, erspart sich viele klassische Fehler.
Alltags-Tipps, die wirklich helfen
- Base-Images: Immer die kleinen nehmen – Alpine oder Slim, nie das Standard-Monster.
- Dockerfile: Layers mit viel Change nach hinten, damit der Cache hilft.
- Compose: Mehrere Services? Docker Compose reicht, Kubernetes ist dann unnötig.
- Volumes: Immer raus aus dem Container, sauber definieren, regelmäßig sichern.
- Logs: Direkt im Container lesen, nicht blind auf externe Tools verlassen.
- Updates: Container regelmäßig neu bauen, Sicherheitslücken werden sonst schnell ein Problem.
Fehler passieren fast immer bei Volumes und Images. Einmal sauber aufgesetzt, spart das später Nerven. Wer mehr Input will: Diskussion dazu im Forum, Link hier: Docker im Webprojekt-Alltag: Was wirklich hilft, wo’s hakt.
Weiterlesen: Docker und PHP-Stacks in echt
Wer tiefer will: Artikel wie Docker im Webprojekt-Alltag: Was wirklich hilft, wo’s hakt und PHP-8-Upgrade im Bestand: Migration ohne Aussetzer liefern Praxis pur für Docker & PHP, Updates und Umgebungswechsel.
Fazit: Docker reicht – meistens
Für die meisten Webentwickler und Agenturen bleibt Docker ohne Kubernetes die pragmatische Wahl. Images, Container, Volumes – das reicht für stabile, nachvollziehbare Abläufe. Kubernetes? Lohnt sich erst, wenn’s richtig groß wird. Bis dahin: Weniger Stress, mehr Zeit fürs eigentliche Entwickeln.
bye
mo