Alternativen zu Docker: Container-Plattform im Überblick

Mit der Container-Plattform Docker feiert die Virtualisierung auf Betriebssystemebene (Operating-System-Level-Virtualisierung) ein Revival. Binnen weniger Jahre ist es dem Entwicklerteam gelungen, die auf Kernel-Funktionalitäten basierende Container-Technologie wiederzubeleben. Sie etablierte sich über die Grenzen des Linux-Universums hinweg als ressourcensparende Alternative zur hypervisorgestützten Virtualisierung durch Hardware-Emulation.

Dank des medialen Echos und eines ständig wachsenden Ökosystems hat sich Docker zum technologischen Marktführer auf dem Gebiet der containerbasierten Virtualisierung aufgeschwungen. Die schlanke Container-Plattform ist jedoch längst nicht das einzige Software-Projekt, in dem Virtualisierungstechniken auf Betriebssystemebene entwickelt werden.

Welche Docker-Alternativen gibt es also? Und wie unterscheiden sich deren Ansätze von den Mechanismen des Marktführers?

Bei unixoiden Systemen wie Linux basiert die Virtualisierung auf Betriebssystemebene in der Regel auf einer erweiterten Implementierung nativer Chroot-Mechanismen. Zudem machen sich Container-Projekte wie Docker, rkt, LXC, LXD, Linux-VServer, OpenVZ/Virtuozzo und runC zum Ressourcen-Management native Linux-Kernel-Funktionalitäten zunutze, um isolierte Laufzeitumgebungen für Anwendungen oder das ganze Betriebssystem zu realisieren.

Docker greift auf grundlegende Funktionen des Linux-Kernels zurück, um Prozesse gegeneinander abzuschirmen, und ermöglicht mithilfe der selbstentwickelten Laufzeitumgebung runC den parallelen Betrieb von Anwendungen in isolierten Containern, ohne dass ressourcenintensive Gastsysteme benötigt werden. Damit etabliert sich die schlanke Container-Plattform als attraktive Alternative zur hypervisorgestützten Virtualisierung. Eine detaillierte Beschreibung der Docker-Plattform und ihrer Grundbestandteile finden Sie in unserem Docker-Tutorial für Einsteiger.

Die Docker-Container-Plattform wird als freie Community-Edition (CE) sowie als kostenpflichtige Enterprise-Version (EE) vertrieben und bietet Unterstützung für diverse Linux-Distributionen. Darüber hinaus steht Docker CE seit dem Release der Version 1.12 als native App für Windows und macOS zur Verfügung. Während Docker for Mac auf den schlanken Hypervisor xhyve zurückgreift, um eine Laufzeitumgebung für die Docker-Engine und Linux-Kernel-spezifische Funktionen für den Docker-Daemon zu virtualisieren, kommt unter Windows zum selben Zweck der Hypervisor Hyper-V zum Einsatz.

Seit September 2016 steht Docker EE zudem nativ für Windows Server2016 zur Verfügung. Microsoft hat dazu in enger Zusammenarbeit mit dem Docker-Entwicklerteam diverse Erweiterungen in den Windows-Kernel eingebaut, die es Docker ohne abstrahierenden Hypervisor ermöglichen, Prozesse als Container in einer Sandbox zu starten. Den Quellcode des speziell dafür entwickelten Treibers hcsshim stellt Microsoft der Open-Source-Community via GitHub zur Verfügung.

Folgender Steckbrief zeigt die wesentlichen Eckpunkte der Docker-Plattform:

Im Laufe der Zeit hat sich um das Docker-Kernprojekt ein lebendiges Ökosystem entwickelt. Laut Angaben der Entwickler ist die Docker-Engine in mehr als 100.000 Drittanbieter-Projekte eingebunden.

Hauptkritikpunkt an der Implementierung der Linux-Container-Technologie im Rahmen des Docker-Projekts ist der Isolationsgrad einzelner Prozesse auf einem gemeinsamen Host-System. Beim Betrieb von Anwendungs-Containern nutzt Docker native Linux-Kernel-Funktionen wie Cgroups und Namespaces. Diese kapseln Container jedoch nicht in gleichem Umfang, wie das bei einer Vollvirtualisierung auf Basis virtueller Maschinen der Fall ist. Um einen sicheren Betrieb von Anwendungs-Containern auch auf Produktivsystemen sicherzustellen, unterstützen neuere Versionen der Container-Plattform Kernel-Erweiterungen wie AppArmor, SELinux, Seccomp und GRSEC, mit denen sich isolierte Prozesse zusätzlich abschirmen lassen.

Im Februar 2016 veröffentliche CoreOS mit rkt Version 1.0 das erste stabile Release der Container-Laufzeitumgebung. Gegenüber Docker möchte der Wettbewerber vor allem durch zusätzliche Sicherheitsfeatures punkten. Zu diesen zählt neben einer Container-Isolierung auf KVM-Basis die Unterstützung der Kernel-Erweiterung SELinux sowie eine Signatur-Validierung für Images der selbstentwickelten Container-Spezifikation App Container (appc). Diese beschreibt das Image-Format App Container Image (ACI), die Laufzeitumgebung, einen Image-Discovery-Mechanismus sowie die Möglichkeit, Images in Multi-Container-Apps – sogenannte App Container Pods – zu gruppieren.

Anders als Docker unterstützt rkt neben eigenen Container-Images auch andere Formate. Die Laufzeitumgebung ist kompatibel zu Docker-Images und bietet mit dem Open-Source-Tool Quay eine Möglichkeit, jedes beliebige Container-Format nach ACI zu konvertieren.

Während die Docker-Plattform auf einen zentralen Daemon setzt, der mit Root-Rechten im Hintergrund läuft, kommt rkt ohne einen solchen Hintergrundprozess aus und arbeitet stattdessen mit etablierten init-Systemen wie systemd und upstart, um Container zu starten und zu verwalten. So umgeht rkt das mittlerweile behobene Docker-Problem, dass Nutzer, die Container über den Daemon starten möchten, Root-Rechte benötigen und somit uneingeschränkten Zugriff auf das Hostsystem erhalten.

Anders als Docker ist rkt bei der Virtualisierung von Anwendungen nicht auf Linux-Kernel-Funktionen wie Cgroups und Namespaces festgelegt. Mit der Laufzeitumgebung von CoreOS lassen sich Container auf Basis von KVM (Kernel-based Virtual Machine, z. B. LKVM oder QEMU) und Intels Clear-Container-Technologie auch als vollständig gekapselte virtuelle Maschinen starten.

Unterstützung finden die appc-Spezifikation und ihre Implementierung rkt durch Branchengrößen wie Google, Red Hat und VMware.

Um Prozesse voneinander abzuschirmen, kommen bei LXC folgende Isolationstechniken zum Einsatz:

• IPC-, UTS-, Mount-, PID-, Netzwerk- und User-Namespaces

• Cgroups

• AppArmor- und SELinux-Profile

• Seccomp-Regeln

• Chroots

• Kernel-Capabilities

Das Ziel des LXC-Projekts ist es, eine Umgebung für Software-Container zu schaffen, die sich so wenig wie möglich von einer Standard-Linux-Installation unterscheidet. LXC wird neben den Open-Source-Projekten LXD, LXCFS und CGManager unter dem Dachprojekt LinuxContainers.org entwickelt.

LXC wurde dazu entwickelt, unterschiedliche System-Container (Full System Containers) auf einem gemeinsamen Host-System auszuführen. Ein Linux-Container startet in der Regel eine komplette Distribution aus einem Betriebssystem-Image in einer virtuellen Umgebung. Anwender interagieren mit dieser ähnlich wie mit einer virtuellen Maschine.

Anwendungen werden in Linux-Containern eher selten gestartet. Damit grenzt sich die Software deutlich vom Docker-Projekt ab. Während LXC in erster Linie der System-Virtualisierung dient, konzentriert sich Docker auf die Virtualisierung einzelner Apps und deren Deployment. Anfangs kamen dabei auch Linux-Container zum Einsatz. Heute setzt Docker auf ein selbstentwickeltes Container-Format.

Ein wesentlicher Unterschied beider Virtualisierungstechnologien ist, dass Linux-Container beliebig viele Prozesse enthalten können, während in Docker-Containern lediglich ein Prozess ausgeführt wird – komplexe Docker-Anwendungen bestehen daher in der Regel aus mehreren Containern. Ein effektives Deployment solcher Multi-Container-Apps erfordert zusätzliche Werkzeuge.

Des Weiteren unterscheiden sich Docker-Container und Linux-Container bezüglich der Portabilität. Entwickelt ein Anwender Software auf Basis von LXC auf einem lokalen Testsystem, kann dieser nicht zwangsläufig davon ausgehen, dass der Container später auf anderen Systemen (z. B. einem Produktivsystem) fehlerfrei läuft. Die Docker-Plattform hingegen abstrahiert Anwendungen deutlich stärker von der Beschaffenheit des zugrundeliegenden Systems. So lässt sich ein und derselbe Docker-Container unabhängig vom Betriebssystem und der jeweiligen Hardware-Konfiguration auf jedem beliebigen Docker-Host (ein System, auf dem die Docker-Engine installiert wurde) betreiben.

Auch LXC kommt ohne zentralen Daemon-Prozess aus. Stattdessen integriert sich die Container-Software ähnlich wie rkt in init-Systeme wie systemd und upstart, um Container zu starten und zu verwalten.

LXD von Canonical

Als Folgeprojekt von LXC hat der Linux-Distributor Canonical im November 2014 die Docker-Alternative LXD (gesprochen: „Lexdi“) ins Leben gerufen. Das Projekt baut auf der Linux-Container-Technologie auf und erweitert diese um den Daemon-Prozess LXD. Die Software versteht sich als eine Art Container-Hypervisor. Der technische Aufbau der Container-Lösung besteht aus drei Komponenten: Als Kommandozeilen-Client fungiert LXC, zudem wird mit nova-compute-lxd ein OpenStack-Nova-Plug-in eingebunden. Die Kommunikation zwischen Client und Daemon erfolgt über eine REST-API.

Ziel des Software-Projekts ist es, Anwendern auf Basis der Linux-Container-Technologie eine ähnliche Nutzererfahrung wie beim Betrieb virtueller Maschinen zu bieten, ohne dass dafür der Overhead einer Emulation von Hardware-Ressourcen in Kauf genommen werden muss.

Wie LXC konzentriert sich LXD auf die Bereitstellung von Full-System-Containern. Diese Rolle als Machine-Management-Tool grenzt LXD von Docker und rkt ab, deren Kernfunktionen eher im Bereich des Software-Deployments liegen. LXD nutzt dieselben Isolationstechnologien wie das zugrundeliegende LXC-Projekt.

Der Daemon der Container-Lösung benötigt einen Linux-Kernel. Andere Betriebssysteme werden nicht unterstützt. Da die Kommunikation mit dem Daemon über eine REST-API erfolgt, ist es möglich, diesen per Remote mit einem Windows- oder macOS-Client anzusprechen. Wie sich der Standard-LXD-Client für das gewünschte Betriebssystem konfigurieren lässt, beschreibt LXD-Projektleiter Stéphane Graber in einem Blog-Artikel vom 9. Februar 2017.

Da VPS als isolierte Prozesse desselben Hostsystems laufen und dieselbe System-Call-Schnittstelle verwenden, entsteht kein zusätzlicher Overhead durch Emulation.

Das von Jacques Gélinas ins Leben gerufene Open-Source-Projekt stand bis zuletzt unter der Leitung des Österreichers Herbert Pötzl. Anwendung findet die Technologie beispielsweise bei Webhosting-Anbietern, die ihren Kunden separierte virtuelle Maschinen auf einer gemeinsamen Hardware-Grundlage anbieten möchten.

Um den Linux-Kernel mit Funktionalitäten zur Operating-System-Level-Virtualisierung auszustatten, muss dieser gepatcht werden. Durch diese Linux-Kernel-Modifikation unterscheidet sich die Technologie grundlegend von Linux-Containern (LXC), die mit Cgroups und Namespaces auf native Isolationsfunktionen zurückgreifen.

Als letztes Release erschien VServer 2.2 im Jahr 2007.

Im Vergleich zur Vorgängerversion bietet OpenVZ 7 einen Satz neuer Kommandozeilenwerkzeuge, die sogenannten Gast-Tools. Diese ermöglichen es Anwendern, Aufgaben auf Gastsystemen direkt über das Terminal des Host-Systems auszuführen. Zudem wurde der selbstentwickelte Hypervisor zum Betrieb virtueller Maschinen gegen die etablierten Standardtechnologien KVM und QEMU ersetzt.

Beim Container-Betrieb hingegen setzt OpenVZ mit Virtuozzo-Container weiterhin auf ein eigenes Format. Dieses dient wie LXC in erster Linie der Virtualisierung kompletter Systeme (VPS) und grenzt sich damit von Docker und rkt ab. Anders als LXC bietet OpenVZ jedoch die Möglichkeit einer Live-Migration via Checkpoint/Restore In Userspace (CRIU), um persistente Abbilder eines laufenden Containers anzufertigen.

Technisch stellen OpenVZ und Virtuozzo eine Erweiterung des Linux-Kernels dar, die diverse Virtualisierungswerkzeuge auf Benutzerebene zur Verfügung stellt. Gastsysteme werden in sogenannten virtuellen Umgebungen (Virtual Environments, VE) realisiert, die isoliert auf demselben Linux-Kernel laufen. Dadurch wird wie bei den anderen vorgestellten Container-Technologien der Overhead durch eine Hypervisor-basierte Hardware-Emulation vermieden. Der geteilte Linux-Kernel hat jedoch zur Folge, dass alle virtualisierten Gastsysteme auf die Systemarchitektur und Kern-Version des Hostsystems festgelegt sind.

Zu den Kernfunktionen von OpenVZ gehören eine dynamische Echtzeit-Partitionierung, Ressourcen-Management und die zentrale Verwaltung mehrere physischer und virtueller Server.

• Dynamische Echtzeit-Partitionierung: Jeder VPS stellt eine isolierte Partition des zugrundeliegenden physischen Servers dar. Die Isolation beinhaltet eigene Dateisysteme, Benutzergruppen (inklusive eigenem Root-User), Prozessbäume, Netzwerkadressen und IPC-Objekte.

• Ressourcen-Management: Die Allokation von Hardware-Ressourcen erfolgt bei OpenVZ über sogenannte Resource-Management-Parameter, die vom Systemadministrator in der globalen Konfigurationsdatei und den entsprechenden Container-Konfigurationsdateien verwaltet werden.

Zur Verwaltung von virtuellen Maschinen und System-Containern setzen OpenVZ und Virtuozzo auf Red Hats Management-Tool libvirt, das aus einer Open-Source-API, dem Daemon libvirtd und dem Kommandozeilenprogramm virsh besteht.

Während das Enterprise-Produkt Virtuozzo mit der integrierten GUI Parallels Virtual Automation (PVA) ausgeliefert wird, kommt OpenVZ in der Grundinstallation ohne grafische Benutzeroberfläche daher. Anwender haben jedoch die Möglichkeit, diese via Drittanbieter-Software nachzuinstallieren. Das OpenVZ-Entwicklerteam empfiehlt das OpenVZ Web Panel von SoftUnity. Weitere Alternativen lassen sich dem OpenVZ-Wiki entnehmen.

Als gemeinnützige Organisation der Linux Foundation wurde die OCI 2015 von Docker und anderen Unternehmen der Container-Branche ins Leben gerufen, um einen offenen Industriestandard für Software-Container zu etablieren. Aktuell bietet die OCI Spezifikationen für eine Container-Laufzeitumgebung (runtime-spec) und ein Container-Image-Format (image-spec).

Die quelloffene Laufzeitumgebung runC kann als kanonische Implementierung dieser Spezifikationen betrachtet werden.

Die Laufzeitumgebung der OCI unterstützt ausschließlich Container im Format OCI-Bundle und benötigt lediglich ein Root-Dateisystem und eine OCI-Konfigurationsdatei, um Container auszuführen. Ein Tool, um Root-Dateisysteme für Container zu erzeugen, wird im Rahmen des Projekts nicht zur Verfügung gestellt. Anwender, die die Docker-Plattform installiert haben, können jedoch auf deren Exportfunktion zurückgreifen, um ein Root-Dateisystem aus einem bestehenden Docker-Container zu extrahieren, dieses um eine config.json zu erweitern und so ein OCI-Bundle zu erstellen. Zudem werden andere externe Tools wie oci-image-tools, skopeo und umoci zur Image-Erstellung unterstützt.

Wie die Docker-Alternativen rkt und LXC kommt bei runC kein zentraler Daemon-Prozess zum Einsatz. Stattdessen integriert sich die Container-Laufzeitumgebung mit dem init-Prozess systemd.

Die folgende Tabelle zeigt eine Gegenüberstellung der vorgestellten Docker-Alternativen.

Das Konzept, Systemressourcen durch kerneleigene Isolationsmechanismen zu partitionieren und unabhängig voneinander gekapselten Prozessen auf demselben System zur Verfügung zu stellen, findet sich in diversen unixoiden Betriebssystemen. Vergleichbar sind Linux-Container mit dem Begriff „Jail“ unter BSD-Systemen und den mit Solaris 10 eingeführten Zonen. Für Windows-Systeme finden sich die Container-Konzepte Microsoft Drawbridge, WinDocks, Sandboxie, Turbo und VMware ThinApp.

Für jedes Jail lassen sich über eine eigene User-Verwaltung unabhängige Benutzergruppen definieren, deren Rechte sich auf die Jail-Umgebung beschränken. So kann ein Benutzer, der innerhalb eines Jails über umfangreiche Berechtigungen verfügt, außerhalb der virtuellen Umgebung keine kritischen Systemoperationen ausführen. Dies stellt sicher, dass ein Hacker aus einem kompromittierten Jail heraus keinen größeren Schaden am System anrichten kann.

Ähnlich wie andere Ansätze zur Virtualisierung auf Betriebssystemebene bieten Solaris-Zonen eine ressourcensparende Möglichkeit, diverse isolierte Betriebssysteme auf einer gemeinsamen Systeminstanz zu realisieren.

Die native Docker-Engine für Windows Server 2016 unterscheidet sich grundlegend von den Anwendungen Docker for Windows und Docker for Mac. Während Letztere den Betrieb der für Linux entwickelten Docker-Engine mithilfe einer schlanken virtuellen Maschine ermöglichen, nutzt die Docker-Version für Windows Server 2016 direkt den Windows-Kernel. Klassische Docker-Container lassen sich auf Windows Server 2016 daher nicht ausführen. Stattdessen wurde im Rahmen des Docker-Projekts ein neues Container-Format namens WSC (Windows Server Container) entwickelt. Darüber hinaus bietet Microsoft eine Hyper-V-basierte Container-Variante an, mit der sich ein höherer Isolationsgrad realisieren lässt.

• Windows-Server-Container: Mit Windows-Server-Container (WSC) bietet Microsoft eine Container-Technologie für die Docker-Plattform, die es erlaubt, Prozesse mit erweiterten Windows-Kernel-Funktionen zu isolieren. Wie bei der Linux-Technologie teilen sich auch Windows-Server-Container den Kernel des zugrundeliegenden Host-Systems (Container-Host).

• Hyper-V-Container: Mit Hyper-V-Containern bietet Microsoft eine Möglichkeit, Container-Instanzen mithilfe klassischer hypervisorbasierter Virtualisierung zusätzlich abzuschirmen. Bei Hyper-V-Containern handelt es sich um virtuelle Maschinen, die sich genau wie Windows-Server-Container über die Docker-Plattform steuern lassen, durch einen eigenen Windows-Kernel jedoch einen deutlich höheren Isolationsgrad aufweisen.

Noch bevor Microsoft im Rahmen der Docker-Kooperation native Container-Technologien in den Windows-Kernel implementiert hat, haben sich diverse Entwickler mit ressourcensparenden Virtualisierungsmethoden für Windows-Systeme beschäftigt. Zu den bekannteren Projekten gehören Microsoft Drawbridge, WinDocks, Sandboxie, Turbo und VMware ThinApp.

Microsoft Drawbridge

Unter dem Namen Drawbridge hat Microsoft den Prototyp einer Vitualisierungstechnologie entwickelt, der auf dem Konzept des Library-OS beruht – einem Betriebssystem, das im Rahmen einer Anwendung als Set von Bibliotheken umgesetzt wird. Mit Drawbridge werden Anwendungen zusammen mit dem Library-OS in sogenannten Pico-Prozessen ausgeführt. Dabei handelt es sich um prozessbasierte Isolations-Container mit Kernel-Schnittstelle. In der Dokumentation zu Windows-Server-Container gibt Microsoft die Erfahrung mit Drawbridge als wichtigen Input für die Entwicklung der Containertechnologie unter Windows Server 2016 an.

WinDocks

Bei WinDocks handelt es sich um eine Docker-Portierung für Windows, mit der sich App-Container für .NET-Anwendungen und Data-Container für SQL-Server erstellen und verwalten lassen. Anders als Windows-Server-Container, die derzeit noch auf die Systeme Windows 10 und Windows Server 2016 beschränkt sind, steht WinDocks auch für ältere Betriebssysteme wie Windows Server 2012, Windows Server 2012 R2 sowie Windows 8 und 8.1 zur Verfügung. Die Software wird als kostenlose Community-Edition und als Enterprise-Produkt mit Kundensupport angeboten.

Sandboxie

Mithilfe von Sandboxie lassen sich Anwendungen unter Windows in einer isolierten Umgebung – der sogenannten Sandbox – ausführen. Ähnlich wie die Container-Technologie zielt dieses Verfahren darauf ab, das zugrundeliegende Host-System und andere Anwendungen von Programmaktivitäten einer isolierten Anwendung abzuschirmen. Dazu schaltet sich das Tool zwischen Anwendung und Betriebssystem, um Festplattenschreibzugriffe abzufangen und in einen geschützten Bereich umzuleiten. Neben Zugriffen auf Dateien lassen sich so auch Schreibanfragen an die Windows-Registry-Datenbank unterbinden. Sandboxie steht für alle aktuellen Windows-Versionen sowie für XP und Vista als kostenlose Grundversion zur Verfügung. Zudem werden kostenpflichtige Versionen mit erweitertem Funktionsspektrum für Privatanwender und den kommerziellen Gebrauch angeboten.

Turbo (ehemals Spoon)

Bei Turbo handelt es sich um eine Docker-Alternative für Windows, mit der sich Anwendungen inklusive aller Abhängigkeiten wie .NET, Java oder Datenbanken wie SQL Server oder MongoDB in isolierte Container verpacken lassen. Anders als Windows-Server-Container werden diese vom Windows-Kernel jedoch nicht nativ unterstützt, weshalb ähnlich wie bei Docker for Windows eine virtuelle Maschine benötigt wird, um Inkonsistenzen zu kompensieren. Turbo-Container laufen daher auf der Spoon-Virtual-Machine-Engine (SVM), die als Schnittstelle zum Windows-Kernel fungiert. Der Austausch von Container-Anwendungen erfolgt auch bei Turbo über ein cloudbasiertes Hub. Die Software ist gut dokumentiert, findet im Vergleich zu Docker in der Fachpresse jedoch wenig Beachtung.

VMware ThinApp

VMware ThinApp ist ein Tool zur Anwendungsvirtualisierung im Desktop-Umfeld. Die Software ermöglicht es, Anwendungen konfliktfrei in komplexen IT-Infrastrukturen bereitzustellen. Dazu werden diese inklusive aller Abhängigkeiten in eine ausführbare EXE- oder MSI-Datei verpackt und so vom zugrundeliegenden Betriebssystem und anderen Anwendungen isoliert. Die mittels ThinApp erstellte Datei lässt sich ohne Installation (und somit ohne Admin-Rechte) auf beliebigen Windows-Systemen ausführen – wahlweise auch von einem tragbaren Speichermedium (z. B. einem USB-Flash-Laufwerk) aus. Eine Alternative zu Docker bietet ThinApp bei der Migration von Legacy-Anwendungen oder der Isolation kritischer Programme.