Container-Laufzeiten im Überblick, Teil 1 Es muss nicht immer Docker mit runc sein

Anbieter zum Thema

DAXTEN GmbH

Kentix GmbH

EPS Rechenzentrum Infrastruktur GmbH

Wer an Container denkt, denkt zunächst an Docker. Hier ist „runc“ die Standard-Engine – dabei gibt es noch eine ganze Reihe anderer Container-Runtimes, die sich ebenso gut für die Software-Entwicklung eignen. Doch worin unterscheiden sich diese?

Container-Runtimes sind praktisch, aber auch komplex. Mit ihrer Hilfe ist es ein Kinderspiel, Anwendungen in einem isolierten, standardisierten und skalierbaren Umfeld zu einem Paket zu schnüren und zu betreiben. Sie funktionieren unabhängig von der zugrundeliegenden Plattform.

Die damit verbundene einfache Übertragbarkeit macht sie sowohl in der Software-Entwicklung als auch später im praktischen Betrieb einer Anwendung nahezu unverzichtbar: Neben der Technologiebranche setzen inzwischen viele Industriebereiche wie der Handel oder Online-Anbieter auf die Technik, um die Homogenität der oft auf viele Server und Systeme verteilten Anwendungen zu gewährleisten.

Wie ein Container funktioniert

Obwohl Docker den „Durchbruch“ der Container-Anwendungen brachte, ist Docker grundsätzlich nicht das einzige System dieser Art. Gemeinsam haben alle Container-Runtimes, dass sie Anwendungen unabhängig, aber nicht isoliert vom zugrundeliegenden Betriebssystem ausführen können.

Alle für den Betrieb notwendigen Dateien befinden sich im Container, das Basissystem muss nur die entsprechende Container-Anwendung vorweisen, damit diese läuft. Damit wird auch vom klassischen Plattformmodell Abstand genommen: Container laufen überall, sofern für das entsprechende System über die Container-Runtime verfügt und damit isolierte Umgebungen zur Verfügung stellen kann.

Drei Typen von Container-Runtimes

Container-Runtimes, die die Entwicklung und den Betrieb von Anwendungen in Containern ermöglichen, können grob in drei Kategorien eingeteilt werden, die aufeinander aufbauen. Es existieren Low-Level Container-Runtimes oder „Native Runtimes“, High-Level Container-Runtimes sowie Sandboxed/Virtual Container-Runtimes. Der Übergang ist oft fließend, weshalb sich die Grenzen je nach Entwicklungsstand der Container-Anwendungen hier und da verschieben können.

Die grundsätzliche Unterteilung lässt sich folgendermaßen vornehmen: Low-Level-Runtimes sind solche, die ausschließlich Container ausführen. High-Level Container-Runtimes besitzen zusätzliche Management-Funktionen, Image-Unterstützung und zusätzliche Interaktionsmöglichkeiten, zudem gibt es gegebenenfalls Verwaltungsoberflächen statt Kommandozeilen-Bedienung. Sandboxed/Virtualized-Anwendungen erlauben außerdem dem plattformübergreifenden Betrieb.

Unübersichtliches Container-Ökosystem

Erschwerend kommt hinzu, dass in der Anwendungsvirtualisierung mittlerweile verschiedene Systeme miteinander konkurrieren, die die Container-Technologie zunächst ausgesprochen komplex erscheinen lassen. Das liegt auch daran, dass verschiedene Unternehmen mit verschiedenen Technologien und Standards am Markt vertreten sind, obendrein gibt es eine blühende Open-Source-Szene.

Im Jahr 2007 wurde cgroups in den Linux-Kernel aufgenommen, das die Erstellung von Low-Level-Containern ermöglicht. Tools wie LXC oder systemd-nspawn bedienen sich dieses Standards, der sehr basale und ressourcensparende Container-Setups ermöglicht.

Zeitgleich kamen allerdings auch kommerzielle Lösungen wie Docker, LMCTFY von Google oder CoreOS mit rkt und appc auf. Diese wiederum waren zum Teil untereinander kompatibel oder auch nicht, wurden aufgrund des Erfolgs von Docker nach und nach aufgegeben und teilweise in Open-Source-Lizenzen überführt, während Docker zusammen mit CoreOS die „Open Container Initiative“ OCI ins Leben rief.

Beide Anbieter stellen Teile der eigenen Software quelloffen zur Verfügung, woraus das Low-Level-Containersystem runc erwuchs. Docker verwendet zudem containerd zur Verwaltung von Images und Ressourcen. Obendrauf sitzt Kubernetes mit dem Container Runtime Interface, das je nach Anwendungsbereich eine Alternative zu Docker darstellen kann.

Kurzum: Im Container-Markt gibt es inzwischen einen ordentlichen Wildwuchs. Dieser ist wahrscheinlich auch der ein Grund für die Popularität von Docker: Im Container-Chaos stellt der Anbieter einen Quasi-Standard dar, der eine High-Level-Umgebung mit hoher Flexibilität zur Verfügung stellt.

Low-Level, High-Level oder virtualized?

Im Grundsatz gilt, dass ein Sandboxed- bzw. Virtualized-Runtime-System auf einem High-Level Runtime aufbaut, das seinerseits eine Low-Level Runtime für die grundsätzlichen Container-Funktionen benötigt. Inwieweit diese miteinander kombiniert werden, liegt nicht selten im Ermessen der Entwickler oder Anwender oder wird von der jeweiligen Umgebung vorgegeben.

Aus diesem Umstand ergibt sich, dass Low-Level Runtimes wie runC, crun oder containerd als Basis für den Betrieb der High-Level-Anwendungen wie Docker oder Kubernetes benötigt werden. Auch Windows-Containers unter Windows Server greift auf dieses Konzept zurück, nutzt dafür aber Microsofts Hyper-V-Isolierung.

Windows hilft beim Verständnis der Ebenen

Microsoft bietet in Windows allerdings auch „Windows-VMs“, die ebenfalls die Hyper-V-Technologie verwenden. Und hier wird deutlich, wo die höchste, nämlich die Virtualisierungsebene von Containern liegt: Virtuelle Systeme sind umfangreich und ressourcenintensiv, weil sie ein eigenes Betriebssystem mitbringen, dafür aber hochgradig portabel und maximal vom Host isoliert. Diese letzte Ebene wird jedoch nur in seltenen Fällen benötigt – was wiederum den Erfolg von Docker und Co. erklärt: Eine High-Level Container-Runtime schafft den idealen Kompromiss zwischen Leistung und Portabilität.

Alternativen zu Docker und Kubernetes

Neben Microsoft gibt es aber noch weitere Alternativen zu Docker und Kubernetes, die auf dem High-Level ansetzen, eine Virtualisierung darstellen oder eine Mischform, darunter OpenVZ, Buildah oder rkt. Als Alternative zu Windows VMs bietet sich zum Beispiel VirtualBox an, wenn es um eine vollständige Virtualisierung geht.

(ID:48760569)