Original-URL des Artikels: https://www.golem.de/news/railcar-oracle-veroeffentlicht-container-runtime-und-debugger-in-rust-1707-128780.html    Veröffentlicht: 06.07.2017 15:29    Kurz-URL: https://glm.io/128780

Railcar

Oracle veröffentlicht Container-Runtime und Debugger in Rust

Mit Railcar veröffentlicht Oracle auf Github eine Rust-Implementierung des OCI-Runtime-Spec. Crashcart ist ein Microcontainer Debugging Tool. Orcale bietet damit Alternativen zu den Diensten von Docker oder CoreOS.

Das neue Open-Source-Projekt Railcar von Oracle ähnelt der Referenzimplementierung der Container-Runtime von Runc, ist aber komplett in Rust geschrieben. Das soll für Speichersicherheit sorgen und ermöglicht es den Programmierern, sich nicht erst mit Garbage Collection und Multithreading beschäftigen zu müssen.

Oracle hat sich für diese Software entschieden, weil Go Probleme im Umgang mit Linux Namespaces hat und C nicht sicher genug ist. Rust bewegt sich zwischen beiden, erlaubt eine weitgehende Kontrolle über das Threading und kommt so auch mit Namespaces zurecht.

Das ebenfalls von Oracle vorgestellte Crashcart ermöglicht es hingegen, ein Image mit Linux-Binärdateien in einen Container zu laden. Ein Builder, der als privilegierter Container läuft, erzeugt aus einem Dockerfile ein crashcart_builder-Image. Den privilegierten Container braucht es, weil Crashcart das Image per Loopback-Mount auf Ext 3 erzeugt und dann Dateien hineinkopiert. Beim Erststart braucht das Image einige Zeit, weil im Hintergrund der Nix-Paketmanager die Binaries aus dem Quellcode erzeugt. Anschließend kann der User seine Binaries in einem Container seiner Wahl verwenden, zum Beispiel für Analysezwecke.

Oracle beschreibt auch die Herausforderungen beim Implementieren von Railcar. Probleme bereite es demnach unter anderem, ein Backend zur Zusammenarbeit mit Docker zu überreden, weil so viele verschiedene Prozesse involviert seien, was Debugging erschwere. Die Spezifikation sei zudem nicht vollständig, denn Containerd und Runc unterstützen bestimmte wichtige Aufrufe, die nicht in der Spezifikation stehen. Auch an anderen Stellen folgt das Duo nicht exakt der Spezifikation. So sollte ein zweifaches Löschen von Containern eine Fehlermeldung ausgeben, was nicht der Fall ist. Auch die Implementierung der Pre- und Poststart-Hooks sei nicht ganz einfach gewesen, wohl auch, weil die Spezifikation noch recht jung sei.

Nicht zuletzt gibt es Abweichungen von Runc: So erzeugt Railcar stets einen Initprozess, um Merkwürdigkeiten im Umgang mit Namespaces und PIDs zu umgehen. Mögliche ungewisse Auswirkungen könnte diese Entscheidung auf Stdout und Stderr haben, wenn man Railcar ohne Terminal betreibt, schreiben die Entwickler in einem begleitenden Blogpost. Dieses Problem wolle man als nächstes angehen, auch um Railcar kompatibler zu Runc zu machen. Ansonsten fehlt Railcar noch das stats-Kommando, automatische Tests gegen neuere Spec-Versionen stehen auch auf dem Fahrplan.

Insgesamt sei man aber sehr zufrieden mit der Wahl von Rust für das Projekt. Anders als Go habe man für die Rust-Implementierung keine C-Code-Injektion benötigt und man sei sehr zuversichtlich, was die Speichersicherheit von Railcar angehe. Die Startzeit für Container sei gut, hier bremse aber tatsächlich der Kernel: Das Anlegen von Cgroups und Network Namespaces sei das größte Hinderniss in dem Konstrukt. Sowohl Railcar als auch Crashcart stehen jeweils unter zwei Lizenzen, der Universal Permissive License (UPL) 1.0 und der Apache-Lizenz 2.0 und lassen sich auf Github herunterladen.  (kki)


Verwandte Artikel:
Open Source: Oracles Serverless-Plattform versteht auch AWS Lambda   
(05.10.2017, https://glm.io/130447 )
IaaS: Openstack Queens unterstützt vGPUs und Container   
(01.03.2018, https://glm.io/133080 )
Kubernetes und Openshift: Red Hat übernimmt Container-Spezialisten Core OS   
(31.01.2018, https://glm.io/132494 )
Buddybuild: Tools zum Testen von Apps werden Teil von Apples Xcode   
(03.01.2018, https://glm.io/131933 )
Containerd: Container-Laufzeit von Docker allgemein verfügbar   
(07.12.2017, https://glm.io/131549 )

© 1997–2020 Golem.de, https://www.golem.de/