CollaboraをKubernetesノード間でオンラインで実行する

マルチノードの Collabora Online デプロイメントでは、同じドキュメントへのすべてのリクエストを同じ Collabora ポッドに保持するイングレスまたはリバースプロキシの背後で Collabora の Kubernetes Helm チャートを使用します。このセッションアフィニティは不可欠です。通常のラウンドロビンバランシングでは、ユーザーの編集リクエストとクリップボードリクエストが異なるポッドに送信され、共同編集が中断される可能性があります。以下の例では、3 つのレプリカ、NGINX Ingress、および固定レプリカ数を使用しています。例のホスト名と TLS シークレットを、ご自身のものに置き換えてください。

レプリカを追加する前に必要なものは何ですか？

少なくとも 2 つのワーカー ノードを備えた稼働中の Kubernetes クラスター、Helm、必要なアフィニティ ルールをサポートするイングレス コントローラー、 などの DNS 名、office.example.comおよびその名前の TLS 証明書が必要です。Nextcloud は、たとえば のパブリック WOPI オリジンで各 Collabora ポッドからアクセスできる必要がありますhttps://cloud.example.com。CODE と Nextcloud は別々のサービスです。このガイドでは Collabora 層を構成し、そのパブリック URL を Nextcloud Office に接続します。

汎用ロードバランサーの背後に複数の独立したDockerコンテナを配置するのではなく、Collaboraチャートのドキュメントに記載されているマルチレプリカ構成を使用してください。ドキュメントのWOPIソースに関係なく各リクエストを分散するロードバランサーは、セッションを切断する可能性があります。このガイドは、2026年10月10日に公開された公式のCollabora Helmチャートの手順に基づいています。チャートの値は変更される可能性があるため、インストール予定のチャートリリースに合わせて値を確認してください。

1. レプリカ、イングレスアフィニティ、およびWOPIホストを設定します。

オーバーライドファイルを作成する前に、チャートリポジトリを追加し、インデックスを更新し、チャートの現在のデフォルト設定を確認してください。

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

my_values.yaml以下のコア設定を使用して作成してください。このサンプルでは、​​CollaboraのチャートREADMEに示されているNGINX Ingressアノテーションを使用しています。ハッシュ化WOPISrcが有効になっているため、1つのドキュメントに関連付けられたリクエストは同じPodに到達します。また、パブリックTLSはイングレスで終端されます。表示されているCollaboraサーバー設定は、このプロキシ終端TLSパタ​​ーンに対応しています。

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

エントリaliasgroupsは Nextcloud WOPI ホストであり、Collabora ホスト名ではありません。範囲を狭くし、Nextcloud が提示するスキーム、ホスト名、ポートを正確に使用してください。イングレス TLS シークレットはイングレス名前空間に存在し、有効な証明書を含んでいる必要がありますoffice.example.com。TLS が別の場所で終了する場合は、2 つのフラグを盲目的にコピーするのではなく、チャートのドキュメントにある対応するプロキシ パターンに従ってくださいextra_params。

バージョンによって異なる自動スケーリングに関する注意点があります。チャートのREADMEのサンプルでは自動スケーリングが無効になっており、スケーリングによって共同編集やコピー＆ペーストが妨げられる可能性があると警告されていますが、現在公開されている値ファイルでは自動スケーリングがデフォルトで有効になっています。予測可能な初期クラスタを作成するには、自動スケーリングを明示的に無効にして、固定のレプリカ数を選択してください。自動スケーリングについては、チャートのリリースに関するガイダンスを確認し、実際の編集セッションでスケールアップとスケールダウンをテストしてから再度検討してください。

2. チャートを設置し、ポッドの配置を確認します。

チャートを専用の名前空間にインストールします。公式チャートリポジトリには、このコマンドパターンが記載されています。

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

次に、デプロイメントが目的のレプリカ数に達したことを確認し、どのワーカーノードがポッドをホストしているかを確認します。

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

3 つのポッドすべてが Ready 状態であること、イングレスに想定されるホストが存在すること、ノードレベルの耐障害性が必要な場合はレプリカがワーカーノード全体に分散されていることを確認してください。レプリカ数だけでは、Kubernetes がポッドを別々のノードに配置することを保証するものではありません。公式チャートテンプレートには、ノードセレクタ、アフィニティ、およびトレランスの設定が公開されています。クラスタに適したスケジューリングルールを設定し、レンダリングされたチャートを検証してから、それらに頼るようにしてください。チャートリリースで必要なポリシーが公開されていない場合は、ポッドが分散されていると想定するのではなく、サポートされているチャート拡張機能または Kubernetes デプロイメントのカスタマイズを使用してください。

3. Nextcloudに接続し、ドキュメントの親和性を確認する

Nextcloud で、Nextcloud Officeアプリをインストールまたは有効化し、管理設定 → Officeを開きます。外部 Collabora サーバーを選択し、 を入力しますhttps://office.example.com。サーバー URL は、Nextcloud サーバーとユーザーのブラウザーの両方がアクセスできるパブリック TLS エンドポイントです。ポッド IP または内部サービス アドレスは入力しないでください。

Nextcloud からテスト用の DOCX または ODT ファイルを開きます。2 つの別々のユーザー セッションで編集し、両方のユーザーが変更を確認できることを確認してください。また、ブラウザの開発者ツールまたはイングレス ログで WebSocket エラーがないか確認してください。イングレスは、長時間の編集接続を維持する必要があります。1 つのファイルの要求が複数のポッドに分散されている場合は、WOPISrcイングレスがハッシュ ルールを適用する場所にクエリ パラメータが存在すること、およびインストールされているイングレス コントローラが注釈を尊重していることを確認してください。

健全なクラスターは何を証明しているのか？

テストが成功すれば、Nextcloud が Collabora エンドポイントに到達でき、設定されたイングレスを介してドキュメントを編集できることが確認できます。ただし、すべてのアクティブなセッションが Pod またはノードの障害後も存続することを保証するものではありません。編集状態は、そのドキュメントを提供する Pod によって処理されるため、他のレプリカが引き続き利用可能であっても、障害が発生するとユーザーは再接続またはファイルの再オープンが必要になる場合があります。重要度の低いドキュメントを使用してメンテナンスおよび障害シナリオをテストし、長期間継続する WebSocket セッションが適切に処理されるようにアップグレードを計画してください。

最新の構文と注意事項については、Collaboraの公式Kubernetes HelmチャートのREADMEと値、公開されているチャート値ファイル、およびNextcloudのOffice構成マニュアルを参照してください。リポジトリの例とデフォルト値は同一ではない可能性があるため、インストールするチャートのバージョンに合わせて設定を確認してください。