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 – 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 – die Debatte ist nicht nur 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.
Schauen wir uns an, was die Community davon hält, ob Docker in einem LXC genial, gefährlich oder beides ist.
Der Reiz: Geschwindigkeit, Einfachheit und pure 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 nicht nur effizient – es ist 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." Das nennt man Skalierung.
Die Schmerzpunkte: Wenn Docker in LXC zurückbeißt
Und 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 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. Docker in einer VM? Einfach. Docker 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. Aber das macht sie 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: Die Antwort ist nicht schwarz-weiß – es geht darum, was Ihnen am wichtigsten ist. Isolation? Portabilität? Einfachheit?
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 still 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? 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
Nutzer A: VM mit Docker, GPU-Passthrough für KI-Workloads. Hält alles modular.
Nutzer B: 11 LXCs, eines pro Service. Stromsparender Server, sorgsamer Ressourceneinsatz.
Nutzer C: Ein LXC mit allen reinen Docker-Services. Sagt, das sei einfacher, als jede App in eine LXC-native Installation umzuwandeln.
Nutzer D: Betreibt Docker in LXCs für "unkritische" Services und akzeptiert gelegentliche Aussetzer als Preis für schlankes Hosting.
Nutzer E: Ist komplett auf Kubernetes über VMs umgestiegen. 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?
Sagen wir es so: Es ist eher wie Jenga spielen. Sie können etwas Hohes, Effizientes und Schönes bauen – aber ziehen Sie den falschen Stein (das falsche Kernel-Update, den falschen Container, 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 – Dinge, die dem Internet ausgesetzt sind, 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.