Proxmox: Docker per VM oder LXC?

[Zipfelklatscher]

Hallo,

ich bin gerade dabei, einen Proxmox Server aufzusetzen, auf dem zukünftig meine Dienste (ReverseProxy, Vaultwarden, Nextcloud etc.) laufen sollen. Als Hardware kommt ein Lenovo Thinkcentre m910q (i5-6500T, 16 GB RAM, 256 GB NVME, 1 Tb SSD) zum Einsatz.

Nun kann man ja für Dienste, die per Docker realisiert werden, für jeden dieser Dienste einen eigenen LXC Container aufsetzen (ja ich weiß, offiziell soll man Docker nicht in LXCs einsetzen). Oder man erstellt eine VM (in meinem Fall würde die Wahl auf Debian 12 fallen) und lässt alle Docker-Dienste darin laufen.

Nachteil der VM: etwas höhere Last auf dem Server und wenn es die VM reisst, dann geht gar keiner der Dienste mehr. Das wäre bei LXCs nicht so tragisch, denn dann würde nur der Dienst ausfallen, der auf dem betroffenen LXC lief.

Vorteil der VM: lässt sich meistens leichter sichern, da soll es mit LXC wohl teilweise Probleme geben, wenn man auf ein NFS-Share sichern möchte?

Nachteil der einzelnen LXCs: der Wartungsaufwand ist höher, da man jeden Container separat updaten muss. Wobei ich gesehen habe, dass es ein Proxmox-Helper-Script gibt, das alle LXC-Container automatisch updatet. Ob das so zuverlässig funktioniert, sei mal dahin gestellt.

Vorteil der LXCs: weniger Ressourcenverbrauch, man kann die einzelnen Container entsprechend dem Dienst skalieren. So braucht man für Wireguard nicht unbedingt 4 Kerne oder 8 GB RAM, da reicht ein Kern und 512 MB RAM für den Container.

Wie lasst ihr Eure Dienste, die auf Docker basieren, auf Eurem Proxmox laufen? Alle in einer VM oder jeden einzelnen per LXC? Oder gar nach "Themen" gruppiert? Also z.B. alles was mit Internetzugriff zu tun hat (DynDNS, Proxymanager, Pihole) in einem gemeinsamen Container oder VM?

 

[GrumpyCat]

Oder man erstellt eine VM (in meinem Fall würde die Wahl auf Debian 12 fallen) und lässt alle Docker-Dienste darin laufen.

Ich weiß jetzt nicht, wie das Proxmox-Rebranding o.ä. aussieht, aber unterschiedliche Docker-Dienste/Container laufen auch immer in unterschiedlichen... Containern. Ich würde mal tippen, wenn Dir da zusätzlich eine VM angeboten wird, wird halt auf dem Host eine Docker-VM angelegt, in der wiederum die einzelnen Docker-Container laufen - und das Wartungs-/Update-Problem hast Du dann entsprechend genauso (plus Wartung der VM).

Persönlich würde ich mir den ganzen Container-Krams sparen. Z.B. ein eigener Container für einen Reverse Proxy ist schon ein Witz; das macht im Zweifelsfall ein winziger gut abgehangener und Security-mäßig unkritischer nginx, der einfach und sauber per apt install nginx zu installieren ist und dann so gut wie keine Ressourcen verbraucht.

Sinnvoll sind IMHO Container nur bei Diensten, die fraglichen Sicherheitszustand haben. NextCloud/OwnCloud sind da eigentlich die Standard-Kandidaten; andererseits ist es, wenn die jemand übernimmt, auch relativ egal, ob da noch ein Container außenherum ist, weil die persönlichen Daten dann naturgemäß eh schon gekapert sind... also gibt's da auch keinen wirklichen Vorteil gegenüber "einfach nur als eigenen Benutzer laufen lassen".

Oh und z.B. systemd und Linux Capabilities können auch einiges an Sicherheit schaffen, teilweise besser und einfacher als Docker das kann.

 

[Malaclypse17]

Würde eine eigene VM für Container anlegen, funktioniert so bei mir schon seit Jahren super, auch als ich die VM mal wiederherstellen musste (über Proxmox Backup Dienst).

gut abgehangener und Security-mäßig unkritischer nginx, der einfach und sauber per apt install nginx zu installieren ist und dann so gut wie keine Ressourcen verbraucht.

Ich finde es schön, weil man vom Host nur den Part exposen muss, den der Dienst wirklich braucht, ebenso bleibt das Hostsystem somit komplett frei von alten Configs oder sonstigen Datenleichen (ich mag es aufgeräumt ).

 

[Drizz]

Hallo,

auf meinem Proxmox habe ich Docker samt Portainer in einem LXC Ubuntu-Container laufen - kam mir damals einfach schlanker vor.
Aktuell laufen 37 Container (mehrere node-red und influx, paperless, mealie etc.), der LXC hat 2vCPUs und 4GB RAM, anfangs war das wesentlich mehr, nach einiger Zeit habe ich aber gemerkt, dass die ganzen Dienste relativ wenig Ressourcen benötigen.

Was das Backup angeht, hmmm da habe ich schon ab und zu meine Probleme:

- Generell ist es so, dass wenn das NFS Share (ein NAS) wackelt und beim Backup nicht erreichbar ist, dann fliegt mir der gesamte Proxmox um die Ohren (dann muss ich alle LXCs und VMs stoppen, was schon lange dauern kann) und dann den gesamten Server neu starten.
Bin daher auf ein NFS Share gegangen, welches über OMV auf dem selben Server bereitgestellt wird und von dort aus über rsync auf das NAS geschoben wird.

- Manchmal kommt es vor, dass alle Docker Container nach dem Backup (Snapshot) plötzlich ausgeschaltet sind (bis auf den Portainer) - ich denke, dass ich hier nochmal auf den Mode "Stop" wechsle.

- Das Recovery hat aber bisher immer (!) funktioniert

Was die Aufteilung der Services angeht, das entscheide ich aus dem Bauch heraus. Es ist aber so, dass ich eine OPNSense FW auf dem Proxmox habe, die für jeden Service ein Subnetz bereitstellt und alles durch die FW muss (die Regeln sind dann auch dementsprechend gesetzt).

OMV z. B. läuft als VM. Es kommt aber auch schon mal vor, dass ich mit einem LXC oder VM starte und die (zum Teil mehr werdenden Services) dann in einzelne Docker Container auflöse, um den Blast Radius zu minimieren -sollte was schiefgehen 🧐.

Edit: Aktuell hat jeder Webservice seinen eigenen NGINX / Apache - bin mir hier selbst noch unschlüssig, ob ich die konsolidieren will / sollte.

MfG Drizz

 

[riversource]

Man kann auch mehrere Docker Container in einem LXC Container unterbringen. Die Container in einem ZFS System halte ich auch für sehr gut geeignet für Backups.

 

[Flossen_Gaming]

Ich habe bei mir für alles was ich brache einen eigenen LXC Container oder eine VM am laufen.

PiHole hat z.B. einen eigenen LXC, Heimdall einen eigenen..

Für den Valheim Server hab ich dagegen ne richtige VM laufen.

Docker/Portainer ist mir zu viel fuddelei

 

[GrumpyCat]

Ich finde es schön, weil man vom Host nur den Part exposen muss, den der Dienst wirklich braucht, ebenso bleibt das Hostsystem somit komplett frei von alten Configs oder sonstigen Datenleichen (ich mag es aufgeräumt ).

Ähja die Docker-Generation spricht, nimm's mir nicht übel.
Z.B. ein nginx "exposed" doch gar nichts, was es nicht braucht. Port 80 und 443 und sonst nichts. Das Problem mit ggf. weiterem Schutt fängt man sich ja gerade erst mit VMs und Containern ein.
Alte Configs und Dateileichen gibt's nicht. dpkg --purge nginx löscht Dir alles weg inkl. Configs. Genau dafür ist das Packaging-System da! Und das ist tausendmal abgehangener und besser maintained als Docker oder gar irgendwelche Docker-Images aus zweifelhaften Quellen, die z.B. gerne ein achsotolles "gehärtetes" Alpine-Linux als Basis benutzen - nur ohne den gehärteten Kernel und in einer uralten Version.
<Rant off>

 

[boeck]

Da bei mir nicht viele Dienste laufen, habe ich nur eine VM mit allen Docker Containern und 2 LXCs.

Docker in der VM deswegen weil bei mir damals Docker in LXC auf ZFS noch nicht out-of-the-box funktioniert hat (dies ist aber glaube ich mittlerweile behoben) und weil ich die HDDs direkt in die VM durchreiche für LUKS.

Da es manche meiner Dienste nur als Docker Container gibt, bin ich gezwungen Docker zu verwenden. Finde ich aber nicht so tragisch da ich Docker sehr angenehm finde um Neues zu testen. Geht meiner Meinung nach einfacher als mittels LXC.

Mein DNS und die Tailscale Exit Node läuft als eigener LXC, damit diese nicht unterbrochen werden wenn ich mal die VM mit den Docker Containern neu starten muss.

Bzgl. Ressourcen Verbrauch einer VM: Debian benötigt mindestens 512MB RAM für die Installation und das Betriebssystem selbst verbraucht glaube ich ca. 60MB. Eine leere VM braucht somit zwar mehr als ein LXC. Aber wenn man ein paar Docker Container in der VM laufen lässt, gleicht es sich meiner Meinung nach wieder aus und die 60MB overhead für die VM fallen nicht so sehr ins Gewicht (sofern man es mit der Anzahl der VMs nicht übertreibt). Die CPU Kerne sind ja eh nicht fix zugeordnet sondern geteilt und somit beim Ressourcenbedarf vernachlässigbar.

Wenn man genug Docker Container hat könnte man diese also locker auf mehrere VMs aufteilen ohne dass der Ressourcenverbraich explodieren sollte.

Bei den Updates bin ich faul und habe sowohl in der VM als auch in den LXCs einen systemd Service eingerichtet welcher täglich alle Updates (sowohl Apt als auch Docker) installiert. In der Arbeit würde ich das bei einer Produktivumgebung natürlich nicht machen, aber am Homeserver lass ich es drauf ankommen. Bis jetzt bin ich damit gut gefahren. Bei Docker Containern ist es bei mir schon ab und zu vorkommen, dass sich ein Fehler in der neuen Version eingeschlichen hat und man dann die alte Version pinnen muss bis der Fehler behoben wurde. Aber diese Fehler hätte ich auch nicht bemerkt wenn ich die Updates händisch gemacht hätte, da sie erst später im Betrieb aufgefallen sind. Bei den automatischen Apt Updates hatte ich bis jetzt noch nie Probleme gehabt.

Und für Backups ist Proxmox Backup Server sehr empfehlenswert, falls du den noch nicht kennst.

 

[Zipfelklatscher]

Danke erstmal für die (bisherigen) Antworten. Bleibt als Fazit: wie man's macht, macht man's falsch. Oder richtig, je nachdem.

Ich denke, ich werde die Docker-Container in einer VM laufen lassen. Bleibt die (Glaubens)frage, ob Ubuntu oder Debian. Dort dann Watchtower laufen lassen, dann entfällt schon mal das manuelle Updaten der Docker-Container. Sowas wie die Nextcloud bekommt dann einen eigenen LXC-Container, da ich die Nextcloud nativ (also per Webserver) laufen lassen wollte.

Ich habe in meiner Fritzbox lediglich Port 80, 443 und die Ports für Wireguard sowie Synology Drive geöffnet, mehr wird nicht benötigt. Wobei ich das Synology Drive eventuell auch durch Syncthing ersetzen möchte. Wobei man beim Einsatz eines ReverseProxy und Zertifikatserstellung durch DNS Challenge doch den Port 80 gar nicht benötigt, sondern lediglich Port 443, um halt auf die verschiedenen Dienste zugreifen zu können? Port 80 wird ja nur bei der "normalen" Methode zur Zertifikatserstellung benötigt, also per HTTP. Oder liege ich da falsch? Je weniger Ports offen sind, um so besser. ;-)

Auf meiner DS720+ (die mit 10 GB RAM läuft) läuft bereits testweise der Proxmox Backup Server in einer VM (2 Kerne, 4 GB RAM), der dann per NFS seine Dateien auf dem NAS ablegt. Die Sicherungen funktionieren auch ohne Probleme. Der Backup-Ordner auf dem NAS wird dann einmal wöchentlich verschlüsselt in eine Hetzner Storagebox hochgeladen und zusätzlich auf eine externe USB-Platte, die nach dem Backup automatisch ausgeworfen wird. 5 Minuten vor dem Backupzeitpunkt wird sie mittels zweier Befehle wieder gemountet. So ist sie im NAS nur für die Dauer des Backups sichtbar. Okay, bei einem Überspannungsschaden hilft das auch nicht, da die USB-Platte ja noch physisch verbunden ist.

Ich übe weiter. :-)

 

[boeck]

Kommt einfach drauf an was einem wichtig oder lieber ist.

Debian hat einen geringeren RAM Verbrauch als Ubuntu, falls du also auf Ressourcenverbrauch optimieren willst. Und wenn dir Debian zu alte Pakete hat, kann man auf die (nicht ganz so alten) Backports zurückgreifen. Aber die Differenz ist vernachlässigbar wenn man nur wenige oder sogar nur eine VM betreibt.

Port 80 wird noch für die Umleitung von HTTP auf HTTPS benötigt. Ansonsten musst du (wenn der Browser die Adresse noch nicht in der Historie hat) immer "https://" eingeben.

Proxmox Backup Server hat eine Verschlüsselung bereits eingebaut (muss extra aktiviert werden). Wenn du diese verwenden würdest, musst du es nicht in einem extra Schritt verschlüsseln und könntest dann sogar mehrmals täglich automatisch die Differenzen des Ordners per rsync in die Storage Box hochladen.

 

[Zipfelklatscher]

Danke für die weiteren Ausführungen.

Habe jetzt die Verschlüsselung für die Sicherungen über den Proxmox Backup Server eingerichtet. Würdet Ihr das so lassen, den Backup-Server auf dem NAS als VM laufen zu lassen? Das NAS ist jetzt sowieso weniger ausgelastet, da die Docker-Container alle auf dem Proxmox laufen. Ich habe übrigens eine VM für Docker eingerichtet. Das läuft bisher auch sehr schnell, wobei da noch nicht viele Container drin laufen. Den Backup Server auf dem gleichen Server laufen zu lassen wie Proxmox selber wäre wohl nicht so clever, nehme ich mal an?

 

[boeck]

„Clever“ ist relativ. Jedes Backup ist besser als kein Backup, würde ich sagen. Betreibe meinen PBS auch direkt am PVE Host und spiegle den Store dann auf eine zweite Platte. Habe halt einfach keinen zweiten Server Zuhause stehen, weil es für meine Bedürfnisse einfach Overkill wäre.

Du könntest aber wenn du den Speicherplatz hast z.B. auch den PBS am PVE Host installieren und direkt dort die Sicherung machen und dann mit der Synchronisation von PBS den Store zum PBS am NAS spiegeln und von dort dann in die Storage Box. Dann könnte man irgendwie von einem 3-2-1 Backup sprechen.

Wenn du keinen HA Cluster betreibst kannst du den CPU Typ der VM auf „Host“ ändern um die maximale Leistung zu bekommen.

 

[Zipfelklatscher]

Okay, danke. Wie läuft das eigentlich, wenn man Proxmox doch mal komplett neu aufsetzen muss. Ich habe schon mal versucht, eine USB-HDD, auf der VMs gesichert waren, anzustecken, aber es ist mir nicht gelungen, sie wieder einzubinden, so dass man nach dem Neuinstallieren die VMs zurückspielen kann. Mit einem NFS-Share ging das ohne Probleme: NFS-Share als Backup-Speicher einbinden und schon hat man gesicherten VMs gesehen und konnte sie erfolgreich wiederherstellen. So konnte ich mir sicher sein, dass das Recovery funktioniert.

Das gleiche mit dem Proxmox Backup Server: da konnte ich auf dem PBS den NFS-Share auch nicht so einfach wieder einbinden, da er rumgemeckert hat, dass das Verzeichnis nicht leer sei. Aber es muss ja eine Möglichkeit geben, den Share wieder als Datastore in PBS einzubinden, ohne die bereits gesicherten VMs zu verlieren. Zur Zeit sichere ich erstmal auf ein normales NFS-Share auf meinem NAS. Das sind zwar immer Vollbackups, aber eine VM, die 30 GB Festplattenplatz hat, aber nur z.B. 6 GB belegt hat, belegt dann auch nur knapp 6 GB beim Backup.

EDIT: Okay, das mit dem Einbinden des NFS-Shares nach Neuinstallation des PBS habe ich hier gefunden, werde ich demnächst mal testen. :-)

 

[boeck]

Ich sichere „/etc“ täglich mit borg. Daraus würde ich dann die beiden Ordner für PVE und PBS wiederherstellen. Dann sollten die ganze Konfiguration wieder so wie vor dem Wiederherstellen sein und ein Restore sofort möglich sein (möglicherweise braucht man noch einen reboot damit die Konfiguration neu eingelesen wird).

Den PBS Store auf einen NFS habe ich auch probiert aber da konnte PBS den Store nicht anlegen und dann habe ich es gelassen und den Store lokal angelegt.

Aber wenn du dann eine PBS Instanz auf deinem NAS hast könntest du nach dem neu aufsetzen von PVE dann diese verbinden und von dort den Restore machen.