Перейти к содержанию

S3 хранилище

Статус функциональности

Поддержка S3-совместимого объектного хранилища для файлового обмена находится в разработке. На текущий момент бинарные вложения передаются в составе сообщений через основной транспорт. Эта статья описывает планируемую модель развертывания и подключения внешнего S3.

Назначение

Объектное хранилище в DataHUB предназначено для разгрузки основного транспорта от тяжёлых вложений — изображений товаров, документов, отчётов, скан-копий. Логика обмена:

  1. Отправитель загружает файл в S3 и получает ссылку.
  2. В сообщение обмена кладётся не сам файл, а ссылка на объект и его метаданные (имя, размер, контрольная сумма).
  3. Получатель скачивает файл из S3 по ссылке после получения сообщения.

Такой режим описывается в Концепции / Файловый обмен и в Интеграции / Файловый обмен. Промышленные сценарии — в Сценариях / Файловое хранилище через S3.

Варианты развертывания

Платформа рассчитана на работу с любым S3-совместимым хранилищем — выбор делает заказчик по соображениям инфраструктурной политики, стоимости и SLA.

1. Внешний S3-провайдер

Использование облачного S3-совместимого сервиса:

  • Yandex Object Storage;
  • VK Cloud Object Storage;
  • Selectel S3;
  • любой другой S3-совместимый сервис (AWS S3, Cloudflare R2 — при наличии разрешённого внешнего доступа).

Достоинства: не требуется собственная инфраструктура хранения, провайдер обеспечивает SLA и геораспределённое хранение. Ограничения: исходящий трафик с сервера DataHUB к провайдеру S3 должен быть разрешён сетевой политикой; стоимость зависит от объёма хранения и трафика.

2. Локальный MinIO

Развертывание MinIO на той же или соседней инфраструктуре заказчика. MinIO предоставляет S3-совместимый API и работает в Docker-контейнере, что согласуется с архитектурой остальных блоков DataHUB.

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

В будущей поставке планируется отдельный блок /etc/datahub/minio/ с готовым docker-compose.yml, аналогичный другим блокам платформы. До этого момента MinIO разворачивается вручную по официальной документации.

3. Существующее корпоративное S3-хранилище

Если у заказчика уже используется S3-совместимое хранилище (например, в составе корпоративной облачной платформы) — DataHUB подключается к нему как обычный клиент.

Планируемые параметры подключения

Backend будет читать параметры подключения к S3 из переменных окружения блока backend:

S3_ENABLED=true
S3_ENDPOINT=https://s3.example.com
S3_REGION=ru-central1
S3_BUCKET=datahub-files
S3_ACCESS_KEY={{S3_ACCESS_KEY}}
S3_SECRET_KEY={{S3_SECRET_KEY}}
S3_PATH_STYLE_ACCESS=true   # true для MinIO и большинства не-AWS провайдеров

Точный набор и имена переменных будут утверждены при выпуске функциональности — следить за изменениями в Релизах / Изменения платформы.

Требования к bucket

  • Bucket создаётся вручную администратором до подключения.
  • Имя bucket'а согласовано с переменной S3_BUCKET.
  • Доступ к bucket'у — через выделенную сервисную учётную запись (access key / secret key), используемую только Сервером DataHUB.
  • Срок хранения объектов (lifecycle policy) задаётся на стороне S3-провайдера в соответствии с регламентом заказчика — DataHUB сам ничего не удаляет.

Безопасность

  • Сетевой доступ к S3 разрешён только из сети, в которой работает Сервер DataHUB.
  • Учётная запись S3 имеет права только на bucket DataHUB (не глобальный доступ).
  • При работе с конфиденциальными вложениями bucket настраивается на server-side encryption.

Платформа использует двухконтурную модель доступа к файлам:

  • Постоянные ссылки внутри учётных систем. Между интегрируемыми системами и Сервером DataHUB передаются постоянные URL объектов S3. Учётные системы хранят их в своих документах и справочниках и обращаются к ним из бэкенда. Доступ к bucket из этого контура разрешён сетевой политикой — ссылки рабочие и переиспользуемые.
  • Временные ссылки для внешних потребителей. Для выдачи файла вне учётной системы (например, в браузер конечного пользователя, в публичный отчёт, в стороннюю систему) постоянная ссылка отдаваться не должна — иначе bucket окажется доступен любому, кто получил URL.

Способ формирования временной ссылки определяет владелец учётной системы. Два типовых подхода:

  1. Presigned URL средствами S3. Учётная система запрашивает у S3 presigned-ссылку с ограниченным сроком действия (обычно минуты–часы) и отдаёт её конечному потребителю. После истечения срока ссылка перестаёт работать. Подходит, когда конечный потребитель напрямую обращается к S3.
  2. Собственный прокси учётной системы. Учётная система публикует свой эндпоинт (например, /files/<id>), на стороне которого выполняется авторизация конечного пользователя, и затем стримит содержимое файла из S3. Конечный потребитель никогда не видит S3-URL. Подходит, когда нужен контроль авторизации на каждом запросе или когда конечный потребитель не должен обращаться к S3 напрямую.

Выбор между этими подходами — задача проектирования каждой конкретной интеграции, не DataHUB.

Альтернативы S3-хранилищу

S3 — рекомендуемый, но не единственный способ передавать файлы в DataHUB. Если поддержка S3 в платформе ещё не выпущена, или если заказчик принципиально не хочет использовать S3-совместимое хранилище в своей инфраструктуре — обмен файлами возможен в одном из двух режимов.

1. Файл внутри сообщения (inline)

Бинарное содержимое включается в payload сообщения обмена и передаётся через основной транспорт.

Когда подходит: редкие, небольшие вложения (единицы–десятки килобайт) — миниатюры, скан-копии справок, небольшие документы.

Ограничения:

  • Верхний лимит размера задаётся nginx (client_max_body_size 128m), но эффективно режим работает только до нескольких сотен килобайт. Передача мегабайтных файлов через основной транспорт даёт высокую нагрузку на брокер и БД, замедляет обработку обычных сообщений.
  • Один и тот же файл, переданный нескольким получателям, физически дублируется в каждой очереди — нет единой точки хранения.
  • При повторной обработке сообщения файл повторно передаётся целиком.

Ограничение режима

Использовать inline-вложения как штатное решение для систематической передачи больших файлов — нельзя.

2. Хранилище на стороне клиента

Клиент использует собственный механизм хранения файлов, а в сообщения кладёт только ссылки. DataHUB ссылки не интерпретирует и не валидирует — для платформы это просто строки в payload. Ответственность за доступность файла по ссылке, авторизацию, ротацию и резервное копирование — полностью на стороне владельца хранилища.

Когда подходит: у заказчика уже есть внутренняя файловая инфраструктура (файловый сервер, корпоративный документооборот, веб-сервис документов), и интеграция должна с ней работать.

Типовой подспот в 1С. В платформе 1С есть встроенная подсистема «Присоединённые файлы», которая хранит вложения в самой информационной базе или в томах хранения файлов. Это рабочий механизм для одной информационной базы.

При обмене файлами между несколькими базами 1С эта подсистема перестаёт быть удобной:

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

Это одна из типичных ситуаций, для которых и существует выделенное общее хранилище S3 — оно решает проблему «единого пула» естественным образом: файл физически один, ссылка на него едина, удаление выполняется в одном месте.

Что выбрать

Сценарий Рекомендация
Редкие маленькие вложения, единственная пара систем Inline
Регулярный обмен файлами от единиц мегабайт Хранилище на стороне клиента
Обмен файлами между ≥ 3 системами или несколькими базами 1С S3 (после выпуска фичи) или MinIO «здесь и сейчас»
Юридически значимые документы с долгим сроком хранения S3 с lifecycle policy или корпоративное хранилище с регламентом архивации

Что дальше