Hängt auch immer davon ab wie unkompliziert und sicher du es haben willst. Legst du wert auf Sicherheit und Migrierbarkeit nimm VMs. Willst du wenig Ressourcen verbrauchen nimm LXCs.
Ich dachte immer wenn es um Migrierbarkeit geht ist es besser Docker Container zu verwenden. Deshalb auch LXC anstatt VM.
VMs sind voll virtualisiert und isoliert.
Docker Container sind auch isoliert, wenn man Docker rootless betreibt.
Da man dann ja auch die Images ohne root nutzt.
Da schaut man also besser ins Dockerfile...
Du hast also keine Abhängigkeiten zum Host-OS da jede VM ihren eigenen Kernel laufen lässt. Das macht dann das Verwalten und Migrieren einfacher, weil jede VM halt ihr eigener kleiner virtualisierter Rechner ist. Wegen Sicherheit sind VMs auch immer LXCs vorzuziehen, da wie du schon sagtest du einfach eine VM runterfahren kannst, wenn diese kompromitiert wurde und ein Angreifer vom Gast nicht ohne weiteres Zugriff auf den Host selbst oder andere Gäste erhält (wobei es da natürlich auch Angriffvektoren über Overflows im RAM gibt etc).
Dafür benötigt die VM halt Ressourcen vom Host (z.B. RAM).
Bei LXCs teilt sich das Gast-OS den Kernel mit dem Host-OS. Du hast also keine keine Virtualiserung und keine echte Isolierung. Hier läuft dann quasi alles auf dem Host selbst, nur halt mehr oder weniger abgeschottet. Bei privilegierten LXCs ist es ganz übel, da es dort im Gegensatz zu unprivilegierten LXCs, kein User/Group-Remapping gibt. Dort ist dann der Root-User im LXC der gleiche wie der des Hostes. Da hast du also schnell echt ein Problem, wenn dir da mal ein Gast kompromitiert wird, weil du etwas falsch konfiguriert hast.
Also kann man kein LXC als User nutzen, nur als root?
Außerdem bist du anfälliger für Probleme. Wenn du Proxmox aktualisierst, dann wird ja auch dein Kernel aktualsiert. Da aber der LXC den Kernel vom Proxmox-Host mitbenutzt, läuft da also auch plötzlich dein Gast mit einem neueren Kernel der vielleicht Features hizufügt oder wegnimmt. Vielleicht gibt es da aber für dein Gast-OS im LXC noch keine Updates für alle Programme und dann läuft dein Gast nicht mehr wie er sollte.
Das ist natürlich ein Argument.
Und wenn du Nesting aktivierst, dann gibst du dem Gast-OS zugriff auf deine System-Ordner des Hosts wie /proc und /sys.
Vorteil beim LXC ist halt der fehlende Virtualisierungsoverhead und das du weniger Ressourcen verbrauchst.
Auch hier die Frage: Also kann man kein LXC als User nutzen, nur als root?
Willst du nur einen Webserver laufen lassen der 50MB RAM braucht, dann braucht dieser als LXC halt nur seine 50MB da der Kernel ja bereits läuft. Lässt du das gleiche in einer VM laufen sind das vielleicht 300MB RAM, da ja jede VM ihr eigenes Linux mit eigenem Kernel mit sagen wir mal 250MB laufenlassen muss, damit da oben drauf dann der Webserver mit 50MB laufen kann.
Klar, alles was in einer VM läuft bräucht mehr Ressourcen vom Host.
Ich persönlich lasse da alles in VMs laufen was irgendwie vom Internet aus erreichbar ist oder sonst wie angreifbar wäre. Und wenn mir ein Dienst besonders wichtig ist, weil der bzw bei mir zur kritischen Infrastruktur zählt, dass ich auf diesen nicht verzichten kann und der wirklich immer fehlerfrei laufen muss, dann nehme ich auch nur VMs. LXCs nehme ich dann für alles andere wie lokale Dienste die nur im LAN bereitgestellt werden sollen und wo es nicht wichtig ist, wenn ein Dienst mal ausfällt. Daher sind bei mir gut 90% aller Gäste VMs.
Ich komme unten noch drauf zu sprechen, da es mir um Root Server geht.
Da werden Dienste wie Webserver normal fest installiert, wenn man kein Docker nutzt.
Somit auch keine VMs benutzt. Kann man, muss aber nicht.
Für Docker würde ich eigentlich immer eine VM empfehlen. Zum einen willst du früher oder später bestimmt etwas in Docker laufen lassen was online verfügbar sein soll und wenn du da dann Wert auf Sicherheit legst, dann sollte das wegen der besseren Isolation schon eine VM sein. Ist dann doof wenn man sich später zu seinem Docker-LXC noch eine Docker-VM machen muss, was dann ja die Verwaltung erschwert, wenn man alles doppelt verwalten muss. Und dann ist Docker fehleranfälliger auf LXCs. Docker will halt oft Features vom Host die wegen der Sicherheit in einem LXC verboten sind. Dann kann man zwar über die Konfig-Datei des LXCs dem LXC diese Rechte einräumen, schwächt damit dann aber natürlich auch die Sicherheit. Ist übrigens noch garnicht so lange her, dass da Docker überhaupt nicht in einem LXC lief.
Docker ist ja dafür gedacht eine Anwendung laufen zu lassen die nicht direkt installiert werden muss.
Ist - für mich - jetzt kein wirkliches Argument mit der Sicherheit selbst, da Docker rootless mit entsprechenden Docker Images schon sicher und isoliert ist.
Das Argument, dass Docker auf LXC fehleranfälliger ist, ok, das zählt (wenn dem "noch" so ist).
Und dann wollen die meisten Leute ja keine eigenen Docker-Container selbst programmieren, wo sie dann selbst Updates einspielen können und genau wissen würden was da im Detail im Docker-Container abgeht. Sondern sie wollen eine Plug-And-Play-Lösung die läuft ohne das sie sich in die Materie einarbeiten müssten oder selbst etwas administrieren müssten. Man lässt also Programme von fremden Leuten laufen denen man prinzipiell nicht vertrauen kann und guckt dann selbst nicht in den Code, ob da vielleicht Schadsoftware enthalten ist oder ob der Container-Ersteller vielleicht selbst keine Ahnung hat was er da tut sich etliche Sicherheitslücken nicht geschlossen hat. Und dann hat man noch das Problem, dass man bei Docker-Containern nichts selbst aktualisieren kann. Oft hat da ein Ersteller mal keine Zeit und dann gibt es halt über Monate keine Sicherheitsupdates oder er gibt den Container komplett auf und dann gibt es überhaupt keine Updates mehr. Manchmal hat man auch offizielle Docker-Container direkt von dem Entwickler einer Software, da ist es dann mit regelmäßigen Updates und dem Vertrauen nicht so das große Problem. Aber der Großteil der Docker-Container ist halt von einzelnen Leuten die sich irgendwie fremde Software zusammenbasteln und dies dann veröffentlichen. Ich würde denen jetzt nicht unterstellen etwas böswillig zu machen, aber oft kann ja mangelndes Fachwissen schon genug Schäden anrichten. Und kann auch mal vorkommen, dass da solcher Account gehackt und dann über diesem gezielt Schadsoftware verbreitet wird die man sich dann bedenkenlos runterläd.
Da ich mich auch damit beschäftige... ich würde meine Images schon selbst bauen, bzw. nur offizielle Dockerfiles und Images nutzen und (per multi-stage build) erweitern wo es für mich sinnvoll erscheint.
So ist für mich vieles unbrauchbar wo alles zusammen in nur einem Iages läuft (z.B. Webserver, DB, Anwendung etc.).
Ebenso unbrauchbar - für meine Zwecke - Compose Dateien, da ich kein Docker Compose benötige.
Gerade wenn man fremde Sachen laufen lässt würde ich so etwas nur in einer VM wollen, wo dann ein böswilliger oder schlecht aktualisierter Docker-Container wegen der besseren Isolierung wenigstens keinen Schaden am Host, anderen VMs oder gar anderen Rechnern im Heimnetz anrichten könnte.
Das ganze soll eben nicht im Heimnetz sonder produktiv auf einem Root Server genutzt werden!
Somit muss diese Maschine mit passender hardware ausgestattet sein, wenn man doch VMs nutzen soll.
Entsprechend sind dann wiederum die Preise.
Das ist aber ein anderes Thema.
