2026 OpenClaw MeshMac in der Praxis: Mehrknoten-Umgebungsvorlagen und Geheimnis-Injektion getrennt nach dev, staging und prod

Zielgruppe und Kernbegriffe

Gedacht für Teams, die mehrere Apple-Silicon-Builder, Gateways oder Agenten-Hosts orchestrieren und dabei konsistente OpenClaw-Konfiguration mit kontrollierten Abweichungen (Queues, GPU-Flags, Regionen) benötigen.

Kernbegriffe: OpenClaw, MeshMac, Umgebungsvariablen, Geheimnis-Isolation, Mehrknoten. Für das Dateilayout von API-Keys und Tokens siehe OpenClaw Geheimnisse & Mindestrechte.

Typische Schmerzpunkte

1. Schatten-Exports: Ad-hoc-export in interaktiven SSH-Sitzungen landet nicht in Git — der nächste Host driftet still.
2. Umgebungsübergriff: Ein falsch benanntes .env kopiert Staging-Endpunkte in Produktion.
3. Audit-Lücken: Ohne template_revision und deployment_id in den Logs lässt sich bei partiellem Ausfall eines Knotens kein belastbarer Nachweis führen.

Umgebungsmatrix: dev / staging / prod

Behandeln Sie jede Umgebung als Richtlinie, nicht nur als Ordnernamen: unterschiedliche Secret-Stores, Token-Scopes, Freigabetempo und Blast-Radius.

Schritt 1 — Repository-Layout und einheitliche Template-Verteilung

Vorlagen liegen in Git; Klartext-Geheimnisse niemals. Schreiben Sie TEMPLATE_REVISION als kurze Git-SHA in eine kleine Datei, die jeder Start oder Health-Check mitloggt.

openclaw-config/
  templates/
    openclaw.env.base.tpl
    overlay.dev.env
    overlay.staging.env
    overlay.prod.env
  nodes/
    worker-01.patch.env
    gateway-01.patch.env

Befehle (Maintainer-Laptop oder CI)

cd openclaw-config
git rev-parse --short HEAD > templates/.template_revision

Verifikation: test -s templates/.template_revision && wc -c templates/.template_revision — Ausgabe zeigt kleine, von null verschiedene Bytezahl.

Schritt 2 — Rendern pro Umgebung

Setzen Sie MESH_ENV explizit — leiten Sie ihn nicht allein vom Hostnamen ab. Reihenfolge: Basis + Overlay; Platzhalter verweisen auf Dateipfade für Geheimnisse, nicht auf eingebettete Werte.

export MESH_ENV=staging
export TEMPLATE_REVISION="$(cat templates/.template_revision)"
cat templates/openclaw.env.base.tpl \
  templates/overlay.${MESH_ENV}.env \
  | envsubst > /tmp/openclaw.${MESH_ENV}.env

Verifikation: grep -E '^(MESH_ENV|TEMPLATE_REVISION)=' /tmp/openclaw.${MESH_ENV}.env. Für koordinierte Cutovers zwischen Knoten: einheitliches Deploy & Task-Queue-Sync.

Schritt 3 — Mindestrechte-Mounts für Geheimnisse

Ein Verzeichnis pro Umgebung: Verzeichnisse 0750, Dateien 0440 für die Gruppe openclaw. Trennen Sie Dateinamen nach Rolle (Gateway vs. Worker), nicht nach „einer großen .env“.

sudo install -d -o root -g openclaw -m 0750 /etc/openclaw/secrets.d/staging
sudo install -m 0440 -g openclaw ./staging_api_token /etc/openclaw/secrets.d/staging/api_token
sudo chmod o-rwx /etc/openclaw/secrets.d/staging/*

Verifikation: sudo -u openclaw test -r /etc/openclaw/secrets.d/staging/api_token muss erfolgreich sein; ein normaler Nutzer ohne Gruppe openclaw scheitert. Abgleich mit Skill-Versionierung & Env-Vorlage.

Schritt 4 — Knotenspezifische Overrides

Nach dem Merge hängen Sie eine kleine Patch-Datei pro ComputerName oder NODE_ROLE an — nur für Queues, Feature-Flags, URLs, keine neuen Secret-Stores.

NODE_ID="$(scutil --get ComputerName | tr ' ' '-')"
test -f "templates/nodes/${NODE_ID}.patch.env" && \
  cat "templates/nodes/${NODE_ID}.patch.env" >> /tmp/openclaw.${MESH_ENV}.env

Verifikation: grep '^NODE_ID=' /tmp/openclaw.${MESH_ENV}.env entspricht dem Inventar; vergleichen Sie zwei Knoten derselben Rolle und stellen Sie sicher, dass nur die erwarteten Schlüssel abweichen.

Schritt 5 — Verifikation ohne Geheimnis-Leck

Vor dem Neustart des Dienstes: Schlüsselabdeckung beweisen; in CI nur redigierte Ausgaben speichern.

awk -F= '/^[A-Z0-9_]+=/ {print $1"=<redacted>"}' /tmp/openclaw.${MESH_ENV}.env \
  | sort | diff -u golden-keys.txt -

Führen Sie einen OpenClaw-Diagnosebefehl ohne Seiteneffekte als Dienstbenutzer aus (ersetzen Sie durch Ihr unterstütztes CLI):

sudo -u openclaw openclaw doctor --config /tmp/openclaw.${MESH_ENV}.env || true

Anforderung: fail-closed, wenn Pflichtschlüssel fehlen — kein stilles Weiterlaufen mit halbleerer Konfiguration.

Rollback, Änderungskontrolle und Audit-Checkliste

Rollback: Bewahren Sie die letzte funktionierende gerenderte Datei und SECRET_BUNDLE_VERSION versioniert auf. Zurückrollen bedeutet: bekannte Git-SHA der Templates und das vorherige Secret-Bündel erneut ausrollen — keine Live-Edits auf Produktionshosts.

git checkout <known_good_sha> -- templates/
./scripts/render-all.sh staging
sudo systemctl restart openclaw || sudo launchctl kickstart -k system/org.openclaw.worker

Audit- und Betriebs-Checkliste (HowTo-Ergänzung)

• ☐Jedes Deployment schreibt deployment_id, Git-SHA und Akteur in zentrale Logs.
• ☐Pro kopierter Secret-Datei Prüfsumme erfassen; Rotationen erhöhen SECRET_BUNDLE_VERSION.
• ☐Vierteljährlicher Drill: Staging aus „prod minus eins“-Template wiederherstellen und Time-to-Green messen.
• ☐Break-Glass auf prod-Geheimnisse nur mit Ticket-ID, referenziert in sudo- oder MDM-Sitzungsprotokollen.
• ☐Canary: zuerst ein Worker- und ein Gateway-Knoten, dann volles Mesh — siehe Mehrknoten-Kollaboration auf Mac-Mesh.