Überlegungen zum Betrieb von Diensten im Jahr 2025
Gedanken zu Betriebssystemen, Containern, Orchestrierung, Deployement und Backup zum Betrieb von Diensten auf Servern im Internet. Dieser Artikel ist Teil der Betrieb von Diensten im Jahr 2025 Reihe. Seit nun über 20 Jahren betreibe ich Dienste auf virtuellen Servern im Internet und zirka alle fünf bis sieben Jahre wird es Zeit sich Gedanken darüber zu machen wie man diese betreibt. Um ehrlich zu sein: Irgendwann hat man eine Uptime von annähend zwei Jahren und traut sich nicht ein Update inklusive Neustart durchzuführen. Da kann man doch gleich die Dienste nacheinander migrieren und es ein Stück besser machen. Ich habe es trotztem getan. Ich habe eine Mail von meinem Hoster erhalten, dass ein Neustart des Hostsystems erforderlich ist. Nach mehr als 670 Tagen Uptime ist ein Neustart unvermeidlich! Ich habe die Gelegenheit genutzt, ein Snapshot erstellt und es ausprobiert: Und einige weitere Punkte die im Arch Linux News Archives erwähnt wurden. Auch Kurz und knapp habe ich folgendes getan: Alles funktioniert wie gehabt. Die Hauptprobleme bestanden aus veralteten Ansible Tasks und Änderungen die ich in der Vergangenheit direkt auf dem System vorgenommen, welche dadurch nicht im Ansible Playbook waren. Hätte ich die manuellen Änderungen im Ansible Playbook gehabt, wie es sein sollte, dann wäre der Zeitaufwand überschaubar gewesen. Aktuell verwende ich auf den virtuellen Servern Arch Linux als Betriebssystem, mit komplett verschlüsselter Speicher (Festplatte/SSD). Die Dienste laufen in Docker Containern und verwaltet wird das ganze mit Ansible. Backups werden täglich mit BorgBackup erstellt. Aus meiner Sicht eine gute Grundlage und man könnte das sicherlich noch einige Jahre weiter so betreiben. Hätte ich bloß disziplinierter das System und die Container auf aktuellem Stand gehalten. Was möchte ich: Da alle Dienste mittlerweile in Containern laufen ist das Betriebssystem fast egal, hier wird es nur mit komplett verschlüsselten Speicher interessant. Warum alles verschlüsseln? Eigentlich nur falls bei meinem Hoster - aus welchen Gründen auch immer - das Abbild abhanden kommt. Automatische Updates des Betriebssystems und verschlüsselter Speicher erfordert beim Neustart manuelle Intervention zur Eingabe des Passworts und klappt auch gut mittels ssh. An dieser Stelle möchte ich kurz auf mögliche Betriebssysteme eingehen, mit denen ich bereits Erfahrungen gesammelt habe, oder die mir interessant für diesen Einsatzzweck erscheinen. Dadurch das automatische Updates von Arch Linux offiziell nicht unterstützt sind, fällt es aus der Auswahl heraus. Wenn ich es wirklich will, wäre eine Option automatisch nach n Tagen Uptime mich täglich mit Mails zu nerven. Zumindest ist man mit Arch Linux immer auf dem aktuellsten Stand. Mit Debian und auch Ubuntu habe ich bisher auch keine negativen Erfahrungen gesammelt. Debian/testing habe ich vor Arch Linux jahrelang privat genutzt und Ubuntu auch im beruflichem Umfeld. Dort gibt automatische Updates mit UnattendedUpgrades. In Kombination mit einem Cron Job, der eine Mail sendet wenn ein Neustart erforderlich ist (Password Eingabe für die Verschlüsselung), läuft so ein Setup ohne großen manuellen Eingriff. Was mich bisher an Debian/Ubuntu gestört hat, ist die Aktualität von Paketen. Die Docker und Podman Versionen hinken relativ weit dem Upstream hinterher. Was insbesondere bei Podman sehr genervt hat, da viele Verbesserungen in den letzten Versionen dazu kamen. Alle zwei Jahre stünde dann ein Distributionsupgrade an, was mit einen verschmerzbaren zeitlichen Aufwand verbunden ist. In meiner beruflichen Laufbahn sind wir damit auch gut gefahren. Bei Fedora Core OS handelt es sich um ein minimales für Container optimiertes Betriebssystem. Automatische Updates sind standardmäßig aktiv und es gib die Möglichkeit Updates im Fehlerfall rückgängig zu machen. Ich habe es für mein OctoPrint Server im Einsatz. Dort läuft nur der OctoPrint Container, welcher bei jedem Start aktuell heruntergeladen wird. Die automatischen Updates habe ich deaktiviert, da ein Neustart während des Druckvorgangs unpraktisch ist. Da ich nicht jeden Tag drucke ist das okay für mich. Vielleicht investiere ich etwas Zeit und mache den Update Dienst davon abhängig ob gerade etwas gedruckt wird. Das Aufsetzen eines Systems erfolgt durch eine Ignition Konfiguration in der beschrieben wird, wie das System aussehen soll. Dort können auch Dienste direkt integriert werden. Dadurch sehe ich zwei Möglichkeiten Systeme zu Verwalten: Alles in der Ignition Konfiguration. Das würde bedeuten, bei jeder Änderung wird das System neu aufgesetzt, aber die Daten ( Basis Setup mit der Ignition Konfiguration und den Rest via Ansible oder anderen Tools die den Zustand des Systems und optional der Dienste beschreiben. Der zweite Ansatz scheint mir am sinnvollsten zu sein. Hier bräuchte ich einen tang Server für die LUKS Verschlüsselung und die restlichen Geheimnisse wie Passwörter, Schlüssel usw. könnten dann weiterhin unter der Verwendung von Ansible Secrets verwaltet werden. Mit NixOS habe ich noch keine Erfahrungen machen können. Der deklarative Ansatz macht es aus meiner Sicht interessant. Hier stellt sich die Frage wie weit man gehen kann und wie es dort mit automatischen Updates aussieht. Noch ein paar weite, die einen Blick wert sein könnten: Bisher liegt meine Präferenz bei der Kombination aus Fedora Core OS und Ansible. Es könnte im Zusammenspiel mit tang auf dem ersten Blick sogar komplett ohne manuellen Eingriff neu starten. Hier wäre dann der tang Dienst die Achillesferse und müsste ja auch irgendwo laufen, wo die Daten sicher sind. Ubuntu/Debian ist eine verlässliche Option und mit UnattendedUpgrades ist man stets auf der sicheren Seite. Die Vergangenheit hat gezeigt das Patche zum stopfen von Sicherheitslücken immer schnell verfügbar waren und zuverlässig durch die Installation von Aktualisierungen geschlossen wurden. Andere Betriebssysteme sind sicherlich ein Blick wert, allem voran NixOS. Hier bin ich neugierig wie es verhält. Hier würde ich gerne den Wechsel von Docker zu Podman vollziehen. Lokal nutze ich Podman schon seit einigen Jahren und bin begeistert. Standardmäßig ist es rootless, läuft also ohne root Berechtigungen und benötigt nicht Mal einen Dienst (Daemonless). IPv6 funktioniert einfach mit Podman, was zumindest mit Docker noch vor einigen Jahren einfach schmerzvoll war. Vielleicht ist die Situation heute besser. Braucht man das überhaupt im kleinen Maßstab oder lohnt sich das erst ab mehr als drei Servern? Bisher hatte ich es nur benutzt, aber noch nicht selber betrieben. Ein paar Optionen die ich mir vielleicht anschauen sollte: Ohje, je nachdem wie das Setup am Ende aussieht gibt es wieder viele Möglichkeiten. Vor allem wenn man K8s verwendet: Tatsächlich finde ich einen GitOps Ansatz reizvoll. Doch was macht man wieder mit dem leidigen Thema Geheimnisse (Passwörter, Schlüssel usw.)? Bisher verwende ich BorgBackup in Kombination mit borgmatic. Einmal aufgesetzt funktioniert es zuverlässig und auch das Wiederherstellen von Daten hat vor kurzem ohne Probleme geklappt. Man soll ja auch über den Tellerrand schauen und dabei bin ich vor kurzem auf restic in Zusammenspiel mit resticprofile gestoßen.Inhaltsverzeichnis
Einleitung
# pacman -Sy
# pacman -S archlinux-keyring
# pacman -Su
pacman weist während des Updates darauf hin.Betriebssystem
Arch Linux
Debian / Debian Derivate
Fedora Core OS
/var) bleiben jeweils erhalten. Die Ignition Konfiguration muss dann auch irgendwo abrufbar sein. Passwörter, Schlüssel usw. sollten aber nicht direkt sichtbar sein und hierfür sind dann weiter Dienste notwendig:NixOS
Weitere
Zusammenfassung
Container Engine
Container Orchestrierung
Deployment
Backups
Nächste Schritte