Перенос и обновление Onlyoffice

Недавно я писал про установку и настройку Onlyoffice - сервиса для совместной работы и редактирования документов. Сегодня хочу поделиться некоторыми моментами из практики, чтобы у вас появилось представление о том, как все это работает. А самое главное, как обслуживать onlyoffice - обновлять или переносить на другой сервер. Я рассмотрю на конкретном примере оба этих варианта.

Введение

У меня под управлением есть Onlyoffice на базе следующих продуктов:

1. Community Server версии 9.6.4.
2. Document Editor 5.2.3.

Все установлено из пакетов на сервере под управлением Centos 7. Данные версии продукта были выпущены минимум пару лет назад, а может и больше. Несколько раз я предпринимал попытки все это обновить штатным образом через менеджер пакетов, но у меня ничего не получалось. Обновленная система не работала. Проблемы в первую очередь возникают либо с зависимостями, либо с интеграцией портала с редактором документов.

Я решил раз и навсегда разобраться с этой проблемой, поэтому поднял тестовый стенд с копией рабочего сервера и проработал сразу несколько моментов:

• Перенос Onlyoffice на другой сервер.
• Переход на работу в Docker.
• Обновление до последних версий софта.

Здесь на каждом этапе будут свои сложности. Во-первых, как такового Community Server на сайте onlyoffice и в документации нет. Его заменил продукт ONLYOFFICE Groups, который включает в том числе и Community Server. Во-вторых, не существует актуальных инструкций по данной теме. Да, есть отдельно по переносу, есть по обновлению. Но рассматривается это примитивно, типа запустите yum update и обновите пакеты, или docker pull и обновите образы. Варианты, когда где-то возникает проблема, не рассматриваются. Ну и в-третьих, нет никакой поддержки. Во всем надо разбираться самому.

У меня по сути наложились две ошибки, поэтому все сильно усложнилось. Обновить onlyoffice через обновление пакетов у меня не получилось, поэтому исходные данные были старой версии. При их переносе на новый сервер, не получалось просто взять их и подсунуть ему. Сервер падал с ошибками. По логам я понял, что изменилась структура базы данных, что с этим делать не сразу догадался.

Здесь косвенно можно судить о качестве разработки и подходу к self-hosted решению (качество не очень). Я ожидал, что когда я перекину старые данные новому серверу, он поймет, что они старые и обновит все до последней версии. Но так не получилось. В итоге все делал вручную, о чем дальше и расскажу.

Обновление Onlyoffice

Чтобы не быть голословным, показываю, чем заканчивается обновление Onlyoffice из пакетов, с использованием предлагаемых разработчиком репозиториев. Причем в разное время ошибки были разные. Это последняя.

В первую очередь возникает проблема с mono. Я ее в итоге решил. Пришлось полностью удалить старую версию и поставить новую. Дальше все равно обновление не идет, так как в зависимостях новой версии стоит elasticsearch, а в старой ее не было. Автоматически это несоответствие никак не разрешается. Ну ок, подключил сам репу с elsticsearch и поставил его. Дальше опять идет ошибка уже с пакетом mono-webserver-hyperfastcgi, которого опять нет ни в одном репозитории. Подключаю вручную репозиторий с этим пакетом, обновляю.

На этот раз проходит обновление всех пакетов, но на выходе все равно ничего не работает. Оба приложения - Document Editor и Community Server запускаются на 80-м порту. Раньше было не так - работали на разных. Опять автоматически этот конфликт никак не разрешается. Лезу в настройки nginx и вручную все разруливаю. Это не так просто, так как конфигов там навалом с разными include и location. В общем, все разнес, приложения по отдельности работают, а вот интеграцию docs в портал так и не настроил.

В конечном итоге я понял, что это пустая затея. Каждый раз тратить столько времени на обновление бессмысленно. Решил пойти другим путем - перенести все в официальные образы docker и обновлять уже там. Рассказываю, как это сделать.

Берем новую виртуалку и устанавливаем Onlyoffice с помощью Docker образов, как я это показал в прошлой статье, ссылку на которую дал в начале. Инсталлятор подключает volume с данными портала в директорию хоста - /app/onlyoffice. Нас в первую очередь будут интересовать данные отсюда:

• /app/onlyoffice/CommunityServer/data - непосредственно сами файлы
• /app/onlyoffice/mysql/data - база данных mysql

Все остальное можно потерять, там ничего критичного. Теперь идем на старый сервер и смотрим, где эти же данные хранятся там:

• /var/www/onlyoffice/Data
• /var/lib/mysql

Базу данных можно остановить и просто скопировать со старого сервера на новый. Но я предпочитаю действовать более надежно - сделать дамп и восстановиться из него. Идем на старый сервер и делаем дамп базы данных mysql от onlyoffice:

# mysqldump -uroot -hlocalhost -p'oNlYoFfIcE2017!' onlyoffice > /root/onlyoffice.sql

Обращаю внимание на выделенный пароль. Раньше дефолтным был этот. По крайней мере на момент установки сервера.

Копируем дамп на новый сервер. Команду выполняю на нем:

# rsync -av --progress root@10.1.4.11:/root/onlyoffice.sql /root

10.1.4.11 - ip адрес старого сервера. Сразу же скопируем остальные файлы:

# rsync -av --progress root@10.1.4.11:/var/www/onlyoffice/Data /root

Теперь наша задача восстановить базу данных из дампа. Смотрим имя контейнера с базой данных на новом сервере.

# docker ps

Копируем дамп базы данных в контейнер.

# docker cp /root/onlyoffice.sql ef4c6676f46e:/onlyoffice.sql

Теперь идем в контейнер и восстанавливаем базу данных onlyoffice из дампа.

# docker exec -it ef4c6676f46e bash
# mysql -u root -p'my-secret-pw' onlyoffice < onlyoffice.sql

Жирным выделил актуальный на момент написания статьи дефолтный пароль базы данных mysql для onlyoffice.

Теперь останавливаем docker контейнер onlyoffice/communityserver и заменяем содержимое /app/onlyoffice/CommunityServer/data на то, что вы скопировали со старого сервера. Набор директорий может отличаться. В новом сервере их немного больше. Я просто удалил на новом те папки, что есть на старом и заменил их полностью старыми данными.

После копирования необходимо выставить правильные права, которые используются в контейнере, на скопированные файлы и директории.

# chown -R 104:107 /app/onlyoffice/CommunityServer/data

После этого можно попробовать запустить контейнер communityserver. Сразу скажу, что ничего не заработает, но я специально веду повествование в таком ключе, чтобы вы понимали, как дебажить проблемы.

Итак, вы запустили контейнер и отправились в браузер по адресу http://ip-сервера/. Скорее всего увидите ошибку 500. Дальше можно посмотреть логи nginx, чтобы хоть примерно понимать, откуда ошибка. Смотреть надо файл /app/onlyoffice/CommunityServer/logs/nginx.error.log. В моем случае там было это:

[error] 460#460: *163 upstream sent unexpected FastCGI record: 3 while reading response header from upstream, client: 127.0.0.1, server: , request: "GET /api/2.0/capabilities.json HTTP/1.1", upstream: "fastcgi://unix:/var/run/onlyoffice/onlyoffice.socket:", host: "127.0.0.1"

Я сходил в контейнер CommunityServer и убедился, что указанный сокет существует, значит служба запущена, но выдает ошибку. Проверяю лог самой службы - /app/onlyoffice/CommunityServer/logs/onlyoffice.log.

Debug Listening on port: 0
Debug Listening on address: /var/run/onlyoffice/onlyoffice.socket

Здесь все в порядке, сервис работает, ошибок нет. Смотрю следующий лог - /app/onlyoffice/CommunityServer/logs/web.log. Тут трудночитаемая лапша, но суть уловить можно. Вот содержательная часть ошибки:

ERROR [6] ASC.Resources - ReplaceLogo MySql.Data.MySqlClient.MySqlException (0x80004005): Unknown column 'p.campaign' in 'field list'

Тут я понял, что проблема в структуре базы данных. Скорее всего в новых версиях она поменялась, поэтому старая база просто так не заводится на новой версии. Долго думал, что тут предпринять. Не понял, почему служба сама не проверила базу и не обновила ее автоматически до актуальной версии. Логично ожидать такого поведения.

Гугление особо не помогло, в документации тоже ничего не нашел. Отправился смотреть исходники и заметил там любопытную директорию - https://github.com/ONLYOFFICE/CommunityServer/tree/master/build/sql. Я понял, что тут лежит именно то, что мне нужно. Здесь описаны изменения базы данных в новых версиях.

Моя старая версия 9.6, значит мне сверху на нее нужно накатить следующие изменения:

• onlyoffice.upgradev100.sql
• onlyoffice.upgradev105.sql
• onlyoffice.upgradev110.sql

Скачиваю эти файлы и копирую в контейнер с mysql.

# docker cp /root/onlyoffice/Sql/onlyoffice.upgradev100.sql ef4c6676f46e:/onlyoffice.upgradev100.sql
# docker cp /root/onlyoffice/Sql/onlyoffice.upgradev100.sql ef4c6676f46e:/onlyoffice.upgradev105.sql
# docker cp /root/onlyoffice/Sql/onlyoffice.upgradev100.sql ef4c6676f46e:/onlyoffice.upgradev110.sql

Далее иду в контейнер и загружаю эти изменения.

# docker exec -it ef4c6676f46e bash
# mysql -u root -p'my-secret-pw'
> use onlyoffice
> source onlyoffice.upgradev100.sql;
> source onlyoffice.upgradev105.sql;
> source onlyoffice.upgradev110.sql;

После этого перезапускаю контейнер с CommunityServer.

# docker restart onlyoffice-community-server

Теперь можно идти в web интерфейс и пробовать залогиниться администратором. У меня все заработало, портал запустился. Единственное, почему-то не смог войти, используя пароль от учетной записи админа на старом портале. Сбросил его, на почту пришла ссылка для обновления пароля, и я установил такой же. После этого успешно зашел в систему.

Дальше нужно выполнить важный шаг. На прошлом сервере пути для интеграции со службой документов были другие. При работе в Docker контейнерах пути должны быть следующие:

/ds-vpath/
http://onlyoffice-document-server/
http://onlyoffice-community-server/

Сразу дам подсказку для тех, кто будет возиться с этими настройками. Они у меня много крови попили, так как не всегда получалось сразу настроить правильно, а подсказок нигде никаких нет. Открывайте dev tools в chrome и смотрите консоль ошибок. Если какие-то пути неправильные, вы в консоли увидите ошибки и поймете, как работает проверка, куда она отправляет запросы и с какими ошибками они возвращаются. После этого можно идти в nginx и разбираться, в чем проблема.

Это в основном актуально, если у вас documentserver и communityserver разнесены по разным машинам, либо через пакеты всё ставили. Когда всё работает на одном хосте в докере, проблем быть не должно. Теоретически и тут могут быть, если по какой-то причине не будет работать внутренний dns в докере. Были раньше такие баги, но это лечится.

В целом, по обновлению onlyoffice все. Логику и последовательность действий я показал. С ее помощью можно действовать практически в любых вариациях использования этого портала совместной работы. По итогу у меня получилось все перенести на следующие версии софта.

Перенос Onlyoffice

В целом, про перенос onlyoffice я почти все рассказал в предыдущем разделе. Выношу его отдельно для тех, кто будет переезжать без обновления. А так же для тех, у кого обновление прошло штатно и отдельно заострять на нем внимания нет необходимости. Если вы переносите данные onlyoffice между серверами одной и той же версии, то проблем никаких быть не должно. Вам необходимо перенести:

1. Базу данных Mysql.
2. Директорию Data портала, где хранятся сами файлы.

В большинстве случаев для переноса базы данных достаточно остановить сервер mysql и скопировать директорию /var/lib/mysql, если у вас локальная версия, либо подключенную к docker через volume - /app/onlyoffice/mysql/data. Я делал так много раз, проблем не было.

Далее переносите файлы из директории /var/www/onlyoffice/Data в случае локальной версии, или /app/onlyoffice/CommunityServer/data в случае с docker. После этого на новом месте проверяете права на файлы и стартуете сервисы. Все, больше ничего делать не надо.

Данное руководство будет актуально для переноса данных с локальной версии, установленной из пакетов, на Docker версию и обратно. Я так одно время делал, когда сталкивался с какими-то проблемами или ошибками. В целом, с переносом проблем нет, если до этого у вас не ломались обновления.

Здесь же сделаю еще одно важное дополнение. Я уже говорил в первой статье, что не рекомендую настраивать https на самом сервере Onlyoffice. Потом будет труднее переезжать, обновляться, тестировать какие-то изменения. Когда у вас версия работает по http, вы спокойно ее клонируете, меняете ip и заходите по нему в веб интерфейс. Нет никаких ошибок https. Если нужно переехать, просто поднимаете новый сервер, все отлаживаете на нем, переносите данные и переключаете на nginx, работающем в режиме proxy_pass бэкенд и все. Я всегда придерживаюсь такого подхода при работе web приложений. Все входящие соединения пропускаю через nginx.

Бэкап

Скажу пару слов про бэкап onlyoffice. Как уже стало понятно из предыдущих разделов, бэкапить достаточно только базу данных и директорию с файлами. Можно их в сыром виде переносить и это будет нормально работать. Раньше я так и делал, да и сейчас делаю, потому что это позволяет автоматизировать процессы с помощью скриптов.

С появлением отдельного компонента портала - Панель управления, этот вопрос упростился, так как то же самое можно сделать через web интерфейс.

У вас есть возможность подключить внешнее хранилище и бэкапить портал туда по расписанию. Либо в локальный файл сохранять и потом куда-то копировать. Надежнее всего использовать оба способа - забирать сырые данные и сформированный через панель управления архив. Бэкапов много не бывает :) С помощью сырых данных можно без проблем держать холодный или горячий резерв.

Для холодного резерва достаточно держать подменный сервер, куда раз в сутки копировать файлы и восстанавливать базу из дампа. Для горячего поднять кластер mysql и почаще синхронизировать файлы.

Заключение

На этом по Onlyoffice на сегодня все. Надеюсь, у вас появилось представление, как этот портал работает и с чем можно столкнуться во время эксплуатации. Как видите, надо немного разбираться во внутренностях этой штуки, чтобы успешно решать проблемы. Если у вас нет достаточного опыта, я бы аккуратно внедрял onlyoffice и старался перейти на платную подписку с тех поддержкой. Либо использовал его для вспомогательных вещей, которые терпят некоторого простоя, пока вы восстановитесь из резервной копии. Как я уже говорил, он отлично подходит для ведения большой и разноплановой документации. Удобно и не критично, если что-то где-то засбоит.

Другой вариант - использовать облако. Но лично мне он не очень нравится. Облачная версия работает заметно медленнее локальной, а это именно то, что лично мне не нравится, когда много работаешь с документами. Но с другой стороны, вам вообще не нужен специалист по поддержке портала. Так что нормальный компромисс.

Если у вас есть желание поднять у себя подобный портал, но некому это сделать, можете обращаться ко мне. Я рассчитаю примерную стоимость своей работы и всё вам настрою по вашему заданию (бэкапы, клонирование, мониторинг, интеграция с почтой и т.д.).

Помогла статья? Подписывайся на telegram канал автора