Auch wenn Container im Linux-Umfeld ein alter Hut sind und diese mit den Linux Containers (LXC) schon seit einem guten Jahrzehnt zur Verfügung stehen, gab es den großen Hype um Container erst mit dem Release von Docker im Jahr 2013. Mit Docker stand erstmals eine umfangreiche Lösung zum Betrieb von Applikations-containern zur Verfügung. Implementiert wurde die Engine als umfassender API-Daemon mit vielfältigen Aufgaben. So besteht der primäre Job natürlich darin, Container zu starten und zu stoppen. Aber auch das Management der Images, die zum Betrieb der Container notwendig sind, zählt dazu.
Auch die kryptografische Verifizierung der Container-Images wurde mit Version 1.10 zu den Aufgaben der Docker-Engine hinzugefügt. Da Container über eine IP-Adresse verfügen, benötigt der Daemon ein eigenes Netzwerk-Segment, aus dem IP-Adressen an die Container zugewiesen werden können. Wer mit Hilfe des Commandline-Tools "docker" die Container und auch die Images verwalten möchte, muss ebenfalls mit dem Docker-Daemon kommunizieren. Steht der Service einmal nicht zur Verfügung, laufen auch die Abfragen ins Leere.
All dies zeigt schon das große Problem mit den ersten Implementierungen der Docker-Engine auf. Ohne den Docker-Service ging nämlich gar nichts. Auch wenn dieser zentrale Ansatz für das Deployment von Containern noch sinnvoll erscheinen mag, so entspricht dieser eigentlich nicht mehr modernen Anforderungen, in denen auch Themen wie Prozess-Isolierung oder auch Privilege Separation eine große Rolle spielen.
Das Problem wurde schon frühzeitig erkannt und so sind diverse Projekte entstanden, um alternative Container-Runtimes zu entwickeln. Auch Docker selbst hat dabei einen gewissen Entwicklungsprozess durchlaufen, angetrieben durch die Open Container Initiative (OCI) [1] unter Führung der Linux Foundation. Hierbei handelt es sich um einen Zusammenschluss von bekannten Firmen aus dem Container-Umfeld, zu denen auch Docker
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.