Der Task entscheidet per If/Then auf espo_zustand, ob er laufen darf; die
Skripte brauchen den Wert dann nicht mehr. ESPO-01 nimmt nur noch den
Kundennamen, ESPO-02 kein Argument, ESPO-03 fqdn und ring.
In ESPO-03 bleibt die Pruefung auf eine vorhandene Instanz - sie beruht auf
Tatsachen auf der VM, nicht auf einem Feldwert, und verhindert eine Migration
ohne geprueftes Backup.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Statt lokaler Merkmale steuert das Custom Field espo_zustand zentral, was laufen
darf. Jedes der drei Skripte nimmt den Wert als Argument und bricht ohne
Aenderung ab, wenn er nicht NEU ist.
In ESPO-03 bleibt die Pruefung auf eine vorhandene Instanz als Rueckfall
erhalten: Der Zustand im RMM ist von Hand aenderbar, eine laufende Instanz ist
es nicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Vorlage ist fuer alle Kunden identisch und traegt genau einen Platzhalter
(__FQDN__); bin/espo-compose-rendern setzt ihn ein und schreibt
/srv/espo/docker-compose.yml. Keine .env mehr: alles ausser den Geheimnissen
steht in der Compose selbst.
Inhalt der Vorlage: Bind-Mounts unter /srv/espo, Datei-Secrets fuer die beiden
MariaDB-Passwoerter, Record-IDs als uuid4/36 ueber configs (in allen drei
EspoCRM-Diensten, weil configs nicht ueber volumes_from vererbt werden),
adminUpgradeDisabled, WebSocket ueber wss://<fqdn>/wss, Healthchecks mit
Startfenstern fuer den Migrationslauf.
ESPO-02 setzt keine abweichende Bindeadresse mehr - die Ports muessen fuer den
Reverse Proxy erreichbar sein. Stattdessen beschraenkt eine DOCKER-USER-Regel
den Zugang auf das eigene Subnetz, das die VM selbst ermittelt; eine
systemd-Unit setzt sie nach jedem Docker-Start neu.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
