Gordon Zimm
996490075a
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>
espo-deploy
Öffentliche, geheimnisfreie Artefakte für EspoCRM-Kunden-VMs. Alles hier wird von den VMs ohne Anmeldung abgerufen – es steht deshalb kein Passwort, kein Token und keine Kundenangabe in diesem Repository.
| Verzeichnis | Inhalt |
|---|---|
autoinstall/ |
NoCloud-Seed für die Basis-VM (user-data, meta-data) |
rmm-tasks/ |
Skripte, die als Task im ConnectWise RMM hinterlegt sind (Quelle für Änderungen) |
bin/ |
Skripte, die auf der VM unter /srv/espo/bin/ liegen und von Tasks aufgerufen werden |
compose/ |
Compose-Vorlage der Kundeninstanz und die EspoCRM-Grundeinstellungen (config-override.php) |
Konzept, Entscheidungen und Runbooks liegen im internen Repository espoCRM/espo-fleet-ops.
Autoinstall
autoinstall ds=nocloud-net\;s=https://gitea.subcura.net/EspoCRM_Public/espo-deploy/raw/branch/main/autoinstall/
Das Semikolon muss maskiert werden – in GRUB trennt ein unmaskiertes ; zwei Befehle.
Compose
compose/docker-compose.vorlage.yml ist für alle Kunden identisch und enthält genau einen Platzhalter: __FQDN__.
bin/espo-compose-rendern <fqdn> setzt ihn ein und schreibt /srv/espo/docker-compose.yml. Diese Datei auf der VM ist
ein Erzeugnis – sie wird bei jedem Lauf neu geschrieben, Änderungen von Hand gehen verloren. Geändert wird die
Vorlage hier im Repository.
Kundenspezifisches
Gehört nicht hierher, sondern in die Custom Fields des RMM (FQDN, Ring, Wartungsfenster). Geheimnisse entstehen auf
der VM (/srv/espo/secrets/, 0600) und verlassen sie nicht.