Container als Standardverpackung. Warum „läuft auf meinem Rechner" damit kein Argument mehr ist.
Kategorie · DevOps & Infra
Was Docker ist.
Docker verpackt eine Anwendung samt allen Abhängigkeiten — Laufzeit, Bibliotheken, Konfiguration — in ein abgeschlossenes Image. Dieses Image läuft auf jedem Host identisch, egal ob Laptop, CI-Runner oder Produktionsserver.
Anders als eine virtuelle Maschine bringt ein Container kein eigenes Betriebssystem mit, sondern teilt sich den Kernel des Hosts. Das macht ihn leicht: Sekunden statt Minuten zum Start, Megabyte statt Gigabyte.
Warum wir konsequent containerisieren.
Jedes Produkt, das wir bauen und betreiben, läuft im Container. Damit ist die Umgebung Teil des Codes — der Satz "läuft auf meinem Rechner" ist kein Argument mehr, weil die Umgebung überall dieselbe ist.
Das senkt den Onboarding-Aufwand für neue Entwickler auf ein "docker compose up" und macht Deployments reproduzierbar. Genau das brauchen wir für nachvollziehbare, auditierbare Betriebsketten.
Wo die Grenze liegt.
Docker löst das Verpacken, nicht das Orchestrieren. Sobald mehrere Container über Maschinen hinweg skalieren, ausfallsicher laufen und automatisch ersetzt werden müssen, braucht es eine Ebene darüber — meist Kubernetes.
Für einen einzelnen Server mit ein paar Services reicht Docker Compose. Erst die Last und die Verfügbarkeitsanforderung entscheiden, ob mehr nötig ist.
