76 lines
5 KiB
Markdown
76 lines
5 KiB
Markdown
+++
|
|
title = "Die Zukunft von Matrix"
|
|
date = "2024-08-28"
|
|
draft = true
|
|
template = "blog/page.html"
|
|
|
|
[taxonomies]
|
|
authors = ["me"]
|
|
# tags = [
|
|
# "matrix",
|
|
# "element"
|
|
# ]
|
|
+++
|
|
|
|
Zunächst, ich bin eine private Person und stehe nicht in Verbindung zu Element oder der Matrix Foundation.
|
|
Daher kann ich nicht die Zukunft vorhersagen, sondern lediglich die ganzen Alphas und Betas bewerten und technisch hier einmal zusammensetzen.
|
|
|
|
Ein weiteres Wort vorweg, Element setzt sehr viel Energie daran, den Grundstock von Element auf eine moderne Technik zu setzen (sogar mit ein kompletten Rewrite der Clients, der gerade Element-X genannt wird).
|
|
Dieses Vorgehen ist löblich, doch zieht einige Änderungen im Betrieb nach sich und besteht nicht mehr nur aus einem Synapse-Server.
|
|
|
|
Die folgenden Artikel werden die einzelnen Komponenten und deren technisches Zusammenspiel einzeln erläutern.
|
|
Diese Artikel plane ich:
|
|
* [Element-Call](https://element.io/blog/introducing-native-matrix-voip-with-element-call/) der folgende Komponenten beschreibt:
|
|
* Element-Web / Element-X
|
|
* [Element-Call](https://github.com/element-hq/element-call)
|
|
* [Livekit JWT - Service](https://github.com/element-hq/lk-jwt-service)
|
|
* [Livekit](https://docs.livekit.io/home/self-hosting/deployment/)
|
|
* Synapse
|
|
* [Sliding-Sync](https://github.com/matrix-org/sliding-sync/blob/main/docs/Landing.md): neu Client API, [die 6000x schneller ist](https://element.io/blog/element-x-experience-the-future-of-element/).
|
|
* [Matrix-Authentification-Server (MAS)](https://matrix-org.github.io/matrix-authentication-service/): neu OIDC-Anbindung
|
|
|
|
## Deployments
|
|
|
|
Wie ihr bereits sieht, sind es ganz schön viele neue Komponenten,
|
|
da entsteht schnell die Frage,
|
|
wie soll man diese alle orchestrieren.
|
|
Meine berufliche Laufbahn hat mich zu Kubernetes geführt, den Weg der Element auch gerade geht.
|
|
Doch aus Sicht eines privaten Betreibers bin ich unglücklich von den Ideen:
|
|
- [Komischer Installer](https://ems-docs.element.io/books/element-on-premise-documentation-lts-2404/page/installing-element-server-suite#bkmrk-kubernetes-deploymen-2)
|
|
- [Kubernetes-Operatoren](https://github.com/element-hq/ess-starter-edition-core)
|
|
|
|
Zu letzteren möchte ich hier ein paar Worte verlieren.
|
|
|
|
### Für Applikation in ein Kubernetes-Cluster sollten Operatoren vermieden werden.
|
|
Hier erst mal eine kurze Begriffserklärung:
|
|
* Ein **Controller** greift auf der Kubernetes-API zu und "kontrolliert" den Workload.
|
|
Dabei kann er mittels eines ServiceAccounts und eine entsprechende RBAC-Rolle auf notwendig ConfigMap, Secrets und Deployments (usw.) zugreifen (durch die Rolle kann diese wunderbar in Namespaces eingesperrt werden).
|
|
* Ein **Operator** ist ein Controller, dessen Logik auf eigene CustomResourceDefinition (CRDs) basieren. Damit ist es eine Cluster-weite Erweiterung der API.
|
|
|
|
#### Warum?
|
|
|
|
Genau das ist das Problem, in vielen Kontexten möchte man nicht für jede Anwendung (und deren Version) ein ganzen Kubernetes Cluster hinstellen.
|
|
|
|
Operatoren verursachen folgende Probleme, die aus meiner Sicht beim Betrieb von Anwendungen benötigt werden:
|
|
* **Staging**, auch wenn die CRDs apiVersion vorsieht, ist nur im geringen Maße ein Staging möglich.
|
|
Der Operator muss alle apiVersion unterstützen und daher den aktuellen Stand entsprechen.
|
|
* **Separierung** ein Operator wird über die CRDs angesprochen, daher muss es für ihn möglich sein, in allen Namespaces Ressourcen verwalten können.
|
|
Dieses ist mit Vorsicht zu genießen. Immerhin ist es damit fast der ganze Cluster (wie für ihn unnötige Namespace und Pods und Secrets andere Applikation).
|
|
* **Shared Hosting** ist in Kubernetes generelle möglich,
|
|
durch die erwähnte Separierung mittels Namespaces und RBAC-Regeln können Benutzer voneinander getrennt (siehe [Rancher-Project](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces) oder [Capsule](https://capsule.clastix.io/)) werden.
|
|
Da ein Operator mindestens für die Installation der CRDs clusterweite Rechte benötigt, schließt man einen solchen Kunden aus.
|
|
PS: Das Teilen eines Clusters könnte nicht nur innerhalb eines Unternehmens (in Abteilungen oder Teams), sondern auch für private Personen, wenn wir an [Uberspace](https://uberspace.de/) denken.
|
|
|
|
Somit ist ein Operator zwar sinnvoll für die Erweiterung aus Infrastruktur-Sicht (Logging, Monitoring usw.), aber nicht aus Anwendungssicht.
|
|
|
|
#### Lösung
|
|
|
|
Neben den typischen Tools:
|
|
* Helm-Chart mit Jobs usw. (Meine sind [hier](https://codeberg.org/wrenix/helm-charts))
|
|
* Helmfile für komplexere Orchestrierung
|
|
* GitOps Operatoren ala FluxCD oder ArgoCD (gilt ja als Infrastruktur) (Meine sind [hier](https://codeberg.org/wrenix/flux-charts/src/branch/main/mycloud-matrix))
|
|
|
|
Hiermit der **Tipp**: Schreibt gerne **Controller**, der mittels Labels ConfigMaps und Secrets sich eure Anwendung konfigurieren lassen.
|
|
So ist es möglich feingranular, in Namespaces:
|
|
* Zu Stagen (mehrere verschiede Versionen des Controllers und der Anwendung)
|
|
* Auf Kubernetes-Ebene Berechtigungen mittels RBAC-Rollen innerhalb eines Namespaces zu beschränken.
|