jitsi-meet — Projekt-Kontext für Claude-Sessions

Selbst-gehostete Jitsi-Meet-Instanz auf darkemberserver via k3s. Same-Cluster-Deploy wie Embertime/Gitea/Headscale. Repo unter ~/Developer/jitsi-meet/, Public-URL https://meet.it.financeflow.de.

Zweck: privater Online-Meeting-Service ohne Google-/GitHub-Login-Zwang (das öffentliche meet.jit.si verlangt seit 2024/25 Moderator-Auth). Wird unter anderem von Embertime als Default-Meeting-URL referenziert.

Architektur

Vier Container nach offiziellem jitsi/docker-jitsi-meet-Pattern:

web (jitsi/web): Nginx + Meet-Frontend, exposed via Ingress :443
prosody (jitsi/prosody): XMPP-Server, cluster-intern
jicofo (jitsi/jicofo): Focus/Conference-Manager, cluster-intern
jvb (jitsi/jvb): Videobridge — hostNetwork: true damit UDP 10001 direkt auf Node-Interface bindet. UDP 10000 ist auf darkember bereits von einer OpenDesk-Bundle-Jitsi-Instanz belegt (opendesk/jitsi-jvb LoadBalancer-Service), daher Shift auf 10001.

Inter-Component-Auth über shared XMPP-Component-Secrets (im Kubernetes-Secret, nicht im Repo).

Wichtigste Dateien

infra/k3s/00-namespace.yaml — Namespace jitsi
infra/k3s/10-config.yaml — ConfigMap mit nicht-sensiblen Env-Vars (XMPP-Domains, PUBLIC_URL, ...)
infra/k3s/20-secrets.yaml.example — Vorlage; echte Secrets manuell erzeugen via scripts/generate-secrets.sh, dann kubectl apply -f infra/k3s/20-secrets.yaml einmalig out-of-band
infra/k3s/30-prosody.yaml, 40-jicofo.yaml, 50-web.yaml, 60-jvb.yaml — Component-Deployments + Services
infra/k3s/70-ingress.yaml — Ingress mit cert-manager (letsencrypt-prod ClusterIssuer)
.gitea/workflows/deploy.yml — kubectl apply -f infra/k3s/... auf Push nach main
scripts/generate-secrets.sh — generiert random Component-Passwords + schreibt 20-secrets.yaml

Setup-Schritte (einmalig)

DNS: A-Record meet.it.financeflow.de → öffentliche IP von darkemberserver
Firewall/Router: UDP-Port 10001 auf darkember-Node forwarden (kritisch! ohne das funktioniert nur Audio, kein Video). Hinweis: 10000 ist von OpenDesks Jitsi-Bundle belegt, daher der Versatz.

Secrets generieren + applyen:

./scripts/generate-secrets.sh > infra/k3s/20-secrets.yaml
# DOCKER_HOST_ADDRESS in 60-jvb.yaml auf die Public-IP von darkember setzen
kubectl apply -f infra/k3s/20-secrets.yaml

Gitea-Repo + Secret KUBECONFIG_B64: Repo bei Gitea anlegen, KUBECONFIG_B64 als Repo-Secret hinterlegen (gleicher Wert wie bei Embertime), push.

Danach: Pipeline rollt aus, in ~3 Min steht https://meet.it.financeflow.de.

Was NICHT machen

Keine Authentifizierung aktivieren — der Witz ist, dass der Service ohne Login funktioniert. ENABLE_AUTH=0 ist Pflicht.
Keinen Jibri (Recording) ohne expliziten Auftrag — braucht extra Pod mit Chrome + viel mehr Ressourcen
Kein Helm — bleibt beim raw-Manifest-Pattern wie Embertime
Nicht replicas > 1 für prosody/jicofo — beide sind stateful Single-Instance
JVB skaliert prinzipiell horizontal, aber für ein Single-Cluster reicht 1 Replica

Verwandt im Obsidian-Vault

feedback_git_workflow.md — Klone-Pfad, Gitea-SSH-Setup
Embertime-CLAUDE.md (~/Developer/embertime/CLAUDE.md) — gleicher Deploy-Pattern, gleiches KUBECONFIG-Secret

3.3 KiB Raw Blame History