- Der Artikel zeichnet die Geschichte von Server-Deployment und Prozessisolierung nach und zeigt, dass FreeBSD jails das moderne Container-Konzept der Branche um 10 Jahre voraus umgesetzt haben
- Jails, eingeführt 2000 mit FreeBSD 4.0, erweiterten
chroot und boten als kernelnative Funktion eine vollständige Isolierung von Dateisystem, Netzwerk und Prozessen
- Linux erreichte Container erst 2008 mit LXC und 2013 mit Docker, wobei sich unterwegs komplexe Abstraktionsschichten wie Namespaces, cgroups und OCI ansammelten
- Docker löste vor allem das Problem des Application Packaging und Deployment (Shipping), während jails zwar bei der Isolierung stark sind, aber kein natives Deployment-Standardformat besitzen
- Im nächsten Teil soll es um den Aufbau einer Jail-basierten Infrastruktur, ZFS-Snapshots, Provisioning mit Ansible und den praktischen Betrieb gehen
Das Problem früher Server-Deployments
- Vor Jahrzehnten bestand die Standardmethode, etwas auf einen Server zu deployen, darin, mit Total Commander, FileZilla, FAR Manager usw. Dateien manuell per FTP zu kopieren; fortgeschrittene Nutzer verwendeten
scp oder rsync, aber das Grundprinzip war dasselbe
- In Projekten, an denen man allein arbeitete, waren Fehler kein großes Problem, aber bei der Verwaltung von Dutzenden Kundenprojekten wurde das kritisch
- In typischen Backend-Setups teilten sich mehrere Websites dieselbe Apache-Webserver-Instanz und hatten denselben Lebenszyklus; fiel Apache aus, fielen alle aus
- Bei Traffic-Spitzen konnte eine einzelne Website alle Ressourcen verbrauchen, wodurch andere Websites auf demselben Server still erstickten
- Systemadministratoren versuchten, das mit Shell-Skripten zu automatisieren, doch es gab keine standardisierte Methode für Versionsverwaltung oder Rollbacks; üblich waren inkrementelle Nummern oder Zeitstempel im Projektordnernamen
Zwei Kernprobleme, die gelöst werden mussten
- Deployment: zuverlässige Auslieferung, Vermeidung menschlicher Fehler, Umsetzung von Versionsverwaltung und Rollback, Bedarf an einer universellen Lösung für alle Business-Cases
- Prozessisolierung: gegenseitiger Schutz von Apps und System, Vermeidung von Situationen, in denen die Anforderungen einer App heimlich andere Apps zerstören, Lösung von Abhängigkeitskonflikten
- Die Versuche, das Deployment-Problem zu lösen, entwickelten sich zu modernen CI/CD-Pipelines, Packaging-Standards und Versionsverwaltungssystemen, aber die Geschichte des Isolierungsproblems ist vergleichsweise wenig bekannt
Von chroot zu virtuellen Maschinen
chroot, 1979 in Bell UNIX eingeführt, gab Prozessen eine isolierte Sicht auf das Dateisystem und verhinderte den Zugriff außerhalb eines Unterbaums – eine primitive, aber nützliche Idee
- Einschränkung: Es isoliert nur das Dateisystem; Netzwerk, andere Prozesse und Systemressourcen konnten weiterhin beeinflusst werden, und ein Ausbruch war ebenfalls möglich
- Die erste ernsthafte Enterprise-Antwort waren virtuelle Maschinen (VMs), die VMware Ende der 1990er Jahre in den Mainstream brachte
- Sie boten jeder Anwendung eine vollständig isolierte OS-Umgebung, doch da jede VM ein komplettes Betriebssystem enthielt, entstanden erheblicher Overhead und Startzeiten im Minutenbereich
Die Geburt von FreeBSD Jails
- Im Jahr 2000 kam es nicht unter Windows Server oder Linux, sondern bei FreeBSD zu einer stillen Revolution
- FreeBSD funktioniert grundlegend anders als Linux: Während Linux nur den Kernel liefert und GNU-Userland, Package-Ökosystem und distributionsspezifische Entscheidungen kombiniert werden, entwickelt, versioniert und testet FreeBSD Kernel, Userland, Basistools und Bibliotheken gemeinsam als vollständiges OS
- Auf dieser konsistenten Basis entstand jails, vorgestellt von Poul-Henning Kamp und Robert Watson und in FreeBSD 4.0 (März 2000) als native Kernel-Funktion aufgenommen
- Jede Jail besitzt ihre eigene Dateisystemsicht, ihren eigenen Netzwerk-Stack und eigenen Prozessraum; das Host-System bleibt unsichtbar
- Da sie sich den Host-Kernel teilen, ermöglichen sie nahezu null Overhead und fast sofortige Startzeiten
- FreeBSD erreichte in der Produktion eine praktische Umsetzung dessen, was wir heute Container nennen, 10 Jahre vor der Branche
Die Timeline der Isolierungstechnologien
- Der tatsächliche Entwicklungspfad des Isolierungsproblems: gemeinsam genutzte Server ohne Isolierung → schwere, aber isolierte virtuelle Maschinen → leichtgewichtige und zugleich isolierte Container
- FreeBSD erreichte die dritte Stufe im Jahr 2000, Linux 2008 mit LXC, Docker erschien 2013
- Als Docker als revolutionär gefeiert wurde, waren FreeBSD jails bereits 13 Jahre lang gereift und in der Praxis erprobt
Warum Linux gewann
- Technische Überlegenheit gewinnt keine Ökosystem-Kriege
- Linux gewann durch schnelle Entscheidungen, den viralen Effekt der GPL-Lizenz und starke Enterprise-Unterstützung durch Red Hat und IBM
- Danach entwickelten Google, Facebook und Amazon Tools für große Rechenzentren und gaben damit die Richtung für die gesamte Branche vor
- Linux wandelte sich von einem „kostenlosen OS für Leute, die sich keine kommerzielle Lizenz leisten konnten“ zu „der einzigen Option für Server“
Die Komplexität des Linux-Container-Ökosystems
- Um die Probleme von Isolierung und Deployment zu lösen, bauten Linux-Ingenieure Kernel-Primitiven wie Namespaces, cgroups, seccomp auf und stapelten darauf komplexe Abstraktionsschichten wie LXC (2008) → OCI/runc (2015) → Docker/Podman (2013/2018) → Docker Hub
- Das Ergebnis war ein überengineertes Bündel leaky abstractions für cloudbasierte, vendorabhängige Infrastruktur
- Heute gilt es beim Betrieb von Anwendungen in großen Systemen als impliziter Standard, sie mit Docker zu containerisieren und mit Kubernetes zu orchestrieren – nicht als eine von mehreren Optionen, sondern als selbstverständliche Wahl
Dockers Beitrag und die Schwäche von Jails
- Was Docker gut gelöst hat, ist das Shipping-Problem: Anwendungen mit allen Abhängigkeiten zu paketieren, über Registries zu verteilen und auf jeder Maschine identisch auszuführen – als universeller Standard
- Das OCI-Image-Format etablierte sich als faktischer Industriestandard
- Jails lösen das Isolierungsproblem hervorragend, aber es fehlt eine native Lösung für Shipping; das ist ein Hauptgrund dafür, dass das Jail-Ökosystem im Vergleich zum Docker-Ökosystem unreifer wirkt
- Auch die Community erkennt diese Lücke, und einige Tools (
cbsd, bastille, pot, appjail usw.) versuchen, das moderne Container-Ökosystem nachzuahmen; daneben gibt es andere Ansätze, die FreeBSD-native Primitiven nutzen
Ausblick auf den nächsten Teil
- Im nächsten Teil geht es um die Schlichtheit und Eleganz einer FreeBSD-basierten Infrastruktur, von den Grundlagen von jails und ihrer Funktionsweise über die Reduzierung von Boilerplate mit Jail-Managern bis hin zu Provisioning und Deployment mit Ansible, der Stärke von ZFS-Snapshots und der Frage, wie sich all das zu einer robusten und skalierbaren Infrastruktur für Hypha kombinieren lässt
1 Kommentare
Hacker-News-Kommentare
Mit technischer Überlegenheit allein ließ sich der Ökosystem-Krieg nicht gewinnen.
Mitte der 90er wuchs Linux dank schneller Entscheidungen, der Ansteckungswirkung der GPL-Lizenz sowie der Unterstützung von Unternehmen wie Red Hat und IBM.
Ich installierte 1994 Linux, aber in der FreeBSD-Community wurde mein 3.500-Dollar-PC als „nicht besonders“ abgetan.
Es gab einen Bug in der IDE-Schnittstelle, doch Linux hatte innerhalb weniger Tage einen Workaround, während man auf BSD-Seite nur sagte, ich solle SCSI-Hardware kaufen.
Als Student hatte ich damals kein Geld, und am Ende war Linux die realistische Wahl.
Später probierte ich FreeBSD noch einmal aus, aber da erledigte Linux bereits alles, was ich brauchte.
Der betreffende Bug ist im CMD640-Wikiartikel dokumentiert.
Trotzdem gefällt mir an FreeBSD die höhere Konsistenz des Systems und dass zentrale Komponenten wie Sound- oder Event-APIs stabil gepflegt werden.
Bei aktueller Treiberunterstützung für neue Hardware ist Linux zwar weiterhin besser, aber ich hoffe, dass FreeBSD nicht zu sehr „linuxisiert“ wird.
Tatsächlich kann man mit jedem modernen *nix fast alles machen. Inzwischen geht es weniger um Performance als um Präferenzen und Vertrautheit.
BSD hingegen wurde wegen des Rechtsstreits mit AT&T von Unternehmen gemieden, und in der Zwischenzeit übernahm Linux den Markt.
Auch heute erscheinen noch Texte zur Verteidigung von FreeBSD, aber die in den 90ern entstandene Dynamik lässt sich nur schwer umkehren.
Trotzdem denke ich, dass es bei der Hardware-Unterstützung auch heute noch viel Luft nach oben gibt.
Der Artikel war interessant.
Ich stimme aber nicht der Einschätzung zu, dass Kernel-Primitiven von Linux wie namespaces, cgroups, seccomp am Ende ein komplexes Ökosystem aus Abstraktionen geschaffen hätten.
Linux wurde komplex, weil es erfolgreich war, nicht wegen eines gescheiterten Designs.
Wäre BSD Mainstream geworden, wäre dort genauso ein „überengineertes“ Ökosystem entstanden.
Container sind letztlich nur leichte VMs, daher halte ich echte VMs für die bessere Wahl.
Docker wurde wegen Wiederverwendbarkeit und Ökosystem populär, nicht wegen Sicherheitsisolierung.
FreeBSD-jails sind schlicht und elegant, aber Linux-OCI-Container sind viel einfacher zu benutzen.
Container sind keine eigenständige Kernel-Funktion, sondern eine Illusion aus mehreren Namespaces sowie Mount- und Prozessisolierung.
Das Linux-Design ist absichtlich so gewählt, und cgroups sowie seccomp werden weit über Container hinaus etwa in systemd oder flatpak genutzt.
Die Philosophie „Vieh statt Haustiere“ lässt sich auf VM- und Orchestrierungsebene anwenden.
Dass jails besser seien, wirkt auf mich in der Praxis nicht überzeugend.
Docker gewann nicht wegen technischer Isolierung, sondern wegen des Ökosystems.
Mit Werkzeugen wie Dockerfile, öffentlichen Registries und Compose konnte man in 30 Sekunden eine lauffähige Umgebung erstellen.
FreeBSD-jails waren technisch hervorragend, aber die Einstiegshürde war hoch.
In jüngerer Zeit sieht man wegen der Komplexität des Container-Stacks auch wieder eine Bewegung zurück zu einfachen jails oder VMs.
Es geht aber nicht um Wettbewerb, sondern darum, dass jedes System seine eigene Rolle hat.
FreeBSD hat kein vergleichbares Konzept, und es fehlt auch ein starkes Image-System.
Hätte FreeBSD wie Docker in UX und Ökosystem investiert, wäre die Nutzerbasis wohl um ein Mehrfaches größer geworden.
Um 2005 herum betrieben wir die gesamte Firma auf FreeBSD.
Doch im Lauf der Zeit übernahm Linux sowohl privat als auch beruflich alles.
Inzwischen ist auch Docker gut genug, und es gibt keinen logischen Grund, zurückzuwechseln.
Es reagierte jedoch zu langsam auf das Zeitalter der Multicore-CPUs und wurde von Linux und Windows überholt.
Die Performance hat sich inzwischen erholt, aber Treiberdefizite und die begrenzte Zahl an Entwicklern bleiben ein Nachteil.
Ich nutze Linux dort, wo GPU oder CUDA gebraucht werden, und FreeBSD für stabile Server.
Die UX von FreeBSD ist konsistenter, aber realistisch betrachtet ist Linux zum „Happy Path“ geworden.
Beiträge, die FreeBSD vorstellen, sind immer willkommen.
FreeBSD führte jails zwar im Jahr 2000 ein, aber unter Linux gab es mit OpenVZ und VServer bereits ähnliche Technologien.
Erst als Ende der 2000er LXC auftauchte, entstand die Wahrnehmung, dass „FreeBSD voraus war“.
Ich würde gern einen Artikel lesen, der die technische Umsetzung der Isolierung bei Containern und VMs erklärt.
Nicht nur im Sinne von „gleicher Kernel, daher schwächer“, sondern mit echten Implementierungsdetails.
Wegen Funktionen wie systemd-oomd denke ich in letzter Zeit öfter darüber nach, wieder zu FreeBSD zurückzukehren.
Früher ließ ich in einem Terminal mehrere Prozesse laufen und protokollierte Logs während der Entwicklung,
aber inzwischen beendet systemd ganze Prozessgruppen auf cgroup-Ebene, wodurch Arbeit verloren geht.
Solche inkompatiblen Systemänderungen stören den Entwicklungsfluss, und es ist frustrierend, für Prozessisolierung jedes Mal systemd-run oder Docker verwenden zu müssen.
Der Schlüssel zum Erfolg von Linux war die Ansteckungswirkung der GPL und der Netzwerkeffekt.
Als Nutzer Linux als Standard wahrnahmen, brachten Hardware-Hersteller ganz selbstverständlich Treiber für Linux heraus.
Dank der Flexibilität des Kernels wuchs das Ökosystem für Open-Source-Treiber explosionsartig.