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.
(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.
(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.
(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.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH, Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung.
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.