Kategorie: FreeBSD

Docker ist überall. Jedes Tutorial, jeder Workshop, jeder Stack-Overflow-Thread — alles dreht sich um Container. Und ehrlich: Das hat Gründe. Docker hat die Bereitstellung von Software radikal vereinfacht. Aber hier ist die unbequeme Frage, die sich kaum jemand stellt: Was macht Docker eigentlich, das ein Betriebssystem nicht schon kann?

Die Antwort, die ich im Lauf der Jahre gefunden habe, lautet: Erstaunlich wenig — wenn das Betriebssystem FreeBSD heißt.

Dieser Artikel ist mein Versuch, die Diskussion über Container-Isolation neu aufzurollen — nicht als Docker-Bashing, sondern als ehrlicher technischer Vergleich zwischen zwei Philosophien, die das gleiche Problem auf grundverschiedene Weise lösen.

Was ist ein Jail?

Ein FreeBSD-Jail ist, auf den Punkt gebracht, ein chroot mit Netzwerk. Und das ist nicht abwertend gemeint — es ist die präzise Beschreibung.

Wenn du unter Linux chroot /mein/verzeichnis ausführst, hast du einen Prozess, der ein anderes Dateisystem-Root sieht. Aber er teilt sich den Kernel, die Netzwerk-Interfaces, die Prozess-Tabelle, die User-IDs — alles. Ein chroot isoliert das Dateisystem, aber sonst nichts. Deswegen heisst es auch nicht umsonst chroot — change root, nicht isolate.

Ein Jail geht weiter. Viel weiter. Ein Jail-Prozess bekommt:

• Ein eigenes Dateisystem-Root (wie chroot)
• Ein eigenes Netzwerk-Interface (eigene IP, eigener Hostname)
• Eine eigene Prozess-Tabelle (Prozesse im Jail sehen nur andere Prozesse im Jail)
• Eigene User-IDs (root im Jail ist nicht root auf dem Host)
• Eigene Netzwerk-Stacks (eigene Ports, eigene Firewall-Regeln möglich)

Und das alles ohne einen Hypervisor. Ohne Virtualisierung. Ohne Emulation. Der Kernel läuft weiter — ein einziger Kernel, der die Isolation direkt bereitstellt, und das als Design.

So sieht das in der Praxis aus:

jail -c path=/jails/webapp host.hostname=webapp.example.com \
  ip4.addr=192.168.1.10 command=/bin/sh

Das war’s. Kein Dockerfile. Kein Build-Kontext. Keine Registry. Ein Befehl, und du hast einen isolierten Prozess, der in seinem eigenen Teil des Systems läuft.

Jails existieren seit dem Jahr 2000. Sie waren da, als Linux noch über chroot stolperte und Container ein Konzept war, das man in Vorlesungen über Betriebssysteme erwähnte. FreeBSD hat das Problem der Prozessisolation vor über 25 Jahren im Kernel gelöst — und die Lösung ist bis heute stabil, sicher und geradezu banal einfach.

Docker-Anatomie: Der Zoo

Lass uns einen Schritt zurücktreten und anschauen, was Docker eigentlich ist. Nicht die Marketing-Version. Die echte Architektur.

Docker besteht aus:

• dockerd — Ein Daemon, der im Hintergrund läuft und alle Container verwaltet. Er hat Root-Rechte. Er lauscht auf einem Socket. Er ist ein Single Point of Failure und ein Single Point of Compromise.
• Docker Registry — Docker Hub (oder eine private Registry), wo Images gespeichert werden. Du pullst Images, du pushst Images. Du hängst an der Verfügbarkeit einer externen Infrastruktur.
• Image Layers — Jedes Image besteht aus Schichten. Jede Schicht ist ein diff über der vorherigen. Das macht Images transportabel, aber es erzeugt einen ganzen Stack von Overlay-Dateisystemen, der zur Laufzeit übereinander gelegt wird.
• Dockerfile — Ein eigenes Build-Format mit eigener Syntax. FROM, RUN, COPY, ENTRYPOINT. Ein Mini-Package-Manager-Ökosystem in Textform.
• Eigener Package-Manager — apk in Alpine, apt in Debian-Images, oft gemischt. Docker hat keinen eigenen Package-Manager, aber es zwingt dich, den der Base-Distribution zu nutzen — innerhalb eines Build-Contexts, der isoliert vom Rest deines Systems ist.
• Docker Compose — Weil ein Container selten allein kommt. Du brauchst ein YAML-File, um mehrere Container zu orchestrieren. Compose ist de facto ein eigenes Tool mit eigener Syntax und eigenen Konventionen.
• Swarm / Kubernetes — Weil Compose nicht für Produktion reicht. Swarm ist praktisch tot. Kubernetes ist… Kubernetes. Ein eigenes Ökosystem mit eigenem Vokabular, eigenen Konzepten, eigener Komplexität.

Das ist ein ganzer Zoo. Und ich meine das nicht nur umgangssprachlich. Docker hat sich von einem Tool zur Prozessisolation zu einer Plattform entwickelt, die ein eigenes Betriebssystem innerhalb deines Betriebssystems aufbaut. Eigene Networking-Lösung. Eigene Storage-Treiber. Eigene Build-Pipeline. Eigene Orchestrierung.

Wenn du Docker einsetzt, betreibst du ein Schichtenmodell:

Hardware → Host-OS → Docker-Daemon → Container-Runtime → Overlay-FS → Container

Jede Schicht hat ihre eigenen Fehlerquellen, ihre eigenen Konfigurationsmöglichkeiten, ihre eigenen Bugs. Und jede Schicht nimmt dir Kontrolle ab und gibt dir Abstraktion. Ob das ein fairer Trade ist, hängt davon ab, was du brauchst. Aber es ist ein Trade — und den sollte man mit offenen Augen machen.

Jail-Anatomie: Das, was übrig bleibt, wenn man alles weglässt

Jetzt der Kontrast. Ein FreeBSD-Jail besteht aus:

• Kernel-Isolation — Der FreeBSD-Kernel bietet Isolation direkt an. Kein Daemon dazwischen. Keine Runtime. Der Kernel ist die Runtime.
• Netzwerk-Isolation — Jedes Jail bekommt sein eigenes IP-Interface. Kein NAT nötig (aber möglich). Kein Bridge-Netzwerk, das du erst verstehen musst. Einfach eine IP, und der Traffic kommt an.
• Dateisystem-Isolation — Das Jail-Root ist ein Verzeichnis. Alles darunter gehört zum Jail. Alles außerhalb existiert für Prozesse im Jail nicht.

Und das war’s. Kein Daemon. Keine Registry. Keine Layer. Kein Build-System. Keine YAML-Datei mit 40 Zeilen, um drei Services zu starten.

Die Verwaltung sieht so aus:

# Jail starten
jail -c path=/jails/webapp host.hostname=webapp ip4.addr=192.168.1.10 \
  command=/sbin/init

# Jail stoppen
jail -r webapp

# Jail-Konfiguration (persistent)
# /etc/jail.conf:
webapp {
    path = /jails/webapp;
    ip4.addr = 192.168.1.10;
    host.hostname = webapp.example.com;
    mount.devfs;
    exec.start = "/bin/sh /etc/rc";
    exec.stop = "/bin/sh /etc/rc.shutdown";
}

Das ist die komplette Konfiguration. Kein YAML. Keine Environment-Variablen, die durch drei Dateien gereicht werden. Keine Networks, die du erst definieren musst. Die Konfiguration ist lesbar, greifbar, debuggbar.

Wenn etwas schiefgeht, greifst du auf die Standard-FreeBSD-Tools zurück. ps, top, sockstat, dmesg — alles funktioniert wie gewohnt, weil es ein echtes System ist, kein Container-Abstraktionslayer.

Die ZFS-Verbindung: Instant-Cloning

Hier wird es spannend. FreeBSD und ZFS sind ein Traumpaar — und Jails profitieren davon massiv.

Stell dir vor, du willst eine neue Instanz deiner Web-Anwendung aufsetzen. Mit Docker: Image pullen, Container starten. Mit Jail und ZFS geht etwas viel Eleganters:

# Snapshot des Basis-Jails erstellen
zfs snapshot zroot/jails/base@clean

# Klonen — dauert Sekundenbruchteile, dank Copy-on-Write
zfs clone zroot/jails/base@clean zroot/jails/webapp2

# Jail konfigurieren und starten
# (Eintrag in /etc/jail.conf)
jail -c webapp2

Das war’s. Der Clone ist da. Sofort. Kein Download. Kein Layer-Aufbau. Kein Caching. ZFS nutzt Copy-on-Write, also belegt der Clone initially keinen zusätzlichen Speicherplatz. Erst wenn sich Dateien zwischen Clone und Original unterscheiden, wird Platz belegt.

Und das Beste: Du kannst das automatisieren. Ein kleines Skript, das einen ZFS-Snapshot nimmt, klont, die Jail-Konfiguration anpasst, und fertig. Kein CI/CD-Pipeline nötig, die ein Docker-Image baut und pusht. Du kannst es natürlich trotzdem tun — aber du musst nicht.

pkgbase: Sauberes Base-System-Management

FreeBSD bietet seit einiger Zeit pkgbase — Pakete für das Base-System. Das bedeutet, du kannst das FreeBSD-Base-System innerhalb eines Jails wie jedes andere Paket aktualisieren:

pkg install FreeBSD-base-default
pkg upgrade FreeBSD-base-default

Statt freebsd-update in jedem Jail laufen zu lassen oder das Base-System manuell zu bauen, kannst du Versionierte, reproduzierbare Base-System-Pakete nutzen. In Kombination mit ZFS-Snapshots bedeutet das: Du kannst ein Jail auf eine bestimmte Base-Version zurückrollen, ohne dass irgendwelche Overlay-Layer involviert sind.

Das ist reproduzierbar. Das ist transparent. Das ist genau das, was Docker mit seinen Layer-Caching verspricht, aber tatsächlich nur mühsam nachbaut.

Praktischer Vergleich: Eine Web-Anwendung deployen

Lass uns das konkret machen. Wir wollen eine typische Web-Anwendung deployen: Nginx als Reverse Proxy, eine App (sagen wir: eine Go-Binary), und PostgreSQL als Datenbank.

Mit Docker

1. Dockerfile schreiben — Basis-Image wählen, Abhängigkeiten installieren, Binary hineinkopieren. 15-30 Zeilen.
2. docker-compose.yml schreiben — Drei Services definieren. Netzwerk konfigurieren. Volumes für persistente Daten. Environment-Variablen. 40-60 Zeilen.
3. Image bauen — docker build -t meineapp .. Dauer: 30 Sekunden bis 10 Minuten, je nach Caching und Komplexität.
4. Image pushen — Auf eine Registry, damit der Server es pullen kann. docker push meineapp:latest.
5. Auf dem Server pullen — docker pull meineapp:latest.
6. Starten — docker-compose up -d.
7. Prüfen — docker ps, docker logs, docker exec -it ...

Fehlerquellen:

• Image-Layer-Caching führt zu veralteten Abhängigkeiten
• Der Docker-Daemon muss laufen
• Netzwerk zwischen Containern ist ein Bridge-Netzwerk mit eigenen Eigenheiten
• Volumes werden vergessen oder falsch gemountet
• Environment-Variablen müssen durchgereicht werden
• Image-Grösse bläht auf, weil jeder Layer seinen eigenen Overhead hat

Mit FreeBSD-Jails

1. ZFS-Dataset für das Jail erstellen — zfs create zroot/jails/webapp
2. Base-System installieren — pkgbase oder bsdinstall oder aus einem Snapshot klonen.
3. Jail konfigurieren — Eintrag in /etc/jail.conf. 10 Zeilen.
4. Pakete installieren — Im Jail: pkg install nginx postgresql16-server. Oder du installierst deine Go-Binary direkt per scp oder pkg install.
5. Services konfigurieren — Standard FreeBSD-Konfiguration. /etc/rc.conf im Jail, Nginx-Konfig, PostgreSQL-Konfig.
6. Jail starten — service jail start webapp
7. Prüfen — jls, jexec webapp ps aux, Standard-Logs unter /var/log

Fehlerquellen:

• Konfigurationsfehler (wie überall)
• Aber: Kein Daemon, der abstürzen kann
• Kein Overlay-Filesystem, das korrumpiert
• Keine Layer, die sich unerwartet verhalten
• Netzwerk ist echtes Netzwerk — was du konfigurierst, ist was du bekommst

Der Unterschied ist nicht nur die Anzahl der Schritte. Es ist die Art der Komplexität. Bei Docker ist die Komplexität in der Toolchain. Bei Jails ist die Komplexität im System — aber das System ist transparent, dokumentiert, und verhält sich wie erwartet, weil es ein echtes Betriebssystem ist, kein Abstraktionslayer.

Security: Isolation per Design vs. Isolation nachgerüstet

Dies ist der Punkt, der mich am meisten bewegt.

FreeBSD-Jails existieren seit dem Jahr 2000. Sie wurden von Anfang an als Isolationsmechanismus designt. Die Sicherheitsgarantien sind Teil des Kernel-Designs:

• Ein Prozess in einem Jail kann nicht auf Prozesse ausserhalb zugreifen.
• Ein Prozess in einem Jail kann nicht Kernel-Module laden.
• Ein Prozess in einem Jail kann nicht Netzwerk-Interfaces ausser seinem eigenen sehen.
• root in einem Jail ist nicht root auf dem Host.

Diese Garantien sind nicht optional. Sie sind nicht ein Config-Flag, das du setzen kannst — oder vergessen kannst. Sie sind die Default-Annahme des Systems.

Docker? Docker lief jahrelang mit Containern, die als root liefen. Die Standard-Konfiguration gab Containern volle Root-Rechte auf dem Host. User-Namespaces wurden erst 2016 eingeführt — und waren jahrelang experimentell. Seccomp-Profile kamen hinzu, aber die Standard-Profile waren lasch und komplexe Profile waren schwer zu schreiben. Capability-Dropping existiert, aber die meisten Container liefen (und laufen) mit zu vielen Capabilities.

Die Geschichte von Container-Security unter Linux ist eine Geschichte von Nachbesserungen. Jedes Jahr kamen neue Mechanismen hinzu: Namespaces, cgroups, Seccomp, AppArmor, SELinux, User-Namespaces, Rootless-Mode. Jeder einzelne Mechanismus ist sinnvoll. Aber zusammen ergeben sie ein Patchwork, das tiefes Expertenwissen erfordert, um es korrekt zu konfigurieren.

FreeBSD-Jails? Da gibt es nichts nachzurüsten. Die Isolation war 2000 da. Sie ist 2026 immer noch da. Und sie hat sich bewährt — in Produktion, in Hosting-Umgebungen, in Firmen, die seit Jahrzehnten Jails betreiben.

25 Jahre getestete Kernel-Isolation vs. ein Patchwork aus nachgerüsteten Linux-Mechanismen.

Ein konkretes Beispiel

Stell dir vor, ein Angreifer bekommt Shell-Zugriff in deinem Container.

Im Docker-Container (ohne User-Namespaces):

• Der Angreifer ist root.
• Er kann alle Prozesse im Container sehen.
• Er kann Netzwerk-Verbindungen des Hosts potenziell sehen (je nach Konfiguration).
• Er kann Capabilities ausnutzen, die der Container hat.
• Escalation zum Host ist historisch wiederholt gelungen.

Im Jail:

• Der Angreifer sieht nur Prozesse im Jail.
• Er sieht nur das Netzwerk-Interface des Jails.
• Selbst als root im Jail kann er nicht auf den Host zugreifen.
• Escalation erfordert einen Kernel-Bug — und FreeBSD hat eine exzellente Security-Historie.

Der Unterschied ist architektonisch, nicht konfiguratorisch.

Performance: Direkter Zugriff vs. Layer-Stack

Performance ist nicht das wichtigste Argument für Jails — aber es ist ein schönes Nebenargument.

Ein Docker-Container läuft auf einem Overlay-Filesystem. Das bedeutet: Jeder Schreibzugriff geht durch einen Layer-Stack. OverlayFS (oder AUFS, oder Btrfs, oder Device Mapper — je nachdem, was du konfiguriert hast) muss bei jedem Dateizugriff prüfen, in welchem Layer die Datei liegt. Das kostet Zeit. Bei vielen kleinen Schreibzugriffen (Datenbanken, Logs) spürst du das.

Ein Jail läuft auf einem echten Dateisystem. ZFS, UFS — was immer du nutzt. Kein Overlay. Keine Layer-Auflösung. Direkter Zugriff. Punkt.

Dann der Daemon: Docker hat dockerd. Ein Prozess, der im Hintergrund läuft, Ressourcen verbraucht, und ein Angriffsziel ist. Jails haben keinen Daemon. Der Kernel macht die Isolation. Kein Prozess, der sterben kann. Kein Prozess, den du überwachen musst.

Und Layer-Caching? Docker macht viel Aufwand darum, Layer zwischen Images wiederzuverwenden. Das ist clever, aber es ist ein Workaround für ein Problem, das gar nicht existieren müsste. Mit ZFS und pkgbase hast du Copy-on-Write und geteilte Datasets. Gleicher Effekt, weniger Komplexität.

Die Zahlen sprechen für sich, auch wenn der Unterschied bei einfachen Workloads marginal ist:

Bei hunderten von Jails/Containern macht das einen messbaren Unterschied. Bei ein paar dutzend ist es vernachlässigbar — aber es ist trotzdem ein Unterschied, der auf architektonischer Eleganz beruht, nicht auf Micro-Optimierung.

Wann Docker Sinn macht — und wann Jails die bessere Wahl sind

Ich bin kein Dogmatiker. Docker hat seinen Platz. Lass uns ehrlich sein:

Docker ist die bessere Wahl, wenn:

• Du Microservices deployst, die von Dritten kommen. Wenn jemand ein Docker-Image bereitstellt, ist es einfacher, das zu nutzen, als es in ein Jail zu portieren.
• Du in einem Team arbeitest, das Docker kennt. Das ist vielleicht das wichtigste Argument. Docker ist die Lingua franca der DevOps-Welt. Neue Kollegen kennen Docker. Jails müssen sie erst lernen.
• Du Kubernetes brauchst. K8s ist das Standard-Orchestrierungstool. Es funktioniert mit Docker (oder containerd). Es gibt kein Äquivalent für Jails — und das wird es wahrscheinlich auch nie geben.
• Du Cloud-native arbeitest. AWS, GCP, Azure — sie alle bieten native Docker-Unterstützung. FreeBSD-Jails auf AWS? Machbar, aber du bist auf dich gestellt.
• Du schnelle Prototypen brauchst. docker run -it ubuntu bash ist schneller als ein Jail aufzusetzen — es sei denn, du hast einen ZFS-Snapshot bereit.

Jails sind die bessere Wahl, wenn:

• Du dein eigenes Hosting betreibst. Eigener Server, eigenes Rechenzentrum, eigene Infrastruktur. Hier hast du die volle Kontrolle und kannst Jails optimal nutzen.
• Du langfristige Stabilität willst. FreeBSD und Jails sind seit Jahrzehnten stabil. Keine Breaking Changes im Isolations-Modell. Kein Daemon, der updated werden muss.
• Du Security ernst nimmst. Kernel-level Isolation statt nachgerüsteter Linux-Mechanismen. Kein Daemon mit Root-Rechten.
• Du Einfachheit schätzt. Weniger Moving Parts. Weniger, was kaputtgehen kann. Standard-Betriebssystem-Werkzeuge statt eines ganzen Ökosystems.
• Du ZFS nutzt. Die Kombination aus Jails und ZFS ist mächtiger als Docker je sein kann — Instant-Cloning, Snapshots, Replication, Deduplizierung. Alles nativ, alles integriert.
• Du Vollständige Kontrolle willst. Über das Betriebssystem, über die Isolation, über die Netzwerk-Konfiguration. Jails geben dir die volle Macht des Betriebssystems, nicht die Teilmenge, die Docker freigibt.

Die ehrliche Wahrheit ist: Die meisten kleinen bis mittleren Deployments brauchen kein Kubernetes. Sie brauchen kein Docker-Ökosystem. Sie brauchen Isolation, Reproduzierbarkeit und Einfachheit. Und genau das bieten Jails.

Die Philosophie: FreeBSD vertraut dem Admin, Docker vertraut dem Workflow

Hier wird es philosophisch — und das ist der Kern meines Arguments.

Docker vertraut dem Workflow. Docker sagt: „Wir machen es einfach, Container zu bauen, zu „verschiffen“ und zu orchestrieren. Du musst nicht verstehen, wie das Betriebssystem funktioniert. Du musst verstehen, wie Docker funktioniert.“ Und das funktioniert — solange du in Dockers Workflow bleibst. Wenn du etwas ausserhalb des Workflows brauchst, wird es kompliziert. Eigene Netzwerk-Konfiguration? Da gibt es ein Plugin. Eigene Storage-Lösung? Da gibt es einen Volume-Treiber. Eigenes Orchestrierung? Da gibt es… naja, Kubernetes.

FreeBSD vertraut dem Admin. FreeBSD sagt: „Hier ist ein mächtiges Betriebssystem mit 30 Jahren Erfahrung. Hier sind die Werkzeuge. Du weisst, was du tust. Mach dein Ding.“ Jails sind ein Werkzeug im Werkzeugkasten, nicht das gesamte Werkzeugkasten-Inventar. Du kannst sie mit ZFS kombinieren, mit pf konfigurieren, mit Ansible automatisieren, mit devfs feinabstimmen. Alles ist kombinierbar, weil alles Teil desselben Betriebssystems ist.

Das ist ein fundamentaler Unterschied in der Design-Philosophie:

• Docker abstrahiert das Betriebssystem weg. Der Container ist die Einheit. Das Betriebssystem darunter ist ein Implementierungsdetail.
• FreeBSD gibt dir das Betriebssystem als Plattform. Der Jail ist ein Feature des Betriebssystems, kein Ersatz dafür.

Beide Ansätze haben ihre Berechtigung.

Wenn du ein Linux-Admin bist, der Docker nutzt, kennst du das Gefühl: „Warum funktioniert dieser Container lokal, aber nicht in Produktion?“ Overlay-Filesystem-Unterschiede. Netzwerk-Konfiguration. Environment-Variablen. Volume-Mounts. Jede Schicht kann ein Problem sein.

Mit Jails? Wenn es im Jail funktioniert, funktioniert es. Weil das Jail ein echtes Betriebssystem ist. Keine Überraschungen.

Die Sache mit dem Ökosystem

Ein Argument, das oft gegen Jails vorgebracht wird: „Docker hat ein riesiges Ökosystem. Jails haben das nicht.“

Stimmt. Docker Hub hat Millionen von Images. Für Jails gibt es keine zentrale Registry.

Aber lass uns ehrlich sein: Wie viele dieser Millionen Images nutzt du wirklich? Und wie viele davon sind veraltet, unsicher, oder einfach schlechte Basis-Images?

In der Praxis brauchst du eine Handvoll gut gepflegter Basis-Images. Und die kannst du dir mit Jails leicht selbst bauen. Ein ZFS-Snapshot eines sauberen FreeBSD-Base-Systems, und du hast dein eigenes „Image“ — reproduzierbar, versioniert, effizient.

Ausserdem: Die Abhängigkeit von Docker Hub ist ein Risiko. Images verschwinden. Tags werden überschrieben. Die Registry kann ausfallen. Mit einem eigenen ZFS-basierten Jail-Setup bist du unabhängig.

Und was Automatisierung angeht: Tools wie Ansible, Salt, oder einfache Shell-Skripte arbeiten mit Jails genauso gut wie mit Docker. Vielleicht nicht so elegant wie ein docker-compose up, aber dafür transparent und nachvollziehbar.

Der praktische Betrieb: Jails im Alltag

Lass mich einen typischen Arbeitsablauf beschreiben, wie ich ihn auf meinen Servern nutze:

Neuen Service aufsetzen

# 1. ZFS-Dataset für das Jail erstellen
zfs create zroot/jails/myservice

# 2. Von einem sauberen Base-Snapshot klonen
zfs clone zroot/jails/base@clean zroot/jails/myservice

# 3. Jail-Konfiguration hinzufügen
cat >> /etc/jail.conf << 'EOF'
myservice {
    path = /jails/myservice;
    ip4.addr = 192.168.1.20;
    host.hostname = myservice.example.com;
    mount.devfs;
    exec.start = "/bin/sh /etc/rc";
    exec.stop = "/bin/sh /etc/rc.shutdown";
}
EOF

# 4. Jail starten
service jail start myservice

# 5. Pakete installieren
jexec myservice pkg install nginx

# 6. Konfigurieren und loslegen
jexec myservice sysrc nginx_enable=YES

Das dauert — mit einem guten Base-Snapshot — unter einer Minute. Und ich habe die volle Kontrolle über jeden Schritt.

Update eines Jails

# Snapshot vor dem Update (zur Sicherheit)
zfs snapshot zroot/jails/myservice@pre-update

# Update durchführen
jexec myservice pkg upgrade

# Wenn etwas schiefgeht: Rollback
zfs rollback zroot/jails/myservice@pre-update

Kein Image-Rebuild. Kein Cache-Invalidation. Snapshot, Update, fertig. Oder Rollback, wenn nötig.

Migration auf einen anderen Server

# ZFS-Dataset senden (inkrementell möglich!)
zfs send zroot/jails/myservice@latest | ssh newserver zfs recv zroot/jails/myservice

Ein Befehl. Das gesamte Jail — Dateisystem, Konfiguration, alles — wird auf den neuen Server übertragen. Inkrementelle Updates? zfs send -i mit Snapshots. Effizient, schnell, zuverlässig.

Vergleiche das mit docker save und docker load. Oder mit einer Registry. Oder mit docker-compose und Environment-Variablen, die du manuell übertragen musst. ZFS send/recv ist eleganter, weil es auf Dateisystem-Ebene arbeitet — und weil es von einem Werkzeug stammt, das seit 2005 in Produktion ist.

Was Docker besser macht (und warum das okay ist)

Ich will fair sein. Docker hat Dinge, die Jails nicht bieten:

1. Portabilität. Ein Docker-Image läuft auf jedem Linux-System mit Docker. Ein Jail läuft nur auf FreeBSD. Wenn du heterogene Infrastruktur hast, ist Docker die bessere Wahl.
2. Ökosystem. Docker Hub, Docker Compose, Docker Swarm, Kubernetes — das Ökosystem ist riesig und gut dokumentiert. Für Jails gibt es Bastille und pot, aber sie sind kein K8s.
3. Entwickler-Workflow. docker build und docker push sind etabliert. CI/CD-Pipelines unterstützen Docker nativ. Jails erfordern mehr manuelle Arbeit in der Pipeline.
4. Cloud-Integration. Jeder Cloud-Provider bietet native Container-Support. FreeBSD-Jails musst du selbst betreiben.

Aber — und das ist wichtig — diese Vorteile sind Ökosystem-Vorteile, keine technischen Vorteile. Docker ist populärer, nicht besser isoliert. Docker hat mehr Werkzeuge, nicht sicherere Isolation. Docker ist bequemer, nicht performanter.

Wenn du dich für Docker entscheidest, tust du das wegen des Ökosystems, nicht wegen der Technologie. Und das ist eine legitime Entscheidung — solange du dir bewusst bist, dass es eine Entscheidung für Bequemlichkeit und gegen Einfachheit ist.

Die Philosophie (nochmal, tiefer)

Ich möchte nochmal auf die Philosophie zurückkommen, weil sie mich nicht loslässt.

Die Container-Bewegung hat einen wichtigen Punkt gebracht: Prozesse sollten isoliert sein. Das ist richtig. Das ist gut. Das ist etwas, das FreeBSD seit dem Jahr 2000 weiss.

Aber die Container-Bewegung hat auch etwas mitgebracht, das weniger gut ist: Die Idee, dass das Betriebssystem ein Implementierungsdetail ist. Dass du Container brauchst, weil das Betriebssystem nicht gut genug ist. Dass du Docker brauchst, weil Linux nicht von sich aus isolieren kann.

Und hier ist die Ironie: Linux kann isolieren. Mit Namespaces, cgroups, Seccomp. Aber Linux hat sich entschieden, diese Mechanismen als Bausteine anzubieten, die du zusammensetzen musst — und das hat Docker übernommen. Docker ist der Wrapper, der die Bausteine zusammensteckt.

FreeBSD hat sich anders entschieden. FreeBSD hat die Isolation in den Kernel gebaut, als zusammenhängendes Konzept. Nicht als Bausteine. Sondern als Design. Und das Resultat ist einfacher, sicherer und leichter zu verstehen.

FreeBSD vertraut dem Admin. Der Admin weiss, was er tut. Er braucht keinen Daemon, der ihm die Isolation abnimmt. Er braucht einen Kernel, der Isolation bereitstellt, und Werkzeuge, die transparent sind.

Docker vertraut dem Workflow. Der Workflow weiss, was gut für dich ist. Du brauchst nicht zu verstehen, wie die Isolation funktioniert. Du musst nur docker run tippen.

Beide Philosophien haben ihren Platz. Aber wenn du ein Admin bist, der sein System versteht — und das bist du, wenn du diesen Artikel liest —, dann weisst du, welche Philosophie dir mehr gibt.

Fazit: Container-Infrastruktur, wenn man das Betriebssystem ernst nimmt

Container sind keine schlechte Idee. Prozessisolation ist essenziell. Aber die Art und Weise, wie Docker sie implementiert — mit einem Daemon, mit Layern, mit einer Registry, mit einem ganzen Ökosystem — ist nicht die einzige Art, Isolation zu erreichen. Und sie ist für viele Use-Cases nicht die beste.

FreeBSD-Jails bieten Isolation auf Kernel-Ebene, seit über 25 Jahren. Ohne Daemon. Ohne Registry. Ohne Layer. Ohne Komplexität. In Kombination mit ZFS bieten sie Instant-Cloning, atomare Updates, und effiziente Migration — alles mit Standard-Betriebssystem-Werkzeugen.

Wenn du dein Betriebssystem ernst nimmst — wenn du weisst, was unter der Haube passiert, wenn du Kontrolle über Einfachheit bevorzugst, wenn du Stabilität über Hype wählst —, dann sind Jails die bessere Wahl. Nicht immer. Nicht für jeden. Aber für die meisten, die ihre eigene Infrastruktur betreiben und wissen, was sie tun.

Docker hat die Container-Welt revolutioniert. Das bestreite ich nicht. Aber Revolution bedeutet nicht, dass das Alte obsolet ist. Manchmal bedeutet es nur, dass das Alte vergessen wurde.

Jails sind nicht vergessen. Sie sind gereift. Sie sind bewährt. Und sie warten darauf, von Leuten genutzt zu werden, die Einfachheit über Komplexität wählen.

Die Frage ist nicht: „Warum Jails statt Docker?“

Die Frage ist: „Warum Docker, wenn Jails alles können, was du brauchst — und weniger mitbringen, was du nicht brauchst?“