Matrix (neu)

Matrix (matrix-new)

#

Migration des matrix-Namespace auf das offizielle ESS Helm Chart (matrix-stack).

Deployment

#

Komponenten

#

Unterschiede zur alten Konfiguration

#

Storage

#

Das Chart verwaltet PVCs selbst über die StorageClass longhorn (global via storage.storageClassName). Vor der ersten Migration gilt:

• matrix-new-postgres-data (10 Gi) — dynamisch provisioniert
• matrix-new-synapse-media (10 Gi) — dynamisch provisioniert

storage.yaml ist ein Migrations-Template für die spätere Übernahme bestehender Volumes (siehe Kommentare darin). Es ist nicht in kustomization.yaml aktiv.

Aktivierung (manifests.yaml)

#

Den auskommentierten Eintrag aktivieren:

1- name: matrix-new
2  dir: "apps/matrix-new"
3  namespace: matrix-new

Datenmigration

#

Kritisch: Der Synapse-Signierungsschlüssel muss übernommen werden. Ohne ihn gilt der Server gegenüber Federation-Partnern als neuer Server.

Schritt 1 — Signierungsschlüssel sichern

#

1SIGNING_KEY=$(kubectl exec -n matrix deploy/matrix -c main -- \
2  cat /data/matrix.kirchner.social.signing.key)
3
4kubectl create secret generic matrix-signing-key \
5  --from-literal=key="$SIGNING_KEY" \
6  -n matrix-new

In values.yaml unter synapse: eintragen:

1synapse:
2  signingKey:
3    secret: matrix-signing-key
4    secretKey: key

Schritt 2 — PostgreSQL-Daten migrieren

#

 1# Export aus altem Namespace
 2kubectl exec -n matrix deploy/matrix -c db -- \
 3  pg_dump -U synapse synapse > /tmp/synapse-dump.sql
 4
 5# Import in neuen Postgres-Pod
 6NEW_PG=$(kubectl get pod -n matrix-new -l app.kubernetes.io/component=postgres \
 7  -o jsonpath='{.items[0].metadata.name}')
 8
 9kubectl cp /tmp/synapse-dump.sql matrix-new/$NEW_PG:/tmp/synapse-dump.sql
10kubectl exec -n matrix-new $NEW_PG -- \
11  psql -U synapse -d synapse -f /tmp/synapse-dump.sql

Schritt 3 — Media-Dateien migrieren

#

1NEW_SYNAPSE=$(kubectl get pod -n matrix-new -l app.kubernetes.io/component=synapse \
2  -o jsonpath='{.items[0].metadata.name}')
3
4kubectl exec -n matrix deploy/matrix -c main -- \
5  tar cf - /data/media_store | \
6  kubectl exec -i -n matrix-new $NEW_SYNAPSE -- \
7  tar xf - -C /data/

Schritt 4 — Cutover

#

1# Alte Instanz stoppen
2kubectl scale deploy/matrix -n matrix --replicas=0
3
4# ArgoCD-Sync für matrix-new anstoßen

DNS: element.kirchner.social → Nutzer auf chat.matrix.kirchner.social hinweisen.

Alternative: Bestehende Longhorn-Volumes direkt übernehmen

#

Statt Datenkopie können die alten Volumes nach Löschen des alten Namespace direkt gebunden werden:

1. Alten Namespace stoppen, PVCs löschen

2. claimRef aus PVs entfernen:

   1kubectl patch pv matrix-db --type=json \
   2  -p='[{"op":"remove","path":"/spec/claimRef"}]'

3. In storage.yaml die volumeHandle-Werte anpassen, Datei in kustomization.yaml aktivieren

4. existingClaim in values.yaml setzen (Kommentare in storage.yaml beachten)

Nutzer-Migration (MAS)

#

Bestehende Authentik-Nutzer können via MAS-CLI migriert werden:

1MAS_POD=$(kubectl get pod -n matrix-new -l app.kubernetes.io/component=matrix-authentication-service \
2  -o jsonpath='{.items[0].metadata.name}')
3
4kubectl exec -n matrix-new $MAS_POD -- mas-cli manage \
5  migrate-upstream --help

Siehe: MAS Migrationsdokumentation