Среди свободного программного обеспечения для работы с документами офисный пакет ONLYOFFICE занял уверенную позицию благодаря серьёзному подходу к совместимости с форматами Microsoft Office. Когда речь заходит о редактировании DOCX, XLSX или PPTX без потери форматирования, мало кто из открытых альтернатив справляется так же ровно. А ведь сохранение исходного вида документа после правки это та самая мелочь, на которой годами спотыкаются другие свободные пакеты, превращая работу в нескончаемую починку поехавшей вёрстки.
Версия 7.2 принесла несколько интересных нововведений, ради которых стоит обновиться или поставить пакет с нуля. Появился маркетплейс плагинов прямо внутри редактора, что заметно расширило возможности кастомизации без необходимости копаться в исходниках. Добавили поддержку дополнительных типов полей в формах, включая email-адреса, телефонные номера и сложные составные поля. Появились настройки формата для текстовых полей: цифры, буквы, произвольная маска или регулярное выражение. Подоспела поддержка лигатур и письменности нко. Завезли тёмную тему с высоким контрастом, горячие клавиши для специальной вставки, встроенные OLE-таблицы и обновлённое окно поиска с заменой.
Развернуть всю эту красоту на Fedora Linux разумнее всего через контейнер. Контейнерный подход избавляет от мороки с установкой кучи зависимостей вручную, изолирует приложение от системы и позволяет одной командой обновляться на свежие версии. В Fedora родным контейнерным движком стал Podman, а не Docker, и это исторический выбор Red Hat в сторону безродемонной архитектуры с лучшими настройками безопасности.
Минимальные требования к железу и почему ONLYOFFICE Docs нельзя ставить на слабую виртуалку
Прежде чем браться за установку, стоит трезво оценить характеристики сервера. ONLYOFFICE Docs не самый лёгкий пакет, и попытка запихнуть его в слабую виртуалку с гигабайтом памяти и одноядерным процессором обернётся бесконечными тормозами и падениями. Внутри контейнера крутится связка из nginx, node.js, postgresql, rabbitmq и нескольких других сервисов, и всему этому хозяйству нужно где разгуляться.
Официальные требования выглядят так. Процессор минимум двухъядерный с частотой от 2 ГГц, оперативной памяти от 2 гигабайт, на диске должно быть свободно не меньше 40 гигабайт, плюс минимум 4 гигабайта файла подкачки. Архитектура процессора обязательно x86_64, а ядро Linux должно быть не старше версии 3.10. Последнее требование на современных дистрибутивах выполняется автоматически, потому что даже устаревшие версии Fedora давно ушли вперёд.
По опыту реальной эксплуатации эти цифры стоит воспринимать как абсолютный минимум для тестового окружения с одним-двумя пользователями. Для команды из десяти человек разумно закладывать четыре ядра и восемь гигабайт памяти, а для серьёзных нагрузок с десятками одновременных редакторов потребуется уже восьмиядерная машина с шестнадцатью или больше гигабайтами оперативки. Файл подкачки это страховка от внезапных всплесков потребления памяти, без него любая нагрузочная пиковая ситуация может привести к OOM-killer и принудительному закрытию контейнера.
Установка контейнерного движка Podman через стандартный пакетный менеджер Fedora
Fedora и Podman дружат давно и тесно, поэтому установка движка контейнеризации сводится буквально к одной команде. В отличие от Docker, Podman не требует запущенного фонового демона, не нуждается в добавлении сторонних репозиториев и не просит лицензионных соглашений. Просто пакет в основном репозитории дистрибутива, который ставится менеджером dnf за секунды.
sudo dnf -y install podman
Здесь стоит остановиться на философских различиях между Podman и Docker, потому что они объясняют многое в дальнейшей работе. Docker использует архитектуру клиент-сервер с постоянно работающим демоном dockerd, который требует прав root и выступает единой точкой управления всеми контейнерами. Если демон падает, все контейнеры тоже останавливаются. Podman пошёл другим путём и реализовал безродемонную модель, где каждая команда podman запускает контейнер как обычный процесс под пользователем, который её вызвал. Никакого центрального демона, никакого единого процесса с привилегированными правами. Это даёт лучшую безопасность и упрощает мониторинг через стандартные системные инструменты.
Команды Podman почти полностью совместимы с Docker. Достаточно заменить docker на podman в большинстве скриптов, и они продолжат работать. Это сделано специально, чтобы упростить миграцию для тех, кто привык к экосистеме Docker. Существует даже алиас podman-docker, который позволяет вообще не менять привычные команды, а просто перенаправляет их на Podman.
Подготовка директорий на хост-системе для постоянного хранения данных контейнера
Контейнеры по своей природе эфемерны. Они создаются, работают и удаляются, а вместе с ними может пропасть всё содержимое внутренней файловой системы. Для рабочего сервера такое поведение неприемлемо, поэтому критически важные данные нужно вынести наружу, в постоянное хранилище на хост-машине. Это делается через монтирование томов, и для ONLYOFFICE требуется четыре отдельные папки под разные типы данных.
sudo mkdir -p /app/onlyoffice/DocumentServer/logs \
/app/onlyoffice/DocumentServer/data \
/app/onlyoffice/DocumentServer/lib \
/app/onlyoffice/DocumentServer/db
Флаг -p в команде mkdir выполняет двойную функцию. Во-первых, он создаёт всю цепочку родительских директорий, если их ещё нет, что избавляет от необходимости делать это вручную. Во-вторых, он не возвращает ошибку, если директория уже существует, что удобно при повторных запусках скрипта. Обратные слэши в конце строк это продолжение команды на следующей строке, всё это могло бы быть одной длинной командой в строчку, но в таком виде читается намного приятнее.
Каждая из четырёх созданных папок имеет своё назначение. Папка logs принимает логи всех внутренних сервисов ONLYOFFICE: nginx, document server, supervisor и других компонентов. Туда же пишутся записи о действиях пользователей и системных событиях. Папка data это сердце пользовательских данных. Туда складываются загруженные документы, кеши превью, временные файлы конвертации и сертификаты для HTTPS. Папка lib хранит данные приложения, которые не относятся к пользовательскому контенту, но должны переживать перезапуски контейнера. Папка db под базу данных PostgreSQL, где ONLYOFFICE хранит метаданные о документах, сессиях редактирования и пользователях.
Вынос данных наружу даёт несколько важных преимуществ. Контейнер можно безболезненно пересоздавать, обновлять до новой версии или временно останавливать без риска потерять данные. Бэкапы делаются просто копированием этих папок на резервный носитель. И в случае серьёзной поломки контейнера всегда есть шанс восстановить работу, подняв чистый образ и подключив к нему существующие тома с данными.
Запуск контейнера ONLYOFFICE Docs с монтированием томов и пробросом портов
Когда папки готовы, можно запускать сам контейнер. Команда получится длинной из-за множества параметров, но каждый из них играет свою роль в правильной работе системы.
sudo podman run -i -t -d -p 80:80 -p 443:443 --restart=always \
-v /app/onlyoffice/DocumentServer/logs:/var/log/onlyoffice:Z \
-v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data:Z \
-v /app/onlyoffice/DocumentServer/lib:/var/lib/onlyoffice:Z \
-v /app/onlyoffice/DocumentServer/db:/var/lib/postgresql:Z \
-u root onlyoffice/documentserver:latest
Каждый флаг здесь несёт смысл, и разобраться с ними полезно для понимания контейнеризации в целом. Флаги -i, -t и -d на первый взгляд кажутся противоречивыми. Первый включает интерактивный режим, второй выделяет псевдо-терминал, а третий запускает контейнер в фоне. Комбинация дана для совместимости с разными сценариями использования и не вредит работе.
Параметры -p пробрасывают порты с хост-машины внутрь контейнера. Запись 80:80 означает, что 80-й порт хоста перенаправляется на 80-й порт контейнера, где слушает встроенный nginx. Аналогично с портом 443 для HTTPS-соединений. Если эти порты на хосте заняты, можно поменять только левую часть, например 8080:80, тогда снаружи нужно будет обращаться по адресу с указанием порта 8080.
Опция --restart=always критически важна для боевого использования. Она говорит Podman автоматически перезапускать контейнер при любой остановке, включая перезагрузку хост-системы. Без этого флага после ребута сервера ONLYOFFICE пришлось бы запускать вручную.
Серия флагов -v это и есть монтирование томов, ради которого создавались папки на предыдущем шаге. Синтаксис prosto. Левая часть до двоеточия это путь на хосте, правая часть это путь внутри контейнера, а суффикс :Z это специальная метка для SELinux. На системах Fedora и других дистрибутивах семейства Red Hat SELinux активно следит за тем, чтобы процессы не лезли в чужие файлы. Без метки Z контейнер получил бы отказ при попытке прочитать или записать что-то в смонтированные папки. Метка переводит файлы в специальный контейнерный контекст безопасности.
Параметр -u root запускает процессы внутри контейнера от имени root. Для ONLYOFFICE это требование самих разработчиков, потому что некоторые внутренние компоненты, особенно работающие с PostgreSQL и системными сервисами, требуют привилегированных прав. Безродный запуск, который теоретически поддерживается Podman, для этого образа официально не рекомендуется.
Последний аргумент onlyoffice/documentserver:latest это имя образа на Docker Hub и тег версии. Тег latest всегда тянет самую свежую стабильную сборку, но для продакшна разумнее закрепляться на конкретной версии вроде onlyoffice/documentserver:7.2 во избежание сюрпризов при автоматических обновлениях.
После запуска полезно убедиться, что встроенный пример-демонстратор работает корректно.
sudo podman exec $(sudo podman ps -q) sudo supervisorctl start ds:example
Команда выполняет внутри запущенного контейнера запуск примера через supervisor. Конструкция $(sudo podman ps -q) подставляет идентификатор первого работающего контейнера, что удобно, когда контейнер на сервере только один. Сама команда supervisorctl это интерфейс к supervisor, классическому менеджеру процессов в Unix-системах, который внутри контейнера ONLYOFFICE управляет всеми внутренними сервисами.
Альтернативный путь сборки образа из исходного Dockerfile через Podman и Buildah
Иногда возникает потребность собрать образ самостоятельно, а не использовать готовый с Docker Hub. Причины могут быть разные. Возможно, нужно внести правки в Dockerfile, добавить свои зависимости или просто иметь полный контроль над процессом сборки в закрытом окружении без доступа к внешним реестрам. ONLYOFFICE официально предоставляет репозиторий со всеми файлами для сборки, и Podman прекрасно умеет это делать.
git clone https://github.com/ONLYOFFICE/Docker-DocumentServer.git
cd Docker-DocumentServer/
sudo podman build --tag onlyofficeds:podman -f ./Dockerfile
Первая команда клонирует репозиторий с инструкциями по сборке. Внутри найдётся не только сам Dockerfile, но и вспомогательные скрипты, конфиги и документация. Переход в каталог делается стандартной командой cd. Третья строка запускает сборку с тегом onlyofficeds:podman, который позволит потом отличать самосборный образ от официального. Флаг -f явно указывает на файл сборки, хотя по умолчанию podman ищет файл с именем Dockerfile в текущей директории и без этого параметра.
Сборка такого образа занимает существенное время, обычно от десяти до тридцати минут в зависимости от мощности машины и скорости интернета. Внутри Dockerfile выполняются десятки шагов: установка системных пакетов, сборка nodejs-компонентов, компиляция нативных модулей, настройка nginx и postgresql, формирование структуры файловой системы. Каждый шаг создаёт промежуточный слой образа, который кешируется и при повторной сборке используется без переделки, если соответствующая часть Dockerfile не менялась.
Существует альтернативный инструмент Buildah, который специализируется именно на сборке OCI-образов и предлагает более тонкий контроль над процессом. Buildah поддерживает создание образов и без Dockerfile, через серию команд в скрипте, что иногда удобнее для сложных сценариев.
buildah bud --tag onlyofficeds:buildah -f ./Dockerfile
Подкоманда bud расшифровывается как "build using dockerfile" и делает практически то же самое, что podman build. Результирующий образ совместим с Podman, и его можно запускать обычными командами podman run. Различие в основном в гибкости и наборе дополнительных возможностей, которые редко нужны для типовых задач.
Переключение ONLYOFFICE Docs на безопасное соединение HTTPS с установкой SSL-сертификатов
Работа офисного пакета по чистому HTTP это плохая идея на любом сервере, который смотрит наружу. Документы могут содержать конфиденциальную информацию, и передавать их незашифрованными через интернет всё равно что отправлять корпоративную переписку на открытках. Современные браузеры тоже не любят HTTP-сайты и помечают их как небезопасные, что отпугивает пользователей.
Сертификаты можно получить двумя путями. Купить у коммерческих центров сертификации вроде DigiCert или Sectigo, или получить бесплатно через Let's Encrypt. Второй вариант стал стандартом де-факто для большинства случаев. Сертификаты Let's Encrypt выдаются автоматически, действительны 90 дней и легко обновляются через утилиту certbot.
Когда сертификат и приватный ключ уже есть на руках, их нужно положить в специальную папку, доступную из контейнера.
sudo mkdir /app/onlyoffice/DocumentServer/data/certs
sudo cp onlyoffice.crt /app/onlyoffice/DocumentServer/data/certs/
sudo cp onlyoffice.key /app/onlyoffice/DocumentServer/data/certs/
sudo chown -R 100108:100111 /app/onlyoffice/DocumentServer/data/certs/
sudo podman restart {container_id}
Имена файлов onlyoffice.crt и onlyoffice.key жёстко зашиты в конфигурации nginx внутри контейнера. Файл с расширением crt содержит сам сертификат, обычно с цепочкой промежуточных сертификатов центра выдачи. Файл с расширением key содержит приватный ключ, без которого сертификат бесполезен. Этот ключ нужно беречь как зеницу ока, потому что его утечка означает компрометацию всего шифрования.
Команда chown с числами 100108 и 100111 это особенность Podman при работе с пользовательскими пространствами имён. Внутри контейнера nginx работает под определённым пользователем, который на хост-системе видится с другим UID. Эти числа представляют собой смещения, которые приводят владельца файла к нужному виду с точки зрения процесса внутри контейнера. Без правильной настройки прав nginx внутри контейнера не сможет прочитать сертификат и откажется запускаться.
Перезапуск контейнера через podman restart применяет изменения. Идентификатор контейнера {container_id} нужно заменить на реальный, который выдаёт команда podman ps. После перезапуска nginx внутри контейнера автоматически определит наличие сертификатов и переключится в режим HTTPS.
Проверка работы делается через браузер по адресу https://localhost/welcome, если установка ведётся на локальной машине, или через реальный домен, если сервер развёрнут публично. На приветственной странице есть кнопка "Go to test example", которая открывает демонстрационную страницу с возможностью создания и редактирования тестовых документов. Стоит помнить, что эта демонстрация не предназначена для работы с настоящими конфиденциальными документами, она существует только для проверки работоспособности и знакомства с интерфейсом.
Интеграция установленного ONLYOFFICE с существующими корпоративными платформами для совместной работы
Развёрнутый сервер документов сам по себе уже неплохой инструмент, но настоящая сила ONLYOFFICE раскрывается при интеграции с другими системами. Архитектура позволяет встраивать редакторы в самые разные платформы через готовые коннекторы, которые разрабатывает как сама команда ONLYOFFICE, так и сторонние разработчики.
Для систем управления контентом существуют коннекторы под WordPress, Strapi и Drupal. Это превращает обычный сайт в полноценную платформу для совместного редактирования документов. Авторы статей могут править материалы прямо в браузере через знакомый интерфейс, похожий на Microsoft Word, без необходимости устанавливать что-либо на свои компьютеры.
Платформы для командной работы тоже отлично дружат с ONLYOFFICE. Nextcloud и Seafile, два популярных самохостящихся аналога Dropbox, получают через интеграцию возможность редактирования документов онлайн. Confluence и Alfresco, корпоративные системы управления знаниями, расширяют свои возможности до полноценной работы с офисными файлами. ONLYOFFICE Workspace это собственное решение от той же команды, заточенное специально под комплексную совместную работу.
Системы отслеживания задач Jira и Redmine получают через коннекторы возможность редактировать прикреплённые к задачам документы прямо в браузере. Это убирает классическую боль с цепочками "скачал-отредактировал-загрузил-послал коллеге", превращая работу с документацией в плавный процесс с историей версий и одновременным соавторством.
Для образовательных платформ есть коннекторы под Moodle, Chamilo и HumHub. Преподаватели могут давать студентам задания в виде документов, которые те правят прямо в системе обучения, а преподаватель видит изменения в реальном времени. Это меняет подход к проверке работ и совместным проектам в учебной среде.
Типичные грабли при интеграции связаны с настройкой сетевого взаимодействия. Сервер ONLYOFFICE должен быть доступен с серверов интегрируемых платформ по HTTPS, при этом сертификат должен быть валидным и доверенным. Самоподписанные сертификаты часто вызывают проблемы при интеграции, потому что внешние системы отказываются им доверять. Для тестирования это терпимо, но для боевой эксплуатации нужны нормальные сертификаты от признанного центра выдачи.
Зачем команде вкладываться в развёртывание собственного офисного сервера и какие преимущества это даёт
Решение установить ONLYOFFICE на собственный сервер вместо использования облачных сервисов Google Docs или Microsoft 365 это серьёзный шаг, который окупается не сразу, но окупается основательно. Главное преимущество это полный контроль над своими данными. Все документы, все правки, вся история изменений хранятся на собственном сервере, под управлением собственной команды, без вмешательства третьих сторон.
Для компаний, работающих с чувствительной информацией, это критично. Юридические фирмы, медицинские учреждения, государственные структуры, оборонные подрядчики обязаны соблюдать строгие требования к обработке данных, и облачные сервисы общего пользования им не подходят. Самохостящийся ONLYOFFICE решает эту проблему элегантно, предоставляя весь функционал современного облачного офиса в собственном контуре.
Экономическая сторона тоже играет роль. Подписки на коммерческие облачные офисы для команды из ста человек обходятся в круглые суммы ежемесячно. Собственный сервер с ONLYOFFICE Docs Community Edition бесплатен в плане лицензии, и платить нужно только за железо и обслуживание. На больших масштабах разница становится заметной.
Интеграция со своими внутренними системами это ещё один козырь. Когда офисный пакет живёт в той же сети, что и корпоративные приложения, можно строить сложные процессы автоматизации, которые с публичными облаками были бы невозможны или потребовали бы громоздких костылей через REST-API с проблемами латентности и квот.
Освоение Podman и контейнерного подхода к развёртыванию приложений это отдельная ценность, которая выходит далеко за рамки одного ONLYOFFICE. Тот же подход применим к десяткам других самохостящихся сервисов, и инженер, разобравшийся с контейнеризацией на одном примере, легко переносит навыки на следующие проекты. Это инвестиция в собственные компетенции, которая отдачи приносит годами, потому что контейнеры стали стандартом современного развёртывания и никуда уходить не собираются.
Канал сайта в Telegram
Канал сайта на YouTube