Gordon Zimm
5c15ac3f0b
1. Gewartet wird jetzt auf ALLE vier Container, nicht nur auf espocrm. "health: starting" im Bericht war keine Aussage. Scheitert es, nennt die Fehlermeldung, welcher Container in welchem Zustand haengt. Gilt fuer ESPO-03, ESPO-10 und ESPO-12. 2. ESPO-10 raeumt alte Images weg: Es bleiben genau zwei je Anwendung, das laufende und das vorherige - fuer EspoCRM wie fuer MariaDB. Das vorherige muss bleiben, sonst zeigt die von ESPO-12 zurueckgerollte Compose auf einen Tag, der lokal nicht mehr liegt. Alles aeltere fuellte bisher nur das docker-lv; Docker raeumt von sich aus nichts weg. 3. ESPO-10 zeigt einen eigenen Abschnitt "Datenbank" mit Image, Version und Digest, analog zum Abschnitt "Instanz", sowie die Images auf der VM. 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) |
Nummernkreise der Tasks
| Kreis | Bedeutung | bisher |
|---|---|---|
0x |
von der leeren VM zur laufenden Instanz | 01 Grundeinrichtung, 02 Docker, 03 First-Deploy |
1x |
aktualisieren | 10 Update, 11 Snapshot verwerfen, 12 Snapshot wiederherstellen |
2x |
Betrieb und Überwachung | 20 Inventar (geplant), 21 Backup-Prüfung (geplant) |
3x |
Extensions | geplant |
Ein Kreis beginnt bei x0. Die Liste im RMM sortiert alphabetisch, die Reihenfolge stimmt damit.
| bin/ | Skripte, die auf der VM unter /srv/espo/bin/ liegen und von Tasks aufgerufen werden |
| docker/ | je Ring ein Ordner mit dem Stand dieses Rings: docker-compose.yml und 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 und Ringe
| Ordner | Ring | Inhalt |
|---|---|---|
docker/0 - intern/ |
0 | der aktuelle Stand, hier wird entwickelt und getestet |
docker/1 - Pilotkunde/ |
1 | freigegebener Stand für Pilotkunden |
docker/2 - Produktivkunde/ |
2 | freigegebener Stand für den Regelbetrieb |
Jeder Ordner enthält den vollständigen Stand dieses Rings: eine docker-compose.yml mit genau einem
Platzhalter (__FQDN__) und die config-override.php mit den EspoCRM-Grundeinstellungen.
Eine Freigabe ist das Kopieren dieser Datei in den nächsten Ordner – damit steht in jedem git diff, welche
Instanzen den neuen Stand bekommen.
bin/espo-compose-rendern <fqdn> <ring> holt den Stand des Rings, setzt den FQDN 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 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.