Okay… Gestern habe ich mich in Ansible gestürzt. Und ich bin verdammt noch mal ein gutes Stück weitergekommen, als ich gedacht hätte.
Aber spulen wir kurz zurück. Warum tue ich mir das an?
Projekt Homelab-Neustart: Warum ich nach 10 Jahren alles einreiße
Ganz einfach: Ich will schon seit Ewigkeiten mein Homelab komplett neu aufsetzen.
Meinen ersten echten Homeserver habe ich mit Anfang 20 zusammengeschustert. Kurz vor meiner Ausbildung zum IT-Systemkaufmann. Das Ding war ein „Billig-PC mit möglichst wenig Stromverbrauch“, zusammengebastelt aus Hardware-Fundstücken von Freunden und Familie.
Mein damaliges Ziel? Ich brauchte einen zentralen Netzwerkspeicher. Und der musste stark genug sein, um meine gerippten DVDs und Blu-rays zu konvertieren.
Die Ära der “Rips”. Vhs, DvD, BluRay
Ich hatte damals Kodi für mich entdeckt. Ich war völlig heiß darauf, mein Heimkino mit einer zentralen Datenbank zu füttern. Damals hatte ich etwas mehr als 200 Filme und tonnenweise Serien auf DvD’s und BluRay’s am Start. Da kamen noch freeTV Aufnahmen via VHS dazu.
Falls sich noch wer erinnert: Werbung rausschneiden mit TS-Doctor… Ich konnte dir damals auf die Sekunde genau sagen, wann im Fernsehen die Werbeblöcke kamen. Wenn man den Dreh einmal raus hatte, saß man da mit ffmpeg, Handbrake und so einem obskuren Indexer, der einen Elch als Logo hatte — wie hieß der noch gleich? Egal, Hauptsache die Files waren „alltagstauglich“ für mein Setup: 7.2 Dolby-Anlage (da hat die Hütte gewackelt!), Full-HD-3D-Beamer von BenQ und aktive Shutterbrillen.
Mein damaliger Raspberry Pi als Mediencenter kam da hardcore an seine Grenzen (damals musste man sich die Codec-Lizenzen für den Pi ja noch extra kaufen, Gott im Himmel…).
Also musste der Bastel-Server ran. Ich hatte mir wilde Bash-Pipelines gebaut. Alles lief über einen Ordner namens /shared_data/movies/todo. Ordner rein, Metadaten in die Config-Datei geschmissen, automatischen Index in die Kodi-DB getriggert. Schon damals habe ich mich nach Struktur und Automatisierung gesehnt — auch wenn das ganze Konstrukt von ziemlich wilden Abhängigkeiten zusammengehalten wurde.
Verschlüsselt, verloren, weggeworfen: Die Backup-Hölle
Seit dieser Zeit lief in meinem Netzwerk immer irgendein Server im Hintergrund, auf dem meine Daten lagen und auf dem Prozesse liefen, die ich mir gerade zusammengesponnen hatte. Das System wurde über Jahre mitgeschleppt und „fortlaufend entwickelt“.
Und ja, es wurde auch oft genug komplett gewiped. Meistens dann, wenn ich das OS so gründlich zerlegt hatte, dass eine Reparatur den Aufwand nicht wert gewesen wäre. Durch diese schmerzhafte Lernkurve habe ich sehr früh gelernt: Backups sind wichtig.
Trotzdem habe ich epische Fehler gemacht:
Der blinde Fleck: Weil die Blu-rays in „besserer Qualität“ in einem anderen Pfad lagen, flogen sie komplett aus dem Backup-Skript. Gemerkt habe ich das natürlich erst ein Jahr später.
Das Verschlüsselungs-Desaster: Nach dem ersten Schock dachte ich mir: *Sicher ist sicher, ich verschlüssele die Backups!*Blöd nur, wenn man den Key nirgends aufschreibt. Als dann mein bisher einziger echter Festplattenausfall einschlug, saß ich da: Backup auf externen Platten vorhanden, Backup in der Cloud vorhanden. Entschlüsseln? Unmöglich. Key weg. Daten weg. Aus Fehlern lernt man… hoffentlich. (Nach diesem Absatz habe ich erstmal gechecked wie mein Backup aktuell läuft. xD Paranoia lässt grüßen!)
Das Doku-Problem (Oder: Mein ADHS vs. Meine Standards)
Bis heute hat mein Homelab ein riesiges Problem: Es gibt so gut wie keine Dokumentation.
Zuletzt habe ich zwar versucht, radikal alles von einer KI dokumentieren zu lassen, aber da schlägt mein ADHS gnadenlos zu. Ich verliere mich aus Prinzip in anderen Prioritäten. Der Ansatz war gut, die Dokus lagen direkt in den jeweiligen Projekten. Aber meine persönlichen Standards entwickeln sich von Tag zu Tag weiter. Das „Nachziehen“ der alten Dokus blieb natürlich liegen. Das Ergebnis? Ein absoluter Wildwuchs aus unterschiedlichen Doku-Standards und unvollständigen Texten.
Damit ist jetzt Schluss. Ich will das Homelab einmal vernünftig neu aufsetzen. Keine Flickschusterei mehr im Livebetrieb. Einmal auf den aktuellen Stand der Technik bringen. Open-Source-Lösungen prüfen, umsetzen, dokumentieren, automatisieren.
Mein Core-Setup: DockerSwarm > proxmox
Ich habe ein paar feste Grundanforderungen im Kopf. Die wichtigste: Ich mag Proxmox nicht. Es widerstrebt mir einfach zutiefst, ein vollständiges Betriebssystem zu emulieren, wenn der Kram auch direkt auf der Hardware laufen kann. Vor allem Wenn das “Gesamt-Konstrukt” eigentlich nur für 1 Environment (in diesem Fall mein Homelab) ist. Ich kenne und verstehe die Vorteile von proxmox. Aber wozu eine vm virtualisieren wenn ich darin quasi nur Docker services laufen lasse. Solange ich noch keine 2 Systeme habe die ich als proxmox Cluster laufen lassen könnte. Sehe ich noch nicht genügend vorteile. Abgesehen Davon kann ich mein Setup jederzeit auch auf einer VM laufen lassen. Proxmox wäre dann nur eine weitere Schicht die “leicht” zu integrieren wäre.
Deshalb bin ich “quasi” im Team Docker. Mein Ziel ist es, mein gesamtes Homelab hardwareunabhängig zu betreiben. Docker Swarm ist dafür mein ToolOfChoice. Ich werfe einfach jede verfügbare Hardware in den Swarm. Wenn eine Node spezielle Hardware hat — wie mein alter Gaming-PC im Gästezimmer, dessen Grafikkarte ich für Games on Whales / Wolf Gaming brauche —, dann fixiere ich den Service per Tag auf diese Node, bzw Nodes mit dieser Eigenschaft oder dem Label. Perfekt.
Und hier kommt Ansible ins Spiel. Ansible soll dafür sorgen, dass alle meine OS-Systeme exakt gleich eingerichtet sind.
Wer schon mal versucht hat, eine Datenbank im Docker Swarm über MacVLAN mit einer eigenen festen IP (z. B. 192.168.1.230) und nicht unter der IP einer der Swarm Nodes für das gesamte Netzwerk erreichbar zu machen, ist vermutlich hier und da in ein paar Sackgassen gelaufen. Man braucht einen MacVLAN-Shim, damit der Host selbst überhaupt auf die IP zugreifen kann.
Auf meinem Haupt-Server lief das im Test wunderbar. Dann ab in den Swarm damit. Ergebnis: Absolute Katastrophe. Der Service startete auf der zweiten Node, auf der das MacVLAN noch gar nicht eingerichtet war. Fehler über Fehler. Als ich das gefixt hatte, habe ich im Stress den Shim vergessen. Die DB war zwar vom MacBook aus erreichbar, aber die anderen Services auf dem Host/ der Node selbst, kamen nicht ran. Sowas nervt einfach nur tierisch.
Mit meiner Ansible-Role passiert mir das nicht mehr. Die wird einmal für alle Docker-Hosts ausgerollt, der Swarm-Manager taggt die Node automatisch mit macvlan_ready=true und der DB-Service läuft nur noch da, wo er soll. Kommt ein neuer Server in den Swarm? Ansible drüberlaufen lassen, fertig. Und dabei ist es einfach “übersichtlicher”. Im Bezug auf “wartbarkeit”, schlägt Ansible meine alten Bash- und SSH-Skripte, bei denen ich 100 Variablen für verschiedene OS-Versionen abfangen musste.
Das “Brain-to-CPU”-Problem
…Und genau hier merke ich wieder, wie ich mich komplett in Details und Erinnerungen verliere.
So läuft das bei mir die ganze Zeit. Ich plane ein Feature und noch bevor der erste Satz Code getippt ist, stehen in meinem Kopf 2–3 komplette Architekturen bis zu einer Art MVP. Dazu natürlich die ersten grundlegenden Gedanken zu UX, Skalierbarkeit und rechtlichen Fallstricken. Und das dann nicht nur für dieses eine Feature/Projekt. Sondern auch für alle anderen “oh das könnte auch noch gut werden” Projekte die mir beim darüber nachdenken zusätzlich einfallen. Mein Gehirn ist einfach schneller, als ich tippen oder sprechen kann. Was ich bräuchte, wäre ein direktes Brain-to-CPU-Interface oder ein Snapshot-System für meine Gedanken.
Aber bevor ich jetzt noch mehr abdrifte und anfange, stundenlang über WordPress vs. Static-Site Generatoren oder die perfekte Domain-Identität nachzudenken, mache ich es kurz:
Hey Leute, ich bin Mike. Ich setze gerade mein Homelab von Grund auf neu auf. Ich werde den gesamten Prozess versuchen ausführlich zu dokumentieren und hier in einer Blogserie festhalten. Dazu wird es immer wieder ehrliche Rants, tiefe Einblicke und hoffendlich für den ein oder anderen hilfreiche Tutorials (Problem -> Lösungsweg -> Ergebnis) geben.
Willkommen an Bord. Das Chaos hat ab jetzt Methode!