OCI-kompatible Container-Runtimes Container mit runC, sysbox oder crun betreiben

Von Thomas Joos

Anbieter zum Thema

Bei runC handelt es sich um eine OCI-kompatible Runtime für Container. Dazu stellt runC auch alle Funktionen für Container zur Verfügung, die für den Betrieb mit Linux notwendig sind. Containerprozesse lassen sich daher problemlos auch mit runC betreiben.

runC lässt sich unabhängig von anderen Docker-Komponenten problemlos in Linux einbinden.
runC lässt sich unabhängig von anderen Docker-Komponenten problemlos in Linux einbinden.
(Bild: Joos / Canonical )

Die Container-Runtime runC ist seit Jahren zusammen mit „crun“ eine bekannte Alternative zum Betreiben von Container-Prozessen auf Linux-Systemen und gehört zu den beliebtesten Runtimes für Container überhaupt. Einfach ausgedrückt handelt es sich bei runC und crun um Terminal-Befehle, mit denen Entwickler ihre Container auch in einer Docker/Kubernetes-Infrastruktur starten und verwalten können.

runC benötigt Linux oder das Windows-Subsystem für Linux in Windows

Um mit runC zu arbeiten, ist eine Linux-Umgebung notwendig. Möglich ist für Entwickler und Admins aber auch der Betrieb über das Windows-Subsystem für Linux auf Rechnern mit Windows 10 und 11. Das ist ideal, wenn zum Beispiel parallel noch Visual Studio zum Einsatz kommt, um Container-Apps zu entwickeln.

Das in Go geschriebene Projekt runC ist ursprünglich direkt bei Docker gestartet. Da seine Funktionen sehr sinnvoll waren, wurde es von den Docker-Entwicklern zu einer eigenen CLI umgewandelt und als unabhängiges Tool zur Verfügung gestellt. Wer auf runC setzt, erhält also eine vollständig zu Docker und zur Open Container Initiative (OCI) kompatible Laufzeit für Container. Das Erstellen, Starten und Verwalten von Containern ist daher auf tiefer Ebene des Systems problemlos möglich.

Als Alternative zu runC ist das in C geschriebene Projekt crun interessant. Es lohnt sich generell, sich die Möglichkeiten der beiden Runtimes anzusehen. Das Projekt crun wird von Red Hat vorangetrieben und arbeitet besser mit buildah und podman zusammen. Allerdings wird podman auch von runC unterstützt. Welches Tool besser zum eigenen Projekt passt, muss jeweils getestet werden.

runC lässt sich unabhängig von anderen Docker-Komponenten problemlos in Linux einbinden.
runC lässt sich unabhängig von anderen Docker-Komponenten problemlos in Linux einbinden.
(Bild: Joos / Canonical )

Eine Container-Runtime hat vor allem die Aufgabe, Namespaces zu erstellen und Container-Prozesse zu starten. Darüber hinaus können einzelne Runtimes auch Verwaltungsaufgaben für Container durchführen. Das ist aber im Grunde genommen bei einer Runtime nicht notwendig und auch nicht immer sinnvoll. Mit runC erhalten Entwickler die Möglichkeiten, eigene Container ohne die Abhängigkeit von Images zu erstellen.

Namespaces, cgroups und Netzwerke mit runC erstellen

runC in Linux-Systemen für die Bereitstellung von Container-Prozessen einbinden.
runC in Linux-Systemen für die Bereitstellung von Container-Prozessen einbinden.
(Bild: Joos / Canonical )

Da runC alle Befehle für die Verwaltung von Containern kennt, zum Beispiel auch Namespaces oder Gruppierungen, kann das Tool vollständig in Open Container Initiative-Umgebungen (OCI) zum Einsatz kommen. Interessant ist an dieser Stelle auch, dass runC Container auch ohne Root-Rechte erstellen kann (rootless).

Mit runC lassen sich im Terminal so viele Container erstellen, wie benötigt werden. Auch Dutzende Container stellen für das Tool kein Problem dar. Nach der Installation von runC, zum Beispiel mit „sudp apt install runc“ kann mit „runc spec“ ein Sicherheitsmodell und eine Konfiguration mit „config.json“ erstellt werden. Wir kommen auf dieses Thema noch ausführlicher zu sprechen. Die Installation auf CentOS/Red Hat kann mit dem Befehl „yum install runc -y“ erfolgen.

Container lassen sich zum Beispiel mit „runc run container1“ erstellen. Dabei sollte berücksichtigt werden, dass runC das Konzept von fertigen Images nicht kennt und sich daher auch keine Images direkt starten lassen. Stattdessen erwartet runc, dass ein „OCI-Bundle“ bereitgestellt wird, das im Wesentlichen aus einem Root-Dateisystem und einer config.json-Datei besteht.

Vorhandene Container lassen sich mit „runc start“ starten. Funktioniert das, lassen sich die Prozesse mit „runc list“ anzeigen. Eine Hilfe zu den verschiedenen Optionen von runC lässt sich mit „runc --help“ anzeigen, die Anleitung mit „man runc“. Damit runC funktioniert ist ein Verzeichnis „rootfs“ notwendig und die beiden Dateien „config.json“ und „runtime.json“. Ein Beispiel dafür sieht folgendermaßen aus:

# Example
mkdir ~/mycontainer
cd ~/mycontainer
mkdir rootfs
docker export $(docker create busybox) | tar -C rootfs -xvf -
# The --rootless parameter instructs runc spec to generate a configuration for a rootless container, which will allow you to run the container as a non-root user.
runc spec --rootless
# The --root parameter tells runc where to store the container state. It must be writable by the user.
runc --root /tmp/runc run mycontainerid

Die Erstellung eines Containers mit runC besteht daher im Grunde genommen aus mehreren Schritten. Zunächst wird das passende Verzeichnis erstellt und in dem Verzeichnis eine Dummy-Datei „config.json“. Das erfolgt zum Beispiel auch mit:

mkdir my-ocibundle
cd my-ocibundle
runc spec

Auch der bereits erwähnte Ordner „rootfs“ ist notwendig und wird mit „mkdir rootfs“ erstellt. Auf der Projektseite von runC sind weitere Informationen zur Erstellung von Containern zu finden.

Container können sich mit sysbox wie virtuelle Server verhalten

Ein Trend geht in die Richtung, dass sich Container wie eine virtuelle Maschine verhalten. Dazu gehört zum Beispiel die Unterstützung von Managern wie systemd und anderen Verwaltungstools. Mit runC und crun ist dies nicht oder nur sehr eingeschränkt möglich. Hier bietet sich die Alternative sysbox an, die parallel zu runC oder crun zum Einsatz kommen kann. Diese Runtime ermöglicht es Docker-Containern, sich wie ein virtueller Server zu verhalten.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Softwareentwicklung und DevOps

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Der Vorteil besteht darin, dass Container dadurch flexibler werden und sich einzelne Anwendungen besser in das Netzwerk integrieren lassen als mit der klassischen Container-Infrastruktur. Mit sysbox erstellte Container können daher die Vorteile von Containern mit den Vorteilen von virtuellen Maschinen verbinden und dadurch eine Alternative zu VMs darstellen, wenn eine Anwendung nicht vollständig als klassischer Container betrieben werden kann.

Da es sich bei Containern im Grunde genommen nur um Linux-Prozesse handelt, die vom Kernel zwar isoliert, aber nicht vollständig getrennt sind, können diese durchaus eine Sicherheitsgefahr darstellen. Bei der Kapselung in einer virtuellen Umgebung erhöht sich die Sicherheit. VMs sind dagegen schwerer orchestrierbar und verursachen natürlich deutlich größeren Overhead bei CPU, Arbeitsspeicher und Datenträger.

Fazit

Wer eine Container-Runtime sucht, um Container in einer Docker- oder einer anderen Umgebung zu erstellen, ist mit runC gut beraten. Es lohnt sich aber immer parallel noch die Möglichkeiten von crun anzuschauen. Wer in seiner Umgebung modernere Container nutzen will, die sich zum Teil wie VMs verhalten, sollten parallel dazu auch sysbox einsetzen. Alle drei Tools funktionieren auch gemeinsam.

(ID:48023848)