Alternativen zu Docker: Container-Plattform im Überblick
IONOS Redaktion
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?
Container-Technologie unter Linux
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.
Chroot steht für „change root“, ein Kommandozeilenbefehl, der unter unixoiden Betriebssystemen zur Verfügung steht, um das Root-Verzeichnis für einen laufenden Prozess und dessen Kindprozesse zu wechseln. Eine Anwendung, die in einer derart modifizierten Umgebung (man spricht von einem Chroot-Jail) ausgeführt wird, kann in der Regel auf keine anderen Dateien außerhalb des ausgewählten Verzeichnisses zugreifen. Da Chroot nicht als Sicherheits-Feature entwickelt wurde, lässt sich eine derartige Isolierung jedoch relativ leicht überwinden.
Docker
Wer sich mit Software-Containern beschäftigt, stößt früher oder später auf den Namen Docker. Dem Open-Source-Projekt der gleichnamigen Softwarefirma Docker Inc. ist es binnen weniger Jahre gelungen, die Container-Technologie zum Top-Thema in den Bereichen Software-Deployment, DevOps und Continuous-Delivery zu machen.
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 Server 2016 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:
Systemvoraussetzungen und unterstützte Systeme
| Benötigter Linux-Kernel | Linux Version 3.10 oder höher |
|---|---|
| Unterstützte Linux-Distributionen | Docker Community Edition (CE): Ubuntu, Debian, CentOS und Fedora Docker Enterprise Edition (EE): Ubuntu, Red Hat Enterprise Linux, CentOS, Oracle Linux und SUSE Linux Enterprise Server |
| Andere Plattformen | Docker Community Edition (CE): Microsoft Windows 10 (Pro, Enterprise oder Education mit 64 Bit), macOS (Yosemite 10.10.3 oder höher), Microsoft Azure, Amazon Web Services (AWS) Docker Enterprise Edition (EE): Microsoft Windows Server 2016, Microsoft Windows 10 (Pro, Enterprise oder Education mit 64 Bit), Microsoft Azure, Amazon Web Services (AWS) |
| Container-Format | Docker-Container |
| Lizenz | Apache 2.0 |
| Programmiersprache | Go |
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.
| Vorteile | Nachteile |
|---|---|
| Docker unterstützt diverse Betriebssysteme und Cloud-Plattformen. | Die Docker-Engine unterstützt lediglich das eigene Container-Format. |
| Mit Swarm und Compose bietet die Docker-Plattform bereits native Orchestrierungs- und Cluster-Management-Werkzeuge. | Die Software liegt als monolithische Programmdatei vor, die alle Features enthält. |
| Mit dem Docker-Hub steht Anwendern eine zentrale Registry für Docker-Ressourcen zur Verfügung. | Docker-Container isolieren lediglich einzelne Prozesse. Der Betrieb von Full-System-Containern wird nicht unterstützt. |
| Das ständig wachsende Ökosystem hält für Anwender diverse Docker-Tools, Plug-ins und Infrastrukturkomponenten bereit. |
Die Container-Technologie wurde ursprünglich mit dem Ziel entwickelt, mehrere virtuelle Betriebssysteme in isolierten Umgebungen auf demselben Kernel ausführen zu können. Man spricht in diesem Fall von Full-System-Containern. Die Container-Plattform Docker hingegen konzentriert sich auf sogenannte Anwendungs-Container, bei denen jede Anwendung in einer eigenen virtuellen Umgebung läuft. Während Full-System-Container so designt werden, dass in ihnen diverse Prozesse ausgeführt werden können, beinhaltet ein Anwendungs-Container immer nur einen einzelnen Prozess. Aufwendige Anwendungen werden mit Docker daher als Multi-Container-Apps realisiert.
rkt von CoreOS
Dockers schärfster Konkurrent auf dem Markt für containerbasierte Virtualisierung ist die Laufzeitumgebung rkt (gesprochen: „Rocket“) des Linux-Distributors CoreOS. Vorgestellt wurde das Software-Projekt bereits im Jahr 2014.
Als einen Grund für die Abkehr von der Docker-Plattform, die bis dahin auf die Unterstützung des CoreOS-Entwicklerteams bauen konnte, gab CEO Alex Polvi eine Unzufriedenheit mit der Entwicklung des Docker-Projekts an. Der Marktführer habe sich Polvi zufolge von dem Ziel, eine Standard-Container-Technik zu entwickeln, entfernt und konzentriere sich stattdessen darauf, eine monolithische Anwendungsentwicklungsplattform zu vermarkten.
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.
Systemvoraussetzungen und unterstützte Systeme
| Benötigter Linux-Kernel | Jeder moderne amd64-Kernel |
|---|---|
| Unterstützte Linux-Distributionen | Arch Linux, CentOS, CoreOS, Debian, Fedora, NixOS, openSUSE, Ubuntu, Void |
| Andere Plattformen | macOS oder Windows mittels Vagrant Virtual Machine |
| Container-Format | appc, Docker-Container; andere Container-Images lassen sich via Quay in das rkt-Format überführen |
| Lizenz | Apache 2.0 |
| Programmiersprache | Go |
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.
Seit Version 1.11 werden Container auch bei Docker nicht mehr direkt vom Docker-Daemon ausgeführt. Stattdessen kommt ein Daemon-Prozess namens Containerd zum Einsatz.
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.
| Vorteile | Nachteile |
|---|---|
| rkt unterstützt neben dem eigenen Container-Format auch Docker-Container und ermöglicht es, jedes beliebige Container-Image via Quay in das rkt-Format ACI zu konvertieren. | Im Vergleich zu Docker stehen für rkt deutlich weniger Drittanbieter-Integrationen zur Verfügung. |
| Techniken wie KVM und Intels Clear-Container-Technologie ermöglichen es, Software-Container sicher voneinander abzuschirmen. | rkt ist für den Betrieb von Anwendungs-Containern optimiert. Full-System-Container werden nicht unterstützt. |
LXC
Bei der Docker-Alternative LXC handelt es sich um ein Set aus Tools, Templates, Bibliotheken und Language-Bindings, die zusammen eine Userspace-Schnittstelle zu den nativen Container-Funktionen des Linux-Kernels darstellen. Linux-Nutzern bietet LXC einen bequemen Weg, Anwendungs- und System-Container zu erstellen und zu verwalten.
Language-Bindings sind Adapter – sogenannte Wrapper (to wrap = „einpacken“) –, die Brücken zwischen verschiedenen Programmiersprachen schlagen und es so ermöglichen, unterschiedliche Programmteile miteinander zu verknüpfen.
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.
Systemvoraussetzungen und unterstützte Systeme
| Benötigter Linux-Kernel | Linux Version 2.6.32 oder höher |
|---|---|
| Unterstützte Linux-Distributionen | LXC ist in den meisten Linux-Distributionen enthalten. Folgende Bibliotheken werden benötigt: C-Bibliothek: glibc, musl libc, uclib oder bionic Weitere Bibliotheken: libcap, libapparmor, libselinux, libseccomp, libgnutls, liblua, python3-dev |
| Andere Plattformen | keine |
| Container-Format | Linux Container (LXC) |
| Lizenz | GNU LGPLv2.1+ |
| Programmiersprache | C, Python 3, Shell, Lua |
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.
| Vorteile | Nachteile |
|---|---|
| LXC ist für den Betrieb von Full-System-Containern optimiert. | Der Betrieb von Applikations-Containern gehört nicht zum Standard-Anwendungsfall. |
| Es gibt keine native Implementierung für andere Betriebssysteme außer Linux. |
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.
Bei Nova handelt es sich um die zentrale Rechenkomponente des quelloffenen Cloud-Betriebssystems OpenStack, die der Bereitstellung und Verwaltung virtueller Systeme in Cloud-Architekturen dient. OpenStack Nova unterstützt diverse Virtualisierungstechnologien auf Hypervisor-Basis und Betriebssystemebene.
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.
Systemvoraussetzungen und unterstützte Systeme
| Benötigter Linux-Kernel | wie LXC |
|---|---|
| Unterstützte Linux-Distributionen | Kommandozeilen-Client (lxc): Ubuntu 14.04 LTS, Ubuntu 16.04 LTS nova-compute-lxd: Ubuntu 16.04 LTS |
| Andere Plattformen | keine |
| Container-Format | Linux Container (LXC) |
| Lizenz | Apache 2.0 |
| Programmiersprache | Go |
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.
| Vorteile | Nachteile |
|---|---|
| LXD ist für den Betrieb von Full-System-Containern optimiert. | Der Betrieb von Applikations-Containern gehört nicht zum Standardanwendungsfall. |
| Der LXD-Client kann für Windows und macOS konfiguriert werden und ermöglicht eine Remotesteuerung des LXD-Daemons via REST-API. | Der LXD-Daemon setzt einen Linux-Kernel voraus. |
Linux-VServer
Bei Linux-VServer handelt es sich um eine Virtualisierungstechnik auf Betriebssystemebene, die ähnlich wie Software-Container auf Isolationstechniken des Linux-Kernels zurückgreift. Dabei werden mehrere virtuelle Einheiten auf einem gemeinsamen Linux-Kernel betrieben, dessen Ressourcen (Dateisystem, CPU, Netzwerkadressen und Speicher) durch einen Jail-Mechanismus in voneinander abgeschottete Partitionen unterteilt sind. In der Linux-VServer-Terminologie wird eine solche Partition als „Security Context“ bezeichnet und durch Standardtechniken wie Segmented Routing, Chroot und Quota erzeugt. Ein virtualisiertes System in einem solchen Security Context wird Virtual Private Server (VPS) genannt.
Da VPS als isolierte Prozesse desselben Hostsystems laufen und dieselbe System-Call-Schnittstelle verwenden, entsteht kein zusätzlicher Overhead durch Emulation.
Eine Operating-System-Level-Virtualisierung via Linux-VServer hat nichts mit dem Projekt Linux Virtual Server zu tun, in dem eine Load-Balancing-Technik für Linux-Cluster entwickelt wird.
Systemvoraussetzungen und unterstützte Systeme
| Benötigter Linux-Kernel | Linux Version 2.6.19.7 oder höher |
| Unterstützte Linux-Distributionen | alle Linux-Distributionen |
| Andere Plattformen | keine |
| Container-Format | Bei Linux-VServer kommt ein containerähnliches Konzept namens Security Context zum Einsatz. |
| Lizenz | GNU GPL v.2 |
| Programmiersprache | C |
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.
| Vorteile | Nachteile |
|---|---|
| Während bei Docker Änderungen in einem Container nur dadurch gespeichert werden können, dass ein neues Image aus einem laufenden Container erzeugt wird, bietet Linux-VServer ein gemeinsames Dateisystem für alle VPS auf dem Host, in dem sich aktuelle Zustände sichern lassen. | Linux-VServer erfordert eine Modifikation des Linux-Kernels. |
| Kein neues Release seit 2007 |
OpenVZ/Virtuozzo 7
Seit Juli 2016 steht Version 7 der Virtualisierungsplattform OpenVZ von Parallels Anwendern als eigenständige Linux-Distribution zur Verfügung. Die Software basiert auf Red Hat Enterprise Linux 7 (RHEL) und ermöglicht den Betrieb von Gastsystemen, die sich wahlweise als virtuelle Maschinen oder in Form von Containern realisieren lassen. Mit der neuen Codebasis rückt OpenVZ näher an Virtuozzo 7 heran, das von Parallels als kommerzielles Enterprise-Produkt vertrieben wird. Ein direkter Vergleich beider Virtualisierungslösungen findet sich im OpenVZ-Wiki.
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.
Systemvoraussetzungen und unterstützte Systeme
| Benötigter Linux-Kernel | RHEL7 (3.10) |
|---|---|
| Unterstützte Linux-Distributionen | Virtuozzo Linux, RHEL7 |
| Andere Plattformen | keine |
| Container-Format | Virtuozzo Containers |
| Lizenz | OpenVZ: GNU GPL v.2 Virtuozzo 7: proprietäre Lizenz |
| Programmiersprache | C |
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.
| Vorteile | Nachteile |
|---|---|
| Parallels bietet mit OpenVZ und Virtuozzo eine komplette, auf Virtualisierungsszenarien optimierte Linux-Distribution. | OpenVZ und Virtuozzo stellen Container zum Betrieb kompletter Betriebssysteme zur Verfügung. Wer eine professionelle Docker-Alternative zur Isolierung einzelner Prozesse sucht, sollte eine andere Plattform wählen. |
| Mit OpenVZ und Virtuozzo lassen sich neben System-Containern auch virtuelle Maschinen mit minimalem Overhead betreiben. | Der Einsatz von OpenVZ und Virtuozzo ist auf die Linux-Distributionen RHEL7 und Virtuozzo Linux beschränkt. |
runC
Bei runC handelt es sich weniger um eine Docker-Alternative als um eine Ausgliederung der von Docker entwickelten Container-Laufzeitumgebung in ein unabhängiges Open-Source-Projekt unter der Schirmherrschaft der Open Container Initiative (OCI).
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.
| Benötigter Linux-Kernel | jeder Linux-Kernel |
|---|---|
| Unterstützte Linux-Distributionen | alle gängigen Linux-Distributionen |
| Andere Plattformen | keine |
| Container-Format | OCI Bundle |
| Lizenz | Apache 2.0 |
| Programmiersprache | Go |
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.
| Vorteile | Nachteile |
|---|---|
| runC basiert auf dem Industriestandard der Open Container Initiative (OCI). | Um Container-Images erstellen zu können, werden externe Tools benötigt. |
Docker-Alternativen im Vergleich
Die folgende Tabelle zeigt eine Gegenüberstellung der vorgestellten Docker-Alternativen.
| Docker | rkt | LXC | LXD | |
|---|---|---|---|---|
| Virtualisierungs-technologien | OS-Level | OS-Level, Hypervisor | OS-Level | OS-Level |
| Full-System-Container | Nein | Nein | Ja | Ja |
| App-Container | Ja | Ja | Nein | Nein |
| Lizenz | Apache 2.0 | Apache 2.0 | GNU LGPLv2.1+ | Apache 2.0 |
| Container-Format | Docker-Container | appc, Docker-Container | Linux Container (LXC) | Linux Container (LXC) |
| unterstützte Plattform | Linux, Windows, macOS, Microsoft Azure, Amazon Web Services (AWS) | Linux, Windows, macOS | Linux | Linux |
| Letztes Release | April 2017 | Februar 2017 | Januar 2017 | März 2017 |
| Patch des Linux-Kernels notwendig | Nein | Nein | Nein | Nein |
| Programmiersprache | Go | Go | C, Python 3, Shell, Lua | Go |
| Linux-VServer | OpenVZ | runC | |
|---|---|---|---|
| Virtualisierungs-technologien | OS-Level | OS-Level, Hypervisor | OS-Level |
| Full-System-Container | Ja | Ja | Nein |
| App-Container | Nein | Nein | Ja |
| Lizenz | GNU GPL v.2 | GNU GPL v.2 | Apache 2.0 |
| Container-Format | Security Context | Virtuozzo Containers | OCI Bundle |
| unterstützte Plattform | Linux | Linux (nur Virtuozzo Linux, RHEL7) | Linux |
| Letztes Release | April 2007 | Juli 2016 | März 2017 |
| Patch des Linux-Kernels notwendig | Ja | Eigenständige Distribution | Nein |
| Programmiersprache | C | C | Go |
Container-Technologie in anderen Betriebssystemen
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.
FreeBSD Jail
Sogenannte Jails („Gefängnisse“) stellen eines der markantesten Sicherheitsmerkmale des unixoiden Betriebssystems FreeBSD dar. Bei einem Jail handelt es sich um eine erweiterte Chroot-Umgebung, die eine komplette virtuelle Instanz des Betriebssystems in einem separaten Verzeichnis einrichtet und im Vergleich zu Chroot-Jails unter Linux einen hohen Isolationsgrad aufweist. Jedes Jail verfügt über einen eigenen Verzeichnisbaum. Zudem werden der Prozessraum sowie Zugriffe auf Benutzergruppen, Netzwerkschnittstellen und IPC-Mechanismen beschränkt. Auf diese Weise ist es Prozessen in einem Jail nicht möglich, auf andere Verzeichnisse oder Dateien außerhalb der isolierten Umgebung zuzugreifen und andere Prozesse auf dem Hostsystem in Mitleidenschaft zu ziehen. Darüber hinaus lässt sich jedem Jail ein eigener Hostname und eine eigene IP-Adresse zuordnen.
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.
Bei FreeBSD handelt es sich um eine freie, quelloffene Version der Berkeley Software Distribution (BSD), einer Variante des Unix-Betriebssystems, die ab 1977 an der University of California in Berkeley entwickelt wurde.
| Vorteile | Nachteile |
|---|---|
| Optimiert für Full-System-Virtualisierung | Eine Isolation einzelner Prozesse (wie bei Docker) wird nicht unterstützt. |
| Die Virtualisierung via Jail setzt ein BSD-System voraus (NetBSD, FreeBSD und OpenBSD). |
Oracle Solaris Zones
Auch unter Solaris lassen sich innerhalb einer Betriebssystem-Installation mehrere voneinander abgeschirmte Laufzeitumgebungen – sogenannte Zonen – einrichten, die sich den gemeinsamen Betriebssystem-Kernel teilen. Dabei werden globale und nichtglobale Zonen unterschieden.
- Globale Zonen: Jede Solaris-Installation beinhaltet eine globale Zone, die als Standard-Betriebssystem fungiert und der Administration dient. In der globalen Zone laufen alle Prozesse des Systems, sofern diese nicht in nichtglobale Zonen ausgelagert wurden.
- Nichtglobale Zonen: Unter nichtglobalen Zonen versteht man separierte virtuelle Umgebungen, die innerhalb der globalen Zone einer Solaris-Installation erstellt werden. Die Isolation einzelner nichtglobaler Zonen erfolgt ähnlich wie bei FreeBSD auf Basis eines modifizierten Chroot-Jails. Jeder dieser Zonen wird ein eigener Hostname und eine virtuelle Netzwerkkarte zugeordnet. Ressourcenanteile der zugrundeliegenden Hardware werden entweder via Fair-Share-Scheduling vergeben oder im Rahmen des Ressourcen-Managements fest zugeteilt.
Ä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.
| Vorteile | Nachteile |
|---|---|
| Die native Implementierung der Solaris-Zonen ermöglicht einen sehr effizienten Betrieb virtueller Umgebungen mit minimalem Overhead. | Ein Einsatz von Solaris-Zonen setzt das proprietäre Betriebssystem Oracle Solaris oder dessen quelloffene Variante OpenSolaris voraus. |
Container-Technologie unter Windows
Seit der Integration eines nativen Docker-Ports in Windows Server 2016 hat die Container-Technologie auch Einzug in das Microsoft-Universum gehalten. Dazu wurde der Windows-Kernel in enger Zusammenarbeit mit dem Docker-Entwicklungsteam um Funktionalitäten erweitert, die ähnlich wie Control-Groups und Namensräume unter Linux fungieren und so eine ressourcensparende Virtualisierung auf Betriebssystemebene ermöglichen.
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.
