Von Debian über AlmaLinux zu K3s: Wie ich aus Versehen eine Mini-Cloud gebaut habe 🚀

Der ursprüngliche Plan™: Tschüss Debian, hallo SELinux

Irgendwann dachte ich mir: „Hey, warum eigentlich nicht von Debian auf AlmaLinux umsteigen?“

Hauptgrund? SELinux.
Denn nichts schreit so sehr „lustiges Wochenendprojekt“ wie Security-Kontexte um 2 Uhr nachts zu debuggen.

In dieser Phase habe ich herausgefunden, wie man Collabora per Container einbindet – und das fühlte sich
deutlich stabiler und berechenbarer an.

Phase 2: „Dann nehmen wir halt noch Kubernetes dazu“ 🤦‍♂️

Natürlich ist das eskaliert.

„Ich sollte wohl mal Kubernetes installieren.“

Auftritt K3s – leichtgewichtig, simpel und gerade gefährlich genug, um es auf einem VPS auszurollen.

Die aktuelle Idee:

• Kerndienste (MariaDB, Redis) nativ betreiben
• Anwendungen in K3s laufen lassen
• Mir einreden, dass das „Architektur“ ist und keine Neugier

Ansible: Vom Werkzeug zur Obsession

Was früher „nur ein Playbook“ war, ist inzwischen praktisch ein kleines Framework.

Zwei Haupt-Playbooks:

• Nextcloud
• WordPress

Gemeinsame Komponenten überall:

• Repos
• fail2ban
• MariaDB
• K3s
• Firewall-Regeln

Aktueller Stand: ~16 Rollen.
Emotionaler Stand: ebenfalls 16 Rollen.

KI-Pair-Programming ist real 🤖

Claude AI in VS Code zu nutzen fühlt sich an wie:

„Ein Senior-DevSecOps-Engineer ist deiner Session beigetreten.“

• Fordert Befehlsausgaben an
• Debuggt Fehler
• Refactort Playbooks
• Erklärt Probleme tatsächlich

Leicht beängstigend. Extrem nützlich.

Jetzt mit Monitoring 📊

• Prometheus
• Grafana

Jetzt kann ich meinem System in Echtzeit beim Scheitern zusehen – aber wunderschön.

🔧 Deep Dive: Vom „einfachen Blog“ zur kompletten Infrastruktur

Einen WordPress-Blog auf einem VPS zu betreiben klingt trivial – bis man anfängt, über Folgendes nachzudenken:

• TLS-Zertifikate
• Firewalls
• Updates
• Security-Monitoring

Also habe ich natürlich alles automatisiert.

Infrastructure as Code (auch bekannt als: überall YAML)

Das komplette Setup ist in Ansible definiert:

ansible-playbook blog.yml --limit meinserver

Reproduzierbar. Idempotent. Leicht süchtig machend.

Architektur: K3s vs. Host

In K3s:

• WordPress (PHP-FPM)
• Nginx (Sidecar)
• MariaDB
• ingress-nginx
• cert-manager (Let’s Encrypt)
• WordPress-CronJob

Auf dem Host:

• Prometheus
• Grafana
• Node Exporter
• fail2ban
• rkhunter
• auditd
• msmtp

Der Ablauf des Playbooks

1. Basissystem
2. SELinux
3. K3s
4. Deployment
5. Monitoring

Sicherheit: Defense in Depth

• iptables-Firewall
• fail2ban
• Rate Limiting
• HTTPS über Let’s Encrypt
• SELinux im Enforcing-Modus
• auditd
• Automatische Sicherheitsupdates
• rkhunter-Scans

Fazit: Work in Progress 🔧

Was angefangen hat als:

„Probieren wir mal AlmaLinux aus“

Wurde zu:

• Kubernetes
• Containern
• einem Ansible-Framework
• einem Monitoring-Stack
• KI-gestütztem Betrieb

Mittlerweile betreibe ich im Grunde eine winzige Cloud auf einem VPS.

Aber: Ich bin immer noch mitten im Verfeinern, Testen und erneuten Kaputtmachen.

Der Ansible-Code ist noch nicht veröffentlicht – vor allem, weil ich noch an den Rollen schraube, aufräume
und sicherstellen will, dass er auf einem frischen System nicht komplett explodiert.

(auch bekannt als „nur noch eine kleine Änderung“ – berühmte letzte Worte)

Ich habe vor, das komplette Playbook in den nächsten Tagen auf GitHub zu veröffentlichen – sobald ich sicher bin, dass es
einigermaßen wiederverwendbar ist und nicht nur maßgeschneidertes Chaos.

Das große Ganze hinter alldem: Ich überlege, die bestehenden Nextcloud-Instanzen
zweier Vereine hier aus der Gegend auf diese Architektur zu migrieren.

Aber im Moment ist mir das noch etwas zu riskant – Produktivdaten umziehen und gleichzeitig K3s einführen
klingt nach einer hervorragenden Methode, sich ein Wochenende (oder mehrere) zu ruinieren.

Die Technik ist für mich noch relativ neues Terrain, und ich möchte erst mehr Praxiserfahrung sammeln,
bevor ich ihr echte Nutzerdaten anvertraue.

Vielleicht ist das ein Projekt für den Herbst 🍂

Bleib dran 😄