2.9 KiB
2.9 KiB
title, description, published, date, tags, editor, dateCreated
| title | description | published | date | tags | editor | dateCreated |
|---|---|---|---|---|---|---|
| Upgrades | Stack aktualisieren — alles über GitOps | true | 2026-08-14T04:58:09.067Z | 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.
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.