Container-Technik: Docker & Co.

Anbieter zum Thema

fsas-afc-horizontal-2-positive-rgb-nov24 (Fsas)

Fsas Technologies GmbH

netfiles GmbH

Hyland Software Germany GmbH

Amazon.de GmbH

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.

Ergänzendes zum Thema

Das Fazit der Autoren

Die größten Kritikpunkte an Docker konzentrieren sich auf unzureichende Kontrollmechanismen zur Gewährleistung der Datensicherheit, der Datenintegrität und der Verfügbarkeit. Über den zweiten und dritten Punkt kann man sich je nach dem Anwendungsszenario entweder herum arbeiten oder darüber hinweg sehen, nicht jedoch über den ersten.

Solange die Docker-Entwickler die bereits ausgiebig dokumentierten Sicherheitsprobleme völlig unverantwortlich auf die leichte Schulter nehmen, lässt sich die Lösung in ihrer bisherigen Form trotz der unbestreitbaren Vorteile nicht uneingeschränkt empfehlen. SELinux- und AppArmor-Schutzeinstellungen stellen auch keinen Ersatz dar für das Fehlen eines ganzheitlichen Sicherheitskonzeptes.

Vorerst gilt es daher, Docker mit Vorsicht zu genießen. Zum Glück reifen und gedeihen inzwischen interessante Erweiterungen und viel versprechende Alternativen wie Rocket. Auf die Anwender von Container-Technik dürften in naher Zukunft überaus interessante Verbesserungen zukommen.

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.

Ergänzendes zum Thema

Background: Link-Sammlung zum Thema Container-Virtualisierung

Docker Fig

Geard

Docker Hub Enterprise (Warteliste)

Kubernetes:

Rocket

AppContainer

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.

Kubernetes, die quelloffene Orchestrierungsengine für Docker-Container von Google(Kubernetes-Ressourcen.png) Kubernetes Master meistert die Orchestrierung von Docker-Containern in einem Cluster mit mehreren Knoten.
(Bild: kubernetes.io)

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 Master meistert die Orchestrierung von Docker-Containern in einem Cluster mit mehreren Knoten.
(Bild-. kubernetes.io)

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.

Mit einer alternativen Container-Technik namens Rocket möchten die Entwickler von CoreOS die Schwächen von Docker ausgleichen.
(Bild: CoreOS)

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).

In CoreOS zeichnet für das Clustering dieselbe Softwarekomponente verantwortlich, die sich auch Googles Kubernetes für Docker zu Nutze macht: etcd von den Erfindern der Docker-Alternative Rocket.
(Bild: coreos.com)

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.