Ich gebe es zu, ich bin Server-Messi. Spätestens seitdem Hetzner mit seinem Cloud-Angebot durchgestartete und man nur so drei Euro für eine CPU und ein bisschen Speicher zahlte, fing ich an für alles mögliche eine neue VM anzulegen. Zuletzt versuchte ich vor etwa einem Jahr dem Chaos Herr zu werden, leider ohne größeren Erfolg. Am Ende hatte ich noch einen Server mehr.

Aktuell sind es ca. 15 und ich zahle dafür um die 50€ im Monat. Denn, wie alles, sind auch die VMs teurer geworden, spätestens seitdem Hetzner für die kostbaren IPv4-Adressen nochmal extra kassiert. Zu recht natürlich. Ich redete es mir immer schön, in dem ich mir sagte, dass es ewig dauern würde, bis sich der Arbeitsaufwand amortisieren wird. Was sind schon gesparte 5€ für einen Server im Monat! Macht man sich die Mühe und multipliziert das mal mit 12 kommt man allerdings schon auf 60€ und das nochmal mit der Anzahl der Server multipliziert, die man abstellen könnte. Plötzlich kommt man auf einen beträchtlichen Betrag, den man sparen könnte. Davon könnte man sich einige Packungen Kippen kaufen, wenn man rauchen würde!

In diesem Post erzähle ich euch nun ein wenig davon, wie ich dieses Projekt angegangen bin, welche Probleme ich hatte und was das Ergebnis ist. Natürlich habe ich währenddessen mal wieder zu wenige Notizen gemacht und schreibe alles schnell in einer Nacht-und-Nebel-Aktion zusammen, daher werden sicher ein paar Sachen fehlen. Vielleicht ergänze ich sie später, wenn sie mir einfallen!

Status Quo

Warum hast du eigentlich so viele VMs, Philipp, könnte man mich jetzt fragen. Meine Antwort: Weil ich gerne alles mögliche selbst entwickle und auch hoste. Klar hat sich in den letzten Jahren viel ergeben und ich könnte auch alles zu fly.io oder Vercel posten, aber ich hatte schon immer gerne alles bei mir. Aktuell geht es um folgende Services:

• speiseplaner, meine Rezepte-Verwaltung
• toller.link, mein Bookmarking-Service
• mey, mein last.fm-Klon
• Compass zum sammeln meiner Location-Daten
• dieser Blog
• diverse statische seiten aus Kleinst-Projekten (salatgenerator.de, termine.baby, waldhauer.solutions)
• ein paar Wordpress-Installationen
• diverse Scripte, die Webseiten crawlen
• meine Gitea instanz
• meine BetterJournal-instanz
• meine Budget-App

Ziel

Am Ende will ich vor allem eins: Weniger Geld an Hetzner zahlen und weniger Server haben, um die ich mich kümmern muss. Abgesehen davon, gab es auch noch folgende Bedenken, die ich aus der Welt schaffen wollte:

Security

Wie das oft so ist, hatte ich die meisten Server einfach hochgefahren, meine Software installiert und geguckt ob alles klappt. Wenn alles lief, fasste ich die Server meistens nicht mehr an. An und für sich sind 99% der Server auch einfach ohne externen Traffic und daher wahrscheinlich auch wenig Angriffen ausgesetzt und die VM von dem Blog hier z.B. bekam auch etwas mehr Liebe, wie z.B. ab und zu mal ein System-Update.

Trotzdem war das eine meiner größten Gründe für die Server-Konsolidierung: Ich wollte mich insgesamt einfach um weniger Betriebssysteme kümmern müssen.

Backups

Bisher gab es keine wirklich durchdachte Backup-Strategie. Die VMs bei Hetzner hatten fast alle das Backup-Feature aktiviert, dass jeden Abend automatisch ein Backup zieht. Bei manchen hatte ich es aber auch vergessen. Das Homelab war bisher überhaupt nicht gesichert und allgemein gab es auch keine Backups außerhalb des Hetzner-Rechenzentrums, oder welche an die ich vernünftig dran kam — die automatisieren VM-Backups lassen sich nämlich nur in neue VMs konvertieren und nicht z.B. einfach als .zip herunterladen.

Probleme

Bei diesem Großprojekt stieß ich leider auf diverse Hürden, was unter anderem zu einer Verzögerung von mehr als einem Jahr führte. Die größten waren die Folgenden:

Aufteilung

Ich wollte die vielen VMs auf jeden Fall um einiges reduzieren. Im Idealfall habe ich am Ende nur noch zwei Server um die ich mich kümmern muss: Einen im Homelab und einen bei Hetzner. Beide sind gleich aufgesetzt, damit man sich nicht umgewöhnen muss.
Im Laufe der Umsetzung dieses Projektes merkte ich allerdings, dass das nicht komplett klappen wird. Hier und da gibt es mal einen Server, auf den noch jemand anderes Zugriff braucht, da hab ich keine Lust, das zu integrieren. Oder es gibt Uralt-Software, die ich lieber nicht anfasse. Never touch a running system und so.

Es wird also am Ende nicht komplett mit zwei Servern enden.

Motivation

Wie man daran merkt, dass ich zuletzt vor mehr als einen Jahr drüber schrieb und exakt nichts an der Situation verbesserte, war meine Motivation nicht so hoch. Ich stand vor mehreren Roadblocks. Ich hatte keine Lust diverse Software herumzukopieren, die Tatsache, dass manche Sachen sicher noch alte PHP-Versionen brauchen werden, nervte mich auch. Klar, man könnte alles in Docker packen, aber ich war nicht überzeugt und alles hatte hier und dort seine kleinen Hürden, über die ich zu springen noch nicht bereit war.

Dieses Jahr ergaben sich aber ein paar Dinge, die dazu führten, dass ich endlich alle nötigen Tools beisammen hatte und auch genug Energie um das Thema einmal komplett durchzufegen und nicht halb-beendet aufzugeben, mit dem Ergebnis einen weiteren Server für diverse monatliche Euros herumliegen zu haben.

Zum Einen habe ich durch ein Freelance-Projekt viel Kontakt zu TailwindCSS gehabt und mich tiefer in Livewire und Laravel einarbeiten können. Nun könnte man sich fragen, was ein CSS-Framework mit Servern zu tun hat, aber das ist ganz einfach. Durch die Kombi hatte ich einfach extreme Lust, die Tools, die bisher auf ihren eigenen Servern liefen, bei denen ich etwas Angst hatte, sie umzuziehen, weil sie z.B. uralte PHP-Versionen benutzten, neu zu schreiben. Der meiste Kram war ja nie besonders aufwändig. Andere Sachen waren zu aufwändig gewesen und mit unnützen Features vollgestopft. Zeit aufzuräumen!

Davon abgesehen konnte ich mich auch endlich mit Docker anfreunden. Bei meinem Sonos-Fernsteuer-Projekt freundete ich mich schon damit an, einfach den eingebauten PHP-Development-Server zu benutzen und mir so eine komplexere Docker-Struktur mit php-fpm und nginx zu sparen. Außerdem lernte ich über Docker Volumes und probierte Coolify aus um herauszufinden, dass ich das gar nicht brauche.

Eine der Sachen, die mich auch immer davon abhielten, die Umstellung anzugehen, war mein eigener Ehrgeiz die Server ganz besonders sauber mit Ansible oder einem anderen System aufzusetzen. Klar, das wäre jetzt auch kein riesiger Aufwand, aber doch ist das etwas, womit ich in der Freizeit eigentlich nichts zu tun haben will. Dadurch, dass jetzt allerdings einfach alles in Docker stattfindet, ist das Setup eines neuen Servers aber so einfach, dass ich mir nur ein paar kleine Notizen machen musste, um ein gleichwertiges System herzustellen. Da ich nicht davon ausgehe, dass es ständig passieren wird, muss ich mir dafür wirklich kein Ansible Playbook oder Bash-Script bauen.

Vom Hundertsten ins Tausendste

Natürlich passierte es mir andauernd, dass ich vom schnellen und geraden Weg abkam und mich in einem Detail verlor. Wie soll man das auch verhindern, wenn man direkt drei, vier Projekte neu implementiert. Dazu kam, dass ich auch noch die DNS-Einträge bei Hetzner zusammenführen wollte, also auch noch ständig in einem anderen Tool unterwegs war, was auch noch teilweise mit diversen Wartezeiten verbunden war. Zwischendurch schrottete ich noch die MX-Einträge und konnte keine E-Mails empfangen, auch nicht besonders spaßig, oder dem Erreichen eines Ziels zuträglich.

Dieses Gif von Heisenberg, wie er versucht eine Glühbirne zu wechseln, ist eines meiner Lieblingsmemes und beschreibt sowohl dieses Projekt, als auch mein Leben sehr gut.

Vorgehen

Zu allererst machte ich mir mal eine Liste von all dem Kram, den ich so auf meinen Servern habe und was wo liegt. Danach priorisierte ich es so, dass ich mit einer Klappe immer möglichst viele Fliegen auf einmal schnappen kann — vor allem die Fliegen, die am teuersten waren. In der Priorität A waren so zum Beispiel sämtliche statische Seiten und eigentlich alle Services, die ich nur selber benutze. Rezepte-Sammlung, Linksammlung, etc. Dabei handelte es sich immerhin schonmal um 7 Server und damit ungefähr 21 Euro potentielle Ersparnis!

Pro Server lief es ungefähr so ab:

1. Gucken, ob ich mich überhaupt noch einloggen kann.
2. Einloggen und im Dateisystem gucken, ob auf dem Server noch mehr ist, als ich vermutet habe. Gerne habe ich noch einzelne PHP-Skripte im Home-Verzeichnis, die obskure Dinge per Cronjob erledigen.
3. Wenn vorhanden, die MySQL-Datenbank dumpen, alle Dateien zippen und herunterladen.
4. Server vorsorglich mal abschalten, um herauszufinden, ob irgendwas explodiert, wenn der Server nicht mehr da ist. Ich machte das mit Absicht schon vor dem Umzug, damit ich mehr Zeit habe, herauszufinden, ob was kaputt ist. War jetzt nicht schlimm, wenn ich zwei Tage nicht auf die Rezeptesammlung kam.
5. Schauen, ob sich die Applikation auf SQLite umbauen und in einen Docker-Container stecken lässt, ansonsten kurz neu implementieren. Hier war sehr viel potential für lange Detours.
6. Entscheiden, auf welchen Docker-Server es kommt, docker-compose.yml anlegen, DNS-Einstellungen ändern, hochladen, freuen.
7. Alten Server löschen.

Setup der Docker-Systeme und andere Tools

Doch zu allererst musste ich natürlich das machen, was ich am Liebsten mache: eine neue VM bei Hetzner klicken. Ich entschied mich für ein CPX21. Drei Kerne, vier GB RAM, für 8,39€ im Monat. Ziehe ich die von den eingesparten 21€ ab, bleiben mir also immerhin 12,61€ Ersparnis. Wahrscheinlich würde alles auch mit zwei Kernen und 2GB RAM laufen, aber naja. Man muss es ja nicht untertreiben.

Das Setup war eine der Sachen, die mich ja, siehe im Abschnitt Motivation, lange davon abhielten anzufangen, weil ich die ganze Zeit perfekt sein wollte und alles mit Ansible erledigen wollte. Das gab ich auf und plötzlich flutschte es! Das Setup ist aber auch eigentlich ziemlich einfach.

• User anlegen, Public Key hinterlegen, sudo konfigurieren, root-login unterbinden
• Docker, Tailscale und nginx installieren
• Restic konfigurieren
• Äh, fertig.

Tailscale

Ich nutze Tailscale, damit der Server nicht über das öffentliche Netz per SSH erreichbar ist. Dazu habe ich einfach Tailscale aufgesetzt und sshd nett mitgeteilt, bitte nur auf dem entsprechenden Interface zu lesen. Per Tailscale ACL habe ich noch genauer konfiguriert, welche Geräte nun wie in meinem Privatnetz kommunizieren dürfen, aber dafür gibt es nochmal einen eigenen Post.

Ich nutze aktuell noch nicht das Tailscale SSH-Produkt, das habe ich noch nicht ganz… verstanden, bzw. mich noch nicht genug damit beschäftigt. Aktuell klappt das mit meinem Weg ausreichend gut.

Docker

Die Docker-Konfiguration habe ich nicht groß angefasst. Eines Abends kam mir mal die Idee, dass es sicher total toll wäre, alle Daten auf ein Volume zu legen, statt direkt in der VM zu hosten. Falls ich mal schnell mehr Speicher brauche, oder die VM ranzig wird und ich alles schnell umhängen will.

Daher habe ich also ein Volume erstellt (erstmal nur 20GB, und damit kleiner als der Speicher, den die VM eigentlich hat, haha) und Docker gesagt, dass es alles unter /docker/data ablegen soll, statt in /var/lib/docker.

Wie schon gesagt, benutze ich keine all-in-one Supersoftware um alles in einem schönen Interface zu managen. Also zumindest auf dem öffentlichen Server nicht. Ich habe mir für jedes Projekt eine docker-compose.yml in /docker/prod/$url abgelegt.

Docker (Homelab)

Wie schon erwähnt gehe ich im Homelab einen etwas anderen Weg. Dort benutze ich nginx Proxy Manager. Das kommt direkt als Docker-Container daher und bietet ein schönes Interface, mit dem man quasi mit ein paar Klicks die nginx-Konfigurationen anlegen kann. Ich wollte das im Homelab, wo ich eh ein etwas einfacheres Setup habe mal ausprobieren und es gefällt mir ganz gut.

nginx

Ja, nginx ist auf dem Server direkt installiert und nicht im Container. Wahrscheinlich eigentlich Quatsch, da ich sicher eine viel neuere und bessere Version benutzen könnte, statt dem uralt Debian-Paket. Habe ich jetzt noch nicht genauer drüber nachgedacht, könnte man aber mal angehen.

Man könnte sich allgemein fragen, warum ich nginx benutze und nicht etwas cooles wie Caddy oder… Apache. Ich hatte mir Caddy mal kurz angeschaut, als ich eine Art automatisiertes Deployment-Tool baute. Die Tatsache, dass es sich selber um SSL-Zertifikate kümmert ist natürlich bestechend, aber mir hat irgendwas an der Konfigurations-API einfach nicht gefallen.

Weil ich natürlich trotzdem keine nginx Konfigurationen selber anlegen oder herumkopieren will, habe ich mir dafür natürlich ein Script geschrieben. Um genau zu sein war das auch sowieso eine der grundlegenden Punkte, warum ich endlich diese Konsolidierung und Modernisierung meiner Infrastruktur machen wollte, ich wollte etwas haben, wo ich mit einem Klick etwas hochladen kann, was sofort unter einer Domain mit SSL verfügbar ist, ohne dass ich mich per SSH einloggen muss. Quasi als würde ich Netlify benutzen, nur mit Self-Hosting!

Johnny Depploy

Schon vor Monaten baute ich mir ein Bashscript, mit dem ich statische HTML-Dateien hochladen und entsprechend versorgen konnte. Als ich von Laravel Zero las, dachte ich mir, das es eine perfekte Möglichkeit ist meine 500 Byte große Bashdatei gegen einen vendor-Ordner mit 2.000 Dateien auszutauschen. Spaß beiseite, natürlich war es auch ein enormer Produktivitätsboost, einfach die bekannten Laravel-Sachen benutzen zu können. Es gefällt mir! Aber natürlich, muss man zugeben, dass es für die paar Befehle vollkommen übertrieben ist. Naja.

Jedenfalls kann ich nun depploy im Projektverzeichnis machen, und sofern eine .depprc vorhanden ist, die z.B. den Domainnamen enthält, macht das Script folgendes:

• Wenn es eine statische Seite ist:
  • Ordner anlegen und Dateien per rsync übertragen
  • nginx-Konfiguration aus einem Template erzeugen
  • Per acme.sh SSL-Zertifikate erstellen
  • nginx neu laden
• Wenn es ein Docker-Projekt ist
  • Ordner anlegen und Dateien per rsync übertragen
  • docker compose up -d
  • nginx-Konfiguration aus einem Template erzeugen
  • Per acme.sh SSL-Zertifikate erstellen
  • nginx neu laden

Meistens funktioniert alles sogar!

Restic

Backups waren ja ein großes Thema. Ich habe mich hier für restic entschieden, das jede Nacht einen Snapshot an eine Hetzner Storage Box schickt. Die Konfiguration war super einfach und bisher läuft es. Was ich noch bauen muss ist, dass meine NAS sich regelmäßig einen aktuellen Stand von der ganzen Sache herunterläd. Ich wollte ja davon weg, dass alle Backups nur im Hetzner-Netz liegen.

Umzüge im Detail

Weil dieser Post noch nicht lang genug ist, folgt hier jetzt noch ein Kommentar zu quasi jeder einzelnen Software, die ich umgezogen habe! Wie schon erwähnt, habe ich einen Großteil meiner Sideprojects dabei neu entwickelt. Es juckte mir einfach so ein den Fingern, alles auf einen neuen Stand zu bringen und mit Tailwind hübsch zu machen.

Die Auflistung erfolgt ungefähr in Umzugsreihenfolge. Nicht, dass es einen Unterschied machen würde.

Gitea

Als Private Repos auf Github Geld kosteten zog ich einigen Kram in eine eigene Gitea-Instanz, die einfach vor sich hin lief. Mittlerweile benutze ich es für fast alles und nutze Github nur noch als zusätzlichen remote.

Gitea lief eh schon als Docker-Container, der Umzug war also relativ easy. Die Daten rüberkopieren und fertig. Zusätzlich führte ich noch einen Switch zu Forgejo durch, dem Fork von Gitea, aus irgendwelchen Gründen, die mich nicht wirklich interessieren.

compass

Seitdem Moves.app nicht mehr am Start war (wie viele Blogposts enthalten bitte diesen Satz?) verließ ich mich für das Aufzeichnen meiner Locationdaten auf die Softwarelösung von Aaron Parecki. Overland auf dem iPhone und Compass auf dem Server. Funktionierte auch super, nur gefielen mir zwei Sachen nicht: Compass ist eine uralte Lumen-App und Lumen machte bei mir bisher nur Probleme und die Daten waren blöd als Flatfiles gespeichert. Beide Punkte führten dazu, dass ich mich nie dazu durchringen konnte, ein paar Features einzubauen, die ich gerne gehabt hätte. Zum Beispiel, dass die getrackten Locations etwas schöner zusammengefasst dargestellt werden, wie damals in Moves halt. Man merkt, dass ich dieser App immer noch nach trauere, oder?

Ich erfand also schnell konpasu, was letztendlich nur das ist, was raus kommt, wenn man Compass in Katakana schreibt und wieder in lateinische Buchstaben übersetzt. Kreativ.

Dazu kam, dass ich mit Midjourney anfing und auf die Idee kam, mir eine süße Illustration für die App zu bauen. Eine Sache, die sich über alle folgenden Sideprojects ziehen wird und eine meine Lieblingssachen in den letzten Jahren.

Naja. Ich versuchte es auf jeden Fall sehr lean zu halten. Eine Kartenansicht und ein Nachbau der API, damit die iOS-App weiter fröhlich Daten senden kann, die nun in einer SQLite-Datenbank gespeichert werden. Die ganzen alten Daten habe ich bisher nicht importiert, da ich sie dabei direkt Bereinigen wollte. Nach ein paar Stunden merkte ich allerdings, dass ich mich da völlig in ein Hasenloch vertiefe, aus dem es so schnell keinen Ausweg geben wird. Daher lud ich die bisher funktionierende App hoch und seit ein paar Wochen schon, sammelt sie fleißig weiter Daten, bis ich mal Lust habe, mich um sie zu kümmern.

Konpasu ist außerdem im Homelab gehosted und wird vom öffentlichen Server nur durchgereicht. So sind meine Locationdaten immerhin privat bei mir gehosted und Overland stört es auch nicht so sehr, wenn einmal ein Gateway not found zurück kommt, wenn das Homelab zufällig kein Internet hat.

mey

Die nächste Nummer war meine last.fm-Kopie. Da dachte ich mir, das geht schnell, gar kein Problem, ist ja eine halbwegs moderne Laravel-App und in der .env stand sogar was von SQLite. Falsch gedacht. Anscheinend hatte ich das Ding lokal nie wirklich benutzt und auf dem Server war natürlich der MySQL-Server am Laufen. Auch mit dem tollen Konvertierungsscript kam ich nur ein Stückchen weiter, denn ich benutzte im Code diverse SQL-Statements, die SQLite nicht versteht. Na toll!

Ich baute es also neu. Ich versuchte möglichst viel von dem Code aus konpasu zu übernehmen und koppelte ein paar Blade-Komponenten in eine eigene Library aus, die sich während der nächsten Projekte noch ziemlich erweitern wird. Auch hier konzentrierte ich mich auf das wesentliche um den laufenden Betrieb schnell zu sichern — den import der aktuellen Tracks aus Spotify. Den ganzen Import der alten Daten muss ich mir nochmal anschauen, der war schon in der ersten Version sehr lückenhaft, da vor allem der Spotify DSGVO-Export ziemlich scheiße ist.

toller.link

Dieses Side-Project fing ja als Go-App an und wurde kurz darauf durch ein schnell zusammengedengeltes PHP-Script ersetzt, dass zwar ein paar mehr Features hatte aber natürlich auch nur bescheiden aussah und genauso funktionierte.

Auch hier hieß es cp -r meyv2 tollerlinkv3, diverse Sachen anpassen, alte Daten importieren und los gehts. Tatsächlich ließ ich mir hier etwas mehr Zeit um ein paar lang ersehnte Features einzubauen. Ich werde das Projekt zu einem späteren Zeitpunkt nochmal gesondert vorstellen und vielleicht auch veröffentlichen, ist eigentlich ganz cool geworden.

Hier gab es auch mal wieder ein Rabbit Hole, aus dem ich mich gerade noch retten konnte: Ich wollte automatisch Screenshots der gespeicherten Links herstellen und spielte mit Browsershot, Chromium und Puppeteer rum, leider bekam ich es nicht alles getrennt voneinander in Containern zum Laufen. Da kümmere ich mich wohl später mal darum.

Diverse Wordpress-Tests

Ich wollte unter allen Umständen vermeiden einen MySQL-Container zu haben, ich weiß gar nicht so richtig warum, einfach um Resourcen zu sparen. Ich schrieb hier letztens schonmal darüber, dass mir die Kombination aus einem Wordpress “Plugin” und einem Konvertierungsscript machten mir die Arbeit hier viel leichter. Für die Wordpresse benutze ich nun einfach deren offizielles Docker-Image, dass Apache und PHP und alles in einem Container vereint. Da da kein Traffic drauf ist, wird es wohl laufen.

Diverse statische Seiten

Hier kam es zu dem Zeitpunkt als ich das oben erwähnte Depploy-Tool entwickelte. Da gibts auch gar nichts groß zu sagen, Dinge neu hochladen, DNS-Einstellungen ändern, fertig.

Diverse Cronjobs

Hier und da fand ich ein paar PHP-Scripte, die diverse Seiten aufrufen und auf Änderungen checken. Ich sammelte sie alle im Homelab und rufe sie wie vorher auf, nur halt mit docker run php:8.2-alpine auf.

fin

Mein Budgetplanungstool. Das war bisher eine Laravel 5 / Vue 2-App und wenn ich ehrlich bin, habe ich sie seit Jahren nicht benutzt. Dazu kam der ganze PSD2-Kram, der meine automatischen Importe von meinen Bank-Konten deaktivierte und naja. Hier entschied ich mich dazu, alles in ein Archiv zu sperren und wegzuschließen. Bye, bye, fin. Welcome Excel-Tabelle.

speiseplaner.app

Ich schrieb ja schonmal darüber, dass mir keine Rezepte-Apps gefallen. Leider gefiel mir meine Speiseplaner-App auch gar nicht mehr. Die API war mit Lumen gebaut, das hatte ich ja oben schon. Das Frontend in Vue 2. Kein Stack, an dem ich 2023 noch arbeiten wollte.
Ich fragte mich nun, ob ich es wegwerfe und mich zwinge eine der verfügbaren Apps zu benutzen, doch ich war so im Flow, dass ich einfach mal wieder cp -r tollerlinkv3 speisev3 machte und… vor mich hin baute.

Hier konnte ich einiges aus der Lumen-App übernehmen und entfernte einfach 85% der Features. Kein Wochenplan, keine Einkaufsliste, kein Storage-Management. Einfach nur Rezepte anzeigen, durchsuchen und importieren. War also an zwei Abenden quasi fertig und sparkt wieder joy.

Bejou

Meine neuste App! Sollte ich sie auch neu bauen? Natürlich nicht. Sie ist halbwegs modern. Das einzige, was ich hier machte, war meine neu geschaffene UI-Library drauf zu klatschen und die CSS-Dateien zu löschen und gegen Tailwind auszutauschen.

Bejou habe ich, wie konpasu, im Homelab untergebracht und nur per Proxy durchgepeitscht.

Offene Themen

Wer jetzt aufgepasst hat, hat mitbekommen, dass ich natürlich noch nicht alles umgezogen habe. Einige große Punkte sind noch offen:

• knuspermagier.de liegt noch auf seiner eigenen virtuellen Maschine. Ich habe mich noch nicht dran gewagt, Kirby in einen Docker Container zu packen. Da es eins der wenigen gehosteten Projekt ist, die mehr als zwei Benutzer haben, möchte ich hier auch ungern diesen PHP Development-Server benutzen und muss wohl auf ein Multi-Container-Setup mit php-fpm und nginx setzen. Etwas in mir wehrt sich allerdings noch dagegen am Ende einen Proxy von nginx zu nginx zu haben, aber was solls!
• watched.li werde ich nicht migrieren, das ist den Aufwand nicht wert.
• Der Home Assistant läuft noch auf seiner eigenen VM im Homelab. Der könnte wohl auch auf die Docker-VM umgezogen werden. Allerdings habe ich auch noch ein Grafana und InfluxDB aufgesetzt und das müsste mitkommen.
• Ich muss unbedingt noch machen, dass die NAS regelmäßig die Backups… backupt.
• Es juckt mir doch noch in den Fingern, das Setup für die Docker-Server nochmal in ein Ansible-Playbook zu verfrachten. Leider ist es kein Jucken, dass Spaß verspricht, da ich weiß, dass es mich nach wenigen Sekunden nerven wird.
• Monitoring – es wäre schon gut, Alerts zu bekommen, wenn die Festplatte voll läuft, oder so

Erkenntnisse und Fazit

Puh, what a ride. Ich hatte mir eigentlich vor genommen mehr von dem Prozess zu dokumentieren, damit ich hier noch alles detaillierter beschreiben kann, habe ich aber nicht gemacht, daher fehlen hier und da sicher noch wichtige Informationen. Ist also eher ein lebendes Dokument, in dem ich sicher noch das ein oder andere hinzufügen werde.

Ich habe auf jeden Fall viel gelernt. Ich hab viel neuen Kram ausprobiert (Laravel Zero, nginx Proxy Manager, TailwindCSS) und in anderen Themen viel gelernt (Laravel, Livewire, Docker). Außerdem habe ich die Möglichkeit gehabt, quasi alles, was ich in den letzten Jahren gebaut habe, nochmal anzufassen und zu aktualisieren, sodass die Sachen jetzt teilweise sogar an einem Stand sind, wo ich das ein oder andere veröffentlichen könnte. Das wichtigste ist natürlich, dass es viel Spaß gemacht hat, zum großen Teil, sogar so viel Spaß, dass ich mich jetzt hart dazu zwingen musste, erstmal diesen Blogpost fertig zu schreiben, bevor ich noch tausend weitere Features in meine Projekte einbaue und auf dem Weg alles vergesse, was ich schreiben wollte!

So. Ich hoffe, das war halbwegs unterhaltsam und informativ, dürfte das längste gewesen sein, was man hier bisher lesen konnte. Wenn nicht, hattet ihr vielleicht wenigstens Spaß an meinem Midjourney-Katzenteam.

Zu den einzelnen Sachen, die ich entwickelt habe, werde ich sicher, wenn die Zeit reif ist, noch gesonderte Posts schreiben.

Schreibt mir gerne, wie ihr euch um eure eigenen Serverfarmen kümmert, oder wenn ihr Tipps oder Fragen habt!