Ausgangspunkt: Komplexität zum Selbstzweck
Container sind heute allgegenwärtig – ob in Rechenzentren, in CI/CD-Pipelines oder im Edge-Computing. Aber wer sich den Stack genauer anschaut, stellt fest: Zwischen Anwendung und Kernel liegt ein ganzes Gebirge aus Abstraktionen. Kubernetes, CRI, Containerd, OverlayFS, Networking-Plugins, Storage-Treiber – alles Schichten, die letztlich nur dafür sorgen, dass ein Prozess in einer eigenen Umgebung läuft.
Die eigentliche Isolation passiert längst im Kernel: Namespaces, cgroups, chroot, mount propagation.
Also stellte sich mir die Frage:
Wie viel C-Code braucht es eigentlich, um das Wesentliche davon selbst zu tun?
Das Experiment: ljexec
ljexec ist mein Versuch, genau das herauszufinden – ein Minimal-Container-Runtime-Proof-of-Concept, geschrieben in C, ohne Frameworks, ohne Dependencies, ohne Daemon.
Die Idee: Mit wenigen hundert Zeilen Code die fundamentalen Kernel-Features aktivieren, die Kubernetes, Podman oder LXC ohnehin verwenden – und zeigen, wie nah diese “modernen” Systeme eigentlich am Kernel operieren.
Ein typischer Start sieht etwa so aus:
# ljexec -n -m -p /bin/sh
Damit wird ein neuer Prozess in separaten PID-, Mount- und Network-Namespaces gestartet – völlig eigenständig, ohne Docker-Daemon, ohne containerd, ohne JSON-Manifest. Optional kann man noch ein Root-FS aus einem SquashFS-Image mounten oder ein Standalone-Binary direkt starten.
Proof of Concept, nicht Produkt
Natürlich ist ljexec (noch) nichts für den Produktionseinsatz. Es gibt weder Security-Audits noch sophisticated Logging, kein Capabilities-Management, kein Resource-Accounting. Aber genau das ist der Punkt: Es zeigt, was übrig bleibt, wenn man alles weglässt, was für den Kernel eigentlich nur Deko ist.
Der Code ist überschaubar, nachvollziehbar, direkt. Wer verstehen will,
was bei docker run oder kubectl exec wirklich passiert, findet hier
eine greifbare Referenz. Das Projekt ist damit eher ein
pädagogischer Werkzeugkasten als eine Runtime.
Motivation: Embedded & Edge
Die Idee entstand aus der Beobachtung, dass viele Embedded- und Edge-Workloads heute unnötig komplex aufgebaut werden. Kleine Systeme mit 128 MB RAM oder ARM-SoCs im Feldeinsatz müssen keinen Kubernetes-Cluster orchestrieren – sie sollen einen Job robust erledigen.
Mit Tools wie ljexec lassen sich:
- Standalone-Binaries direkt isoliert ausführen
- SquashFS-Images als “Software-Cartridges” mounten
- Prozesse starten, die sich wie Container verhalten – ohne Daemon, YAML oder JSON
Das ist kein Rückschritt, sondern eine Alternative für Minimalumgebungen, wo Einfachheit und Vorhersagbarkeit wichtiger sind als dynamische API-Schichten.
Weniger Framework, mehr Kernel
Ein Großteil der Containerwelt besteht aus Hilfskonstrukten um den Kernel herum. ljexec dagegen nutzt:
unshare()für Namespacesmount()undpivot_root()für Root-FS-Isolationsethostname()für Netzwerk-Abtrennung- und
execve()– weil am Ende alles darauf hinausläuft.
Das sind exakt die Systemcalls, die auch jede große Runtime verwendet. Nur eben ohne die 100 MB Dependencies und ohne 27 Hintergrundprozesse.
👉 Quellcode: forge.ext.d2ux.net/Atlas/ljexec
Ein bisschen Augenzwinkern darf sein
Mir ist natürlich klar: ljexec ersetzt kein Kubernetes. Es orchestriert nichts, es verwaltet keine Container, es monitored nicht. Aber es zeigt auf amüsante Weise, wie dünn die Trennlinie zwischen “Container” und “Prozess” wirklich ist.
Und manchmal hilft gerade so ein minimalistischer Ansatz, den Blick auf das Wesentliche zu schärfen: Wie viel „Innovation“ in modernen Toolchains eigentlich nur verpackte Kernel-Mechanik ist.
Fazit
ljexec ist kein Tool für den produktiven Betrieb – sondern eine
Einladung, zu verstehen, wie wenig Code nötig ist, um die Kernideen
von Containerisierung umzusetzen.
Es ist ein Gegengewicht zum Overengineering, ein Werkzeug zum Lernen, Experimentieren und Nachdenken.
Kurz gesagt: Wer die Kernel-Mechanismen direkt nutzt, versteht, warum Einfachheit keine Einschränkung ist – sondern oft der schnellste Weg zum Ziel.
Anmerkung: Der Name ljexec ist bewusst gewählt – als kleine Hommage an den ähnlichnamigen Befehl unter FreeBSD, der dort für das Starten von Jails verantwortlich ist.
Bildnachweis: Das Kubernetes-Logo ist eine eingetragene Marke der Cloud Native Computing Foundation (CNCF). Verwendung im Rahmen redaktioneller Berichterstattung. Tux, das Linux-Maskottchen, wurde von Larry Ewing erstellt (unter Verwendung von GIMP, 1996). Verwendung im Rahmen redaktioneller Berichterstattung.