Docker in LXC auf Proxmox: Risiken, Kompromisse und Erkenntnisse

In der Welt der Proxmox-basierten Homelabs taucht eine Frage immer wieder auf wie ein Uhrwerk: Sollten Sie Docker in einem LXC-Container laufen lassen, oder lieber auf Nummer sicher gehen und Docker in eine virtuelle Maschine packen? Es klingt einfach, denn LXCs sind leichter, schneller und ressourcenschonender. Aber unter dieser schlanken Oberfläche lauern ein paar Risiken, die Nutzer ins Grübeln bringen.

Von abgestürzten Hosts bis zu Kernel-Panics ist die Debatte alles andere als theoretisch, sie basiert auf Erfahrung. Dutzende Homelabber haben geteilt, was funktioniert, was scheitert und was sie gerne vorher gewusst hätten, bevor sie ihre Betriebszeit auf Container in Containern verwettet haben. Die Community ist sich dabei ziemlich uneinig darüber, ob Docker in einem LXC genial, gefährlich oder beides ist.

Der Reiz: Geschwindigkeit, Einfachheit und Effizienz

Wenn sich Proxmox-Nutzer bei einer Sache einig sind, dann darin, dass LXCs wendig sind. Sie booten schnell, verbrauchen weniger Ressourcen als eine VM und lassen sich mit chirurgischer Präzision in der Ressourcenzuteilung feinjustieren. Das macht sie attraktiv, um Docker darin laufen zu lassen.

„Ich nutze mehrere LXCs. Die Verwaltung ist für mich einfach leichter. Ich weiß, dieses eine LXC macht eine Sache, und das war's“, sagte ein Nutzer und brachte damit die „Ein-Container-pro-Service“-Denkweise auf den Punkt.

Andere lassen Docker in einem einzigen LXC laufen, um Services gebündelt zu halten, besonders wenn diese wenig Last erzeugen. Für viele ist das effizient und zugleich vertraut. Wer Docker und Compose-Dateien schon kennt, dem fühlt es sich natürlich an, sie in ein LXC zu packen.

Ein paar Nutzer trieben es sogar noch weiter: „Ich habe 50 LXCs und eine Docker-VM. Das ist nicht so schwer zu verwalten, wenn man die üblichen Dinge automatisiert.“ So sieht Skalierung im Homelab aus.

Die Schmerzpunkte: Wenn Docker in LXC zurückbeißt

Hier wird es unübersichtlich. Ein Nutzer teilte eine warnende Geschichte: „Ein Prozess in meinem Docker-LXC verursachte eine Kernel-Panic und brachte meinen gesamten Host zum Absturz. Wäre es stattdessen eine VM gewesen, wäre nur die VM abgestürzt.“ Das ist das Albtraum-Szenario, und es ist kein Einzelfall.

LXC teilt sich den Kernel mit dem Proxmox-Host. Geht also etwas im Container schief, kann das gesamte System betroffen sein. Manche Nutzer mussten das auf die harte Tour lernen.

„Sie kombinieren zwei Arten von Sicherheitsbedenken“, erklärte ein anderer. „LXC hat Lücken. Docker hat Lücken. Zusammen bekommen Sie zusätzliche Angriffsvektoren.“

Andere stellten fest, dass Docker-in-LXC mit bestimmten Containern einfach nicht harmonierte: „Nicht jeder Docker-Container läuft in LXC. Mein Mailserver lief nicht richtig, wahrscheinlich wegen AppArmor oder so etwas.“

Es gibt außerdem Kopfschmerzen beim Einbinden von NFS-Shares oder beim Durchreichen von Hardware wie GPUs. In einer VM ist Docker dabei einfach, in einem LXC manchmal ein Konfigurationsalbtraum.

Privilegiert vs. unprivilegiert: Wählen Sie Ihren Kämpfer

Ein Großteil des Risikos hängt davon ab, ob Sie Ihr LXC privilegiert oder unprivilegiert betreiben.

Privilegierte LXCs verhalten sich mehr wie das Host-System und erlauben direkteren Zugriff auf Hardware, was Docker glücklicher macht, besonders bei GPU-Passthrough oder dem Einbinden von USB-Geräten. Genau das macht sie aber auch gefährlicher. Gerät etwas außer Kontrolle, kann es durchbrechen und Ihren Proxmox-Host durcheinanderbringen.

Unprivilegierte LXCs sind sicherer. Sie sandboxen Dinge strenger, aber Docker läuft darin nicht immer reibungslos.

Ein Nutzer versuchte den unprivilegierten Weg mit rootless Podman als Alternative: „War Ihr LXC privilegiert? Ich bin mit einem unprivilegierten LXC und rootless Podman gefahren. Ich sehe nicht, wie das in dieser Konfiguration passieren könnte.“ Aber selbst dann ist es nicht kugelsicher. Ein anderer merkte an: „Nicht alles kann im unprivilegierten Modus laufen. Kommt darauf an, was Ihr Docker leisten muss.“

Der Mittelweg: Hybride Ansätze gewinnen an Boden

Immer mehr Proxmox-Nutzer landen irgendwo dazwischen: VMs für zentrale oder komplexe Docker-Stacks nutzen und bei LXCs für leichtere, weniger kritische Services bleiben.

Ein Homelabber brachte es gut auf den Punkt: „Ich nutze LXC für meine wichtigsten Services und habe eine Docker-VM für Docker-Services, bei denen es mir nicht so wichtig ist, wenn sie ausfallen. Null Docker auf den LXCs.“

Ein anderer ging den entgegengesetzten Weg: Docker in LXCs für kleinere Services, VMs für große Apps wie Frigate und Immich, die GPU-Zugriff oder bessere Isolation brauchten.

Ein Dritter berichtete: „Ich habe ein Docker-spezifisches LXC, das alle meine kleineren Services betreibt. Ich hatte nie ein Problem damit, Docker in einem LXC laufen zu lassen.“

Klar ist, dass die Antwort nicht schwarz-weiß ausfällt, weil es davon abhängt, ob Ihnen Isolation, Portabilität oder Einfachheit am wichtigsten ist.

Das Argument für VMs: Stabilität, Sicherheit und Seelenfrieden

Viele Nutzer, besonders jene, die auf seltsame Bugs gestoßen sind oder ihren Proxmox-Node zum Absturz gebracht haben, schwören inzwischen darauf, Docker stattdessen in eine VM zu packen.

„So wie ich das verstehe, hat LXC ein paar Sicherheitslücken und Docker hat ein paar Sicherheitslücken. Addiert man sie, bekommt man mehr Ärger“, schrieb ein Nutzer.

Sogar Proxmox' eigene Dokumentation legt nahe, dass Docker für bessere Isolation in einer vollständigen VM laufen sollte. Und wenn Updates für Proxmox ausrollen, laufen Ihre Container in einer Docker-VM einfach weiter. Versuchen Sie das mal mit LXC, das könnte pikant werden.

Dann gibt es noch das Backup-Problem. „LXCs unterstützen keine Dirty Bitmaps für Backups“, warnte ein Nutzer. „Das bedeutet, jedes Mal, wenn Ihr Backup läuft, wird der gesamte Storage gescannt. VMs sind da wesentlich effizienter.“

Setups aus der Praxis: Was Nutzer wirklich tun

Ein Nutzer betreibt eine VM mit Docker und GPU-Passthrough für KI-Workloads und hält damit alles modular. Ein zweiter fährt 11 LXCs, eines pro Service, auf einem stromsparenden Server mit sorgsamem Ressourceneinsatz. Ein dritter hat ein LXC mit allen reinen Docker-Services und sagt, das sei einfacher, als jede App in eine LXC-native Installation umzuwandeln.

Ein vierter betreibt Docker in LXCs für „unkritische“ Services und akzeptiert gelegentliche Aussetzer als Preis für schlankes Hosting. Ein fünfter ist komplett auf Kubernetes über VMs umgestiegen und hat sowohl LXC als auch Docker-in-LXC zugunsten von etwas Skalierbarerem und Moderneren aufgegeben.

Jedes Setup spiegelt persönliche Vorlieben, Server-Spezifikationen und die Bereitschaft wider, Schmerz zu ertragen, wenn etwas schiefläuft.

Letztes Wort: keine Bombe, aber definitiv scharf gemacht

Ist Docker in einem LXC also eine tickende Zeitbombe? Es ist eher wie Jenga spielen. Sie können etwas Hohes, Effizientes und Schönes bauen, aber ziehen Sie den falschen Stein heraus, also das falsche Kernel-Update, den falschen Container oder eine Fehlkonfiguration, kann alles härter einstürzen als erwartet.

Wenn Ihr Setup nur für interne Services gedacht ist und Sie gerne herumtüfteln, kann Docker in LXC absolut funktionieren. Gehen Sie einfach mit dem Wissen um die Risiken hinein und planen Sie für den Ernstfall. Snapshots, Backups außerhalb des Hosts und Sicherheitshärtung sind Ihre Freunde.

Aber wenn Sie Services betreiben, auf die es ankommt, also Dinge, die dem Internet ausgesetzt sind oder Authentifizierung, Medienzugriff, KI-Modelle oder öffentliche APIs betreffen, packen Sie sie vielleicht besser in eine VM. Der Mehraufwand ist den Seelenfrieden wert.

Und denken Sie daran: Das ist Ihr Homelab. Sie müssen es nicht von Anfang an perfekt hinbekommen. Experimentieren Sie, scheitern Sie schnell und bauen Sie klüger wieder auf.