Richtet EspoCRM auf einer vorbereiteten VM zum ersten Mal ein: Verzeichnisse,
Geheimnisse auf der VM erzeugt, config-override.php bereitgelegt, Compose aus
dem Stand des Rings gerendert, up -d, Warten auf app-check, Abschlusspruefung.
Bricht ab, sobald eine Instanz vorhanden ist (Container, Compose-Datei oder
data/config.php). Damit kann dieses Skript keine Migration ohne geprueftes
Backup ausloesen - Aktualisierungen bekommen einen eigenen Weg.
Die Abschlusspruefung misst zugleich die in ADR 0008 offenen Punkte:
Zeichensatz des Servers und Laenge der Record-IDs (36 = UUIDv4 aktiv, sonst
Abbruch). Die Datenbankabfragen laufen im Container und lesen das Passwort dort
aus der Secret-Datei.
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>
