Schlagwort: Kubernetes

Kategorien
Blog

Fnordschritt

Seit der letzten Erwähnung meiner Mastodon-Instanz hat sich noch so einiges getan. Auf der einen Seite sind noch so einige Benutzerkonten dazugekommen (wir sind aktuell so ungefähr bei 230), und auf der anderen Seite habe ich ein paar der letzes mal noch offenen Hausaufgaben gemacht:

Regeln

Ja, die Hausregeln sind inzwischen explizit aufgeschrieben. Erst mit expliziten Regeln ergibt Moderation überhaupt Sinn.

Und ich habe bei der Gelegenheit auch gleich ein git-Repository eingerichtet, das einerseits eine ausführlichere Version der bewusst knapp gehaltenen Regeln enthält und andererseits die Möglichkeit zur Mitarbeit bietet (dazu muss im Moment leider noch ein eigener Account auf meinem git-Server erstellt werden, aber ich setze da große Hoffnung in das forgefed-Projekt).

Monitoring

Ein Dienst, der nicht ordentlich überwacht ist, muss automatisch als offline gelten.

Grafana

Deshalb habe ich zwei Exporter installiert, die Daten über den aktuellen Zustand der Instanz für Prometheus bereitstellen (statsd_exporter und prometheus-mastodon-exporter) und ein Dashboard zur Visualisierung in Grafana gebaut.

Darauf kann ich jetzt mit einem Blick sehen, ob es meinem Mastodon gerade gut geht, oder ob z.B. die Antwortzeiten ungewöhnlich angestiegen sind oder die Hintergrundprozesse klemmen.

Uptime Kuma

Seit Version 4.1 hat Mastodon außerdem die Möglichkeit gewonnen, den Link zu einer Statusseite zu hinterlegen. Das habe ich zum Anlass genommen, auf einer VM in Helsinki Uptime Kuma zu installieren. Denn fast alle meine Dienste laufen im gleichen Rechenzentrum bei Hetzner in Falkenstein, und sollte das mal komplett nicht erreichbar sein, würde auch mein normales Monitoring nicht mehr funktionieren.

Screenshot von status.fnordon.de: alles grün und "All Systems Operational"

Jetzt bekomme ich auch bei Netzwerkproblemen sofort Benachrichtigungen, und die Fnordon-Benutzer:innen können auch nachsehen, ob es am Dienst oder an ihrem Ende liegt, wenn sie Fnordon nicht erreichen.

MinIO

In Vorbereitung auf den geplanten Umzug aller Dienste auf Kubernetes, und um Mastodon später mal überhaupt in einem über mehrere Maschinen verteilten Cluster betreiben zu können, habe ich schließlich noch die Mediendateien in einen Object Storage ausgelagert. Das klingt nicht nur schick und modern sondern sollte auch die Ladezeiten von Bildern und Videos in Beiträgen und von Avataren erheblich verringern. Mastodon unterstützt Amazon S3 und kompatible Systeme direkt, und MinIO läuft gut in Kubernetes.

Mit diesen Verbesserungen und der aktuellen Anzahl von Accounts dürfte Fnordon weiter locker laufen können, müsste eigentlich sogar etwa für die zehnfache Menge geeignet sein. Wer also noch eine digitale Heimat im Fediverse sucht, kann sich gerne melden.

Kategorien
Blog

Alles muss hier moderner werden

Gestern ist dieses – zugegebenermaßen im Moment etwas vernachlässigte – Blog 18 Jahre alt geworden. Herzliche Glückwünsche zur Volljährigkeit.

Nicht ganz so alt, aber fast, ist die Infrastruktur, auf der es läuft: das Blog und ein ganzer Strauß weiterer Dienste verteilen sich auf zwei „root-Servern“ bei Hetzner, die ich jetzt schon seit 2009 bzw. 2014 gemietet habe.

Das ist jeweils das „richtige Blech“, und in einem der beiden Server laufen die Festplatten (ja, so richtig mit rotierendem Rost!) seit bald 13 Jahren durchgehend, im anderen ist das mit 8 Jahren auch nicht viel besser.

[…]
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   100   051    Pre-fail  Always       -       0
[…]
  9 Power_On_Hours          0x0032   077   077   000    Old_age   Always       -       114123
[…]

Ich habe zwar ordentliche Backups eingerichtet (und auch die Wiederherstellung getestet), und ich bin mir deshalb recht sicher, dass keine Daten verloren gehen würden, wenn doch mal was abraucht (klopft auf die Tischplatte) … aber ich hätte wahrscheinlich einige Tage Arbeit, um einen der Rechner wieder so aufzusetzen, dass alles so läuft wie zuvor.

In der Arbeit hingegen bin ich inzwischen Teil des „Site Realiability Engineering“-Teams, das die Cloud-Infrastruktur betreibt und betreut. Dort benutzen wir Kubernetes auf Virtuellen Maschinen in der Azure Cloud. Die Infrastruktur ist komplett in beschreibem Code abgelegt und kann jederzeit wieder in den definierten Zustand gebracht werden.

Ist so eine VM kaputt, dann wird sie einfach gelöscht und neu angelegt. In der Theorie der Infrastructure as Code wird das als Pets vs. Cattle bezeichnet, und die Idee dahinter ist, dass die einzelnen, spezialisierten und schwer aufzubauenden Server gedanklich wie Haustiere sind, während die kurzlebigen und austauschbaren Cloud-VMs eher wie Nutztiere sind, wo eine Kuh genau so gut ist wie die nächste (sowohl Veganer als auch bayerische Kleinbauern, die die Namen all ihrer Kühe kennen, werden dem Bild nicht ganz zustimmen können, aber die Idee kommt wohl rüber).

Jetzt ist Azure für mich viel zu teuer, da dort jede einzelne VM monatlich schon mehr kostet als alle meine Server zusammen. Doch auch Hetzner bietet inzwischen Cloud-VMs, darum möchte ich alles hier (macht ausholende Handbewegung) auf Kubernetes in der Hetzner Cloud umziehen.

Ein paar weitere Modernisierungen plane ich im Zuge der Umbauten auch gleich zu machen, und ich werde das hier begleiten in einer eher technischen Artikelserie.