Docker vs. LXC auf Proxmox: Was bei mir wirklich produktiv läuft

Bei jedem neuen Proxmox-Host, den ich für einen Kunden aufsetze, kommt früher oder später dieselbe Frage: "Warum nicht einfach alles in Docker laufen lassen?" Eine berechtigte Frage, gerade weil Proxmox im deutschsprachigen Raum so verbreitet ist und Docker-Images so praktisch portabel sind, jeder Entwickler kennt das Format. Aber nach Jahren mit gemischten Workloads, MariaDB-Galera-Clustern, PostgreSQL, Redis, RabbitMQ, dazu was auch immer der Kunde an Anwendungs-Stack mitbringt, habe ich mich auf eine Aufteilung festgelegt, von der ich kaum abweiche.

LXC für alles, was zustandsbehaftet ist und lange läuft

Für Datenbanken, Caches und Message Queues setze ich auf LXC-Container direkt auf dem Proxmox-Host. Ein LXC teilt sich den Kernel mit dem Host, es gibt also keinen Virtualisierungs-Overhead: Disk-I/O und Speicherverhalten entsprechen praktisch dem von Bare Metal. Bei einem MariaDB-Galera-Node oder einer Redis-Instanz macht sich das direkt in den Benchmark-Werten bemerkbar, besonders auf kleineren VPS-Instanzen, wo jedes bisschen Overhead zählt.

Der andere Grund ist operativ. Diese Services laufen oft über Jahre, und ich will mit pct enter in den Container, iostat checken, innodb_buffer_pool_size anpassen oder schnell ein pg_dump ziehen können, ohne dass eine zusätzliche Container-Runtime zwischen mir und dem Dateisystem sitzt. Snapshots und Backups auf Proxmox-Ebene (vzdump) funktionieren einfach, und ein einzelnes LXC wiederherzustellen ist eine Sache von fünf Minuten.

Warum Docker-in-LXC bei mir nie zur Wahl steht

Ich habe Docker-in-LXC am Anfang ausprobiert, weil es nach dem Besten aus beiden Welten aussah: die Leichtigkeit von LXC plus die Paketierung von Docker. In der Praxis sind das zwei Containerisierungsebenen, die sich einen Kernel teilen, und diese Kombination ist auf eine Art zerbrechlich, die sich immer im ungünstigsten Moment zeigt. Man muss Nesting aktivieren und das AppArmor-Profil des Containers lockern, was den Sicherheitsvorteil von LXC schon ziemlich einschränkt. Dann bricht ein Kernel-Update auf dem Host still und heimlich den Overlay-Storage-Treiber im verschachtelten Docker-Daemon, und man merkt es erst, wenn ein Container nach einem ganz normalen pct reboot nicht mehr hochkommt.

Neuere Proxmox-Versionen haben native OCI-Image-Unterstützung in LXC eingeführt, was ein wirklich brauchbarer Mittelweg ist: Man zieht ein Standard-Image und lässt es als LXC laufen, ganz ohne Docker-Daemon. Für kleine, größtenteils zustandslose Services nutze ich das inzwischen, wo ich früher zu einem kleinen Docker-Container gegriffen hätte. Sobald eine Datenbank dahinter steckt, halte ich aber weiterhin Abstand.

Docker, aber in einer VM

Wenn ein Kunde mir eine App als Dockerfile oder docker-compose-Stack übergibt, was inzwischen bei den meisten der Fall ist, kommt dieser Stack in eine eigene Proxmox-VM, nicht in ein LXC. Die VM gibt Docker einen eigenen Kernel, sodass Updates am Kernel des Proxmox-Hosts nicht in die Container-Runtime durchschlagen, und die iptables/nftables-Regeln, die Docker gerne selbst umschreibt, bleiben in dieser VM und geraten nicht mit der Firewall-Konfiguration des Hosts in Konflikt.

Ja, das ist eine zusätzliche Virtualisierungsebene gegenüber Docker-in-LXC. Im Gegenzug hatte ich noch nie einen Anruf mitten in der Nacht, weil ein Kernel-Update auf dem Host irgendjemandes Container zerschossen hat. Für Kundenprojekte ist dieser Tausch jedes Mal die richtige Entscheidung.

Die Aufteilung in der Praxis

Als Regel formuliert: zustandsbehaftete Infrastruktur (Datenbanken, Queues, Caches) läuft als LXC direkt auf Proxmox, Anwendungs-Container laufen als Docker in einer VM, und kleine zustandslose Hilfsdienste laufen zunehmend als natives OCI-in-LXC, jetzt, wo diese Option existiert. Dogma ist das keines, braucht ein Workload wirklich Kubernetes oder eine bestimmte Orchestrierungsschicht, ist das ein anderes Thema. Aber für die kleine bis mittlere Infrastruktur, die ich betreue, ist das die unaufgeregteste, am besten vorhersehbare Konfiguration, die ich gefunden habe, und unaufgeregt ist genau das, was man sich von Infrastruktur wünscht.