GitOps-Teams, die OpenClaw-Gateways auf dedizierten Mac mini M4-Knoten bei clustervps betreiben, erhalten mit Flux (ImageRepository, ImageUpdateAutomation, Receiver) ein anderes Auslösermodell als bei Argo Rollouts und dessen AnalysisRun-Webhooks. Dieser Leitfaden liefert eine minimal reproduzierbare Kette: signierte Image-Tags triggern Automation, der Receiver POSTet an Ihr Gateway, ein gewichteter Canary-Split verteilt Last, zusammengeführte openclaw doctor-JSONs bilden die Sondenbasis, und ein Fehler-Digest geht an einen Notifier-Knoten.
Struktur: Abgrenzungsmatrix, Webhook-Vertrag, Mehrknoten-Slices, Sondenfenster, Broadcast, Runbook in sechs Schritten plus FAQ. Für Rollouts-spezifische AnalysisRun-Pfade siehe den separaten Artikel Argo Rollouts + OpenClaw; hier liegt der Fokus ausschließlich auf Flux.
- Falsche Tool-Erwartung: Flux liefert keinen eingebauten progressive-delivery-Controller wie Rollouts; Canary-Logik muss in Gateway-Tags, Routing-Gewichten und Webhook-Antworten modelliert werden.
- Token-Drift: Statische Receiver-Secrets ohne Überlappungsfenster führen zu harten Ausfällen, sobald Git und Cluster nicht synchron rotieren.
- Slice-Kollisionen: Ohne deterministische
gateway.d-Scheiben pro Region überschreiben sich OpenClaw-Fragmente — vergleiche Fragment-Merge-HowTo. - Retry-Stürme: Unbegrenzte POST-Wiederholungen blockieren SSH-Sitzungen und APFS-Metadaten, bevor der Canary überhaupt Metriken liefert.
| Aspekt | Argo Rollouts | Flux ImageUpdateAutomation | Ops-Hinweis | Stabilitätsnote |
|---|---|---|---|---|
| Auslöser | AnalysisRun-Webhook während Canary-Step | Image digest geändert → Git commit via Automation | CI muss Tags signieren | Klare Kausalität |
| Payload | Rollouts-Metriken + Job-IDs | Flux event / notification JSON | Schema im Repo versionieren | Größenlimit setzen |
| Canary | Rollouts weight / pause | Eigene Gateway-Gewichte + Tags | Multi-AZ-Latenzen beachten | Gateway-Matrix |
| Rollback | Automatisierte Rollback-Steps | Git revert + reconcile | Webhook quiescent Mode | Doctor vor Merge |
Webhook-Vertrag zwischen Flux Receiver und OpenClaw
Der Receiver-Endpunkt auf dem clustervps-Mac muss TLS, Bearer-Token oder HMAC, Content-Type application/json und eine Idempotenz-Schicht (Commit-Hash als Schlüssel) garantieren. Der Handler mappt Flux-Felder auf Ihre interne canary-Struktur, bevor irgendein Traffic umgeschaltet wird.
| Feld / Schicht | Pflicht | Validierung | Sicherheit | Beispielwert |
|---|---|---|---|---|
Authorization |
Bearer | const-time compare | 90-Tage-Rotation | Bearer ocw_… |
InvolvedObject |
Kind/Name/NS | Allowlist | Kein Wildcard-Match | ImageUpdateAutomation/ci |
artifact digest |
SHA256 | Rekonstruktion gegen Registry | Signaturpflicht | sha256:… |
retry-after |
Server-seitig | Exponentielles Backoff | Max drei Versuche | 2s,4s,8s |
audit log |
append-only | Byte-Quota | PII maskieren | /var/log/ocw-hook |
Mehrknoten-Konfigurationsscheiben (Slices)
Jeder OpenClaw-Knoten erhält eine Slice-Datei (gateway.d/region-xx.yaml) mit Routing-Gewicht, Tag-Label (canary vs stable) und Webhook-Pfad. Der Merge-Job läuft vor jedem Flux-POST und erzeugt eine kanonische Datei, damit parallele SSH-Sitzungen nicht widersprüchliche Gewichte lesen. Regionale DNS- und Artefakt-Hinweise finden sich in der Split-DNS-Matrix.
Kalibrieren Sie CPU- und RAM-Reserven pro Slice konservativ: ein fehlerhafter Automation-Commit darf keine vollständige Neujustierung aller Knoten auslösen, bevor doctor grün meldet. Dokumentieren Sie zudem, welche Notification Controller-Version auf dem Management-Cluster läuft, damit Payload-Drifts früh erkannt werden.
Sonden: openclaw doctor mergen
Führen Sie openclaw doctor --json auf jedem Gateway-Mac aus und mergen Sie die Ausgaben zu einem JSON-Array mit stabil sortierten Keys. Der Webhook-Handler vergleicht diese Datei gegen Schwellen (Latenz, Queue-Länge, freier APFS-Raum). Schlägt ein Teilfeld fehl, wird kein Canary-Traffic erhöht; stattdessen wird ein kompakter Fehlercode in die Broadcast-Queue geschrieben.
Legen Sie ein Zeitfenster fest, in dem Sonden gültig bleiben (z. B. fünf Minuten). Ältere Doctor-Snapshots verwirfen Sie, damit stale Metriken nach einem erfolgreichen Flux-Reconcile nicht versehentlich grün bleiben.
Fehler-Broadcast und Retry-Kappen
Der Notifier-Knoten (eigenständiger Mac in der Flotte) abonniert eine append-only-Datei oder einen lokalen Message-Bus. Jeder fehlgeschlagene Webhook schreibt eine Summary-Zeile mit Zeitstempel, Digest, betroffener Region und HTTP-Status. Teams integrieren dieselbe Pipeline wie im Cluster-Log-Webhooks-Leitfaden.
- Flux-Ressourcen:
ImageRepository+ImageUpdateAutomation+Receivermit exakt einem externen Ziel-URL pro Umgebung. - Token-Doppelbelegung: Neues Bearer-Token ausrollen, vierundzwanzig Stunden Überlappung mit altem Token erzwingen, danach altes Secret aus dem Key-Store löschen.
- Canary-Split: Start mit zehn Prozent Traffic auf
canary-Tag, exponentielle Erhöhung nur nach grünem Doctor-Merge. - Doctor-Merge: Skript sortiert JSON, entfernt doppelte Interface-Einträge, speichert nach
/var/lib/openclaw/probes.json. - Webhook-Handler: Validiert Digest, schreibt Audit, antwortet
202erst nach persistiertem State. - Broadcast + Cap: Summary an Notifier, maximal drei Flux-Retries mit Jitter, dann Pause und manuelle Freigabe.
FAQ
Brauche ich Kustomize-Helm für den Receiver? Beliebig, solange Secrets nicht im Klartext im Git landen; bevorzugen Sie SOPS oder externe Secret-Stores.
Was passiert bei divergierenden Doctor-Dateien? Merge bricht ab, Canary bleibt eingefroren, Broadcast enthält MERGE_CONFLICT.
Kann ein einzelner Mac mehrere Regionen simulieren? Nur zu Testzwecken; produktiv getrennte clustervps-Instanzen pro Region halten Latenz realistisch.
Flux-Canary mit OpenClaw skalieren
Lesen Sie weiter im Tech-Blog, springen Sie zur Startseite oder vergleichen Sie Mac-mini-M4-Pakete — reproduzierbare Webhook-Pfade brauchen konsistente Bare-Metal-Kapazität.