Container-Technik Stärken und Schwächen von Docker & Co

Docker hat das Datencenter im Sturm erobert, alternative Container-Technologien ließen nicht lange auf sich warten. Inzwischen donnert es aber auch scharfe Kritik gegen Docker. Was steckt hinter der Container-Revolution?

Container-Frameworks wie Docker erleichtern das Aufsetzen von portablen Anwendungsausführungsumgebungen und die Inbetriebnahme von virtualisierten Anwendungen und ermöglichen eine effizientere Nutzung der vorhandenen Ressourcen. Bei Docker (alter Codename: „dotCloud“) handelt es sich um ein Framework zur Bereitstellung von Anwendungen in isolierten Laufzeitumgebungen. Es beinhaltet eine quelloffene Engine zum Erzeugen autarker Container für verteilte Applikationen, eine portable Runtime und eine Orchestrierungsplattform für Container-übergreifende Anwendungen.

Was Docker von alternativen Lösungen unterscheidet, ist die einfache Portabilität der Laufzeitumgebung. Docker unterstützt LXC (Linux Containers) als einen von mehreren Laufzeittreibern für autarke Container.

Die beachtliche Portabilität von Docker hat sich in einer bemerkenswerten Popularität reflektiert: Bis Ende 2014 konnte das Framework 100 Millionen Downloads verzeichnen und verweist auf satte 85.000 „dockerisierte“ Anwendungen.

Container-Virtualisierung ist an sich eigentlich nichts Neues. Linux bietet eine eigene Virtualisierungsumgebung auf der Betriebssystemebene mit der Bezeichnung „LXC“ (Linux Containers mit Unterstützung für Portabilität zwischen Distributionen). Ein ähnliches Konzept auf FreeBSD nennt sich „Jails“. Auf Solaris/OpenSolaris gibt es schließlich die so genannten Zonen („Zones“).

Container-Technik und Hypervisor-Virtualisierung im Vergleich

Hypervisor-gestützte VM-Virtualisierung und Container-basierte Anwendungsvirtualisierung liegen vom Konzept her wie Tag und Nacht auseinander. Bei der Hypervisor-gestützten Virtualisierung wie sie beispielsweise in KVM (Kernel-based Virtual Machine) implementiert wurde verfügen die einzelnen VM-Instanzen über eigene, voneinander unabhängige Kernel, die alle auf dem so genannten Hypervisor aufsetzen.

Dieser Ansatz erhöht die Sicherheit durch eine lückenlose Trennung der VMs, erschwert jedoch wesentlich ihre Interoperabilität. Hypervisor-gestützte Virtualisierungslösungen bieten unter anderem VMware, Citrix und Microsoft an.

Container-Virtualisierung auf der Basis von LXC ermöglicht das Ausführen von einzelnen Anwendungen in einem Sandkasten der jeweiligen Laufzeitumgebung direkt auf dem Kernel des Host-Systems, also ohne einen Hypervisor. LXC nutzt Kernel-Features wie Kontrollgruppen („cgroups“) und Namensräume, um die Container und die darin eingeschlossenen Prozesse voneinander abzugrenzen, so dass sie auf einen gemeinsamen OS-Unterbau kollisionsfrei zugreifen können.

Auslastung der Systemressourcen

Der Ansatz verbessert die Auslastung vorhandener Systemressourcen und damit die Performance der Anwendungen gegenüber einem Hypervisor. Der LXC-Ansatz hat jedoch nach wie vor unter anderem den Nachteil, dass sich systemweite Änderungen wie Updates von dem Host-System auf die Container propagieren.

Container-Virtualisierung kann allerdings gravierende Sicherheitslücken eröffnen. So liefen LXC-Container bis Februar 2014 zwangsweise mit Root-Rechten des Host-Systems; inzwischen lassen sie sich auch im Userspace ausführen. (Der Docker-Daemon benötigt im Übrigen nach wie vor Root-Rechte.)

Der LXC-Ansatz kommt im Hinblick auf die Portabilität eines Deployments deutlich zu kurz: Es isoliert nur einzelne Prozesse in einem Kernel-spezifischen Sandkasten und erschwert oder verhindert gar die Übertragung der Container auf andere Hosts. Abhilfe schaffen Lösungen wie Docker schaffen.

Die Funktionsweise von Docker: Pro und Contra

Dank einer Abstraktionsebene, welche die LXC-Fähigkeiten des Linux-Kernels erweitert, erzeugt Docker eine einheitliche, vorhersehbare Laufzeitumgebung, die von der Host-Plattform nicht abhängt. Docker-Container sind daher nicht nur leichtgewichtig sondern vor allem portabel. Dockers bemerkenswerte Fähigkeiten zur isolierten Bereitstellung von Anwendungen in portablen Containern eliminieren nicht nur das Problem von Software- und Infrastruktur-Abhängigkeiten, sondern erlauben eine höhere Auslastung bestehender Ressourcen (eine höhere Dichte als im Falle vollwertiger VMs).

Ein Docker-Container beinhaltet kein Betriebssystem; das Framework nutzt den Kernel des Host-Systems, um die benötigten Ressourcen wie CPU-Zyklen, den Arbeitsspeicher, Blockspeicher-I/O und Netzwerkschnittstellen anzufordern und unter Verwendung von Technologien wie cgroups und Linux-Namensräumen der Anwendung in dem jeweiligen Container isoliert zur Verfügung zu stellen. Zur Kommunikation mit dem Kernel nutzt Docker die integrierte „libcontainer“-Bibliothek, die quelloffene API „libvirt“, LXC oder ein „systemd“-Utility namens „systemd-nspawn“. Soweit so gut.

Die praktische Implementierung von Docker wirft im Hinblick auf die Sicherheit einige berechtigte Fragen auf. Docker wurde als ein Daemon implementiert und läuft mit Root-Rechten des Host-Systems.

Die Sicherheitsimplikationen dieser Entscheidung liegen auf der Hand: eine Sicherheitslücke in einem einzelnen Container kann das gesamte Host-System kompromittieren. Ein Workaround besteht im Einsatz von „SELinux“ oder „AppArmor“ zur Prozessisolierung.

Diese beiden Maßnahmen stellen natürlich keine vollwertige Lösung dar, sondern verstehen sich lediglich als Krücken. Die Entwickler von Docker haben die Sicherheitsmängel auf dem Radar und möchten diese adressieren, allerdings sind bisher kaum Fortschritte zu erkennen. Die Popularität von Docker wächst dennoch unaufhaltsam.

Lösungen rund um Docker

Einige der führenden Betreiber von Mega-Datencenter, darunter Google (in Zusammenarbeit mit VMware und Pivotal), Amazon, IBM, Rackspace und Microsoft haben hinter Docker ihr ganzes Gewicht geworfen. Bei Googles „Container Engine“ handelt es sich praktisch um eine Art „Docker-as-a-Service“.

Im vergangenen August hat Microsoft eine deklarative Management-Plattform für Docker-Container in Linux-Clustern von Google namens „Kubernetes“ in die eigenen Azure-Dienste integriert. Kubernetes ermöglicht die zeitgesteuerte Verwaltung von Docker-Containern auf mehreren Nodes eines Clusters, eine Aufgabe, welche Docker selbst bisher schlicht überfordert.

Für eine künftige Version von Windows Server plant Microsoft, eigene Images für die Docker Engine über Docker Hub, das gemeinschaftliche Repository, bereitzustellen und in Azure via Azure Management Portal und Azure Gallery zu integrieren. Microsoft möchte außerdem an der Weiterentwicklung der quelloffenen Orchestrierungs-APIs für Container-übergreifende Anwendungen von Docker mitwirken.

Docker-Repositories

Dockers eigener Dienst zum Verwalten von Repositories, „Docker Hub“, soll in Kürze in einer Enterprise-Edition für Datencenter und On-Premise-Umgebungen verfügbar sein. Mit dem „Docker Hub Enterprise“ (kurz: DHE) sollen sicherheitsbewusste Anwender ihre Container-Images künftig in privaten Repositories hinter einer eigenen Firewall aufbewahren können. AWS, IBM und Microsoft haben bereits ihre Unterstützung bekundet. Mit der öffentlichen Verfügbarkeit von DHE sei laut Docker im Frühjahr 2015 zu rechnen.

Hinweis:

Für weitere Fragen rund um die Container-Technik stehen Ihnen die Buchautoren unter @d1gitalinfo und @d1gitalPro gerne zur Verfügung.

AWS-Anwender können Docker-Container im Rahmen von „AWS Elastic Beanstalk“ ausführen. Elastic Beanstalk übernimmt in diesem Fall die Provisionierung von Kapazitäten, verwaltet eigenständig die Lastverteilung, skaliert automatisch und überwacht die Gesundheit der Anwendungen in Docker-Containern.

Der enorme Erfolg von Docker hat auch zahlreiche kleinere agile Anbieter dazu angespornt, Lösungen rund um Docker zu entwickeln. Zu den Vorreitern zählen unter anderem Joyent und Canonical.

Der Joyent Container Service

Mit einem gehosteten Cloud-Dienst „Joyent Container Service“ ) möchte der kalifornische Anbieter von Container-Lösungen Joyent einen neuen Standard für Container-Deployments geschaffen haben, der für Big-Data-Anwendungsszenarien optimiert ist. Eine Technologie namens „Linux Branded Zones“ (LXz) ermöglicht das Ausführen von Linux-Applikationen, einschließlich solcher in Docker-Containern, nativ auf einer gesicherten Virtualisierungsebene ohne den Einsatz eines Hardware-Hypervisors.

Die Joyent Container-Technologie besteht aus zwei Komponenten: einem Objektspeicher „Manta“ (ohne “r”!) und der Orchestrierungssoftware „SmartDataCenter“. Manta basiert auf dem selbstheilenden 128-Bit-starken „ZFS“-Dateisystem (Zettabyte File System) von Oracle/Sun Microsystems. Der robuste Objektspeicher ermöglicht das Ausführen von Containern direkt am Ablageort der Daten; Zeit und Platz raubendes Hin-und-her-Kopieren der Datenbestände entfällt. Jeder Container bekommt zudem einen eigenen virtualisierten Netzwerkstack zugewiesen.

LXD von Canonical

Canonical, der Anbieter der Linux-Distribution „Ubuntu“, hat sich vorgenommen, eine eigene Container-Technologie im Stil Hypervisor-gestützter Virtualisierung mit erhöhter Sicherheit ohne den Einsatz eines Hardware-Hypervisors zu implementieren. Mit dem „LXD“ (kurz für Linux Container Daemon) bietet Canonical eine Lösung, welche die gesamte Funktionalität des Linux-Kernels (also nicht nur einzelne Prozesse) in isolierten Containern bereit stellt und mit einer engen OpenStack-Integration trumpfen kann.

LXD-Container sind sowohl über eine RESTful-API als auch mit Kommandozeilenwerkzeugen ansprechbar, wahlweise via Netzwerk oder via Unix-Sockets. Zur Gewährleistung der Sicherheit kommt unter anderem das Kernelmodul AppArmor zum Einsatz.

Die Technologie zeichnen bemerkenswerte Fähigkeiten zur schnellen Bereitstellung aus: LXD-Container fahren in unterhalb einer Sekunde hoch. Ein einzelner physikalischer Host kann mehrere hundert LXD-Container ausführen und eine wesentlich höhere Sicherheit als Docker gewährleisten.

Mit dem überaus interessanten Ansatz hat Canonical den Zug dennoch möglicherweise bereits verpasst. IBM, Microsoft, Red Hat und sogar VMware haben sich bereits für Googles Docker-Orchestrierungswerkzeug Kubernetes entschieden.

Docker-Orchestrierung mit Google Kubernetes

Mit Kubernetes (http://kubernetes.io/) (wörtlich „Pilot“ auf Griechisch) bietet Google eine umfassende Lösung aus einer Hand rund um Container-Orchestrierung, Diensterkennung und Lastverteilung in Clustern.

Docker-Anwender konnten zwar eigene Lösungen zur Orchestrierung von Containern aus Tools wie „Fleet“, „Geard“, „Marathon“ und/oder „Apache Mesos“ zusammenstricken, doch nur die Wenigsten fanden den Aufwand vertretbar. Mit Kubernetes erfüllt Google eben dieses Bedürfnis nach einer koordinierten Bereitstellung von Docker-Containern auf mehreren Knoten eines Clusters.

Kubernetes ist auf sehr viel Zuspruch gestoßen, obwohl die Sicherheit bisher praktisch auf der Strecke blieb. Google warnt ganz laut und eindeutig vor dem Einsatz von Kubernetes in Multi-Tenant-Umgebungen auf Grund der bisher noch ungelösten Sicherheitsprobleme mit Docker.

Docker-Alternativen: die „Rocket“-Runtime und das App-Container-Format von CoreOS

Im Kontext von Angriffsvektoren wie „BREACH“ (Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext) halten die Entwickler der Cluster-optimierten Linux-Distribution CoreOS die aktuelle Implementierung von Docker für völlig unverantwortlich. Sie argumentieren, dass die gesamte Funktionalität der Runtime nicht in einem monolithischen, ungeschützten Binärfile gebündelt werden dürfe, damit dieses dann auch noch mit Root-Rechten auf dem Host-Kernel vor sich hin läuft.

Da die Docker-Codehüter ihrerzeit einige Vorschläge der Gemeinde in den Wind schlugen, sahen sich die CoreOS-Entwickler genötigt, eine eigene Container-Runtime zu schaffen, welche die Schwächen von Docker überwinden sollte. So entstand Rocket (zur sichtlichen Verunsicherung des Geschäftsführers von Docker, Ben Golub).

Im Gegensatz zu Docker läuft Rocket niemals als ein Daemon. Stattdessen wird die Rocket-Runtime dem jeweiligen Prozess untergeordnet, der sie aufgerufen hat, und mittels systemd beaufsichtigt. Anders als im Falle von Docker kann Rocket mehrere Prozesse pro Container ausführen, jedem dieser Prozesse Beschränkungen auferlegen und sie bei Bedarf neu starten.

Diese Implementierung erleichtert die Integration von Prozessen durch Socket-Aktivierung und ermöglicht die Übergabe von Dateideskriptoren, bei denen es sich um geöffnete, lauschende Sockets handeln kann, von einem Prozess zum anderen. Dieser Ansatz verbessert nicht nur die Sicherheit sondern auch das Management von Abhängigkeiten. So lässt sich in einem Rocket-Container etwa ein Web-Server ausführen, der über keinerlei Netzwerkverbindungen nach Außen hin verfügt und stattdessen an einem Unix-Socket lauscht.

Das App-Container-Format appc

Das App-Container-Format von Rocket, „appc“, lässt sich mit ganz gewöhnlichen GPG-Schlüsseln signieren; Images können sich gegenseitig auffinden, als gültig validieren und gegenseitig starten. (Zwar nutzt auch Docker in der aktuellen Version 1.3 digitale Signaturen, doch resultieren Unstimmigkeiten lediglich in einer ignorierbaren Fehlermeldung.)

CoreOS leistete übrigens Pionierarbeit mit der Anpassung von Google Kubernetes von der Google Cloud Plattform für On-Premise-Umgebungen und Datencenter; die Initiative trägt den Projektnamen „Flannel“. Kubernetes vertraut im Übrigen auf eine andere quelloffene Lösung aus dem Hause CoreOS: „etcd“.

Das Entwicklerteam von CoreOS hat dem eigenen App Container-Format appc Kompatibilität mit der ersten Version des Docker-Image-Formats verliehen. Zu diesem Zweck reichte CoreOS auf GitHub einen Pull-Request ein, der als Beweis dafür dienen soll, dass die Interoperabilität bereits zuverlässig funktioniert. Dank dieser Komptabilität können Unternehmen schrittweise von Docker auf das App Container-Format der Rocket-Runtime umstellen.

* Filipe Pereira Martins und Anna Kobylinska arbeiten für dieSoft1T S.a r.l. Beratungsgesellschaft mbH McKinley Denali Inc (USA).

(ID:44382515)