Как мы вернули предпросмотр документов в Битрикс24 без выхода в интернет

Когда коробочный Битрикс24 стоит в изолированной сети, привычные функции, такие как предварительный просмотр документов, перестают работать. Мы столкнулись с этой проблемой у одного из клиентов и в итоге собрали собственный сервер конвертации, который полностью заменяет облачный сервис вендора.

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

Зачем понадобилась собственная конвертация 

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

Проблема обнаружилась быстро. Сотрудники стали жаловаться, что предварительный просмотр файлов Word, Excel и PowerPoint на портале не работает. Открываешь документ и вместо содержимого идет загрузка, а потом появляется ошибка. Скачивать каждый файл, чтобы посмотреть, что внутри – тупиковый путь. Это неудобно и ломает половину сценариев работы в CRM, задачах и на Диске.

Почему стандартный предварительный просмотр не работает в закрытом контуре

Портал сам по себе не умеет рендерить файлы Office. Когда пользователь открывает документ, Битрикс выполняет четыре шага:

1. Извлекает файл из хранилища.
2. Отправляет его на внешний сервер конвертации Битрикс.
3. Получает обратно PDF и превью-изображения страниц.
4. Показывает результат в браузере.

Для облачного портала или «коробки» с доступом в интернет схема удобная, ничего разворачивать и поддерживать не нужно. Но у нашего клиента второй шаг невозможен — интернета нет и не будет.

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

Какие требования поставили перед сервисом 

Первое, что приходит в голову, взять готовое опенсорсное решение и доработать его. Но при рассмотрении варианты не подошли: одни не интегрируются с API Битрикс «из коробки», другие —  тяжелые монолиты, которые сложно масштабировать, третьи требуют платных лицензий.

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

• Полностью автономный, без единого обращения во внешнюю среду.
• Развертывается одной командой, чтобы администратор клиента мог сам устанавливать и обновлять его.
• Устроен таким образом, что при росте нагрузки его можно расширять горизонтально, без переписывания кода.

Почему выбрали Go, а не PHP

Битрикс написан на PHP, и логично было бы использовать тот же язык. Но для сервиса, который существует отдельно от портала и должен обрабатывать параллельные запросы, PHP — не лучший выбор. Go дал нам несколько преимуществ:

• Низкое потребление памяти, для небольших серверов клиентов это критично.
• Быстрый запуск контейнеров, что упрощает горизонтальное масштабирование.
• Параллельная обработка без сторонних библиотек.
• Компиляция в один бинарный файл, деплой и обновления становятся тривиальными.

Разделили API и обработку документов 

Соблазн собрать монолит, который «делает все», через полгода эксплуатации обычно оборачивается проблемами. Сломалась одна функция и падает вся система. Захотел обновить библиотеку конвертации — приходится перезапускать API. Нагрузка выросла — масштабировать некуда, потому что все в одном процессе.

Мы разложили решение на независимые компоненты, каждый из которых делает что-то одно:

1. Producer — HTTP API на Go, входная точка. Принимает запросы от Битрикс24, проверяет параметры и ставит задачу в очередь. Производитель не выполняет тяжелую работу, его задача быть быстрым и всегда доступным.
2. RabbitMQ — брокер сообщений. Через него задачи асинхронно попадают к обработчикам. Именно очередь делает систему отказоустойчивой: если все воркеры сейчас заняты, задача дождется своей очереди и не потеряется.
3. Consumer (Worker) — обработчик на Go. Забирает задачи из очереди, запускает конвертацию, отдает результат обратно на портал. Consumers можно запускать сколько угодно, они работают параллельно и независимо друг от друга.
4. LibreOffice — конвертирует офисные форматы (DOCX, XLSX, PPTX и десятки других) в PDF. Работает в консольном режиме, это де-факто стандарт для серверной конвертации Office-файлов.
5. ImageMagick — разбивает PDF на изображения, которые портал использует для постраничного предварительного просмотра.
6. Docker Compose — оркестрация всего стека. Клиент запускает одну команду, и через минуту система готова принимать запросы.

Как подключили сервис к Битрикс24

Процесс запуска намеренно сделали максимально коротким:

1. Разворачивается стек командой docker compose up -d.
2. Проверяется, что контейнеры подняты и очередь готова принимать задачи.
3. В настройках модуля Битрикс24 вместо стандартного указывается адрес нового сервера конвертации.

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

Обеспечили безопасность, документы не покидают периметр

Главная задача проекта — обрабатывать документы внутри закрытого контура и не передавать во внешние сервисы.

Для этого Docker-контейнеры подключили только к внутренней сети сервера. У них нет доступа в интернет, они могут работать внутри системы и обмениваться данными между собой, но не могут установить внешнее соединение. API также доступен только из внутренней сети, где работает Битрикс24.

В результате итоговая схема выглядит так:

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

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

Как развернули сервис у клиента

Ключевое здесь — асинхронность. Пользователь не привязан к конкретному серверу и не ждет, пока освободится процесс. Задача попадает в очередь и обрабатывается первым свободным воркером, что обеспечивает предсказуемое время отклика даже во время всплесков активности.

Пользователь открывает DOCX в Битрикс24:

1. Портал отправляет запрос на Producer.
2. Producer проверяет параметры, забирает файл и кладет задачу в очередь RabbitMQ.
3. Свободный Consumer забирает задачу.
4. LibreOffice конвертирует файл в PDF.
5. Если нужны превью, ImageMagick разбивает PDF на картинки.
6. Готовый результат возвращается на портал, пользователь видит документ.

В результате мы получили отдельный сервис, который можно развернуть внутри закрытого контура и масштабировать независимо от Битрикс24. Для конечного пользователя ничего не изменилось: документы по-прежнему открываются в один клик. Изменилось главное — весь процесс конвертации теперь остается внутри инфраструктуры компании.

Если ваша инфраструктура устроена похожим образом, оставьте заявку на сайте webest.ru и мы обсудим архитектуру и возможные варианты интеграций.