Beschreiben Sie einmal, was ein neuer Kunde braucht: Datenbank, Domain, Buckets, Workload. Clusterward führt die Pipeline pro Tenant aus, mit Fortschritt, Retry, Rollback und einem Offboarding, das zuerst sichert und dann abbaut.
Eine Tenant-Pipeline ist eine geordnete Liste von Schritten, die Clusterward für jeden neuen Tenant ausführt. Die Schritte sind Bausteine: eine Datenbank auf einer Instanz, eine Domain mit Record und Zertifikat, ein oder mehrere Buckets mit eigenem Schlüssel, eine Umgebung mit Anwendung oder Container, ein Helm-Workload. Jeder Baustein veröffentlicht Werte auf einem Variablen-Bus, etwa Datenbank-URL oder Hostname, die spätere Schritte erst bei der Ausführung auflösen. Der Designer prüft die Reihenfolge, das Onboarding läuft im Hintergrund, und jeder Schritt lässt sich wiederholen oder rückabwickeln.
Bausteine hinzufügen und ordnen; der Designer weist kaputte Reihenfolgen ab.
Der Wizard fragt nur die Kundendaten und die deklarierten Eingaben ab.
Datenbanknamen, Hosts, Service-Namen und Buckets werden live auf Kollisionen geprüft.
Jeder Schritt speichert seine Ressourcen sofort; Wartezeiten blockieren nichts.
Host, Service, Datenbank und Buckets stehen auf der Tenant-Seite mit Live-Status.
Ein Onboarding, das Sie heute in Skripten, Tickets und Kopf haben, wird zu Daten, die jeder im Team lesen kann.
Jeder Baustein ist ein Schritt mit Voraussetzungen und Ergebnissen. Datenbank, Domain, Bucket, Umgebung und Workload lassen sich beliebig kombinieren und im Designer inline anlegen.
Workloads verwenden ${db.main.url} oder ${domain.app.host}. Die Werte werden erst bei der Ausführung gelesen; das Datenbank-Passwort steht nie im Lauf.
Der Wizard löst die exakte Spezifikation auf und prüft jeden Artefaktnamen gegen die Instanz, die Domains und die Buckets. Ein Konflikt blockiert den Start, ein unklarer Check warnt nur.
Ein fehlgeschlagener Schritt wird wiederholt, ohne dass Vorheriges neu entsteht. Rollback führt die Kompensationen rückwärts aus: Datenbank weg, Records weg, Services abgebaut.
Zuerst jede Datenbank sichern und gefüllte Buckets archivieren, dann abbauen. Ohne gesicherten Dump wird nichts gelöscht.
Ihre Anwendung bestellt Onboarding und Offboarding über ein dokumentiertes Protokoll; Clusterward fragt sie ab, erfüllt die Anfragen und meldet den Stand zurück.
Eine Zeile KEY=secret:Wert im Env-Template eines Umgebungs-Bausteins wird zum nur schreibbaren Secret des Services – auf Wunsch im Scaleway Secret Manager, im Ordner des Services.
Ein Workload-Baustein legt vor dem ersten Rollout Chart-Secrets an: generierte Schlüssel, Wizard-Eingaben oder Datenbank-Passwörter. Die Values lesen sie als ${secret.NAME}.
Umgebungs-Bausteine tragen die Netzwerk-Einstellungen des Services mit: Timeouts, Retries, Rate-Limits, CORS und Basic Auth.
Umgebungs-Bausteine haben im Designer den Abschnitt „Volumes (optional)“: Name, Mount-Pfad, Größe, Storage-Klasse und Snapshot-Plan je Festplatte, angelegt mit dem Service jedes Kunden, der dann mit genau einer Instanz läuft. Rollback und Offboarding sichern jede Platte per Snapshot, bevor sie gelöscht wird.
Die Karte „Inputs“ zeigt, womit ein Kunde angelegt wurde. „Edit inputs…“ ändert einen Wert und zeigt vorher jede Zeile der Service-Werte, die sich ändert.
Bekommt die Pipeline später eine Eingabe dazu, sehen bestehende Tenants sie als neu markiert und setzen sie wie die anderen. Leere optionale Eingaben bleiben leer.
Ein Domain-Schritt übernimmt die Ingress-Klasse des Workload- oder Umgebungs-Schritts, der seinen Host bedient – so zeigt der Record auf genau dessen Load Balancer. Die Klasse wählen Sie einmal aus einer Liste, am bedienenden Schritt; nur für einen Host, den kein Schritt bedient, wählt sie der Domain-Schritt selbst.
Workload- und Umgebungs-Schritte haben eine Liste „Uptime checks“: Host, Pfad, erwarteter Status und Intervall. Die Checks entstehen direkt nach dem ersten gesunden Rollout – ein neuer Kunde ist vom ersten Moment an überwacht.
Jeder Bucket des Bucket-Schritts hat das Kästchen „Back up nightly“, standardmäßig an. Für Buckets, deren Inhalt sich neu erzeugen lässt, wählen Sie es ab.
Die Tenant-Liste zeigt, auf welcher Chart-Version jeder Tenant läuft oder wie viele Commits seine Anwendung hinter dem Branch liegt. Die Kachel „behind version“ filtert die, die auf ein Update warten.
„Update to the newest version…“ im Menü eines Tenants pinnt seine Chart-Services auf die neueste Version und rollt sie aus – für genau diesen Tenant. So probieren Sie ein Update an einem Kunden aus, bevor die übrigen folgen.
Jede Zeile der Tenant-Liste zeigt die Gesundheit der Services und die letzten 24 Stunden der Uptime-Checks als Balken. Die Kacheln oben filtern die Liste, und Retry, Open site, Edit inputs und Offboard liegen direkt in der Zeile.
Eine Namespace pro Tenant, gepinnt bei der Erstellung, nie aus dem Namen neu berechnet.
Anwendung aus einem Build, Container-Image oder Helm-Chart mit Values aus dem Bus.
Dotenv-Vorlage mit Bus-Werten und frisch erzeugten Geheimnissen pro Vorkommen.
Record, Ingress und Zertifikat; Cloudflare-Proxy wird erkannt.
Jeder Baustein erzeugt seine Ressourcen idempotent und kennt seine Kompensation für den Rollback.
| Baustein | Erzeugt | Veröffentlicht | Rollback |
|---|---|---|---|
| Datenbank | Datenbank und Besitzer-Rolle auf einer Instanz | name, user, password, host, port, url | Drop |
| Domain | Record, Ingress, Zertifikat; Ingress-Klasse vom bedienenden Schritt | host, url | Eigene Records löschen |
| Bucket | 1..n Buckets, jeder auf Wunsch nachts gesichert, optional ein Schlüssel | access_key, secret_key | Leere Buckets und Schlüssel löschen |
| Umgebung | Namespace und ein Service aus Build oder Image, optional mit Volumes und Uptime-Checks | Service und Host | Volume-Daten (nach Snapshot), Undeploy, Namespace, Umgebung |
| Workload | Helm-Release aus der Template-Bibliothek, optional mit Uptime-Checks | Service und Host | Uninstall und Löschen |
| HTTP-Check | Nichts; wartet auf eine gesunde Antwort | Nichts | Nichts |
Die Bausteine nutzen dieselben Funktionen wie das Cockpit: Die Datenbank entsteht wie unter Managed Datenbanken beschrieben, der Host wie unter DNS und Zertifikate, der Bucket wie unter Object Storage.
Wer viele Kunden betreibt, findet auf der Seite für SaaS-Anbieter den Weg vom ersten Cluster bis zur bestellbaren Pipeline.
Postgres und MySQL privat angebunden, eine Datenbank pro Service.
Zu Managed DatenbankenZonen bei Cloudflare oder Scaleway DNS, Records automatisch, Wildcard-Zertifikate verwaltet.
Zu DNS & ZertifikateBuckets mit eigenem IAM-Key und Bucket-Policy pro Anwendung.
Zu Object StorageEin Lauf mit Datenbank, Domain und Container-Workload war live in unter einer Minute fertig. Die Dauer hängt von der Zertifikatsausstellung und dem Start der Anwendung ab; Verifikationsschritte warten geduldig und lassen sich bewusst überspringen, wenn DNS noch propagiert.
Ihre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenBringen Sie Ihr heutiges Runbook mit. In der Demo bauen wir es als Pipeline nach und führen den ersten Tenant aus.
