4.1 KiB
title, description, published, date, tags, editor, dateCreated
| title | description | published | date | tags | editor | dateCreated |
|---|---|---|---|---|---|---|
| Upgrades | Stack aktualisieren — alles über GitOps | true | 2026-08-14T14:34:49.634Z | markdown | 2026-08-13T20:27:33.029Z |
Der Stack wird per GitOps aktualisiert — nichts von Hand am Cluster, alles über einen Commit nach git.lab (nie direkt nach Gitea pushen).
ESS-Chart
- Chart-Version in
apps/production/element-server-suite.yaml(HelmRelease) anheben, committen → Flux zieht die neue Version. - Vorher das Changelog/Breaking-Changes der ESS-Version prüfen (die Schema-Validierung ist streng — ungültige Werte brechen den Reconcile mit kryptischen Fehlern).
Einzel-Images (Authentik, coturn, ClamAV, Draupnir, Wiki.js …)
- Image-Tag im jeweiligen Manifest anheben, committen → Flux rollt neu aus.
- Bei DB-Schema-Migrationen (Authentik, Wiki.js): vorher ein aktuelles Backup sicherstellen.
Ablauf
- Backup-Stand prüfen.
- Version im Repo anheben, committen, nach git.lab pushen.
flux reconcilebeobachten; Pods + Health prüfen.- Bei Problemen: Commit zurückrollen — GitOps macht das Rollback trivial.
Stack-Anpassungen & Fork-Porting
Beim Upgrade der zugrundeliegenden Element-/Synapse-Versionen müssen unsere Anpassungen mit. Wo sie liegen:
| Komponente | Basis | Änderungen dokumentiert in |
|---|---|---|
| ThreadNet Web (Element-Web-Fork) | Element Web/Desktop 1.12.17 |
ThreadNet-Web:docs/axion1337-fork.md · /betrieb/element-customization |
| threadnet-call (Element-Call-Fork) | Element Call 0.19.2 (via emmick4/element-call livekit) |
threadnet-call:docs/axion1337-fork.md · /betrieb/element-call |
| Synapse & Stack | ESS v26.4.0 — kein Code-Fork, nur Config/Module |
gitops (synapse-values.yaml, clamav_spam_checker.py, …) + die jeweiligen Betriebsseiten |
Ablauf beim Element-Upgrade eines Forks:
- Ziel-Upstream-Version wählen; das jeweilige
axion1337-fork.mdist die Liste dessen, was re-appliziert/geportet werden muss. - Rebase/Merge auf die neue Version; die dort genannten kritischen Dateien zuerst prüfen (dort sitzt die Merge-Reibung).
- Bauen, Image nach Gitea publizieren, im gitops-Stack die Version anheben (siehe oben).
Synapse/Stack ist kein Fork: unsere Eingriffe sind GitOps-Config (Room-Policies, ClamAV-Modul, Backups, TURN-Rotation …) und wandern mit dem ESS-Chart-Upgrade automatisch mit — dokumentiert auf den jeweiligen Betriebsseiten, nicht als Code-Diff.
Wiki.js: Startup-Patch (Zeitzone)
Wiki.js läuft als Upstream-Image (ghcr.io/requarks/wiki:2.5) — kein Code-Fork, keine Build-Pipeline. Unsere eine Anpassung wird als Startup-Overlay im Deployment (apps/production/wikijs.yaml, Container-command) eingespielt: neue OIDC-Nutzer bekommen timezone: 'Europe/Berlin' statt des Wiki.js-Defaults America/New_York. Wiki.js legt SSO-Nutzer in processProfile (server/models/users.js) ohne Zeitzone an, sonst greift der DB-Spalten-Default (New York). Der Container sed-patcht die Datei vor dem Boot — idempotent (grep-Guard) und fail-open (Wiki.js startet auch, wenn der Patch nicht greift; neue Nutzer fielen dann auf New York zurück).
⚠️ Beim Wiki.js-Upgrade prüfen: Der Patch hängt am Anker localeCode: WIKI.config.lang.code, in users.js. Ändert sich diese Zeile in einer neueren Version, muss der sed im Deployment nachgezogen werden (der ⚠️-Kommentar steht direkt im Manifest). Gleiche Logik wie bei den Element-Forks oben: Upstream-Bump → Patch gegenprüfen → ggf. Anker anpassen. Der localeCode selbst kommt bereits aus der Standard-Locale (de), nur die Zeitzone braucht den Patch.
Kadenz & CVE-Bezug
Updates sind zugleich unser wichtigster CVE-Fix (siehe Sicherheit & CVE-Remediation). Deshalb:
- Regelmäßig (Richtwert monatlich) Basis-Images/Charts anheben — nicht warten, bis der Report explodiert.
- Ad-hoc bei einer CRITICAL-CVE mit verfügbarem Fix.
:latest-Tags vermeiden (z.B. coturn) — sonst kein reproduzierbarer/scanbarer Stand.