Collabora Online в Docker Compose: готовый файл

MAATRIX

Nextcloud сам по себе — это только файловое хранилище: открыть .docx прямо в браузере и вместе с коллегой отредактировать таблицу он не умеет. Эту функцию добавляет отдельный редакторский движок, и Collabora Online (CODE) — самый популярный self-hosted вариант на базе LibreOffice. Ниже — рабочий docker-compose.yml, разбор WOPI-настроек, из-за которых чаще всего не подключается редактор, и SSL-связка через reverse proxy.

Что такое Collabora Online и чем он отличается от OnlyOffice

Collabora Online Development Edition (CODE) — это LibreOffice, упакованный в контейнер и выставленный наружу через WOPI-протокол: внешнее приложение (Nextcloud, ownCloud, собственный сервис) присылает документ, CODE рендерит его в браузере через LibreOffice-движок и синхронизирует правки обратно. По сути это тот же принцип, что у OnlyOffice Docs, но реализация другая — движок рендеринга не свой, а LibreOffice, что сказывается на совместимости форматов.

Главное практическое отличие от OnlyOffice — в точности отображения файлов, сделанных в Microsoft Office. OnlyOffice изначально целился в максимальную бинарную совместимость с форматами .docx/.xlsx/.pptx, потому что построен на движке, разделяющем родословную с MS Office. Collabora через LibreOffice исторически чуть слабее держит сложную вёрстку (нестандартные стили, макросы, специфичные диаграммы), зато лучше работает с открытыми форматами (.odt/.ods/.odp) и имеет более щедрую бесплатную лицензию для self-hosted использования без ограничения по числу пользователей — у OnlyOffice Community Edition лимит в 20 одновременных подключений, у Collabora CODE такого потолка формально нет.

Если планируете держать документы в основном в .docx/.xlsx для совместимости с клиентами на Windows — присмотритесь и к OnlyOffice. Если приоритет — открытая экосистема без искусственных лимитов и вы готовы мириться с точечными расхождениями в сложной вёрстке — Collabora логичнее.

Требования к серверу

LibreOffice-движок внутри CODE ощутимо прожорливее статичного веб-сервиса: каждый открытый документ держит в памяти отдельный процесс рендеринга. Официальный минимум — 2 vCPU и 2 ГБ RAM для тестового запуска, но это хватит буквально на одного-двух одновременных редакторов. Разработчики Collabora сами говорят прямо: под реальную многопользовательскую нагрузку закладывайте от 4 ГБ RAM и от 2 vCPU, и добавляйте ресурсы по мере роста числа одновременных сессий — точных цифр «столько-то МБ на пользователя» они не публикуют, потому что сильно зависит от размера и сложности документов.

Что понадобится:

• VPS с 4+ ГБ RAM, 2+ vCPU — для рабочей нагрузки на команду из 5-15 человек;
• уже развёрнутый Nextcloud (если ставите CODE именно как редактор для него) — см. установку Nextcloud на VPS;
• отдельный поддомен под Collabora, например office.example.com — WOPI-протокол требует HTTPS и не будет работать по голому HTTP или на том же домене, что и сам Nextcloud;
• открытые порты 80/443 в фаерволе для выпуска сертификата и работы reverse proxy.

Держать Collabora на отдельном поддомене — не прихоть, а обязательное требование протокола WOPI: если Nextcloud и редактор сидят на одном origin, браузер и сама интеграция начинают путаться в cookies и CSP-заголовках.

Готовый docker-compose.yml

Структура каталога простая — CODE в базовой конфигурации не пишет данные на диск постоянно (документы живут в оперативной памяти на время редактирования, сохранение идёт через WOPI обратно в Nextcloud), поэтому volumes под сам сервис не нужны:

mkdir -p /opt/collabora && cd /opt/collabora
nano docker-compose.yml

services:
  collabora:
    image: collabora/code:latest
    container_name: collabora
    restart: unless-stopped
    ports:
      - "127.0.0.1:9980:9980"
    environment:
      - domain=nextcloud\\.example\\.com
      - username=admin
      - password=замените-на-длинный-случайный-пароль
      - extra_params=--o:ssl.enable=false --o:ssl.termination=true
    cap_add:
      - MKNOD
    tty: true

Разбор переменных, которые чаще всего настраивают неверно:

• domain — это regex-паттерн домена Nextcloud (не самого Collabora!), с которого разрешены запросы к редактору. Точки нужно экранировать обратным слэшем, иначе CODE будет молча отклонять WOPI-запросы, а в логах — почти пустая ошибка авторизации.
• username/password — учётка для встроенной админ-панели CODE по адресу /browser/dist/admin/admin.html, не путать с логином Nextcloud.
• ssl.termination=true — говорит контейнеру, что TLS терминируется снаружи (на reverse proxy), а сам CODE слушает по HTTP на 9980. Порт биндим только на 127.0.0.1, наружу его открывать не нужно — доступ только через прокси.

Запуск:

docker compose up -d
docker compose logs -f collabora

В логах должно появиться Ready — если контейнер перезапускается в цикле, почти всегда причина в неверном формате domain (забытое экранирование точек) или в конфликте порта 9980 с уже запущенным сервисом.

SSL и reverse proxy: без этого WOPI не заработает

Collabora Online не выпускает сертификаты сам — HTTPS-терминация возлагается на прокси перед контейнером. Проще всего поднять её через Caddy, который сам получает сертификат Let's Encrypt:

office.example.com {
    reverse_proxy 127.0.0.1:9980 {
        header_up Host {upstream_hostport}
    }
}

Если на сервере уже используется Traefik как единая точка входа для нескольких сервисов, добавьте лейблы прямо в docker-compose.yml вместо отдельного блока Caddy — принцип описан в статье про Traefik как reverse proxy для Docker:

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.collabora.rule=Host(`office.example.com`)"
      - "traefik.http.routers.collabora.tls.certresolver=letsencrypt"
      - "traefik.http.services.collabora.loadbalancer.server.port=9980"

С WebSocket-соединениями (а совместное редактирование в реальном времени идёт именно через них) у некоторых конфигураций nginx возникают обрывы сессий — важно явно прописать заголовки апгрейда:

location / {
    proxy_pass http://127.0.0.1:9980;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 36000s;
}

proxy_read_timeout стоит выставлять с большим запасом — если пользователь оставит документ открытым на длительное время без активности, короткий таймаут прокси разорвёт WebSocket раньше, чем сам CODE закроет сессию, и редактор зависнет с ошибкой соединения.

Если выпускаете сертификат вручную, а не через встроенный автоSSL Caddy или Traefik, — сначала определитесь с инструментом (Certbot или acme.sh), это отдельная тема с собственными нюансами по автопродлению.

Подключение к Nextcloud

После того как https://office.example.com отдаёт корректный сертификат и в логах CODE тишина без ошибок, подключение делается в самом Nextcloud:

1. Установите приложение Nextcloud Office (бывшее Collabora Online) через Настройки → Приложения → Инструменты офиса.
2. Перейдите в Настройки администратора → Nextcloud Office.
3. В поле URL (и порт) сервера Collabora Online укажите https://office.example.com и сохраните.

Если Nextcloud пишет «Не удалось подключиться к серверу Collabora Online: Error: Certificate verification failed» — проверьте, что сертификат на поддомене реально валиден (не self-signed) и что контейнер Nextcloud (если он тоже в Docker) имеет доступ до office.example.com по DNS изнутри своей сети, а не только снаружи.

Отдельная категория проблем — открытие документа зависает на «Загрузка документа…» бесконечно. В 90% случаев это несовпадение domain в переменных окружения CODE с реальным доменом Nextcloud, либо блокировка WebSocket на прокси перед CODE (см. предыдущий раздел). Если Nextcloud и без редактора уже заметно тормозит, сначала стоит разобраться с базовой производительностью — лишняя нагрузка от одновременных редакторских сессий только усугубит картину.

Ограничение доступа и безопасность

Админ-панель CODE (/browser/dist/admin/admin.html) даёт доступ к статистике активных документов и подключений — держать её открытой для всего интернета не стоит, даже с паролем. Два рабочих варианта:

• ограничить доступ к пути /browser/dist/admin/ по IP на уровне reverse proxy (белый список офисных/домашних адресов);
• завести отдельный внутренний домен или порт, доступный только через VPN/WireGuard.

Сам WOPI-эндпоинт (/hosting/discovery, /cool/...) должен оставаться публично доступным — иначе Nextcloud не сможет достучаться до редактора, если сам Nextcloud тоже не за тем же VPN.

Ещё один нюанс: переменная extra_params поддерживает флаг --o:security.seccomp=false, который иногда советуют в старых мануалах для обхода ошибок песочницы. Не отключайте его без крайней необходимости — seccomp-фильтр ограничивает системные вызовы внутри контейнера и является одним из немногих защитных механизмов, реально снижающих ущерб при эксплуатации уязвимости в LibreOffice-движке (а такие уязвимости у офисных парсеров находят регулярно, это специфика формата).

Обновление и мониторинг

Обновление образа — стандартная процедура Compose, но с оговоркой: активные сессии редактирования при перезапуске обрываются, документы в момент обновления лучше не редактировать:

cd /opt/collabora
docker compose pull
docker compose up -d

Проверить состояние сервиса без захода в веб-панель можно через встроенный health-эндпоинт:

curl -s http://127.0.0.1:9980/hosting/discovery | head -c 200

Если в ответ приходит XML с перечнем MIME-типов — сервис жив и раздаёт конфигурацию WOPI-хостинга. Пустой ответ или connection refused — контейнер не поднялся или порт перебит другим сервисом.

Для продакшен-стенда, где Collabora стоит рядом с другими контейнерами, полезно свериться с общим чек-листом по типовым проблемам docker-compose на сервере — там разобраны частые причины падений после обновлений и рестартов, не специфичные для конкретного сервиса: Docker Compose для продакшена — частые ошибки и решения.

Частые вопросы