OwnVPS – eine Plattform, die ich selbst verstehen und betreiben will

Worum geht es?

Wie bringe ich Änderungen kontrolliert in Produktion? Woher weiß ich, welcher Stand gerade läuft? Was passiert, wenn etwas schiefgeht? Und ist ein Backup wirklich ein Backup, wenn ich nie ausprobiert habe, ob ich es wiederherstellen kann?

Aus diesen Fragen ist mein OwnVPS entstanden. Eigentlich sollte er zunächst nur eine Heimat für meine persönlichen Websites und kleinere Projekte werden. Inzwischen ist daraus eine kleine Plattform geworden, auf der ich vieles bewusst so umsetze, wie ich mir einen zuverlässigen Betrieb vorstelle: Änderungen sind nachvollziehbar, Deployments reproduzierbar, Dienste werden überwacht und für den Fehlerfall gibt es einen getesteten Weg zurück.

Warum ein eigener VPS?

Natürlich könnte ich meine persönliche Website auch bei einem klassischen Webhoster betreiben. Das wäre vermutlich sogar einfacher. Mich reizt aber gerade die andere Richtung: die gesamte Strecke selbst zu verstehen – vom DNS-Eintrag über Reverse Proxy und Container bis zum Deployment und Monitoring.

Selbst betreiben heißt für mich dabei nicht, alles selbst hosten zu müssen. Ein gutes Beispiel ist die E-Mail-Adresse meiner Domain. Natürlich könnte ich auch noch einen Mailserver auf den VPS stellen. Technisch wäre das interessant, betrieblich würde ich mir damit aber eine ziemlich anspruchsvolle zusätzliche Baustelle schaffen. Deshalb läuft die Mail bewusst bei einem spezialisierten Anbieter.

Solche Entscheidungen gehören für mich genauso zum Projekt wie Docker oder Linux. Die technisch aufwendigste Lösung ist nicht automatisch die beste.

Vom Commit bis zum laufenden Release

Änderungen an meinen Anwendungen beginnen im Git-Repository. Der produktive Stand soll sich daraus eindeutig ableiten lassen – und nicht davon abhängen, welche Datei irgendwann einmal per Hand auf den Server kopiert wurde.

Aus einem konkreten Git-Commit entsteht deshalb beim Deployment ein unveränderliches Release. Vor dem eigentlichen Wechsel wird die Konfiguration geprüft, benötigte Container-Images werden vorbereitet und das neue Release zunächst in einem Dry-Run gestartet.

Danach ist für mich aber noch nicht Schluss. Der interne Dienst wird geprüft, die öffentlich erreichbare Website wird mit dem erwarteten Release verglichen und auch das Monitoring muss einen erfolgreichen Zustand melden. Erst dann wird dieser Stand als neuer „Last Known Good“ festgehalten.

Dadurch weiß ich nicht nur, dass ich etwas deployed habe. Ich kann auch nachvollziehen, was gerade produktiv läuft und ob genau dieser Stand von außen tatsächlich funktioniert.

Backup heißt Wiederherstellen können

Bei Backups wollte ich von Anfang an vermeiden, einfach nur beruhigend Daten irgendwohin zu kopieren. Entscheidend ist für mich die andere Richtung: Wie bekomme ich das System zurück, wenn tatsächlich etwas kaputtgeht?

Deshalb gehören zu OwnVPS lokale Restore-Punkte ebenso wie verschlüsselte Offsite-Backups in einem S3-kompatiblen Object Storage. Die Backup-Läufe werden überwacht, der letzte erfolgreiche Lauf wird festgehalten – und Wiederherstellungen werden tatsächlich ausprobiert.

Eine Erfahrung aus dem Betrieb von Systemen bringt das für mich ziemlich gut auf den Punkt: Ein erfolgreicher Backup-Job beweist zunächst nur, dass der Backup-Job erfolgreich war. Ob daraus wieder ein funktionierendes System wird, ist eine andere Frage.

Bewusst unspektakulär

Die technische Basis von OwnVPS ist bewusst eher unspektakulär: Docker Compose für die Anwendungen, Caddy als Reverse Proxy, Uptime Kuma fürs Monitoring und Restic für die Backups.

Das ist kein Zufall. Ich möchte den Server auch in zwei Jahren noch verstehen können, ohne zuerst rekonstruieren zu müssen, welches damals gerade angesagte Werkzeug ich unbedingt ausprobieren wollte.

Neue Komponenten kommen deshalb nicht hinzu, weil sie interessant aussehen oder gut in eine Architekturzeichnung passen. Sie sollen ein konkretes Problem lösen. Dasselbe gilt für Automatisierung: Sie soll wiederkehrende Arbeit sicherer und reproduzierbarer machen – nicht einfach nur zusätzliche Technik erzeugen, die danach ebenfalls gewartet werden muss.

Wie geht es weiter?

Inzwischen ist die Plattform stabil genug, dass der Blick stärker auf das wandern kann, was darauf entstehen soll. Diese Website ist eine der ersten sichtbaren Anwendungen davon. Mit Balken & Bytes soll ein Ort dazukommen, an dem ich technische Themen und Projekte ausführlicher dokumentieren kann.

Gleichzeitig gibt es bereits Ideen für die Verbindung mit meiner Infrastruktur zu Hause. Messwerte, Smart Meter, Energie und Hausautomation laufen dort auf lokalen Systemen. Perspektivisch möchte ich ausgewählte Daten und Dienste sinnvoll mit OwnVPS verbinden – allerdings ohne deshalb mein privates Heimnetz zu einem öffentlichen Experiment zu machen.

Genau darin liegt für mich inzwischen der eigentliche Reiz des Projekts: OwnVPS ist nicht fertig, weil nichts mehr zu tun wäre. Es ist fertig genug, dass darauf neue Dinge entstehen können.