Unser Self-Hosted Stack 2024: Open-Source-Tools im Überblick

Dreieinhalb Jahre später

Anfang 2021 haben wir beschrieben, warum wir bei encircle360 auf Self-Hosted Open Source setzen. Die Gründe -- Datensouveränität, Vendor-Unabhängigkeit, Kostenkontrolle -- gelten unverändert. Was sich verändert hat, ist der Stack selbst. Dienste sind dazugekommen, andere wurden ausgetauscht, die Plattform darunter hat sich weiterentwickelt. Zeit für ein Update.

Dieser Beitrag ist ein Katalog. Kein tiefes Eintauchen in einzelne Tools, sondern ein Überblick über die Bausteine, die Mitte 2024 unsere interne Infrastruktur bilden. Alles läuft auf unseren K3s-Clustern, die wir seit Jahren im Produktiveinsatz betreiben. Je nach Setup nutzen wir Helmfile oder Argo CD für das Deployment-Management -- Helmfile für die Cluster, die wir schon länger betreiben, Argo CD in neueren Setups, wo der Pull-basierte GitOps-Ansatz besser passt. Die Nodes darunter laufen auf NixOS -- deklarativ konfiguriert, reproduzierbar, und nach über zwei Jahren in Produktion genau so zuverlässig, wie wir es uns erhofft hatten.

Gitea: Git-Hosting ohne Ballast

Gitea war schon 2021 Teil unseres Stacks und ist es geblieben. Die Software ist in Go geschrieben, startet in Sekunden und verbraucht einen Bruchteil der Ressourcen einer vergleichbaren GitLab-Instanz. Für ein Team unserer Größe ist das ein realer Vorteil -- weniger Ressourcenverbrauch bedeutet weniger Nodes, weniger Kosten, weniger Komplexität.

Wir nutzen Gitea für sämtlichen Quellcode, Pull Requests, Code Reviews und Issue-Tracking. Die API ist stabil und gut dokumentiert, was die Integration in unsere CI/CD-Pipelines unkompliziert macht. Die API ist stabil und gut dokumentiert, was die Integration in unsere Automatisierungen unkompliziert macht.

Directus: Headless CMS auf der eigenen Datenbank

Directus hat sich seit 2021 von einem Experiment zu einem zentralen Baustein entwickelt. Wir nutzen es als Headless CMS für unsere Website, für Blog-Beiträge und für strukturierte Daten, die über REST- und GraphQL-APIs bereitgestellt werden. Was Directus besonders macht: Es sitzt direkt auf einer bestehenden PostgreSQL-Datenbank und generiert die API automatisch aus dem Datenbankschema. Kein proprietäres Datenformat, keine Migration -- die Daten gehören uns, im wahrsten Sinne.

Im Tagesgeschäft schätzen wir die Admin-Oberfläche, die es auch nicht-technischen Teammitgliedern ermöglicht, Inhalte zu pflegen. Die Flows-Engine erlaubt es, Automatisierungen direkt in Directus zu konfigurieren -- Webhooks bei Änderungen, automatische Bildverarbeitung, Benachrichtigungen. Für ein kleines Team erspart das eine Menge Glue-Code.

Keycloak: Identity Management und SSO

Keycloak übernimmt das Identity und Access Management für unseren gesamten Stack. Single Sign-On über OpenID Connect, Nutzerverwaltung, Rollenvergabe, Zwei-Faktor-Authentifizierung -- alles an einem Ort. Jeder interne Dienst, der eine Authentifizierung braucht, bindet sich über OIDC an Keycloak an: Gitea, Directus, Grafana, unsere eigenen Anwendungen.

Die initiale Konfiguration von Keycloak bleibt aufwändig. Realms, Clients, Flows, Mapper -- die Lernkurve ist steil. Aber wenn es einmal eingerichtet ist, läuft es zuverlässig und bietet ein Niveau an Flexibilität, das gehostete Alternativen wie Auth0 nicht im gleichen Maß bieten -- zumindest nicht ohne Enterprise-Preise. Seit Keycloak 22 ist die Umstellung von WildFly auf Quarkus abgeschlossen, was den Ressourcenverbrauch und die Startzeiten deutlich verbessert hat. Für das Deployment auf Kubernetes nutzen wir das codecentric Keycloakx Helm Chart, nachdem das frühere Bitnami-Chart deprecated wurde.

PostgreSQL: Die Datenbank für alles

PostgreSQL ist das Rückgrat unserer Datenhaltung. Directus, Keycloak, Gitea und diverse eigene Anwendungen nutzen PostgreSQL als primäre Datenbank. Wir betreiben mehrere PostgreSQL-Instanzen auf dem Cluster, getrennt nach Dienst und Umgebung.

Für das Management der PostgreSQL-Instanzen auf Kubernetes setzen wir auf den CloudNativePG-Operator. Der Operator übernimmt Provisioning, automatische Backups, Point-in-Time-Recovery und Failover. Was früher manuelles Backup-Scripting und sorgfältig konfigurierte Replikation erforderte, ist heute eine Kubernetes-Custom-Resource. Die Backups gehen automatisch nach MinIO -- womit wir beim nächsten Baustein wären.

MinIO: Object Storage im eigenen Cluster

MinIO liefert S3-kompatiblen Object Storage auf unserer eigenen Infrastruktur. Wir nutzen es für Datenbank-Backups, Directus-Assets, Build-Artefakte und alles, was nicht in eine relationale Datenbank gehört. Die S3-API-Kompatibilität ist dabei der entscheidende Punkt: Jedes Tool, jede Library, die mit AWS S3 sprechen kann, funktioniert ohne Änderung mit MinIO.

MinIO läuft in einer Distributed-Konfiguration auf mehreren Nodes, was Redundanz und Verfügbarkeit sicherstellt. Die Performance ist für unsere Anwendungsfälle mehr als ausreichend. Und im Vergleich zu den Kosten von S3 oder vergleichbaren Cloud-Storage-Diensten ist der Betrieb auf eigener Hardware deutlich günstiger -- vor allem bei größeren Datenmengen, wo die Egress-Gebühren der Cloud-Anbieter empfindlich ins Gewicht fallen.

Grafana und Prometheus: Monitoring und Alerting

Monitoring ist kein optionales Feature, wenn man Infrastruktur selbst betreibt. Prometheus sammelt Metriken von allen Diensten und Nodes, Grafana visualisiert sie in Dashboards und löst bei Schwellwertüberschreitungen Alerts aus.

Wir deployen den kube-prometheus-stack über Helmfile, der neben Prometheus und Grafana auch den Alertmanager, node-exporter und kube-state-metrics mitbringt. Die vordefinierten Dashboards decken Kubernetes-Cluster-Health, Node-Ressourcen und Pod-Metriken ab. Für unsere eigenen Spring-Boot-Services haben wir zusätzliche Dashboards gebaut, die Micrometer-Metriken wie Request-Latenzen, JVM-Heap-Usage und Thread-Pools abbilden.

Alerts gehen über den Alertmanager an unseren Messaging-Kanal. Wenn ein Pod in einer CrashLoopBackOff hängt, ein Node nicht erreichbar ist oder der Disk-Space knapp wird, erfahren wir das innerhalb von Minuten -- nicht erst, wenn ein Nutzer sich meldet.

Gatus: Health-Checks und Status-Seite

Für das externe Monitoring setzen wir Gatus ein. Gatus ist in Go geschrieben, konfiguriert sich über eine einzige YAML-Datei und prüft in konfigurierbaren Intervallen die Erreichbarkeit unserer Dienste -- HTTP-Endpoints, TCP-Ports, DNS-Auflösung, TLS-Zertifikate. Die integrierte Status-Seite zeigt den aktuellen Zustand aller Dienste auf einen Blick.

Gatus ergänzt Prometheus, ersetzt es aber nicht. Prometheus überwacht die Interna -- Metriken, Ressourcen, Performance. Gatus überwacht von außen: Ist der Dienst erreichbar? Antwortet er innerhalb akzeptabler Zeiten? Stimmt das TLS-Zertifikat noch? Diese Außenperspektive ist wichtig, weil interne Metriken allein nicht verraten, ob ein Dienst für Endnutzer tatsächlich funktioniert. Zuvor hatten wir Uptime Kuma für diesen Zweck im Einsatz, aber Gatus hat sich durch seine YAML-basierte Konfiguration besser in unseren GitOps-Workflow eingefügt.

Die Plattform: K3s auf NixOS

Unter all diesen Diensten liegt unsere K3s-Infrastruktur auf NixOS-Hosts. K3s liefert Kubernetes mit minimalem Overhead -- eine einzige Binary, kein separater etcd-Cluster in den meisten Setups, Traefik als Ingress-Controller out of the box. Wir betreiben mittlerweile drei Cluster (Dev, Staging, Production), die über Helmfile mit Environments und Selektoren verwaltet werden.

NixOS als Host-Betriebssystem hat sich über die Jahre bewährt. Jeder Node ist durch seine configuration.nix vollständig beschrieben. Ein neuer Node ist keine manuelle Installation, sondern ein Deployment einer deklarativen Konfiguration. Kernel-Updates, Systemd-Services, Netzwerkkonfiguration -- alles versioniert, alles reproduzierbar, alles rollbar.

Was sich seit 2021 verändert hat

Der Vergleich mit unserem Stack von Anfang 2021 zeigt eine klare Entwicklung. Die Kernbausteine -- Gitea, Keycloak, Directus, PostgreSQL, Prometheus/Grafana -- sind geblieben und gereift. Dazugekommen sind MinIO als Object Storage, Gatus für externes Health-Monitoring, CloudNativePG für das Datenbankmanagement und Argo CD als ergänzende Deployment-Option neben Helmfile. Nextcloud nutzen wir weiterhin, aber zunehmend weniger für Kernaufgaben, da spezialisierte Dienste die jeweiligen Aufgaben besser abdecken.

Die größte Veränderung ist aber nicht ein einzelnes Tool, sondern die Reife des Gesamtsystems. Helmfile und Argo CD für Deployment-Management, automatisierte Backups über CloudNativePG und MinIO, durchgängiges SSO über Keycloak, lückenloses Monitoring durch Prometheus und Gatus. Jeder Baustein ergänzt die anderen. Das Ergebnis ist eine Plattform, die sich anfühlt wie ein Produkt -- nicht wie eine Sammlung einzelner Tools.

Fazit

Unser Self-Hosted Stack 2024 ist kein Bastelprojekt mehr. Es ist eine gewachsene, durchdachte Infrastruktur, die unsere tägliche Arbeit trägt. Der operative Aufwand ist real -- Updates, Troubleshooting, Kapazitätsplanung fallen nicht weg, weil man Open Source nutzt. Aber der Aufwand ist planbar, die Kosten sind überschaubar, und die Kontrolle über unsere Daten und Prozesse ist vollständig.

Für uns als Kubernetes-Consultancy ist der eigene Stack gleichzeitig Produktionsumgebung und Lernplattform. Jedes Problem, das wir auf unserer eigenen Infrastruktur lösen, macht uns besser in der Beratung unserer Kunden. Das ist kein Nebeneffekt -- es ist Teil der Strategie.