Docker vs. LXC auf Proxmox: Was ich in Produktion wirklich einsetze

Jedes Mal, wenn ich einen neuen Proxmox-Host in Betrieb nehme, kommt unweigerlich die Frage: „Warum lassen wir nicht einfach alles in Docker laufen?“ Das ist berechtigt. Docker-Images sind portabel, das Ökosystem ist riesig und die meisten Entwickler wissen ohnehin, wie man ein Dockerfile schreibt. Aber nach Jahren des Betriebs gemischter Workloads – MariaDB Galera-Cluster, PostgreSQL, Redis, RabbitMQ und jeglichen App-Stacks, die Kunden mir hinwerfen – habe ich mich auf eine strikte Trennung festgelegt.

LXC für Stateful-Dienste und Langzeitbetrieb

Für Datenbanken, Caches und Message Queues greife ich direkt zu LXC-Containern auf dem Proxmox-Host. LXC teilt sich den Host-Kernel, was bedeutet, dass es absolut keine Virtualisierungsverluste gibt. Disk-I/O und Arbeitsspeicher verhalten sich exakt so wie auf Bare Metal. Bei einem MariaDB Galera-Node oder einer Redis-Instanz spiegelt sich dieses fehlende Overhead sofort in den Benchmarks wider, insbesondere bei kleinerer VPS-Hardware.

Der andere Grund ist rein operativer Natur. Diese Dienste laufen über Jahre. Ich möchte jederzeit mit pct enter in den Container springen, iostat checken, die innodb_buffer_pool_size tunen oder schnell einen pg_dump ziehen können, ohne dass eine zusätzliche Container-Runtime das Dateisystem abstrahiert. Backups auf Proxmox-Ebene (vzdump) funktionieren einfach und die Wiederherstellung eines einzelnen LXCs ist in fünf Minuten erledigt.

Warum Docker-in-LXC keine Option ist

Ich habe den Docker-in-LXC-Ansatz früher ausprobiert. Es sah nach dem Besten aus beiden Welten aus: die Leichtigkeit von LXC gepaart mit dem Packaging von Docker. In der Praxis ist das Stapeln von zwei Container-Layern auf einem Kernel extrem fragil und bricht immer im denkbar schlechtesten Moment zusammen.

Man muss Nesting aktivieren und das AppArmor-Profil lockern, was die Sicherheitsvorteile, die LXC überhaupt erst bot, sofort zunichtemacht. Dann macht ein routinemäßiges Kernel-Update auf dem Host unbemerkt den Overlay-Storage-Treiber innerhalb des verschachtelten Docker-Daemons kaputt – und man merkt es erst, wenn die Container nach einem Reboot nicht mehr starten wollen.

Neuere Proxmox-Releases bieten nativen OCI-Image-Support innerhalb von LXC. Das ist ein wirklich nützlicher Mittelweg: Man kann ein Standard-Image pullen und als LXC ohne Docker-Daemon ausführen. Ich nutze das für kleine, stateless Services. Sobald aber eine Datenbank involviert ist, halte ich Abstand.

Docker, aber innerhalb einer VM

Wenn mir ein Kunde eine App als Dockerfile oder docker-compose-Stack übergibt (was heutzutage der Standard ist), kommt dieser Stack in seine eigene Proxmox-VM. Nicht in einen LXC.

Die VM gibt Docker einen echten, isolierten Kernel. Kernel-Updates auf dem Proxmox-Host schlagen nicht mehr in die Container-Runtime durch, und die iptables-Regeln, die Docker so gerne umschreibt, bleiben in der VM eingesperrt und pfuschen nicht in der Firewall-Config des Hosts herum.

Ja, das ist eine zusätzliche Virtualisierungsschicht im Vergleich zu Docker-in-LXC. Dafür wurde ich aber noch nie um 3 Uhr morgens aus dem Bett geklingelt, weil ein Host-Kernel-Update einen verschachtelten Docker-Daemon zerschossen hat. Für Produktions-Workloads ist mir dieser Trade-off jeden Preis wert.

Meine strikte Aufteilung

Wenn ich es als feste Regel formulieren müsste: Stateful-Infrastruktur (Datenbanken, Queues, Caches) läuft als LXC direkt auf Proxmox. App-Container laufen als Docker innerhalb einer VM. Kleine Stateless-Tools laufen zunehmend nativ als OCI-in-LXC.

Nichts davon ist ein unverrückbares Dogma. Wenn ein Workload zwingend Kubernetes erfordert, ist das eine andere Diskussion. Aber für die kleine bis mittelgroße Infrastruktur, die ich betreue, hat sich diese Aufteilung als das langweiligste und vorhersehbarste Setup erwiesen. Und „langweilig“ ist genau das Prädikat, das man von seiner Infrastruktur haben möchte.