Naja da es einfach eine Abfolge von shell befehlen ist, wird es einfacher wie ein fertiger docker Container
Nee in beiden Fällen weiß die Person nicht wirklich, was im Hintergrund passiert. Darum würde ich immer danach gehen, was die jeweiligen Entwickler empfehlen, das erhöht bei Problemen die Wahrscheinlichkeit dass einen jemand helfen kann statt zu sagen "Ist so nicht vorgesehen, bitte teste ob das Problem noch auftritt, wenn du dich an unsere Doku hälst".
Das Problem ist halt, dass bei so Sachen wie paperless oder immich in einen lxc in einen docker-Container man sich für das kleinere Übel entscheiden muss:
- docker im lxc, wovon die Proxmox Entwickler abraten
- paperless ohne docker, was die paperless/immich -Entwickler nicht unterstützen, es wird jedenfalls nicht in ihrer Doku beschrieben
- Immich/paperless als in lxc umgewandelter docker-container mit dem neuen oci-Feature in ProxmoxVE 9.1, was noch experimentell ist und im Grunde auch eine nicht von den paperless/Immich-Entwicklern vorgesehene Variante
- docker in der vm, was sowohl die Proxmox- als auch Immich-Entwickler unterstützen, wo man aber halt nicht direkt die iGPU nutzen kann, solange man die nicht durchreicht.
Wie man damit umgeht muss natürlich jeder selbst wissen (ich selbst fahre eine Strategie der Risikominimierung, lxc ohne docker, wenn möglich, docker in vm, wenn möglich, docker in lxcs nur wenn es gar nicht anders geht), aber das sollte man sich schon überlegen, bevor man munter Skripte oder ansible-playbooks ausführt
Mein Problem mit solchen Helferskripten oder ansible ist nicht so deren Existenz (auch wenn ich sie nicht für hilfreich für Neulinge finde), sondern wenn sie Dinge tun, die so eigentlich nicht vorgesehen wurden und Leute die dann benutzen, ohne sich die oben genannten Implikationen klar zu machen. Sprich wie Leute sie oft benutzen. Hier im Forum schrieb auch mal jemand, dass er die Skripte gerne benutzt, aber auch jedes Mal vorher die durchgeht, um zu verstehen, was das jeweilige Skript macht. Das finde ich dann vollkommen ok, so jemand weiß dann ja im Fehlerfall ja schon mal, wo er beim Troubleshooting anfangen muss.
Und wo ist der Mehrwert einen Cluster in einen Host zu betreiben? Man hat dann ja den Host als single-point-of-failure. Um sich mit kubernetes zu befassen oder (weil man kubernetes eh gewohnt ist) natürlich total legitim. Aber nichts, was ich einen Newbie empfehlen würde
