Suchen

Stärken und Schwächen von Docker und den Alternativen

Container-Technik: Docker & Co.

Seite: 4/4

Firmen zum Thema

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

Die Autoren:

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

Artikelfiles und Artikellinks

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de (ID: 43246015)