Docker & Container

Entstehung und Beteiligte

Docker wurde 2013 von Solomon Hykes bei dotCloud veröffentlicht. Es baute auf Linux-Namespaces, cgroups, Union-Dateisystemen und Erfahrungen mit LXC auf. Das portable Imageformat und eine einfache Entwickleroberfläche machten Container massentauglich.

Welches Problem sollte gelöst werden?

Anwendungen liefen in Entwicklung, Test und Produktion oft unterschiedlich. Virtuelle Maschinen waren portabel, aber relativ schwer. Container sollten Anwendung und Abhängigkeiten reproduzierbar verpacken und den Kernel gemeinsam nutzen.

Technische Hürden und Lösungen

Isolation über einen gemeinsamen Kernel ist keine vollständige VM-Grenze. Images benötigen sichere Lieferketten, minimale Inhalte und Patchpflege. Persistente Daten, Netzwerke und Ressourcenlimits müssen außerhalb des Containers geplant werden.

Standardisierung und Einordnung

Cloud- und Plattformtechnik entstand aus Rechenzentrum, Virtualisierung, verteilten Systemen und automatisierter Softwareauslieferung. Die grundlegenden Probleme sind nicht neu: Ressourcen müssen geteilt, Ausfälle abgefangen, Änderungen reproduzierbar und Lastspitzen bewältigt werden. Neu ist die hohe Automatisierung und die Möglichkeit, Infrastruktur über Programmierschnittstellen in kurzer Zeit zu erzeugen oder zu verwerfen.

Technik im praktischen Betrieb

Im praktischen Cloudbetrieb müssen Automatisierung und Kosten gemeinsam beobachtet werden. Ressourcen entstehen schnell, verschwinden aber nicht immer automatisch. Tags, Limits, Richtlinien und getrennte Konten oder Projekte schaffen Verantwortlichkeit. Verfügbarkeit sollte über mehrere Fehlerdomänen geplant und mit realen Wiederanlaufproben belegt werden. Ein Anbieter übernimmt Gebäude, Hardware und Teile der Plattform; Konfiguration, Identitäten, Daten, Anwendungen und Backups bleiben je nach Dienstmodell ganz oder teilweise beim Kunden.

Warum das Thema heute noch relevant ist

Viele Cloudbegriffe klingen neu, beschreiben aber bekannte verteilte Systeme unter stärkerer Automatisierung. Die Geschichte hilft, Marketing und Architektur zu trennen. Ein Dienst bleibt von Netz, Speicher, Konsens und Identitäten abhängig, auch wenn diese Schichten nicht sichtbar sind. Betreiber sollten deshalb Ausfallmodelle, Datenexport und Abhängigkeiten dokumentieren. Je bequemer ein verwalteter Dienst ist, desto wichtiger wird die Frage, welche Kontrolle bewusst an den Anbieter abgegeben wurde.

Daten und Meilensteine

• 2013 wird Docker öffentlich vorgestellt.
• 2015 entsteht die Open Container Initiative.
• Images bestehen aus wiederverwendbaren Layern.
• Ein Container ist ein isolierter Prozess, kein kleiner vollständiger Server.

Was sind Container?

Container sind isolierte Laufzeitumgebungen für Anwendungen. Im Gegensatz zu VMs teilen sie sich den OS-Kernel des Hosts, starten in Sekunden und sind nur Megabytes groß (statt Gigabytes). Die Isolation erfolgt über Linux-Namespaces (Prozesse, Netzwerk, Dateisystem) und cgroups (Ressourcenlimits).

Docker ist die populärste Container-Plattform. Ein Docker-Image ist das read-only Template (Schichten-Modell, Union Filesystem). Ein laufender Container ist eine beschreibbare Instanz daraus. Images werden in Registries gespeichert (Docker Hub, AWS ECR, GitLab Registry).

Docker-Konzepte

• Dockerfile: Textdatei mit Build-Instruktionen (FROM, COPY, RUN, EXPOSE, CMD). Jede Anweisung erzeugt einen Layer.
• Image: Immutabler Snapshot – einmal gebaut, überall lauffähig. Layered caching beschleunigt Rebuilds.
• Container: Laufende Instanz eines Images. Zustandsbehaftet, aber stateless design ist Best Practice.
• Volume: Persistenter Speicher außerhalb des Container-Filesystems (Datenbanken, Config).
• docker-compose: Multi-Container-Orchestrierung für lokale Entwicklung (YAML-Definition).
• Docker Networking: Bridge (default), Host, Overlay (Swarm), None.

Docker-Sicherheit

Container sind keine VMs – die Isolation ist schwächer. Best Practices: Non-root User in Container (USER directive), read-only Filesystem, minimale Base-Images (alpine, distroless), Image-Scanning (Trivy, Snyk), keine Secrets in Images oder Env-Variablen (Vault, Kubernetes Secrets nutzen), regelmäßige Image-Updates gegen CVEs.