diff --git a/Containerfile b/Containerfile index ea18cbd..e1c416c 100644 --- a/Containerfile +++ b/Containerfile @@ -1,4 +1,4 @@ -FROM ghcr.io/getzola/zola:v0.18.0 as builder +FROM ghcr.io/getzola/zola:v0.19.2 as builder COPY content content COPY static static @@ -12,4 +12,4 @@ RUN [ "/bin/zola", "build" ] FROM docker.io/svenstaro/miniserve:alpine COPY --from=builder /public /data -CMD [ "--index", "index.html", "/data" ] \ No newline at end of file +CMD [ "--index", "index.html", "/data" ] diff --git a/config.toml b/config.toml index 5fca1b2..c1de288 100644 --- a/config.toml +++ b/config.toml @@ -2,7 +2,7 @@ base_url = "https://wrenix.eu" title = "WrenIX" description = "Der Zaunkönig im Netzwerk" -generate_feed = true +# generate_feed = true compile_sass = true build_search_index = false @@ -14,7 +14,7 @@ taxonomies = [ {name = "tags"} ] -feed_filename = "rss.xml" +# feed_filename = "rss.xml" default_language = "de" [languages.en] diff --git a/content/2024-08-23-matrix.md b/content/2024-08-23-matrix.md new file mode 100644 index 0000000..9229b2c --- /dev/null +++ b/content/2024-08-23-matrix.md @@ -0,0 +1,73 @@ ++++ +title = "Die Zukunft von Matrix" +date = "2024-08-28" + +[taxonomies] +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.