Geo-redundantes S3 über die Föderation — Garage in zwei Phasen

Ceph RGW war pro Cluster — ein Standort-Ausfall, und der Bucket ist weg. Garage löst das: Phase 1 läuft heute single-cluster auf hydra mit Replication-Factor 3 und übersteht den Verlust eines Workers. Phase 2 macht jeden Cluster zu einer Zone und übersteht den Verlust eines ganzen Standorts — über dieselbe Tailnet-Föderation, gated auf denselben L4-Router.
Stand: zweiphasig. Phase 1 (Single-Cluster auf hydra, drei Knoten) läuft und hat das frühere Ceph RGW bereits abgelöst. Phase 2 (cross-cluster, eine Zone pro Cluster) ist Roadmap — Issue 6d3a0eb — und wartet auf eine Voraussetzung, die sich am Ende mit der Headscale-HA-Arbeit trifft.

Objektspeicher ist im Lab unspektakulär, aber überall: Restic-/VolSync-Backup-Targets, Artefakte, kleine statische Sites. Lange lieferte das Ceph RGW — pro Cluster. Genau das ist das Problem: Fällt der Standort aus, ist der Bucket weg. Seit die ClusterMesh-Episode eine Föderation über das Tailnet etabliert hat, wird ein echter Multi-Site-Store möglich. Die Antwort heißt Garage .

Radicle CI — eine Pipeline, die auf Patches reagiert

Der Code des Labs liegt in einer P2P-Forge, die CI aber noch nicht: Builds laufen post-merge auf einer externen .build.yml. Wie ein Radicle-CI-Broker das schließt — er hört auf die Patch-Events der eigenen Seed-Node, baut und signiert in-cluster und schreibt das Ergebnis zurück auf den Patch. Plus das eigentlich harte Problem: Vertrauen in einer Forge ohne Owner.
Stand: Design/Roadmap. Issue 7f834f9 : „Wire Radicle CI once the lab repo is published (patches already wired)." Die Seed-Node läuft in-cluster, der Patch-Workflow steht — der CI-Broker ist das letzte fehlende Stück. Dieser Beitrag beschreibt, wie er andocken soll.

In Von SourceHut zu Radicle ist der Lab-Code in eine Peer-to-Peer-Forge umgezogen: keine zentrale Instanz mehr, Patches und Issues leben als signierte Collaborative Objects (COBs), Flux deployt vom kanonischen main. Ein Faden blieb dort offen — und der ist genau der hier: Radicle ist eine Forge, kein CI-System. Der Code liegt P2P, der Build aber noch nicht.

Headscale aus dem Single Point of Failure holen

Headscale ist die Kontrollebene der ganzen Föderation — und heute bewusst eine Single-Replica auf SQLite. Der geplante Weg zu HA: das Image festnageln, SQLite gegen CloudNativePG tauschen, den öffentlichen Endpunkt failover-fähig machen und das gebündelte tailnet-gateway entflechten.
Stand: Design/Roadmap. Das hier ist der geplante Weg, kein Live-Setup. Heute läuft Headscale im Lab bewusst als Single-Replica; die einzelnen Schritte leben als Issues im Backlog (rad issue list: b404b7a , 5f36156 , 231c25c , 8b9e4e1 , fa3985f ). Ich schreibe das auf, bevor ich es baue — die Reihenfolge ist der eigentliche Inhalt.

Im tailnet-gateway-Beitrag habe ich Headscale zur Kontrollebene des Labs gemacht: ein selbst gehostetes Tailscale-Coordination, durch das jeder Cluster ins Tailnet kommt. Die ClusterMesh-Episode hat denselben Strang weitergesponnen. Was beide stillschweigend voraussetzen: Es gibt genau eine Headscale-Instanz, auf hydra, und wenn die wegfällt, hat die Föderation kein Gehirn mehr. Genau diesen Single Point of Failure will ich auflösen — und der Weg dahin ist überraschend gestuft.

Restore als ein Kommando — die backup-Task-Kategorie

Ein VolSync-Restore ist eine sechsstufige Choreografie aus Flux-suspend, PVC-wipe und restic-restore. Wie das go-task-Setup im Lab daraus ein einziges, idempotentes Kommando macht — inklusive des Pod-Security-Tricks, der den wipe-Job überhaupt erst durchlässt.

Ein Restore ist der eine Moment, in dem man garantiert unter Stress steht: irgendwas ist kaputt, und ausgerechnet jetzt soll man sich die Reihenfolge aus Flux-suspend, PVC-leeren, restic restore und Flux-resume fehlerfrei aus dem Kopf klicken. Genau diese Reihenfolge gehört nicht in den Kopf, sondern in Code. Im go-task-Setup des Labs übernimmt das die backup-Kategorie — ein dünner Wrapper um VolSync und restic , der aus dem VolSync-Aufbau ein paar einprägsame Kommandos macht.

Von Makefiles zu task: Das Cluster über Anweisungen bedienen

Warum ich die operativen Anweisungen meines Labs von Makefiles auf go-task migriert habe — mit Namespaces, Preconditions, Prompts und einem Überblick, was sich damit alles steuern lässt

Ein Follow-up zum GitOps-Aufbau meines Labs: Wenn das Repository den Zustand beschreibt, brauche ich trotzdem eine Handvoll Anweisungen, um den Cluster zu bedienen — bootstrappen, Secrets rotieren, Backups zurückspielen, Zertifikate erneuern. Lange lebten diese Anweisungen in Makefiles. Heute steckt jede davon in einem go-task -Taskfile, und der Umstieg war eine der besseren kleinen Entscheidungen.