Beratung: Umzug eines Server-Setups (Software)

[ShadowDragon]

Hi,

ich plane aktuell meinen Server umzubauen und bin am überlegen welche Software ich hierfür einsetzen kann. Aktuell ist es ein durcheinander von Docker Containern und Anwendungen in LXC Containern auf dem Proxmox System ist. Wobei Docker selbst auch in einem LXC Container läuft.
Hinzu kommen zich Netzwerk-Laufwerke (HDDs) vom NAS, welche ich dann in die einzelnen Container via bindmount durchgebe, einfach weil der Server (mit SSDs) zwar ausreichend Speicher für die Datenbanken und sowas wie den Minecraft Server hat, aber für alle Urlaubsfotos und Videos reicht es dann doch nicht mehr. ^^

Anwendungen:

• Jellyfin (mit Datenbank)
• Mealie (mit Datenbank)
• traefik als reverse proxy
• Minecraft
• Matrix & Element (mit Datenbank)
• pihole

Backup Location:
- lokales TrueNAS System, welches dann über Nacht die Daten aller wichtigen Geräte off-site sichert.

Hier stellt sich dann natürlich die Frage, wie ich am besten alle Daten umziehe und welche Software als Basis genutzt werden kann, also weiterhin Proxmox mit Containern oder vlt Kubernetes oder was es da sonst noch so gibt.

 

[snaxilian]

Kubernetes ist overkill, bringt viel administrativen Overhead mit und macht erst ab 3+ Systemen wirklich Sinn und Spaß.

Die Frage lautet: Willst du LXCs behalten oder kannst du komplett auf Docker umsteigen? Falls ja, irgendeine halbwegs schlanke und stabile Distribution deiner Wahl, Docker + Docker-Compose installieren, kostenlosen github/gitlab Account anlegen und dann los.
Deine compose files legst in einem privaten(!) github/-lab Repo ab, Credentials in ein extra env-file was z.B. mit auf dem NAS liegt und fertig.
Änderungen an der Config hast dank git versioniert, Credentials und persistente Daten, sprich Volumes oder Bindmounts, liegen auf dem NAS und werden so regelmäßig gesichert.

Wichtig: Bei laufenden Containern kann es je nach darin befindlicher Anwendung, zu Problemen kommen wenn du im laufenden Betrieb die Volumes weg sicherst. Also das Backup wird klappen aber der Restore unter Umständen nicht, z.B. wenn bei einem Container in dem eine DB läuft gerade eine Änderung an der DB gemacht wird und mitten drin das Backup läuft. Im besten Fall also entweder die Container kurz pausieren, Backup anstoßen, wenn Backup fertig, Container wieder laufen lassen.


Ansonsten stelle ich die ketzerische Gegenfrage: Warum willst du weg von Proxmox?

 

[ShadowDragon]

Kubernetes ist overkill, bringt viel administrativen Overhead mit und macht erst ab 3+ Systemen wirklich Sinn und Spaß.

Inwiefern bringt Kubernetes viel administrativen overhead mit? Also wodurch entsteht bei Kubernetes mehr overhead als bei proxmox?

Die Frage lautet: Willst du LXCs behalten oder kannst du komplett auf Docker umsteigen?

Alle Anwendungen die ich laufen habe oder laufen lassen werde, sind auf dockerhub verfügbar.

Ansonsten stelle ich die ketzerische Gegenfrage: Warum willst du weg von Proxmox?

Einerseits will ich mal etwas neues lernen und ausprobieren, andererseits bin ich mit dem Proxmox Setup nicht komplett zufrieden.
Mit Containern in Container, aber auch mit etlichen Kleinigkeiten die mir dort nicht gefallen, z.B. das handling von Netzwerk Laufwerken und deren paththrough in die Container.

Der Hauptgrund ist aber wohl, dass ich einfach mal was neues lernen will.

 

[snaxilian]

Proxmox ist vergleichsweise einfach zu installieren und zu administrieren da es bereits viel Komplexität vor dem User/Admin versteckt.

Das reine Kubernetes (k8s) ist da ein bisschen das Gegenteil. Ein unheimlich mächtiges Tool bei dem man vieles beachten muss. Ich kenne mehr als einen Konzern dessen IT/Devs glaubten es besser zu können oder spezielle Anforderungen zu haben... Nun ja inzwischen nutzen alle irgendwelche Kubernetes-as-a-Service bzw. Managed Kubernetes Lösungen^^
Außerdem ist k8s ausgelegt für Installationen mit mehreren Systemen. Klar kannst bei nur einem Server darauf single-master UND worker-node laufen lassen aber so wirklich "empfohlen" ist das nur für Testzwecke...

Du kannst natürlich auch abgespeckte oder fertige Lösungen wie z.B. k3s nehmen, das ist für 1-Server-Setups ausgelegt aber das hat andere Einschränkungen.

So oder so musst du sehr viel neu lernen und die Fehlersuche wird aufwendiger weil du ein deutlich komplexeres Setup plötzlich haben wirst ggü. einem Linux deiner Wahl und Docker (+Compose).

 

[ShadowDragon]

Dann wird es denke ich ein Linux System meiner Wahl mit docker/podman werden.

Hättest du noch eine Empfehlung bezüglich System Update Management und dem Update Management von den docker Containern? Da aktuell muss ich halt jedes Mal für jeden Container etc. nachschauen ob es ein Update gibt und was das ändert. Zudem gibt es zurzeit auch keine Trennung zwischen Production und Test, also jedes Update und jede Änderung landet direkt im Production System. -_-

 

[snaxilian]

System Update Management

Bei Debian, Ubuntu und Co. gibt's das Paket unattended-upgrades um z.B. Security Updates automatisch installieren zu lassen, bei fedora, rhel, centos/rocky/alma/oracle/usw. kann man dies ebenso konfigurieren und bei opensuse tumbleweed/leap kannst so etwas ebenso einrichten.
WICHTIG: Müssen aufgrund von Updates Dienste wie z.B. SSH oder Docker/Containerd/Podman neu gestartet werden oder das System selbst aufgrund eines Kernelupdates, so geschieht dies afaik nicht automatisch. Hier solltest du dir etwas skripten/automatisieren oder mindestens ein Alerting einrichten.

Update Management von den docker Containern

Watchtower oder Ouroboros fallen mir da spontan ein, bei beiden wird aktuell dringend nach Maintainern gesucht.
Denke daran: DockerHub hat ein rate-limit und ich würde es auch nur zur Prüfung machen ob es Updates gibt und dann Alerting. Neue Images direkt starten kann auch gerne schief gehen^^

Zudem gibt es zurzeit auch keine Trennung zwischen Production und Test, also jedes Update und jede Änderung landet direkt im Production System

Naja privat kann man das machen. Mit Docker geht sowas ja zum Glück schnell zurück zu drehen.
Wenn ein neues Image verfügbar ist, die Container stoppen, Volumes sichern, Container mit neuem Tag starten lassen, prüfen. Wenn kaputt, Tag wieder auf vorherige Version setzen und testen. Falls sich durch die neue Version etwas an den persistenten Daten geändert hat -> Volume aus Backup wieder herstellen und dann Container mit altem Tag starten lassen.

 

[ShadowDragon]

Naja privat kann man das machen.

Würde ich aber auch privat vermeiden wollen. Sicher ist sicher.

. Falls sich durch die neue Version etwas an den persistenten Daten geändert hat -> Volume aus Backup wieder herstellen und dann Container mit altem Tag starten lassen.

Je nach Backup Strategie ist dies bestimmt einfach. Bei meinem aktuellen proxmox System ist dies immer nervig, da das Backup auf LXC Ebene stattfindet indem Proxmox den Container zipped und auf den NAS schiebt. Dabei laufen alle Docker Anwendungen in einem LXC Container (um die maintance bezüglich Updates zu verringern, da ich somit weniger LXC Container aktualisieren muss neben dem Basis System und den docker Containern)

An den persistenten Daten ändert sich bei einem Update ganz bestimmt etwas. Bei den meisten Anwendungen die ich habe gibt es keine backwards compatibility der Daten außerhalb von bugfix Updates.

Neue Images direkt starten kann auch gerne schief gehen^^

Oh ja. Damit habe ich Erfahrung. ^^

Bei Debian, Ubuntu und Co. gibt's das Paket unattended-upgrades um z.B. Security Updates automatisch installieren zu lassen

Interessant. Dies ist mir tatsächlich neu. Bei Manjaro und Proxmox muss ich dies manuell installieren und Neustarten (im Falle von Server nach Möglichkeit wenn niemand drauf zugreift xd)

WICHTIG: Müssen aufgrund von Updates Dienste wie z.B. SSH oder Docker/Containerd/Podman neu gestartet werden oder das System selbst aufgrund eines Kernelupdates, so geschieht dies afaik nicht automatisch. Hier solltest du dir etwas skripten/automatisieren oder mindestens ein Alerting einrichten.

Ah, ok. Dann muss ich mal schauen wie man solche Sachen abfragen kann.

 

[snaxilian]

An den persistenten Daten ändert sich bei einem Update ganz bestimmt etwas. Bei den meisten Anwendungen die ich habe gibt es keine backwards compatibility der Daten außerhalb von bugfix Updates.

Deshalb ja Backups der Volumes anlegen BEVOR eine neue Version eines Docker/Podman/whatever Containerimages gestartet wird. Ist da irgendwas mit kaputt wird das vorherige Image zusammen mit dem wieder hergestellten Backup des Volumes gestartet.
Funktionierte wunderbar als Nextcloud und MariaDB >10.6 nicht mehr miteinander sprechen wollte.

Bei Manjaro

Naja Nischen-OS halt...^^ Aber für Arch und seine Krabbelgruppe von Distri-Sprösslingen wird es vermutlich ähnliches geben.

Proxmox

Ist auch "nur" ein Debian als Unterbau. Da kannst also genau so ein unattended-upgrades nachträglich installieren und einrichten. Da klingelt aber in meinem Hinterstübchen irgendwo, dass Proxmox da Warnhinweise bei Upgrades eingebaut hat, also so ganz unattended ist das dann nicht mehr aber das ist ja nix was man nicht wieder raus basteln kann.

 

[andy_m4]

WICHTIG: Müssen aufgrund von Updates Dienste wie z.B. SSH oder Docker/Containerd/Podman neu gestartet werden oder das System selbst aufgrund eines Kernelupdates, so geschieht dies afaik nicht automatisch. Hier solltest du dir etwas skripten/automatisieren oder mindestens ein Alerting einrichten.

Dazu werfe ich einfach mal needrestart in die Runde:
https://packages.debian.org/bullseye/needrestart
bzw.:
https://github.com/liske/needrestart