„Next Generation runC“ für eigene Container nutzen Sysbox Container Runtime für Microservice-Umgebungen

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Sysbox ist eine Low-level Container Runtime, die Container in einer Microservices-Umgebung erstellen kann und dabei eine bessere Isolierung bietet als andere Laufzeitumgebungen. Der Einsatz ist auch für Legacy-Anwendungen interessant, die teilweise noch virtuelle Maschinen benötigen.

Um Container zu erstellen, setzen viele Entwickler zum Beispiel auf Docker oder andere Lösungen, die wiederum mit Kubernetes bereitgestellt werden. Der Container-Dienst sendet in diesem Fall die Anforderung an containerd, dieser Daemon bemüht wiederum runC, um den Container tatsächlich zu erstellen. Wir haben das Thema bereits im Beitrag „Container mit runC, sysbox oder crun betreiben“ ausführlich behandelt.

Sysbox kann in entsprechenden Umgebungen parallel zu runC zum Einsatz kommen. Das hat den Vorteil, dass die Runtime genutzt werden kann, ohne die vorhandene Infrastruktur anzupassen. Die Einstiegshürde für die Verwendung von Sysbox ist folglich nicht sehr hoch. Das hinter Sysbox stehende Unternehmen Nestybox gehört zu Docker. Das Produkt steht kostenlos unter der quelloffenen Apache-2.0-Lizenz zur Verfügung.

Vorteile von Sysbox sind das Erstellen von VM-ähnlichen Containern und das Deployment von sehr sicheren, isolierten Containern, ohne auf Root-Rechte setzen zu müssen. Dadurch können Legacy-Anwendungen in Containern installiert werden, die ansonsten VMs benötigen. Sysbox ist also dazu in der Lage, virtuelle Maschinen (VMs) zu ersetzen, da die Anwendungen in Container verschoben werden können.

Sysbox kann sichere Container bereitstellen

Im Grunde genommen kann Sysbox auf die gleiche Art in einer Kubernetes- oder Docker-Umgebung zum Einsatz kommen wie runC, und ist dazu in der Lage, die gleichen Container zu starten. Sysbox steht als Community Edition und als Enterprise Edition zur Verfügung. Die Steuerung und Integration entspricht den Möglichkeiten von runC, sodass keine komplizierte Einarbeitung in die Runtime notwendig ist.

Die Enterprise Edition bietet zusätzlich noch Unterstützung für Red Hat und Flatcar Container Linux sowie eine erweiterte Isolierung für Container, die noch über die Isolierung der Community Edition hinausgeht. Alle Unterschiede der beiden Editionen sind auf der GitHub-Seite des Sysbox-Projekts zu finden, das gilt auch für die Vergleiche mit anderen Runtimes wie Kata, KubeVirt oder gVisor.

Sysbox bietet gegenüber anderen Runtimes verschiedene Vorteile (Bild: Nestybox)

Der Betrieb von mit Sysbox erstellten Containern läuft über herkömmliche Benutzerrechte. Dadurch hat der Container keine Root-Rechte auf dem System. Dazu kommt die Virtualisierung von procfs und sysfs innerhalb des Containers. Die Informationen des Containers werden vor anderen Daemons versteckt, sodass die Container sicherer betrieben werden können.

Container können Software auf Systemebene wie systemd, Docker, Kubernetes, K3s, buildx, Legacy-Anwendungen und mehr ausführen. Sysbox ermöglich generell die Bereitstellung von Containern, die über eine gehärtete Isolierung verfügen und fast jeden Dienst ausführen können, der auf VMs läuft.

Use Cases für den Einsatz von Sysbox

Der Einsatz von Sysbox ist vor allem bei Containern sinnvoll, die besonders sicher betrieben werden sollen. Auch bei einer Isolierung von Containern vom Rest des Systems ist Sysbox eine gute Wahl. Beispiele sind Container, bei denen die IT-Sicherheit und das Härten von Containern eine wesentliche Rolle spielen, zum Beispiel in den Bereichen Edge und IoT.

Für CI/CD-Szenarien und Entwicklungsumgebungen ist Sysbox ebenfalls eine gute Basis. Schlussendlich eignet sich Sysbox bei der Migration von Legacy-Anwendungen zu Containern. Wenn es um Geschwindigkeit, Effizienz und Sicherheit bei Containern geht, ist Sysbox anderen Runtimes wie Kata, KubeVirt oder gVisor oft überlegen.

Sysbox in der Praxis

Sysbox kann innerhalb von Docker und Kubernetes zum Einsatz kommen. Am Beispiel von Docker erfolgt die Installation mit dem folgenden Befehl:

Am Beispiel von Kubernetes sieht die Spezifikation folgendermaßen aus:

Die Installation lässt sich über das jeweilige Betriebssystem anstoßen, zum Beispiel Ubuntu oder Fedora. Ob Sysbox im Kubernetes-Cluster funktioniert, lässt sich zum Beispiel mit „kubectl get runtimeclass“ überprüfen. In diesem Fall sollte „sysbox-runc“ auftauchen. Ob die Pods/Container, die Sysbox für seinen Betrieb in Kubernetes braucht, gestartet sind, lässt sich wiederum mit „kubectl get pods -A“ überprüfen. Die Pods sollten den Status „Running“ haben.

Um zum Beispiel in Docker einen Container auf Basis von Sysbox bereitzustellen, kann folgender Befehl genutzt werden:

Da Sysbox VM-ähnliche Container erstellen kann, ist es innerhalb eines Sysbox-Containers möglich, weitere Container in einer verschachtelten Infrastruktur bereitzustellen. Dazu lassen sich innerhalb des Containers über Docker-Befehle Images aus den angebundenen Repositories herunterladen und im Sysbox-Container bereitstellen, zum Beispiel mit:

Der Container verhält sich so, als ob er direkt auf einem Host betrieben wird, nicht innerhalb eines anderen Containers. Interessant ist an dieser Stelle, dass Docker auf dem Host nicht den inneren Container erkennt, sondern nur den Sysbox-Container. Sysbox schirmt die Anwendungen und Daten innerhalb der Container aus Sicherheitsgründen gegenüber dem Host ab.

(ID:49018536)