45 lines
1.7 KiB
Markdown
45 lines
1.7 KiB
Markdown
# Parallelbetrieb mit OpenClaw
|
|
|
|
## Empfehlung
|
|
|
|
Lass OpenClaw in einem **separaten Compose-Projekt** laufen.
|
|
|
|
Das Repo hier geht davon aus, dass OpenClaw bereits existiert oder separat gepflegt wird. Dadurch bleiben Updates, Logik und Fehlersuche voneinander getrennt.
|
|
|
|
## Regeln gegen Konflikte
|
|
|
|
- andere Host-Ports als Hermes verwenden
|
|
- eigenes Volume oder eigener Basisordner fuer OpenClaw
|
|
- eigener Compose-Projektname
|
|
- wenn moeglich kein gemeinsamer Schreibzugriff auf denselben Host-Pfad
|
|
- Shared-Netz nur verwenden, wenn es einen echten Grund gibt
|
|
- fuer Internetzugang idealerweise dasselbe Muster verwenden: **eigenes externes Macvlan-Netz auf `br0` oder bewusst dasselbe externe `br0`-Netz mit eigener IP**
|
|
|
|
## Sichere Defaults
|
|
|
|
Hermes expose't nur lokal:
|
|
|
|
- `127.0.0.1:18642/tcp` fuer API/Health
|
|
- `127.0.0.1:19119/tcp` fuer Dashboard, falls aktiviert
|
|
|
|
OpenClaw sollte auf einem **anderen** Host-Port laufen, z. B. `127.0.0.1:18080` oder `127.0.0.1:18081`, je nach Image.
|
|
|
|
## `br0`-Hinweis
|
|
|
|
Wenn OpenClaw wie Hermes ueber `br0` ins Netz soll, hast du zwei saubere Optionen:
|
|
|
|
1. **gleiches externes Docker-Netz** verwenden, mit eigener statischer IP je Container
|
|
2. **separates zweites Macvlan-Netz** auf demselben Parent `br0` anlegen
|
|
|
|
Option 1 ist einfacher. Option 2 ist strenger getrennt.
|
|
|
|
## Wann das Shared-Netz sinnvoll ist
|
|
|
|
Nur wenn sich OpenClaw und Hermes wirklich gegenseitig erreichen muessen, z. B. fuer einen lokalen Upstream-Endpoint oder Kontrollpfad. Ansonsten reicht die komplette Trennung.
|
|
|
|
## Beispiel fuer OpenClaw
|
|
|
|
Siehe `compose/openclaw.override.example.yaml`.
|
|
|
|
Das ist bewusst nur eine Vorlage, weil der OpenClaw-Docker-Oekosystem-Stand momentan fragmentiert ist und verschiedene Images unterschiedliche Environment-Variablen erwarten.
|