LXC vs. Docker

[PVE-Newbee]

Hallo,

ich habe nun meine ersten Gehversuche auf Proxmox hinter mir und bin erstmal sehr zufrieden, einfach auch, weil es funktioniert.

Aktuell laufen bei mir auf meienr Synology einige Docker-Container. Diese Dienste möchte ich sukzessive nach Proxmox umziehen.
Ich habe nun einen LXC Container aufgesetzt und darauf dann Docker installiert mit den ersten Containern (Adguard, NGINX, Portainer, Watchtower).
Demnächst sollen die Anwendungs-Dienste wie Paperless und Bitwarden folgen. Danach Jellyfin, YT-Download und weitere für den Heimgebrauch.

Ich verstehe zwar den Unterschied der beiden Ansätze, dennoch stellt sich bei mir die Frage, ob ich diese alle in eigenen, separaten LXC Containern laufen lassen soll oder gesammelt im bestehenden Docker? Was ist da sinnvoll? Gibt es da irgendwelche Kriterien, wonach man das beurteilen kann? Oder ist es letztlich egal. An Docker gefällt mir, dass ich einmal für alle Container die Ressourcen definiere. Wo liegen die Vorteile bei LXC? Ich frage auch deshalb, weil in vielen Tutorial Videos, die ich mir angesehen habe, dort sehr oft die 1 Dienst = 1 LXC Container gesehen habe.

Danke für Hinweise.

 

[UdoB]

...ob ich diese alle in eigenen, separaten LXC Containern laufen lassen soll oder gesammelt im bestehenden Docker?

Weder noch ;-)

https://pve.proxmox.com/pve-docs/pve-admin-guide.html#chapter_pct --> "If you want to run application containers, for example, Docker images, it is recommended that you run them inside a Proxmox QEMU VM."

Docker hat mehrere Mechanismen, die möglicherweise für Konflikte sorgen, das ist dann insbesondere bei der Fehlersuche problematisch. Mit dem Einsperren in eine VM verhindert man diese Probleme wirksam.

Natürlich muss man dann auch diese zusätzliche VM pflegen und monitoren. Choose your poison...

(( Ich selber verwende zu 90% VMs, ohne Docker. Die paar wenigen Docker, die ich "aus Gründen" dennoch verwende, laufen jeweils separat/einzeln in jeweils einer separaten VM. Das maximiert quasi den (Ressourcen-) Aufwand, aber die saubere Trennung der Dienste untereinander ist es mir wert... ))

 

[PVE-Newbee]

Danke für die Antwort. Allerdings bin ich jetzt verwirrt.
Zunächst mal laufen die Container, die ich bisher auf meiner Synology installiert habe, seit ca. 3 Jahren ohne große Probleme.

QEMU sagt mir gar nichts. Bin ich noch nie drauf gestoßen. Hab gerade mal gegoogled, aber so richtig schlau bin ich daraus nicht geworden. Es handelt sich dabei doch auch wie Proxymox um eine Virtualiserungsumgebung? Die Empfehlung ist also, in Proxmox eine VM laufen zu lassen und darin dann QEMU, um dort wiederum die Container laufen zu lassen? In QEMU dann nochmal Docker? Hab ich das richtig verstanden?

Und vor allem: Warum finde ich dann, wenn QEMU die Empfehlung für Container in Proxmox ist, so viel LXC und Docker Tutorials? Also, ich bin irritiert ...

Vielleicht nochmal zu meinem Ziel: Es ist ein rein privates Projekt, ich hab Spaß an der Sache, aber am Ende soll es mit möglichst geringem Aufwand stabil laufen. Ich will hier nicht mit Kanonen auf Spatzen schießen.

 

[UdoB]

QEMU sagt mir gar nichts.

QEMU ist ein altes Projekt für den Ansatz, virtuelle Maschinen zu emulieren, anfangs in "Software im Userpace" --> https://www.qemu.org/

Mittlerweile verwendet der fast immer ein Kernel Modul, damit eine brauchbare Performance erreicht wird. --> https://linux-kvm.org/page/Main_Page

Proxmox PVE verwendet dies intensiv um eben... virtuelle Maschinen zu bauen.

Die Empfehlung ist also, in Proxmox eine VM laufen zu lassen und darin dann QEMU, um dort wiederum die Container laufen zu lassen? In QEMU dann nochmal Docker? Hab ich das richtig verstanden?

Fast

Du baust in PVE eine VM. Punkt. Innerhalb dieser VM kannst du dann ganz normal Docker installieren. Wie das konkret geht, hängt dann vom gewählten Gast-Betriebssystem ab.

Ich will hier nicht mit Kanonen auf Spatzen schießen.

Klar, du kannst natürlich learning-by-doing machen, ich empfehle das im Prinzip sogar ausdrücklich. Selber Probleme zu lösen lässt mich Dinge lernen.

Allerdings vermeide ich möglichst Bereiche, die andere Nutzer bereits ausgelotet haben und umfassend für "problematisch" erachtet haben. Du kannst natürlich gerne Docker in LXC nutzen. Ich halte das für fehleranfällig, schwer zu entwanzen und vermeide es ausdrücklich.

Have fun!

 

[maxim.webster]

Ich würde keinesfalls pro OCI Container (AKA „Docker“) eine eigene VM aufmachen, das wäre wirklich übertrieben.

Stattdessen eher an Verfügbarkeit und Netzwerk-Zonen orientieren, also was muss hochverfügbar sein, was im Intranet, was in der DMZ, was im Intranet.

Bei einzelnen Anwendungen dann überlegen, ob sie statt als Docker Container in einer VM als LXC laufen können, um direkte Unterstützung durch Proxmox zu haben (Migration, Replikation, Backups).

Man muss halt Umdenken, die Einfachheit eines OCI Container Images mit „latest“ Tag in Verbindung mit Watchtower kann aber durchaus durch einen Debian LXC mit unattended-Updates ersetzt werden.

Größer Vorteil eines LXC gegenüber OCI Constainer m.E.: Eigene IP und Hostname out-of-the-Box

 

[UdoB]

Ich würde keinesfalls pro OCI Container (AKA „Docker“) eine eigene VM aufmachen, das wäre wirklich übertrieben.

Mag sein. Aber nicht für mich; daher schrieb ich oben: Choose your poison...

Ich leide auch etwas unter der generellen Konstruktion von Containern, egal ob LXC oder Docker: die Trennung zum Host ist nur hauchdünn und nachträglich aufgesetzt - was immer schlecht ist. Ursprünglich gab es weder Namespaces im Kernel noch sonst etwas, Container waren einfach nur bessere "chroot"s. Mittlerweile ist das wesentlich besser gelöst und wird allgemein als benutzbar eingestuft. Aber der einzige Kernel wird immer noch geteilt. Gut, dass es im Kernel keine Bugs gibt...

Frohe Weihnachten

PS: bitte nicht missverstehen, ich hatte Container schon verwendet, als es sie noch gar nicht gab ;-) und sie stattdessen "OpenVZ" genannt wurden: https://en.wikipedia.org/wiki/OpenVZ. Aber heute kann meine Hardware KVM und Container sind für mich definitiv nur zweite Wahl.

 

[maxim.webster]

PS: bitte nicht missverstehen, ich hatte Container schon verwendet, als es sie noch gar nicht gab ;-) und sie stattdessen "OpenVZ" genannt wurden

Kenn ich, war aber unnötig solange es noch Solaris Zones gab

Es gibt leider keinen allgemein gültigen Wenn-Dann-Nimm-Leitfaden für VM, LXC und OCI Container. Compose Stacks sind toll für Kohärenz bei gleichzeitiger Isolation. Gleichzeitig kommt halt jeweils eine eigene Datenbank-Instanz mit genau einem Schema im WordPress, Nextcloud oder Matomo-Stack zum Einsatz. Wäre da ein zentraler DB-Cluster auf LXC Basis nicht besser?

Wie auch immer, der Endgegner ist schon vorbereitet: 3 Talos Linux VMs für Kubernetes.

 

[jim_os]

Zu dem Thema ob man nun eine VM für/mit Docker nutzt oder nicht sagen ich mal nichts - weil das halt "Geschmackssache" ist, sondern ich will es nur mal aus meiner Sicht und eher einfach beschreiben.

weil in vielen Tutorial Videos, die ich mir angesehen habe, dort sehr oft die 1 Dienst = 1 LXC Container gesehen habe.

Weil das auch der übliche Weg ist. Wenn Du jetzt das

Ich habe nun einen LXC Container aufgesetzt und darauf dann Docker installiert

gemacht hast hat Du es quasi "doppeltgemoppelt".

Ich verstehe zwar den Unterschied der beiden Ansätze, dennoch stellt sich bei mir die Frage, ob ich diese alle in eigenen, separaten LXC Containern laufen lassen soll oder gesammelt im bestehenden Docker?

Wenn Du die Unterschiede kennst, bzw. weißt was LXC sind, dann stellt sich m.M.n. die Frage eigentlich gar nicht. Ohne jetzt weiter auf die genauen Unterschiede einzugehen: Docker oder LXC sind quasi beides eine Form von Container und man nutzt sie üblicherweise dafür das Anwendungen, mit möglichst wenig Ressourcenverbrauch, getrennt voneinander laufen. Wenn Du bisher Docker auf Deiner DS genutzt hast, dann hast Du da doch auch jede Anwendung in einem seperaten Docker installiert und nicht mehrere Anwendungen in dem gleichen Docker, oder? Nichts anders machst Du dann mit LXC. Wenn Du es Dir einfach machen willst kannst Du auch auf die Scripte von tteck zurückgreifen und damit vermutlich jede Anwendung die Du jetzt in einem Docker auf der DS installiert hast, dann als LXC unter Proxmox installieren.

Oder fragen wir mal anders: Warum hast Du Dir einen LXC installiert und dann in dem auch noch Docker und darunter dann weitere Docker Container? Was genau willst Du damit bezwecken?

Ach ja - und frohe Weihnachten.

VG Jim

 

[PVE-Newbee]

Oh weh, ich verstehe ja nicht mal die Hälfte von dem, was ihr da schreibt. Bin halt noch am Anfang. Werde mal weiter probieren und mich weiter einarbeiten. Solange lass ich die Container erstmal auf Synology. Da läuft es ja stabil.

Danke in jedem Fall erstmal und Frohe Weihnachten.

 

[PVE-Newbee]

Oder fragen wir mal anders: Warum hast Du Dir einen LXC installiert und dann in dem auch noch Docker und darunter dann weitere Docker Container? Was genau willst Du damit bezwecken?

Ach ja - und frohe Weihnachten.

VG Jim

OK, jetzt komme ich der Sache näher: Ich hab den falschen Ansatz gewählt. LXC und darauf Docker ist "doppelt gemoppelt". Danke, das hab ich verstanden.
Bedeutet also, alles nochmal überarbeiten. Aber man lernt ja auch dadurch ...

Frohe Weihnachten!

 

[jim_os]

Bin halt noch am Anfang.

Das hatte ich auch vermutet und deshalb es auch möglichst einfach geschrieben. Ich drücke es mal noch einfacher aus: LXC = Docker --> Vergiss einfach Docker. Wie gesagt kannst Du Deine ganzen bisher per Docker Container auf der DS genutzten Anwendungen auch weiterhin unter Proxmox nutzen, nur das Du dort nicht Docker nutzt sondern einfach LXC.

Mal das Beispiel Adguard: Du gehst auf die o.g. Seite mit den Scripten des inzwischen leider verstorbenen Users tteck. Dort gibt es ein Script für Adguard
https://community-scripts.github.io/ProxmoxVE/scripts?id=adguard

bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/adguard.sh)"

Dieses Script führst Du dann einfach in der PVE Shell aus und es startet eine meist dialoggeführte Installation. In dem Fall von Adguard. Wenn die Installation durchgelaufen ist hast Du im Anschluss einen fertigen LXC Container mit Adguard unter PVE. Also quasi das gleiche wie Du es bisher als Docker auf der DS hast, nur das es jetzt in einem LXC Container unter Proxmox und nicht in einem Docker Container auf der DS ist.

Beispiel von mir mit LXC Container für EMQX und Z2M

Laufender LXC Container mit Z2M


Ggf. müssen dann nach einer Installation per tteck Script - je nach Anwendung - noch ein paar Dinge irgendwo angepasst und/oder zusätzlich erstellt werden, aber darauf wird dann meist verlinkt. Beispiel Z2M: https://github.com/community-scripts/ProxmoxVE/discussions/410

Anm.: Natürlich kannst Du Dir auch selber irgendwelche LXC erstellen, aber die Scripte von tteck nehmen einem halt die Arbeit ab und wurden bisher auch sehr gut gepflegt und immer wieder - wenn nötig - angepasst.

VG Jim

 

[maxim.webster]

Oh weh, ich verstehe ja nicht mal die Hälfte von dem, was ihr da schreibt. Bin halt noch am Anfang. Werde mal weiter probieren und mich weiter einarbeiten. Solange lass ich die Container erstmal auf Synology. Da läuft es ja stabil.

Danke in jedem Fall erstmal und Frohe Weihnachten.

Wie wäre es mit einer VM mit Docker Engine/CRI und Migration aller Container von der Synology in diese VM? Dürfte mehr oder minder 1:1 möglich sein.

LXC können dann später kommen, denn auch wenn der Hinweis auf die LXC Community Skripte richtig ist: OCI Container Images sind a) m.E. einfacher und b) teilweise von offizieller Stelle erhältlich

Docker Container sind halt darauf ausgerichtet, vergänglich (ephemeral) zu sein, die Skripte helfen bei der Erstellung eines LXC, danach ist man aber auf sich gestellt. Schon alleine ein Upgrade der Anwendung im LXC ist m.W. out-of-scope für die Skripte.

 

[jim_os]

von offizieller Stelle

Was ist denn eine "offizielle Stelle"? Die Scripte von tteck laden ja auch die Anwendung von der jeweils "offiziellen" Stelle, sprich der Webseite des Herstellers dieser Anwendung herunter. Offizieller geht's eigentlich nicht.

Ist eigentlich nur eine rhetorische Frage, denn ich weiß natürlich was Du meinst.

Schon alleine ein Upgrade der Anwendung im LXC ist m.W. out-of-scope für die Skripte.

Dafür sind sie ja auch nicht gemacht, oder gedacht. Wobei es auch noch das LXC Updater Script gebe:
https://tteck.github.io/Proxmox/#proxmox-ve-lxc-updater

Für einen Proxmox Einsteiger sind die Scripte von tteck m.M.n. halt der einfachste Einstieg in das Thema. Das dadurch der User weniger lernt als wenn er sich im Vorfeld (kompl.) in das Thema einliest und sich damit beschäftigt, ist natürlich klar. Aber Du weißt ja sicher auch wie es heutzutage (häufig) so ist: Die meisten Anwender wollen alles so einfach wie möglich und mit möglichst wenig Aufwand. Viele wollen leider auch gar nicht (mehr) verstehen was sie da eigentlich machen, sondern sie wollen einfach nur eine Lösung. Ob das jetzt gut oder schlecht ist will und habe ich nicht zu beurteilen.

@PVE-Newbee Nur zur Klarstellung: Der letzte Absatz ist jetzt nicht auf Dich bezogen!

VG Jim

 

[Johannes S]

Was ist denn eine "offizielle Stelle"? Die Scripte von tteck laden ja auch die Anwendung von der jeweils "offiziellen" Stelle, sprich der Webseite des Herstellers dieser Anwendung herunter. Offizieller geht's eigentlich nicht.

Sie sind aber kein Offizielles Projekt der Proxmox Server Dolutiobs GmbH oder der damit i stallierten Softwarepakete. Ubd ich bezweifle, dass jeder Endanwender prüft, ob durch einen Angreifer die hinterlegten URLs geändert hat.

Ist eigentlich nur eine rhetorische Frage, denn ich weiß natürlich was Du meinst.


Dafür sind sie ja auch nicht gemacht, oder gedacht. Wobei es auch noch das LXC Updater Script gebe:
https://tteck.github.io/Proxmox/#proxmox-ve-lxc-updater

Gibt mittlerweile ein Nachfolgeprojekt:
https://community-scripts.github.io/ProxmoxVE/

Für einen Proxmox Einsteiger sind die Scripte von tteck m.M.n. halt der einfachste Einstieg in das Thema. Das dadurch der User weniger lernt als wenn er sich im Vorfeld (kompl.) in das Thema einliest und sich damit beschäftigt, ist natürlich klar. Aber Du weißt ja sicher auch wie es heutzutage (häufig) so ist: Die meisten Anwender wollen alles so einfach wie möglich und mit möglichst wenig Aufwand.

Dann ist aber PVE nicht das Mittel der Wahl. Eine NAS ( meinetwegen auch als VM in PVse) mit Docker ist einfach, Helperskripte nicht. Die Helperskripte sind gut um zu lernen, wie man Sachen zum Laufen kriegt, indem man sich erarbeitet, wie sie funktionieren und dann für dich anpasst. Für den eigentlichen Betrieb machen und lösen sie Probleme,
( siehe zig Debatten zu Problemen mit dadurch installierten docker in lxc, sich automatisiert neustartenden vms etc ), die man ohne sie nicht hätte.
Und gerade dass Leute sie nutzen, um nichts lernen zu müssen, ist doch das Problem. Wenn ich zig lxcs betreiben, muss ich sie auch administrieren, Updates einspueken Fehler beheben etc. Das ist nicht für jeden, da macht eine VM oder NAS mit den Apps in Docker weniger Aufwand.
Außerdem halte ich es für keine gute Idee Leute dazu zu erziehen Skripte aus dem Internet herunterzuladen und ohne Prüfung auszuführen. Das trifft zwar auch für deb-Pakete und docker-Files zu, wenn das die jeweils offiziellen sind, finde ich die aber immer noch vertrauenswürdigen, als curl https://skript | bash und Co.

 

[jim_os]

Sie sind aber kein Offizielles Projekt der Proxmox Server Dolutiobs GmbH oder der damit i stallierten Softwarepakete.

Das sind die oben erwähnten OCI Container Images von https://opencontainers.org auch nicht und um die ging es ja.

Gibt mittlerweile ein Nachfolgeprojekt:

Jepp den Link hatte ich in #11 auch genannt. Nur in #13 habe ich noch den original Link zu tteck genutzt, der auch immer noch funktioniert.

Dann ist aber PVE nicht das Mittel der Wahl.

Das Mittel habe ich ja nicht vorgeschlagen oder ausgewählt sondern der TE.

Eine NAS ( meinetwegen auch als VM in PVse) mit Docker ist einfach, Helperskripte nicht.

Helperscripte sind einfach und wer das dann möchte auch nachvollziehbar. Schließlich sind sie auch nur ein Abfolge von Befehlen die man entweder manuell und zu Fuß eingeben kann, oder halt automatisiert per Script. In sofern gibt es da gar keinen Unterschied und eigentlich auch keinen Grund die Helperscripte von tteck als Problem zu sehen oder darzustellen. Wenn es damit mal ein Problem geben sollte dann ist das halt so und dann muss man das Problem halt lösen. Ob User das dann können, oder ggf. auch nicht weil ihnen ggf. das Wissen dazu fehlt, ist hier auch kein Thema.

Und gerade dass Leute sie nutzen, um nichts lernen zu müssen, ist doch das Problem.

Das sehe ich zwar exakt genau so, aber wie schon gesagt habe ich nicht zu beurteilen was gut oder schlecht für jemanden ist.

Außerdem halte ich es für keine gute Idee Leute dazu zu erziehen Skripte aus dem Internet herunterzuladen und ohne Prüfung auszuführen.

Ich will auch niemanden "erziehen", oder dazu bringen sich irgendwo irgendwelche Scripte herunter zu laden, sondern hier geht es ausschließlich um die Helperscripte von tteck. Und ja, auf diese zu verweisen halte ich nicht für schlecht, oder gar gefährlich. Wer die Scripte von tteck nutzt nutzt sie eigenverantwortlich und ob und wie er sie dann nutzt und ob er sich damit dann beschäftigt um etwas daraus zu lernen, muss auch jeder für sich selber beurteilen und verantworten.

Ich will hier auch gar keine Grundsatzdiskussion darüber führen wie gut oder schlecht jetzt Scripte von tteck sind, oder was welcher User dann wie und womit machen kann oder soll, oder eben auch nicht, sondern ich wollte dem User @PVE-Newbee nur möglichst einfach erklären wie er seine bisher benutzen Docker Anwendungen auf der DS als LXC unter Proxmox wieder nutzen kann. Dafür habe ich ihn a) auf die Helper Scripte von tteck aufmerksam gemacht und b) erwähnt das er selbstverständlich auch eigene LXC ohne die Scripte erstellen kann. Was er dann wie macht ist seine Sache und er kennt ja jetzt auch die unterschiedliche Ansichten dazu.

So und nu is Weihnachten.

VG Jim