Exécuter Collabora en ligne sur plusieurs nœuds Kubernetes

Pour un déploiement Collabora Online multi-nœuds, utilisez le graphique Helm Kubernetes de Collabora derrière un proxy d'entrée ou un proxy inverse afin de centraliser toutes les requêtes concernant un même document sur le même pod Collabora. Cette affinité de session est essentielle : un équilibrage de charge classique de type round-robin peut répartir les requêtes d'édition et de presse-papiers d'un utilisateur sur différents pods et perturber l'édition collaborative. L'exemple ci-dessous utilise trois réplicas, un proxy d'entrée NGINX et un nombre fixe de réplicas ; remplacez les noms d'hôtes et le secret TLS par les vôtres.

De quoi avez-vous besoin avant d'ajouter des répliques ?

Vous avez besoin d'un cluster Kubernetes opérationnel avec au moins deux nœuds de travail, Helm, un contrôleur d'entrée prenant en charge la règle d'affinité requise, un nom DNS tel que `@ office.example.comCollabora.com` et un certificat TLS pour ce nom. Nextcloud doit être accessible par chaque pod Collabora à son origine WOPI publique, par exemple `@ https://cloud.example.comCollabora.com`. CODE et Nextcloud sont des services distincts ; ce guide configure la couche Collabora puis connecte son URL publique à Nextcloud Office.

Utilisez la configuration multi-réplicas documentée du graphique Collabora plutôt que de placer plusieurs conteneurs Docker indépendants derrière un équilibreur de charge générique. Un équilibreur de charge qui répartit chaque requête sans tenir compte de la source WOPI indiquée dans la documentation peut interrompre les sessions. Ce guide suit les instructions officielles du graphique Helm Collabora, disponibles le 10 octobre 2026. Les valeurs du graphique peuvent changer ; vérifiez donc les valeurs pour la version exacte que vous prévoyez d'installer.

1. Configurez les réplicas, l'affinité d'entrée et l'hôte WOPI.

Ajoutez le dépôt de graphiques, mettez à jour son index et examinez les valeurs par défaut actuelles du graphique avant d'écrire votre fichier de remplacement :

helm repo add collabora https://collaboraonline.github.io/online/
helm repo update
helm show values collabora/collabora-online

Créez le cluster my_values.yamlavec les paramètres de base ci-dessous. Cet exemple utilise l'annotation NGINX Ingress décrite dans le fichier README du graphique Collabora. Le hachage est effectué de WOPISrcsorte que les requêtes associées à un même document atteignent le même pod. La connexion TLS publique est également terminée au niveau de l'entrée ; les paramètres du serveur Collabora affichés correspondent à ce modèle TLS terminé par un proxy.

replicaCount: 3
autoscaling:
  enabled: false

ingress:
  enabled: true
  className: nginx
  annotations:
    nginx.ingress.kubernetes.io/upstream-hash-by: "$arg_WOPISrc"
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
  hosts:
    - host: office.example.com
      paths:
        - path: /
          pathType: ImplementationSpecific
  tls:
    - secretName: office-example-tls
      hosts:
        - office.example.com

collabora:
  aliasgroups:
    - host: "https://cloud.example.com:443"
  extra_params: --o:ssl.enable=false --o:ssl.termination=true

L' aliasgroupsentrée correspond à l'hôte WOPI de Nextcloud, et non au nom d'hôte Collabora. Veillez à utiliser une configuration précise, en respectant le schéma, le nom d'hôte et le port fournis par Nextcloud. Le secret TLS d'entrée doit se trouver dans l'espace de noms d'entrée et contenir un certificat valide office.example.com. Si la connexion TLS se termine ailleurs, suivez le modèle de proxy correspondant dans la documentation du graphique au lieu de copier extra_paramsaveuglément les deux indicateurs.

Attention : la mise à l’échelle automatique dépend de la version. L’exemple du fichier README du graphique désactive la mise à l’échelle automatique et prévient que celle-ci peut perturber l’édition collaborative et les opérations copier-coller, alors que le fichier de valeurs actuellement publié l’active par défaut. Pour obtenir un cluster initial prévisible, désactivez-la explicitement et choisissez un nombre de réplicas fixe. Ne réactivez la mise à l’échelle automatique qu’après avoir consulté les recommandations de la version exacte du graphique et effectué des tests de montée et de descente en charge lors de sessions d’édition réelles.

2. Installez le graphique et vérifiez l'emplacement des modules.

Installez le graphique dans un espace de noms dédié. Le dépôt officiel du graphique documente ce modèle de commande :

helm install --create-namespace \
  --namespace collabora \
  collabora-online collabora/collabora-online \
  -f my_values.yaml

Vérifiez ensuite que le déploiement a atteint le nombre de réplicas souhaité et voyez quels nœuds de travail hébergent les pods :

kubectl get pods -n collabora -o wide
kubectl get ingress -n collabora
helm status collabora-online -n collabora

Vérifiez que les trois pods sont prêts, que l'entrée possède l'hôte attendu et que les réplicas sont répartis sur les nœuds de travail si une résilience au niveau des nœuds est requise. Le nombre de réplicas seul ne garantit pas que Kubernetes placera les pods sur des nœuds distincts. Le modèle de graphique officiel expose les paramètres de sélection des nœuds, d'affinité et de tolérance ; configurez des règles d'ordonnancement adaptées à votre cluster et validez le graphique généré avant de vous y fier. Si votre version de graphique n'expose pas la stratégie dont vous avez besoin, utilisez une extension de graphique prise en charge ou une personnalisation de déploiement Kubernetes plutôt que de supposer que les pods sont répartis.

3. Connectez-vous à Nextcloud et vérifiez l'affinité des documents.

Dans Nextcloud, installez ou activez l' application Nextcloud Office , puis ouvrez les paramètres d'administration → Office . Sélectionnez le serveur Collabora externe et saisissez https://office.example.coml'URL du serveur. Cette URL correspond au point de terminaison TLS public accessible à la fois par le serveur Nextcloud et par les navigateurs des utilisateurs ; ne saisissez pas l'adresse IP du pod ni l'adresse du service interne.

Ouvrez un fichier DOCX ou ODT de test depuis Nextcloud. Modifiez-le depuis deux sessions utilisateur distinctes et vérifiez que les modifications sont visibles pour les deux utilisateurs. Consultez également les outils de développement du navigateur ou les journaux d'entrée pour détecter d'éventuelles erreurs WebSocket ; l'entrée doit maintenir la connexion à l'éditeur ouverte en permanence. Si les requêtes d'un fichier sont réparties sur plusieurs pods, vérifiez que le WOPISrcparamètre de requête est présent à l'endroit où l'entrée applique la règle de hachage et que le contrôleur d'entrée installé respecte l'annotation.

Que prouve un cluster sain ?

Un test réussi confirme que Nextcloud peut accéder au point de terminaison Collabora et qu'un document peut être modifié via l'entrée configurée. Il ne garantit cependant pas la continuité de chaque session active en cas de panne d'un pod ou d'un nœud. L'état d'édition étant géré par le pod hébergeant le document, une panne peut contraindre les utilisateurs à se reconnecter ou à rouvrir un fichier, même si d'autres répliques restent disponibles. Il est recommandé de tester les scénarios de maintenance et de panne avec des documents non critiques et de planifier les mises à niveau en prenant en compte la gestion des sessions WebSocket de longue durée.

Pour connaître la syntaxe actuelle et les limitations, consultez le fichier README et les valeurs du graphique Helm Kubernetes officiel de Collabora , le fichier de valeurs du graphique publié et le manuel de configuration d'Office pour Nextcloud . Vérifiez que les paramètres correspondent à la version du graphique que vous installez, car les exemples et les valeurs par défaut du dépôt peuvent différer.