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.
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, optional Ingress-Klasse | host, url | Eigene Records löschen |
| Bucket | 1..n Buckets, optional ein Schlüssel | access_key, secret_key | Leere Buckets und Schlüssel löschen |
| Umgebung | Namespace und ein Service aus Build oder Image | Service und Host | Undeploy, Namespace, Umgebung |
| Workload | Helm-Release aus der Template-Bibliothek | 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 DatenbankenCloudflare-Zonen, Records automatisch, Wildcard-Zertifikate verwaltet.
Zu DNS & ZertifikateBuckets mit eigenem IAM-Key und Bucket-Policy pro Anwendung.
Zu Object StorageIhre 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.
