Permanente URL: 2026-openclaw-clustervps-rolling-upgrade-peer-deps-canary.html. Ergänzend zu diesem Runbook: Multi-AZ-Gateways, Probes & Webhooks, Canary, Skill-Slices & gemergte Probes, Mandanten-Split, Doctor & Webhook-Digests sowie rsync-Matrix für Mac-mini-Cluster. Den vollständigen Index finden Sie im Tech-Blog.
Die folgenden Schritte sind bewusst knapp gehalten und setzen voraus, dass Sie bereits Gateways, optional Worker und einen Notifier-Knoten betreiben. Wo Begriffe wie readyz oder Digest-Endpoints vorkommen, ersetzen Sie Host, Port und Pfade durch Ihre Produktionswerte — die Semantik entspricht den anderen OpenClaw-Artikeln in dieser Serie.
Schrittliste mit Rollback-Punkten
Arbeiten Sie die Liste von oben nach unten ab. Sobald ein Rollback-Punkt (R0–R3) greift, stoppen Sie das Rolling, stellen den letzten stabilen Zustand wieder her und erst danach analysieren Sie die Ursache.
- 0 Einfrieren:
openclaw.lock(oder Ihr Äquivalent), Load-Balancer-Gewichte, Skill-Symlinks und den globalennpm ls -g-Auszug dokumentieren. R0: Ohne diese Snapshots keine Paketänderungen. - 1 Canary-Host: Nur ein Knoten erhält die
npm -g-Sequenz aus dem nächsten Abschnitt; nach jeder Stufeopenclaw doctor --json. R1: doctor nicht „grün“ → auf die dokumentierte Vorversion pernpm -gzurück, Zusammenfassung an den Notifier broadcasten. - 2 Probes mergen: Auf dem Canary eine zusammengeführte
readyz-Antwort aus Doctor, Queue-Tiefe und Webhook-Digest erzeugen. R2: Harte Fehler im Merge-JSON → kein Traffic, Rolling pausieren. - 3 Traffic: Etwa 5 % neuer Sitzungen auf das Canary-Gateway lenken, mindestens zwei Probe-Intervalle abwarten, vor jeder Erhöhung die Merge-Probe erneut lesen. R3: SLO oder Fehlerquote kippt → Gewichte auf Snapshot zurück.
- 4 Weitere Knoten: Schritte 1–2 wiederholen; Worker-Constraints aus dem Multi-AZ-Artikel beibehalten (kein Promote vor verifiziertem Gateway).
- 5 Abschluss: Audit-Zeile mit Akteur, Ticket, Semver und
probe_sha256(oder Hash Ihrer Merge-Dateien) ins Log schreiben.
npm -g: empfohlene Reihenfolge
Für 2026.4.x ist die Annahme: Die globale Installationsreihenfolge verhindert hängende Zwischenzustände. Zuerst CLI und Kernlaufzeit (alles, was die Release Notes vor den Plugins verlangt), anschließend die offiziellen Plugin-Pakete in der dort dokumentierten Abhängigkeitsreihenfolge. Teams mit privatem Registry-Spiegel validieren auf dem Canary npm view, Cache-Kohärenz und gespiegelte Tarballs, bevor der Rest der Flotte folgt. Nach jeder Schicht openclaw doctor --json und npm ls -g --depth=0 ausführen; Peer-Warnungen landen im Ticket statt still ignoriert zu werden.
# Beispiel — Paketnamen und exakte Reihenfolge an Lockfile + Release Notes anpassen npm install -g openclaw@2026.4.x # Anschließend @openclaw/*-Plugins in der dokumentierten Spaltenreihenfolge, z. B.: # npm install -g @openclaw/plugin-foo@^2026.4.0 openclaw doctor --json | tee /tmp/doctor-after-core.json npm ls -g --depth=0 2>&1 | tee /tmp/npm-global.txt
npm config get prefix nutzen. Typische Peer-Drift entsteht, wenn ein Knoten Homebrew-, ein anderer PKG-basierte Prefixe mischt — genau dann liefert doctor auf Host A „ok“, während Host B zur Laufzeit an einem Plugin scheitert.Plugin-peers und 2026.4.x — sachlicher Kontext
In den jüngeren Releases der Hauptlinie wurden Peer-Metadaten von Plugins und Verweise in der Dokumentation mehrfach korrigiert; parallel tauchten Anpassungen in Mirror- und Image-Build-Pipelines auf, die dieselbe globale Auflösung berühren können. Maßgeblich für Ihr Verhalten im Betrieb bleiben weiterhin CHANGELOG und Release Notes der jeweiligen Version — dieser Artikel bewertet weder die Motivation noch die Tragweite dieser Änderungen. Vor dem Rolling sollten Sie in einer read-only-Umgebung Peer-Ranges, empfohlene Installationsreihenfolge und Breaking Changes abgleichen; bei privaten Registries prüfen Sie, ob die gespiegelte Plugin-Liste noch zum installierten CLI passt. ERESOLVE lösen Sie über die in den Notes genannten Versionsspannen; blindes npm install -g --force verschleiert nur den nächsten Produktionsabend.
Wenn Ihre CI-Images oder Sidecars neu gebaut werden, achten Sie darauf, dass die darin festgeschriebenen globalen Paketversionen mit dem Canary-Präfix übereinstimmen — sonst sieht der Container „grün“ aus, während Bare-Metal-Gateways nach dem Rolling andere Peer-Kanten sehen.
Doctor je Knoten und zusammengeführte Health-Probes
Jeder Mac, der nach dem Upgrade Traffic sieht, muss openclaw doctor einmal sauber durchlaufen. Nach außen reicht eine zusammengeführte Ready-Route: Das Gateway baut lokal Doctor-Kurzinfo, Queue-Wasserstand und Webhook-Digest (aggregierte Fehlerfläche) zu einem JSON. Das entspricht dem Muster „ein Ready-JSON“ aus dem Artikel Mandanten-Split, Doctor & Digests; der Digest ist ein Feld unter vielen und allein kein Freigabekriterium für Production-Traffic.
#!/usr/bin/env bash
set -euo pipefail
TENANT="${TENANT:-acme}"
/usr/local/bin/openclaw doctor --tenant "${TENANT}" --json >/tmp/doctor.json
/usr/bin/curl -fsS --max-time 3 "http://127.0.0.1:8088/readyz" -o /tmp/readyz.json
/usr/bin/curl -fsS --max-time 3 "http://127.0.0.1:9099/v1/webhook-digest" -o /tmp/digest.json
/usr/bin/python3 - <<'PY'
import hashlib, json, pathlib
parts = [pathlib.Path(p).read_bytes() for p in ("/tmp/doctor.json","/tmp/readyz.json","/tmp/digest.json")]
print(json.dumps({"merged_sha256": hashlib.sha256(b"".join(parts)).hexdigest()}))
PY
Weichen Semver, Lockfile und tatsächliche Auflösung auf der Platte auseinander, werten Sie das als harten Fehler. Bewusstes Herunterfahren einzelner Teilchecks gehört in ein degraded-Feld — nicht in „200 OK“ ohne Kontext, sonst lügt der Load Balancer.
Fehler-Broadcast und Canary-Rollback im Gleichschritt
Tritt während des Rollings doctor rot auf, bricht die zusammengeführte Probe hart weg oder reißt die Queue-Backpressure Ihre Schwelle, soll ein konfigurierter Notifier eine deduplizierte Kurz-Zusammenfassung schicken: Knoten-ID, Semver, Fehlercode, Auszug aus dem letzten Digest. So bleibt der Chat lesbar. Broadcast und LB-Rollback laufen parallel: zuerst Traffic abziehen (R3), danach Pakete bzw. Symlinks zurücksetzen (R1/R2), Rolling auf den übrigen Knoten stoppen und ein Ticket öffnen. Gesamtbild zu Webhooks und Token-Lifecycle: Multi-AZ-Gateways & Webhooks.
FAQ
Canary überspringen und alle Knoten auf einmal per npm anheben? Ungünstig. Peer- und Mirror-Inkonsistenzen zeigen sich typischerweise zuerst auf einem Host; ein Fleet-weiter Schritt vervielfacht den Rollback-Aufwand.
Betreffen Image-Build-Updates das Rolling? Ja, sobald CI eine andere globale Paketliste einbrennt als Ihre Bare-Metal-Gateways erwarten — dann scheitert doctor oder das Plugin-Laden trotz „grüner“ Pipeline. Vor dem Promote einmal einen Trockenlauf mit produktionsgleichem Prefix fahren.
Mindestgröße zum Üben? Ein Canary plus zwei stabile Gateways sind eine pragmatische Untergrenze, um Gewichts-Rollbacks und Registry-Spiegel realistisch zu drillen.
Hilfe, Startseite, Kauf & Artikel für bestehende Cluster
Öffentliche Einstiege ohne Konsole: Hilfe-Center, Überblick über Angebote auf der Startseite, Bestellung und Node-Erweiterung über Kaufen; Tarife vergleichen Sie unter Preise. Teams mit laufendem Mehrknoten-OpenClaw sollten dieses Runbook mit Canary & Skill-Slices, Multi-AZ-Gateways und Mandanten-Split & Doctor verzahnen — dann bleiben Rollbacks reproduzierbar.