Naja die Grundsatzdebatte um das Für- und Wider von Containern (ob mit docker oder anders) gehört hier eigentlich nicht her (da kein Proxmox-Thema) wurde aber auch schon öfter diskutiert:
Egal wie man da selbst zu steht, muss man aber zugeben, dass der Trend zu Kubernetes (für große Umgebngen) und docker-/podman-Containern (für kleine Umgebungen) weiter anhält und das auch aus nachvollziehbaren Gründen. Bei einen klassischen Linuxserver ist es es relativ krampfig das System mit neueren Anwendungen zu bestücken als von der Distribution vorgesehen. Das muss nicht unbedingt ein Nachteil sein, wenn man z.B. nur einen relativ simlen Web- oder Dateiserver betreiben will, freut man sich darüber, dass man sich für die Supportdauer um nichts kümmern muss, trotzdem Securityupdates, aber keine breaking Changes bekommt. Will man neue Software, dann muss man entweder ausgewählte neue Pakete (sofern verfügbar) installieren (nicht ganz risiko los das in
https://wiki.debian.org/DontBreakDebian gilt so auch für Sachen wie RHEL, SLES oder Rocky/AlmaLinux obwohl die im RPM statt DEB-Ökosystem beheimatet sind) oder den jeweiligen Entwicklungszweig (Debian Unstable, Centos Stream ) oder eine rolling release Distribution (wie ArchLinux oder Gentoo, OpenSuSe Tumbletweed) nehmen, die dafür auch ein größeres Risko an breaking changes haben.
Außerdem läuft man dann unter Umständen in das Problem, dass eine nicht über die Distribution installierte Software gerne eine neuere Libary hätte, die Software der Distribution dagegen weiterhin eine ältere. Ja, man kann das auch alles irgendwie hinkriegen, aber es wird dann halt irgendwann sehr frickelig.
Dagegen haben container den Vorteil, dass sie ja ihre Dependencies alle mitbringen und alles außerhalb ihrer Umgebung gar nicht berühren. Das hat mehrer Vorteile:
- Entwickler können sich sicher sein, dass ihr "bei mir geht es" in den meisten Fällen auch für die Endanwender funktionieren wird
- Man kann die Anwendung samt Abhängigkeiten "in einen Rutsch" aktualisieren
- Da bei docker/podman/kubernetes Containern Nutz- und Anwendungsdaten strikt getrennt sind, ist es trivial möglich bei Problemen den Container wegzuwerfen und neu zu erstellen, ohne Auswirkung auf die Daten
- Keine Probleme mehr durch schieflaufende Updates:
- Vor Update Backup der Nutzdaten machen
- container updaten und testen
- Test erfolgreich? Backup wegwerfen
- Test geht schief? Backup einspielen, alte Version der Container ausrollen
Das macht (gerade in großen Umgebungen!) das Leben deutlich einfacher. Nur kommt man dann irgendwann an den Punkt, wo man für diverse Container einen Haufen VMs (samt Overhead) betreibt. Könnte man das nicht alles in einer Umgebung laufen lassen? Theoretisch ja, alle auf einer VM oder Host, aber dann muss man weder wegen Security aufpassen. Das ist eines der Probleme, die kubernetes löst: Es schaltet mehrere Server zu einen Cluster zusammen, dessen Ressourcen über eine einheitliche API sicher (also mit sauberer Abgrenzung und Trennung voneinander) zur Verfügung gestellt werden. Das geht aber auch mit einer entsprechend gestiegenenen Komplexität einher, die gerade für kleine Operating-Teams nicht leistbar ist. Die Lösung dafür ist dann entweder die Leistung (als managed kubernetes) einzukaufen oder eben die Nummer kleiner (VMs mit docker/podman-Containern) zu fahren. Im Umkehrschluß gilt aber auch: Je größer die Umgebung wird, desto eher lohnt sich die Komplexität von kubernetes, weil man darüber dann auch Sachen abbilden kann, die eine rein auf vms mit docker/podman basierende Umgebung nicht oder nur mit Mehrwaufwand (man muss selbst Zeug entwicklen, was kubernetes schon gelöst hat) einher geht.
Mir ist eine Umgebung bekannt, wo insgesamt 400 VMs mit docker und mehr oder weniger identischen tomcat-Applicationservern laufen. Da ist mittelfristig geplant die Richtung kubernetes zu migrieren, eben weil diese 400 VMs von Hand zu managen auch schmerzhaft ist und am Ende des Tages die Verantwortlichen eigentlich keine Server betreiben möchten, sondern eben Fachanwendungen für bestimmte Verwaltungsprozesse zur Verfügung stellen. Außerdem kann man kubernetes auch direkt auf Servern installieren (gibt dafür eigene Distributionen), sodass man dann nicht mehr unbedingt einen Hypervisor wie ProxmoxVE oder vmware benötigt. Wenn der Großteil der Workloads eh in kubernetes läuft, kann man damit ordentlich Kosten sparen und behält dann den Hypervisor (stark reduziert) nur noch für die verbleibenden Legacy-/Windows-Anwendungen (sofern man die nicht über Kubernetes eigenen Virtualisierungsdienst in kubevirt) laufen lässt.
Anderes Beispiel: Kleine Firma hat sechs ITLer, man könnte diese dafür bezahlen selbst Kubernetes oder einen vmware/ProxmoxVE-Cluster zu betreiben. Dann hat man aber noch nichts gewonnen, außer dass man diesen Cluster hat. Es wäre vermutlich für die Firma besser sich einen Kubernetes- oder ProxmoxVE-Cluster als managed Dienst einzukaufen und die sechs ITler statt dessen dafür zu bezahlen Business-Logik auf Basis des managed Service zu entwickeln.
Kleiner Handwerksbetrieb, die "IT" gibt es eigentlich nur für das Office der Buchhaltung und envtl. damit die Monteure Einsätze im Außendienst über ihr Smartphone dokumentieren können. Da wäre Kubernetes oder auch nur eine eigene IT-Abteilung völlig drüber, aber ein vom Systemhaus des Vertrauens bereitgestelltes Office365 sowie ein vom selben Systemhaus aufgesetztes NAS mit einigen docker-Containern (paperless, frigate und co sind auch für kleine Unternehmen praktisch) aber trotzdem nötig.
..... Also erstmal beides genau angucken und eventuell IRGENDWANN umstellen. Für mich ist es keine wirklich Alternative alles einzeln zu installieren. Da ist man ja nur noch mit der Pflege beschäftigt.