147 lines
4.7 KiB
Markdown
147 lines
4.7 KiB
Markdown
# Info-Board Neu - Tech Stack
|
|
|
|
## Ziel
|
|
|
|
Dieses Dokument zieht die Technologieentscheidungen verbindlich zusammen, damit sie nicht nur verteilt in Plan und Todo-Liste stehen.
|
|
|
|
Leitlinien:
|
|
|
|
- moeglichst wenige Laufzeitabhaengigkeiten
|
|
- gute Portabilitaet zwischen Raspberry Pi OS und Debian
|
|
- einfache Verteilung per Ansible
|
|
- robuste Offline-Faehigkeit
|
|
- moeglichst wenig Ballast auf den Playern
|
|
|
|
## Verbindliche Entscheidungen
|
|
|
|
### Betriebssysteme
|
|
|
|
- Player: aktuelles Raspberry Pi OS Lite auf Debian-13-Basis
|
|
- Server: Debian-artiges System, bevorzugt mit Docker Compose betrieben
|
|
|
|
### Display-Stack auf dem Player
|
|
|
|
- Version 1 basiert auf X11
|
|
- keine volle Desktop-Umgebung
|
|
- kein LXDE, kein LightDM als Pflichtbestandteil
|
|
- Chromium laeuft im Kiosk-Modus gegen eine lokale Player-Oberflaeche
|
|
|
|
Begruendung:
|
|
|
|
- X11 ist fuer Chromium-Kiosk auf Raspberry Pi aktuell konservativer und besser vorhersehbar als Wayland
|
|
- weniger Ueberraschungen bei Screenshot-Erzeugung, Display-Steuerung und Watchdog-Verhalten
|
|
|
|
### Programmiersprachen
|
|
|
|
- `Go` ist die bevorzugte Sprache fuer systemnahe Komponenten
|
|
- `Go` ist die Standardwahl fuer den `player-agent`
|
|
- `Go` ist die bevorzugte Sprache fuer das Server-Backend, solange keine zwingenden Gruende dagegensprechen
|
|
- Browser-Oberflaechen werden mit einem normalen Web-Frontend-Stack umgesetzt
|
|
|
|
Begruendung:
|
|
|
|
- statische oder weitgehend selbstgenuegsame Binaries
|
|
- geringe Laufzeitabhaengigkeiten
|
|
- gute Cross-Compile- und Deploy-Eigenschaften
|
|
- passend fuer Debian- und Raspberry-Pi-Umgebungen
|
|
|
|
### Frontend-Stack
|
|
|
|
- Admin-UI: Web-Anwendung
|
|
- Tenant-/Monitor-UI: Web-Anwendung
|
|
- Player-UI: lokale Web-Anwendung fuer den Renderer
|
|
|
|
Noch offen, aber bewusst klein zu halten:
|
|
|
|
- Framework-Auswahl fuer Server-UIs, bevorzugt leichtgewichtig
|
|
- keine unnötig schwere Fullstack-Plattform nur aus Gewohnheit
|
|
|
|
### Server-Betrieb
|
|
|
|
- zentrale Komponenten bevorzugt in Docker Compose
|
|
- getrennte Services fuer Backend, Datenbank, MQTT und Reverse Proxy
|
|
- persistente Daten ausserhalb fluechtiger Container-Dateisysteme
|
|
- Provisionierungsjobs laufen serverseitig ueber einen dedizierten Worker oder Jobrunner
|
|
|
|
### Player-Betrieb
|
|
|
|
- keine Voll-Containerisierung des Grafikpfads in Version 1
|
|
- native systemd-Dienste fuer `player-agent` und Browser-Startlogik
|
|
- lokale Verzeichnisse fuer Cache, Medien, Status und Logs
|
|
|
|
### Provisionierung und Deployment
|
|
|
|
- die technische Erstinstallation neuer Screens wird ueber SSH + Ansible umgesetzt
|
|
- das Admin-Backend ist die steuernde Oberflaeche, aber nicht der Ort fuer eigentliche Shell-Logik
|
|
- Root-Passwoerter dienen nur als Bootstrap-Mittel und sollen nicht dauerhaft gespeichert werden
|
|
- nach der Erstinstallation erfolgt die weitere Verwaltung schluesselbasiert
|
|
|
|
## Zielkomponenten
|
|
|
|
### Player
|
|
|
|
- `player-agent` in `Go`
|
|
- `player-ui` als lokale Web-Oberflaeche
|
|
- Chromium als Renderer
|
|
- Xorg-Minimalstack
|
|
- systemd fuer Start, Neustart und Watchdog-Integration
|
|
|
|
### Server
|
|
|
|
- Backend-API in `Go`
|
|
- Admin-UI als Web-Frontend
|
|
- Tenant-UI als Web-Frontend
|
|
- PostgreSQL
|
|
- MQTT-Broker, bevorzugt Mosquitto
|
|
- Reverse Proxy
|
|
- Dateispeicher fuer Uploads, Caches und Screenshots
|
|
|
|
## Kommunikationsstack
|
|
|
|
- HTTPS fuer API, Upload, Download, Authentifizierung und Screenshots
|
|
- MQTT fuer Heartbeat, Status, Kommandos und Acknowledgements
|
|
|
|
Nicht vorgesehen:
|
|
|
|
- Medienuebertragung ueber MQTT
|
|
- permanente Spezial-Streams fuer den Regelbetrieb
|
|
|
|
## Laufzeit-Minimum auf dem Player
|
|
|
|
Anzustreben sind nur diese grossen Bausteine:
|
|
|
|
- Raspberry Pi OS Lite
|
|
- Xorg-Minimalstack
|
|
- Chromium
|
|
- eigenes `Go`-Binary fuer den Agenten
|
|
- systemd
|
|
|
|
Moeglichst zu vermeiden:
|
|
|
|
- komplette Desktop-Umgebungen
|
|
- mehrere externe Viewer wie `feh`, `vlc`, `wmctrl`, `xdg-open`
|
|
- umfangreiche Python- oder Node-Laufzeitstapel direkt auf dem Player
|
|
|
|
## Build- und Deployment-Richtung
|
|
|
|
- `Go`-Binaries sollen zentral gebaut und per Ansible verteilt werden koennen
|
|
- Konfiguration soll dateibasiert und gut templatisierbar sein
|
|
- Frontend-Artefakte sollen versioniert und reproduzierbar baubar sein
|
|
|
|
## Architekturfolgen aus diesen Entscheidungen
|
|
|
|
- der Player bleibt moeglichst nah an einem Appliance-Modell
|
|
- Browserfehler duerfen nicht direkt die eigentliche Logik bestimmen
|
|
- Renderer und Systemlogik bleiben getrennt
|
|
- Serverlogik ist zentralisiert, Playerlogik minimal und robust
|
|
|
|
## Bewusst vertagte Entscheidungen
|
|
|
|
- moeglicher spaeterer Wechsel auf Wayland
|
|
- exakte Frontend-Framework-Wahl
|
|
- genaue Auspraegung des Build-Systems fuer Frontend-Artefakte
|
|
- eventuelle Objekt-Storage-Einfuehrung statt einfachem Dateispeicher
|
|
|
|
## Aktueller technischer Grundsatz
|
|
|
|
Wenn zwei Varianten funktional gleichwertig sind, wird die Variante mit weniger Laufzeitabhaengigkeiten, einfacherem Deployment und besserem Offline-Verhalten bevorzugt.
|