In diesem technischen Leitfaden zeigen wir Ihnen, wie Sie die Rundum-Lösung openDesk auf Ihrem eigenen Server mit K3s installieren und so Ihre digitale Unabhängigkeit selbst in die Hand nehmen.
Über die öffentliche Verwaltung hinaus sind viele Organisationen und Einzelanwender daran interessiert, sich von den großen Softwareanbietern unabhängiger zu machen. Genau hier liegen auch die Vorteile von Open-Source-Softwarelösungen mit ihrer Transparenz und openDesk wurde entwickelt, um diese Unabhängigkeit als vielseitige, flexible Office- und Kollaborationssuite zu ermöglichen.
Ein direkter Weg zu openDesk ist Selbsthosting in lokaler Umgebung. Durch die Kombination von openDesk mit K3s können auch kleinere Organisationen und Privatanwender eine souveräne und datenschutzfreundliche digitale Arbeitsumgebung auf ihrer eigenen Infrastruktur betreiben.
Diese Anleitung geht Schritt für Schritt auf die Installation von openDesk auf einem K3s Kubernetes-Cluster. Als schlanke, relativ einfach einzurichtende Kubernetes-Distribution ist K3s für ressourcenschonende Umgebungen gut geeignet.
Bitte beachten Sie: Grundkenntnisse in Kubernetes und der Kommandozeile sind für diese Anleitung hilfreich.
Bevor Sie mit der Installation von openDesk beginnen, soll Ihre Umgebung die folgenden Anforderungen erfüllen.
openDesk hat spezifische Anforderungen an den Kubernetes-Cluster und die unterstützende Infrastruktur. Die wichtigsten Punkte sind:
Ein bestehender Kubernetes (K8s) Cluster mit Version >= v1.24 ist notwendig. Es muss eine CNCF Certified Kubernetes Distribution sein. K3s erfüllt diese Anforderung, da es eine zertifizierte Distribution ist.
Sie benötigen eine Domain und einen konfigurierten DNS-Dienst, um openDesk zugänglich zu machen. openDesk ist so konzipiert, dass jede Anwendung bzw. jeder Dienst unter einer dedizierten Subdomain bereitgestellt wird. Es wird empfohlen, einen *.ihre-domain.tld A-Record sowie einen ihre-domain.tld A-Record für Ihren Cluster Ingress Controller zu erstellen.
Ein Ingress Controller ist erforderlich, um den externen Datenverkehr an die openDesk-Dienste innerhalb des Clusters weiterzuleiten. openDesk unterstützt den Ingress NGINX Controller, Version >= 4.11.5/1.11.5. Es ist wichtig, bestimmte Konfigurationen für den Ingress NGINX Controller vorzunehmen, um die Kompatibilität mit openDesk zu gewährleisten. Insbesondere müssen controller.allowSnippetAnnotations=true undcontroller.admissionWebhooks.allowSnippetAnnotations=true gesetzt werden, da openDesk-Komponenten Snippet-Annotationen verwenden.
Wichtiger Hinweis zu Ingress NGINX >= 1.12.0:
Mit der Veröffentlichung von Ingress NGINX 1.12.0 wurden neue Sicherheitsstandardeinstellungen eingeführt, die mit den aktuellen openDesk-Versionen inkompatibel sind. Wenn Sie Ingress NGINX >= 1.12.0 verwenden möchten, müssen die folgenden Einstellungen gesetzt werden:
controller.config.annotations-risk-level=Critical
controller.config.strict-validate-path-type=false
Stellen Sie außerdem sicher, dass Sie mindestens Ingress NGINX 1.11.5 oder 1.12.1 installieren, da frühere Versionen Sicherheitsprobleme aufweisen können.
Helm ist ein Paketmanager für Kubernetes und wird für die Bereitstellung von openDesk-Komponenten verwendet. Sie benötigen Helm Version >= v3.9.0, aber nicht v3.18.0 (aufgrund eines bekannten Fehlers). Neuere Versionen als v3.17.3 sollten ebenfalls funktionieren, die Version v3.17.3 wurde jedoch getestet.
Helmfile ist ein deklaratives Spezifikationssystem für die Bereitstellung von Helm-Releases. Es wird verwendet, um die über 35 Helm-Charts von openDesk zu konfigurieren und zu templaten. Sie benötigen Helmfile Version >= v1.0.0.
HelmDiff wird von Helmfile benötigt, um den gewünschten Zustand mit dem bereitgestellten Zustand zu vergleichen. Sie benötigen HelmDiff Version >= v3.11.0.
openDesk benötigt einen Volume Provisioner, der ReadWriteOnce (RWO) unterstützt. Für lokale Bereitstellungen ist ein lokaler oder hostPath-Provisioner ausreichend. Beachten Sie, dass einige Komponenten für den verteilten Modus oder die horizontale Skalierung einen ReadWriteMany (RWX) Volume Provisioner erfordern können.
Ein Zertifikatsmanager (z. B. cert-manager), der TLS-Zertifikate für Ihre Domain verwaltet, ist erforderlich. Wenn Sie cert-manager verwenden, muss dieser, einschließlich seiner speziellen Kubernetes-Definitionen (CRDs), vor der openDesk-Bereitstellung installiert sein.
In Single-Node-Konfigurationen ist es möglich, dass Fehler im Zusammenhang mit Filewatches auftreten, die mittels $ sudo sysctl -w fs.inotify.max_user_instances=10000000 behoben werden können.
Die folgenden Mindestanforderungen sind für eine erste Evaluierungsbereitstellung von openDesk vorgesehen. Für Produktionsumgebungen werden höhere Spezifikationen empfohlen:
Für die Entwicklung und Evaluierung von openDesk werden einige Dienste gebündelt. Für Produktionsbereitstellungen sollten Sie jedoch Ihre eigenen produktionsreifen Dienste verwenden. Empfohlene externe Dienste:
K3s ist eine ausgezeichnete Wahl für openDesk, da es leichtgewichtig und einfach zu installieren ist. Standardmäßig installiert K3s jedoch Traefik als Ingress Controller. Da openDesk den NGINX Ingress Controller bevorzugt, müssen Sie Traefik deaktivieren.
Wenn Sie K3s neu installieren, können Sie Traefik direkt während der Installation deaktivieren. Verwenden Sie dazu das --disable=traefik Flag:
$ curl -sfL https://get.k3s.io | sh -s -- --disable=traefik
Alternativ können Sie K3s über das Helper-Tool k3sup installieren:
$ k3sup install --cluster --host <Host IP> --user <Host User> --k3s-channel stable --k3s-extra-args '--disable traefik'
Wenn Sie bereits eine K3s-Installation mit aktiviertem Traefik haben, können Sie Traefik nachträglich deaktivieren. Die einfachste Methode ist, die K3s-Server mit dem --disable=traefik Flag neu zu starten.
Sie können auch die Traefik-Manifeste manuell entfernen:
$ sudo rm -rf /var/lib/rancher/k3s/server/manifests/traefik.yaml
Anschließend müssen Sie den K3s-Dienst neu starten:
$ sudo systemctl restart k3s
Nachdem Traefik deaktiviert wurde, können Sie den NGINX Ingress Controller installieren. Es wird empfohlen, die offizielle Helm-Chart zu verwenden. Stellen Sie sicher, dass Sie die Version installieren, die mit den openDesk-Anforderungen kompatibel ist (>= 4.11.5/1.11.5).
Fügen Sie das Helm-Repository für NGINX Ingress Controller hinzu:
$ helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
$ helm repo update
Installieren Sie den NGINX Ingress Controller mit den erforderlichen Snippet-Annotationen und angepassten Security Settings:
$ helm install ingress-nginx ingress-nginx/ingress-nginx \
--create-namespace \
--namespace ingress-nginx \
--set controller.allowSnippetAnnotations=true \
--set controller.admissionWebhooks.allowSnippetAnnotations=true \
--set controller.config.annotations-risk-level=Critical \
--set controller.config.strict-validate-path-type=false
Überprüfen Sie, ob der Ingress Controller erfolgreich bereitgestellt wurde:
$ kubectl get pods -n ingress-nginx
openDesk benötigt SSL-Zertifikate für ihre-domain.tld. Der einfachste Weg ist, Let’s Encrypt dafür zu nutzen. Im Folgenden wird der cert-manager installiert und ein ClusterIssuer für Let’s Encrypt eingerichtet. openDesk beantragt und installiert die benötigten SSL-Zertifikate dann vollautomatisch.
$ kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.18.2/cert-manager.yaml
Erstellen sie die Datei clusterissuer.yaml mit folgendem Inhalt. Setzen sie im Feld email ihre E-Mail-Adresse für Benachrichtigungen zu ablaufenden Zertifikaten ein:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer # I'm using ClusterIssuer here
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: <ihre-email@ihre-email-domain.tld>
privateKeySecretRef:
name: letsencrypt-prod
solvers:
- http01:
ingress:
class: nginx
Installieren sie den ClusterIssuer nun im Cluster:
$ kubectl apply -f clusterissuer.yaml
Für lokale Bereitstellungen eignet sich der Local Path Provisioner, der RWO unterstützt. Er erstellt dynamisch PVs auf dem Host-Dateisystem.
$ kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.32/deploy/local-path-storage.yaml
$ kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
Die Bereitstellung von openDesk erfolgt über Helmfile, das die Verwaltung der vielen Helm-Charts von openDesk vereinfacht.
Klonen Sie das openDesk-Bereitstellungs-Repository von GitLab (hier in der Version 1.11.0):
$ export OPENDESK_RELEASE="v1.14.1"
$ git clone -b $OPENDESK_RELEASE https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk.git
$ cd opendesk
Jetzt muss die Bereitstellung an Ihre Umgebung angepasst werden. Es wird empfohlen, dies in einer dedizierten Umgebung (z. B. dev , test oder prod ) und nicht direkt in den default Umgebungsdateien vorzunehmen, um Updates zu erleichtern.
Erstellen Sie eine Datei values.yaml.gotmpl für Ihre Umgebung. Für diese Anleitung verwenden wir dev :
touch helmfile/environments/dev/values.yaml.gotmpl
Bearbeiten Sie die helmfile/environments/dev/values.yaml.gotmpl Datei, um Ihre Domain und andere spezifische Einstellungen zu konfigurieren. Die wichtigsten Einstellungen sind:
Domain: Setzen Sie Ihre Domain unter global.domain. Beispiel:
global:
domain: "ihre-domain.tld"
Alternativ können Sie die Domain auch über eine Umgebungsvariable setzen:
bash export DOMAIN=ihre-domain.tld
Apps: Sie können bestimmte openDesk-Anwendungen aktivieren oder deaktivieren, indem Sie die apps.yourAppName.enabled Werte in dieser Datei anpassen. Eine Liste aller verfügbaren Apps und ihrer Standardwerte finden Sie unter helmfile/environments/default/opendesk_main.yaml.gotmpl.
Ein Beispiel zum Deaktivieren von Jitsi:
apps:
jitsi:
enabled: false
Cluster-Fähigkeiten: Konfigurieren Sie den Diensttyp (NodePort, LoadBalancer oder ClusterIP) für openDesk-Anwendungen, die externe Verbindungen benötigen (z. B. Jitsi, Dovecot).cluster:
service:
type: "NodePort"
Ingress Class Name: Wenn Ihr Ingress Controller nicht der Standard-Ingress Controller in Ihrem Cluster ist, können Sie den ingressClassName anpassen:ingress:
ingressClassName:
"ingress-nginx"
Ansonsten setzen sie bitte die folgende Einstellung:ingress:
ingressClassName: "nginx"
Zertifikate: Zuletzt verweisen sie openDesk auf den cert-manager ClusterIssuer aus dem vorherigen Schritt:
certificate:
issuerRef:
name: "letsencrypt-prod"
Die vollständige helmfile/environments/dev/values.yaml.gotmpl Datei sieht dann wie folgt aus:
global:
domain: "ihre-domain.tld"
cluster:
service:
type: "NodePort"
ingress:
ingressClassName: "nginx"
certificate:
issuerRef:
name: "letsencrypt-prod"
Nachdem Sie die Umgebung konfiguriert haben, kann openDesk mit Helmfile bereitgestellt werden. Stellen Sie sicher, dass Sie sich im opendesk Verzeichnis befinden, das Sie zuvor geklont haben.
Bevor wir openDesk bereitstellen, erzeugen wir einen dedizierten Kubernetes Namespace und machen ihn zum Standard-Namespace im aktuellen Kontext.
$ export OPENDESK_NAMESPACE="opendesk"
$ kubectl create namespace ${OPENDESK_NAMESPACE}
$ kubectl config set-context --current --namespace=${OPENDESK_NAMESPACE}
Nun können wir openDesk in diesem Namespace bereitstellen.
$ helmfile apply --environment dev --namespace ${OPENDESK_NAMESPACE}
Dieser Befehl wird alle erforderlichen Helm-Charts bereitstellen und die openDesk-Anwendungen in Ihrem K3s-Cluster installieren. Der Prozess kann einige Zeit in Anspruch nehmen.
Nach der Bereitstellung können Sie den Status der openDesk-Pods und -Dienste überprüfen:
$ kubectl get pods -A
$ kubectl get svc -A
$ kubectl get ingress -A
Alle Pods sollen den Status Running haben und die Ingress-Ressourcen sollen korrekt konfiguriert sein und auf Ihre Domain verweisen.
Geschafft, Sie haben openDesk auf Ihrem K3s-Cluster installiert! Sobald alle Dienste ausgeführt werden und der DNS-Eintrag korrekt eingestellt ist, können Sie openDesk über Ihre konfigurierte Domain in Ihrem Webbrowser aufrufen.
openDesk wird mit einem Administrator-Account installiert. Das Passwort kann im Cluster wie folgt ausgegeben werden:
$ kubectl get secret ums-nubus-credentials -o jsonpath='{.data.administrator_password}' | base64 -d
Diese Implementierung bietet eine sichere Basis für Ihre täglichen Office- und Kollaborationsanwendungen. Damit kommen Sie in den Genuss der zentralen Vorteile von Open-Source-Softwarelösungen: Transparenz, Flexibilität und die eigenständige Gestaltung einer souveränen Arbeitsumgebung.
Eine noch detailliertere Installationsanleitung sowie weiterführende technische Informationen finden Sie in unserer offiziellen Dokumentation auf GitLab.
openDesk 1.6 hebt die Dokumentenbearbeitung auf ein neues Niveau, optimiert die Zusammenarbeit in Tabellen sowie Präsentationen und fördert durch gezielte Sicherheitsverbesserungen die digitale Souveränität der Öffentlichen Verwaltung.
NeuigkeitenWichtiges Sicherheitsupdate für OpenProject, das einen kritischen Fehler behebt. Wir empfehlen ein zeitnahes Update.
Neuigkeiten