Proxmox 9.1 führt Docker-Images aus, aber als LXC-Container ohne Docker-Engine

An dem Morgen, an dem das Feature landete, lehnte sich irgendwo ein Cluster-Admin vermutlich in seinem Stuhl zurück, kniff die Augen vor dem Proxmox-9.1-Changelog zusammen und murmelte: „Kein Weg, dass sie das wirklich gemacht haben." Jahrelang war das Ausführen von Docker auf Proxmox in irgendeiner „nativen" Form so etwas wie ein Homelab-Tagtraum. Manche wickelten Docker in LXCs ein, andere steckten es in schlanke VMs, und einige abenteuerlustige Seelen taten so, als sei alles in Ordnung, während sie die gelegentliche Kernel-Beschwerde ignorierten. Jeder hatte seinen eigenen Hack und seine eigenen Narben.

Proxmox 9.1 brachte dann einen neuen Trick: OCI-basierte Container, die wie schlanke LXC-Guests aussehen, direkt aus Docker-Images hochgezogen. Über Nacht erwachte eine Ecke der Infrastruktur-Welt zum Leben, mit Beiträgen, Kommentaren und YouTube-Erklärvideos, manche begeistert, manche verwirrt, manche mit der Warnung an andere, um der Verfügbarkeit willen erst einmal durchzuatmen, bevor man kopfüber einsteigt.

Am meisten lernt man über dieses Feature, wenn man den Leuten zuhört, die es in den ersten Stunden auf Herz und Nieren geprüft haben. Technisch gesehen hat Proxmox den Nutzern einen Weg gegeben, „Docker-Container auszuführen". Tatsächlich bekommen sie einen sehr proxmox-typischen Hybrid, der clever und vielversprechend ist, ein bisschen seltsam dazu, und der ganz sicher kein Docker-Ersatz ist. Zumindest noch nicht.

Die erste Reaktion: hoffnungsvoll, aber vorsichtig

Eine frühe Reaktion traf die Stimmung genau: „Ich werde meine VMs wohl noch nicht ersetzen, aber ich mag die Idee und die Richtung." Viele Leute betreiben Container mit Portainer in einer dedizierten VM, weil das saubere Isolation, Namespacing und vertraute Docker-Semantik liefert. Diese Nutzer reißen ihr Setup nicht über Nacht ein.

Jemand anderes gab zu, Dockers Umgang mit Namespaces viel zu sehr zu mögen, um ihn aufzugeben. Für diese Person ist das Stapeln von Containern mit sauberen Netzwerkgrenzen und unter einer einzigen IP gruppierten Ports die Grundlage des gesamten Self-Hosted-Designs. Genau darum waren mehrere Leute enttäuscht, dass sich die OCI-Container von Proxmox wie LXCs verhalten: Jeder bekommt seine eigene IP, und daran lässt sich nichts drehen. Wollen Sie ein Dutzend Dienste an einer IP mit verschiedenen Ports hängen? Pech gehabt. Ein Reverse Proxy könnte helfen, gemeint war das Feature so aber nicht.

Trotzdem sah die Gruppe mit knappen Ressourcen echtes Potenzial. Volle VMs für winzige Dienste zu betreiben fühlt sich verschwenderisch an, und LXCs, die Docker hosten, können je nach Kernel-Features seltsam werden. Dass Proxmox einen containerartigen Workload ohne Docker, Podman oder irgendeine OS-Schicht bereitstellen kann, ist für kleine Maschinen gewaltig.

Dann kam die Frage, die den Ton für den Rest des Threads setzte: „Was ist der eigentliche Anwendungsfall?" Es stellte sich heraus, dass die Leute reichlich Antworten hatten, und reichlich Vorbehalte.

Die erste Welle der Verwirrung: wie funktioniert das eigentlich?

Das häufigste Missverständnis im Thread war die Vorstellung, Proxmox würde „Docker in Containern" ausführen. Mehrere Leute versuchten das zu korrigieren, manche sanft, manche weniger sanft.

Sie betonten alle denselben Kernpunkt: Proxmox wandelt ein OCI-Image in ein LXC um. Der Container-Inhalt aus dem Image wird also zu einem schlanken Dateisystem für einen privilegierten LXC-Guest. Es gibt keine Docker-Engine, keinen Podman und keinen Docker-Daemon. Sie rufen kein docker ps auf, Sie beobachten keinen Docker-Socket, und Multi-Container-Stacks gibt es auch nicht.

Es ist eher so:

1. Ein Docker-Image herunterladen
2. Dessen Dateisystem entpacken
3. Das als Root-FS für ein LXC verwenden
4. Als Systemdienst starten

Das ist clever, lädt aber auch Ärger ein, wenn das Image ein Verhalten erwartet, das nur eine Docker-Laufzeitumgebung liefert: ephemere Resets, konsistente Mounts, Netzwerkannahmen oder Overlay-Dateisystemverhalten. Docker-Images wurden nicht dafür gebaut, vollständige Root-Dateisysteme zu sein, und das kann einem auf die Füße fallen.

Ein Kommentator formulierte das trocken: „Die meisten Docker-Container funktionieren bei mir nicht. Deshalb ist das ein Technik-Review."

Das Update-Problem

Fast alle waren sich über das größte Kopfzerbrechen einig: Das Aktualisieren von OCI-Containern auf Proxmox ist derzeit umständlich.

Wenn Sie einen OCI-Container in Docker neu bauen, ziehen Sie einfach und starten neu. Die Laufzeitumgebung fegt die neuen Layer herein, und das ephemere Design des Containers erspart Ihnen die Sorge, was mit dem darunterliegenden Root-FS passiert.

Auf Proxmox verhält sich Ihr aus OCI abgeleitetes LXC wie jedes andere LXC: Es hat einen Zustand. Wenn Sie nicht auf gemounteten Storage achten, bedeutet ein Update:

1. Eine neue Instanz bauen
2. Mounts neu anhängen
3. Konfiguration kopieren
4. Den alten Container ersetzen

Elegant ist das nicht. Ein YouTuber empfahl diesen Ansatz für den Moment, und ehrlich gesagt muss es so bleiben, bis Proxmox einen echten Update-Workflow hinzufügt. Ein Nutzer fasste den Stand der Dinge treffend zusammen:

„Vielleicht nutze ich statt Volumes einfach SMB, falls das überhaupt funktioniert, keine Ahnung."

Mounts, Netzwerk und die seltsamen Ecken

Mehrere Nutzer stießen früh auf Einschränkungen.

Geteilte Mounts sind nicht offensichtlich

Jemand versuchte, SMB-Shares zu mounten, und stieß an eine Wand. Andere wiesen darauf hin, dass LXCs lokale Bind-Mounts durchaus unterstützen, allerdings nicht auf eine Weise, die das Docker-Volume-Verhalten sauber nachahmt.

Netzwerk verhält sich wie LXC, nicht wie Docker

Wer an Dockers Modell „eine IP, viele Ports" gewöhnt ist, empfindet den Wechsel zu „jeder Container hat einen vollständigen IP-Stack" als hart. Proxmox weist seinen OCI-Containern automatisch Netzwerkkonfigurationen wie bei LXCs zu, einschließlich MAC-Adressen, Bridges und Firewall-Regeln. Ein Reverse Proxy behebt das, ist aber zusätzliche Verkabelung, mit der die Leute nicht gerechnet hatten.

Keine Multi-Container-Setups

Compose? Stacks? Immich-Fans fragten danach, und die Antwort war durchgängig nein, im Moment jedenfalls. Kein Docker-Daemon bedeutet keine Orchestrierungsschicht. Jeder OCI-Container ist eine einzelne Laufzeitumgebung: eine App, ein Root-FS, ein Startbefehl. Großartig für kleine Dienste, furchtbar für alles, was komplexe Orchestrierung braucht.

Das YouTube-Chaos: Leute erklären das Feature und streiten darüber

Kaum war das Feature draußen, stürzten sich die YouTuber natürlich darauf. Manche mochten den Überblick von Techno Tim. Andere sagten, das Video habe Verwirrung gestiftet, weil es suggerierte, Container würden innerhalb von Containern laufen. Er stellte später klar, aber der Schaden war angerichtet, und viele Zuschauer trugen das falsche mentale Modell davon. Andere verwiesen auf eine technischere Aufschlüsselung und beharrten darauf, sie erkläre die Architektur besser.

Das war das Muster im gesamten Thread: Jede begeisterte Erklärung wurde von jemandem gekontert, der mit dem Feuerlöscher hinterherlief und rief: „NEIN! So funktioniert das nicht!" Das passiert, wenn ein Feature früh, ungewöhnlich und schlecht dokumentiert ist.

Praktische Anwendungsfälle: wo OCI-Container wirklich glänzen

Jenseits der Debatte tauchten mehrere reale Anwendungsfälle auf.

1. Ersatz für schlanke LXCs, die für einzelne Apps gedacht waren

Viele Leute betreiben Apps in LXCs, obwohl diese Apps eigentlich für Container gebaut wurden. Denken Sie an AdGuard, Unifi, kleine Netzwerktools oder Service-Manager. LXCs brauchen aber weiterhin Patches, Paketverwaltung und OS-Pflege. Eine Person fasste es so zusammen: „Ich will nicht als 2000er-Jahre-Sysadmin herumspielen und mich bei jedem Update mit Abhängigkeiten herumschlagen."

Mit OCI-Containern können Sie eine App über ihr Docker-Image betreiben, ohne Docker zu benutzen, und umgehen dabei die OS-Wartungssteuer.

2. Ressourcenbeschränkte Hardware

Leute, die Proxmox auf NUCs, Mini-PCs oder kleinen Heimservern betreiben, können sich manchmal den RAM-Overhead einer VM nicht leisten, nur um einen Docker-Daemon zu beherbergen. OCI-Container geben ihnen minimalen Overhead mit dienstspezifischer Isolation.

3. Cluster-Netzwerk-Anwendungsfälle

Ein Nutzer erklärte, er habe ein dediziertes SDN-Netzwerk, isoliert vom Haupt-LAN, und betreibe eine VM nur, um einen Reverse Proxy zu hosten. Das ist Overkill. Er versuchte Docker in einem LXC, bekam es aber nicht sauber zum Laufen. Ein OCI-Container, gebaut aus dem Traefik-Image, löst genau dieses Problem mit minimalem Overhead. Sicher, das ist eine Nische. Aber das sind Homelabber, da ist jeder Anwendungsfall eine Nische.

Die Dealbreaker: wo es heute noch hakt

Selbst die Optimisten gaben einige Schmerzpunkte zu.

1. Docker-Semantik ist einfach nicht da

Wer Updates über den Docker-Socket verfolgt, schaut in die Röhre, denn der Socket existiert nicht. Projekte, die eine Docker-Umgebung erwarten, laufen ins Leere, und Tools, die auf Docker-Events angewiesen sind, bekommen keine.

2. Viele Container-Images laufen einfach nicht

Je mehr ein Image von Docker-Laufzeitfeatures abhängt statt nur von Dateisysteminhalten, desto wahrscheinlicher bricht es.

3. Zustandsbehaftete LXCs verhalten sich anders als ephemere Docker-Container

Jemand fragte: „Moment, setzt sich das Dateisystem zurück wie bei Docker?" Die Antwort ist nein. Alles, was ins Root-FS schreibt, bleibt dort, es sei denn, Sie bauen es neu auf oder räumen manuell auf. Schlecht ist das nicht zwangsläufig, es ist nur grundlegend anderes Verhalten.

4. Multi-Container-Workflows sind vom Tisch

Compose-basierte Apps wie Immich, Home Assistant mit Add-ons oder Datenbanken zusammen mit Frontends lassen sich nicht sauber verwalten.

Die LXC-Fraktion: „Das machen wir schon seit Jahren"

Manche Leser waren fast amüsiert. Menschen betreiben Docker in LXCs schon lange, und es funktioniert einigermaßen gut, besonders für unkritische Homelab-Setups. Ein paar erwähnten kleine Patches, die nach bestimmten Updates nötig waren, insgesamt sei das Setup aber stabil gewesen.

Für sie fühlen sich Proxmoxs OCI-Container deshalb wie eine seitliche Variante dessen an, was sie ohnehin schon tun: nett, aber keine Revolution. Sie wollen echtes Docker oder echtes Podman auf Host-Ebene integriert, und das ist dieses Feature nicht. Wenn Sie noch zwischen reinem LXC, Docker-in-LXC und einer vollen VM abwägen, geht unser Entscheidungsleitfaden LXC vs. VM vs. Docker die Abwägungen für jede Option durch.

Wo dieses Feature tatsächlich steht

Zusammengenommen zeichnet die Diskussion das Bild eines Features, das neu, seltsam, mächtig und weithin missverstanden ist, das nicht produktionsreif ist und das jedenfalls heute noch nicht „Docker auf Proxmox" heißt.

Was Proxmox tatsächlich gebaut hat, ist ein Weg, OCI-Images als schlanke Systemcontainer zu booten, ohne eine Container-Laufzeitumgebung zu installieren. OCI ist eines der am weitesten verbreiteten Packaging-Formate der Tech-Welt, das macht die Sache clever und nützlich, und weiterentwickeln wird sie sich auch. Im Moment sitzt sie in einer eigenartigen Mittelspur: zu mächtig, um sie zu ignorieren, zu unfertig, um sich darauf zu verlassen, und zu verwirrend, um sie zu erklären, ohne einen Streit anzuzetteln.

Die Zukunft: wann Proxmox Docker-Hosts wirklich ersetzen könnte

Wird sich dieses Feature irgendwann zu einem echten Docker-Ersatz für Homelab-Nutzer entwickeln? Vielleicht. Laut der Diskussion braucht es dafür:

• Echte Update-Workflows
• Bessere Kompatibilitätsschichten für Images
• Multi-Container-Orchestrierung
• Sauberere Netzwerkoptionen
• Stabileres Dateisystemverhalten
• Bessere Dokumentation
• Und generell weniger Verwirrung

Wenn Proxmox das hinbekommt, würde es zu einer Anlaufstelle für Virtualisierung, leichtgewichtiges App-Hosting und Container-Workloads, an der selbst TrueNAS noch arbeitet. Im Moment ist es experimentell und vielversprechend, und ehrlich gesagt macht es ziemlich Spaß, dabei zuzusehen, wie es sich entfaltet.

Schlusswort

Proxmox 9.1 hat Docker nicht obsolet gemacht. Sie können Ihre Compose-Dateien nicht wegwerfen, und Ihren gesamten Heimstack in ein einziges Hypervisor-Feature zusammenzufalten geht auch nicht.

Geöffnet hat es dagegen eine Tür in eine Zukunft, in der Proxmox containerisierte Apps ohne schwergewichtige Laufzeitumgebungen oder fragile Hacks ausführen kann. Eine Tür, durch die Homelabber kleine Dienste schnell bereitstellen, OS-Wartung überspringen und VMs für Einzel-App-Workloads vermeiden können. Es ist früh, es ist unordentlich, es ist missverstanden, und es ist trotzdem etwas Neues. In einer Welt, in der jeder eine Meinung dazu hat, wie Container funktionieren sollten, hat Proxmox die Debatte gerade noch interessanter gemacht.