Eigenen Container-Runtime in Go mit Linux-Mitteln entwickeln

Ein Container startet einen Prozess – und plötzlich hat dieser ein eigenes Dateisystem, ein eigenes Netzwerk, eine eigene Umgebung. Doch wie funktioniert das überhaupt unter der Haube? Viele Entwickler nutzen Docker oder containerd, ohne zu verstehen, was im Hintergrund abläuft.

Statt sich durch unzählige Blogartikel zu kämpfen, entschied sich ein Entwickler für einen pragmatischen Ansatz: Er baute seine eigene Container-Laufzeit von Grund auf – ohne Docker, containerd oder LXC. Stattdessen nutzte er ausschließlich Linux-interne Mechanismen wie Namespaces, cgroups, Netzwerk-Isolierung und Dateisystem-Trennung. Das Ergebnis: LXR, eine in Go entwickelte Laufzeitumgebung, die Containerisierung mit minimalistischen Mitteln ermöglicht.

Warum eine eigene Container-Laufzeit bauen?

Die Motivation hinter dem Projekt war einfach: Der Entwickler wollte ein tiefes Verständnis dafür entwickeln, wie Containerisierung eigentlich funktioniert. Docker und ähnliche Tools sind zwar mächtig, aber sie verbergen viele technische Details hinter Abstraktionen. Durch das Bauen einer eigenen Laufzeit sollte nicht nur die Theorie, sondern auch die Praxis verstanden werden – von der Prozessisolierung bis zur Netzwerkkonfiguration.

Das Ziel war klar definiert: LXR sollte nicht nur Container erstellen, sondern auch ihre Nutzung vereinfachen. Ob über die Kommandozeile oder einen Browser – die Laufzeit sollte eine nahtlose Integration bieten. Dabei setzte der Entwickler auf folgende Kernfunktionen:

• Abrufen von Images aus Docker Hub
• Extraktion der Root-Filesysteme
• Einrichtung isolierter Container
• Automatische Netzwerkkonfiguration (inklusive veth, Bridge und IP-Zuweisung)
• Shell-Zugriff via lxr exec
• Integrierter Code-Server für browserbasierte Entwicklungsumgebungen

So funktioniert LXR im Detail

Die Bedienung von LXR wirkt auf den ersten Blick simpel. Ein Befehl wie

lxr create --name goCon golang

erzeugt einen neuen Container mit dem Namen goCon, der auf einem Go-Image basiert. Doch was passiert tatsächlich im Hintergrund? Der Entwickler beschreibt den Prozess als eine Kette komplexer Schritte, die alle notwendig sind, um einen einzigen Container zu starten:

1. Image-Layer abrufen: LXR lädt die benötigten Schichten des Docker-Images herunter und kombiniert sie zu einem vollständigen Root-Filesystem.
2. Abhängigkeiten installieren: Im extrahierten Root-Filesystem werden alle notwendigen Pakete installiert – ähnlich wie bei einem frischen System.

1. Root-Filesystem vorbereiten: Das isolierte Dateisystem wird für die Container-Nutzung konfiguriert, inklusive aller notwendigen Verzeichnisse und Berechtigungen.

1. Overlay-Filesystem erstellen: Um Änderungen am Container zu ermöglichen, ohne das Original-Image zu modifizieren, kommt ein Overlay-Filesystem zum Einsatz. Dieses ermöglicht eine effiziente Schreibweise auf readonly-Layern.

1. Netzwerk einrichten: Ein virtuelles Ethernet-Interface (veth) wird erstellt und an eine Bridge angebunden. Eine IP-Adresse wird dynamisch zugewiesen, um den Container im Netzwerk sichtbar zu machen.

1. Prozess starten: Der eigentliche Container-Prozess wird in der isolierten Umgebung gestartet – vollständig getrennt von anderen Prozessen des Systems.

1. Code-Server integrieren: Für eine browserbasierte Entwicklungsumgebung wird automatisch ein Code-Server innerhalb des Containers gestartet, der über eine Webschnittstelle zugänglich ist.

All diese Schritte laufen ab, nur um einen einzigen Container zu starten. Der Entwickler betont, dass selbst scheinbar einfache Operationen wie das Starten eines Prozesses unter Linux mit Namespaces und Berechtigungen komplex sein können.

Erste Hürden: Warum Root-Zugriff oft unverzichtbar ist

Die größte Herausforderung tauchte bereits zu Beginn auf – und sie hatte wenig mit Netzwerk oder Dateisystemen zu tun. Es ging um Berechtigungen. Der Entwickler versuchte zunächst, Container als normaler (nicht-root) Benutzer zu starten. Doch die Ergebnisse waren unerwartet: Prozesse scheiterten oder verhielten sich unvorhersehbar.

Die Ursache lag in der Art und Weise, wie Linux Namespaces und Berechtigungen handhabt. Einige Linux-Kernel-Features – etwa die Nutzung von User Namespaces oder die Konfiguration von Capabilities – erfordern Root-Privilegien. Ohne diese können bestimmte Isolierungsmechanismen nicht vollständig umgesetzt werden.

Der Entwickler plant, diese Problematik in einem folgenden Beitrag detailliert zu analysieren und mögliche Lösungsansätze vorzustellen. Für den Moment zeigt das Projekt jedoch: Selbst bei einfachen Container-Implementierungen stoßen Entwickler schnell an die Grenzen von Standard-Berechtigungsmodellen.

Ein Schritt in Richtung transparenter Containerisierung

LXR ist mehr als nur ein Proof-of-Concept. Es demonstriert, dass Containerisierung auch ohne monolithische Laufzeiten wie Docker möglich ist – solange man die zugrundeliegenden Linux-Mechanismen versteht und richtig einsetzt. Für Entwickler, die sich tiefer mit der Materie beschäftigen möchten, bietet das Projekt eine einfache, aber leistungsfähige Grundlage, um Containerisierung von Grund auf zu lernen.

Die nächsten Schritte könnten darin bestehen, die Laufzeit weiter zu optimieren, die Fehlerbehandlung zu verbessern oder sogar eine grafische Oberfläche für die Verwaltung von Containern zu entwickeln. Eines ist jedoch klar: Projekte wie LXR zeigen, dass die Container-Welt nicht nur aus großen Ökosystemen besteht – sondern auch aus kleinen, aber mächtigen Alternativen, die Transparenz und Kontrolle zurück in die Hände der Entwickler legen.

Wer selbst experimentieren möchte, findet den Quellcode auf Plattformen wie GitHub. Vielleicht ist LXR der Anfang für eine neue Generation von Container-Tools – oder zumindest ein wertvolles Lernprojekt für alle, die verstehen wollen, was wirklich hinter docker run steckt.