fix: start writting matrix posts

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" ]
+CMD [ "--index", "index.html", "/data" ]

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]

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.