Brinkhaus openXEdge
Konzept v2

Wenn Sie in Einstellungen → Update auf Upgrade oder Downgrade klicken, läuft ein mehrstufiger Prozess. Dieses Dokument erklärt, was im Hintergrund passiert — nützlich, wenn etwas nicht wie erwartet abläuft.

Beteiligte Komponenten

  • MainUI — die Bedienoberfläche, die den Klick entgegennimmt und die Update-Dateien herunterlädt.
  • BOS Update Server (https://update.brinkhaus-gmbh.de) — die zentrale Quelle aller Firmware-Versionen, signiert mit einem Ed25519-Schlüssel.
  • UpdateService — ein eigener Hintergrund-Container auf der Edge, der den eigentlichen Austausch orchestriert. Er läuft in einem separaten Compose-Stack als der Haupt-Stack — denn er muss den Haupt-Stack neu starten können, ohne sich selbst zu beenden.

Phase 1: Auswahl und Download (durch MainUI)

  1. MainUI ruft die verfügbaren Versionen vom Update-Server ab.
  2. Sie klicken auf eine Version → MainUI lädt drei Dateien in genau dieser Reihenfolge:
    1. public-key.pem — der öffentliche Signatur­schlüssel
    2. docker-compose.yml.sig — die Signatur über die neue Compose-Datei
    3. docker-compose.yml — die eigentliche Compose-Datei (zuletzt!)
  3. MainUI verifiziert die Ed25519-Signatur. Bei Fehlschlag → Diagnose-Code 1009, Update wird abgebrochen.
  4. Die drei Dateien liegen jetzt unter /home/gmn-service/docker/updates/data/. Das Schreiben der Compose-Datei ist das Trigger-Ereignis für den UpdateService.

Phase 2: 7-Phasen-Deploy (durch UpdateService)

Der UpdateService prüft das Staging-Verzeichnis im 10-Sekunden-Takt. Sobald er eine neue docker-compose.yml findet, läuft folgender Ablauf:

PhaseAktion
1Validierung — gestagete Compose-Datei vorhanden und syntaktisch gültig?
2Backup — aktuelle Compose-Datei und description.json ins Backup-Verzeichnis kopieren.
3Stop — docker compose stop + docker compose rm -f für den Haupt-Stack (nicht down, damit das gemeinsame bos-internal-Netz erhalten bleibt).
4Deploy — atomares Kopieren der neuen Dateien an den Live-Speicherort. config.json wird nicht überschrieben (MainUI mergt neue Defaults beim Start).
5Start — .env neu generieren (für die aktuelle Multi-IP-Liste), docker compose pull, docker compose up -d.
6Health-Check — Container-Stabilität (≥ 10 s laufend, keine Restart-Loops) und HTTP-Probe gegen http://localhost:5000/api/version im Container.
7Cleanup (bei Erfolg) oder Rollback (bei Misserfolg).

Während des gesamten Vorgangs ist die Bedienoberfläche nicht erreichbar.

Phase 3: Rollback (nur bei Misserfolg)

Wenn der Health-Check innerhalb von 90 Sekunden nicht grün wird, springt der UpdateService automatisch zurück:

  1. Stack mit der neuen Version stoppen.
  2. Backup-Compose und -Description an den Live-Speicherort kopieren.
  3. Stack mit der alten Version wieder starten.
  4. Diagnose-Codes 2005 (Rollback gestartet), dann 2006 (erfolgreich) oder 2007 (fehlgeschlagen) absetzen.

💡 One-cycle backwards-compatibility: der vorherige UpdateService führt den Health-Check während eines Upgrades durch — die neue MainUI muss daher mindestens einen Update-Zyklus lang noch genauso auf http://localhost:5000/api/version antworten, wie es der alte UpdateService erwartet. Diese Regel galt nicht in 2.1.0 — alle Upgrades von 2.0.x rollten zurück; 2.1.1 hat es korrigiert.

Was bedeuten die Versionen in der Service-Tabelle?

In Einstellungen → Update sehen Sie nicht nur die Firmware­version (z. B. 2.2.1), sondern auch die individuellen Versionen jedes Docker-Containers:

Service-Versionen-Tabelle in der Update-Ansicht

Eine Firmware-Version ist eine Sammlung kompatibler Service-Versionen, festgelegt in der ausgelieferten docker-compose.yml. Updates ersetzen also nicht nur ein Image, sondern stellen eine geprüfte Kombination aus 9–11 Containern her.

Verwandt