Alles klar, danke für die ausführliche Erläuterung.
Dann noch die letzte Frage:
Wenn der Dienst im Docker Container läuft, dann pro Dienst eine eigene Ubuntu Server VM oder mehrere Docker Container in einer VM?
Das kommt drauf an, was einen wichtig ist
Will man möglichst wenig Wartungsaufwand ( Systemupdates und co) oder muss mit relativ wenig Ressourcen auskommen? Dann bietet sich an möglichst viel auf eine VM zu packen. Oder will man eine strikte Trennung nach Dienst oder Funktion der Container ( "Spielwiese" für Experimente, darf such mal kaputt sein versus "Produktion", die einfach nur funktionieren soll)? Außerdem gibt es Anwendungen, wo über docker-compose o.ä. mehrere Container gestartet werden, die erst zusammen den Dienst ergeben ( z.B. Webserver und Datenbank für einen Webshop), da macht es dann wieder Sinn die alle in reine VM zu packen.
Dazu kommt noch, ob man die VMs eher als "pets" oder "cattle" betrachtet. Diese Analogie kommt aus den devops-Berwichvund wurde u.A. von Thomas Limoncelli, Christina Hogan und Strata R. Chalup in ihrer "Bibel" für Sysadmins popularisert (
https://everythingsysadmin.com/books.html ):
Mein privates Notebook oder der klassische zentrale Firmenserver ist im Grunde ein Haustier ( pet) Es wurde genau für eine bestimmte Verwendung eingerichtet und optimiert, alle Anwendungen samt Daten laufen direkt darauf, alles genauso wieder einzurichten, wäre mit relativ viel Aufwand verbunden. Linuxserver in der Cloud sind dagegen wie Vieh beim Bauern: Jeder hat eine Nummer, wurde aus den gleichen Basisimage erzeugt und über ein Autonatisierungstool ( wie ansible oder puppet) mit der gleichen Software ( in Form von Docker, Kubernetes oder podman Containern) und Konfiguration bestückt. Die Daten werden außerhalb der VM auf externen Storage bereitgestellt. Gibt es mit einer Instanz ein Problem, wirft man sie weg ( quasi eine Notschlachtung ) und erstellt sie neu. Es gibt Firmen, die dabei soweit gehen ihre VMs regelmäßig geplant abzuschießen und neu aufzusetzen, ihr Basisimage wird dabei regelmäßig mit allen aktuellen Patches automatisiert neu erzeugt.
Vorteile davon sind kleben dem Sicherheitsgewinn geringerer Wartungsaufwand ( alles automatisiert) und dass die Daten außerhalb gelagert werden ( macht Backups leichter).
Da die meisten Cloudanbieter als Basis für ihre Plattform Linux und KVM genommen haben ( was ja auch bei ProxmoxVE die Basis ist) finde ich es immer witzig, wenn über die "mangelnde Enterprisefähigkeit" von OpenSource im Allgemeinen und PVE im Besonderen schwadroniert wird. Die wenigsten Firmen betreiben eine auch nur annähernd so komplexe Umgebung wie Amazon oder Google ( und wenn gibt es tatsächlich auf KVM basierende OpenSource Lösungen wie Openstack. Die kommen such mit deutlich größeren Ungebungen als ProxmoxVE klar, sind aber auch komplexer im Betrieb).
Nun ist das Alles in der maximalen Ausbaustufe fürs Homelab sicher erstmal völliger Overkill, aber einiges davon kann und sollte man sich meiner Meinung nach schon abschauen
Cloud-init wäre ein Beispuel, damit kann man in der Clizd schnell eine neue VM starten ubd gleich die passenden Pakete installieren und nötige Systemanpassubgen bornehmen lassen und das wird such von ProxmoxVE unterstützt.
Auch zuhause ist es ja praktisch, im Katastrophenfall alles schnell wieder ans Laufen zu kriegen oder nicht viel Hirmschmalz und Aufwand in Konfiguration stecken zu müssen oder eine verbastelte VM auch mal ohne negative Folgen wegwerfen zu können.
Auch eine Ausgliederung der Daten ( an ein NAS per Netzwerkfreigabe oder als eigene virtuelle Datenplatte) macht es leichter einen Dienst von einer VM an eine andere umzuziehen oder schnell wieder ans Laufen zu kriegen
