Войти

Настройка blob-адаптера для передачи вложений

Известно, что для передачи текстовых и числовых данных нужно настроить Агенты (один у поставщика, один у потребителя), развернуть витрину данных (ВД) и создать регламентированный запрос (РЗ), с помощью которого и будет осуществляться обращение к витрине за данными.  Но что, если требуется передавать также и файлы?

В этом нам поможет инструмент, необходимый для работы с передачей файлов (blob-объектов), именуемый BLOB-адаптер. Для его работы требуется тот же функционал, что и при обмене обычными данными, но дополнительно установить и настроить сам BLOB-адаптер.

В данной статье рассмотрим пример взаимодействия с витриной данных Лайт версии. Предполагаемая витрина данных (ВД) в ЕИП НСУД в своей таблице должна содержать атрибуты с типом данных bytea, что позволит хранить двоичные данные (последовательность байт).

Рассмотрим на примере витрины: “Реестр страховых компаний”, где осуществляется передача логотипов страховых компаний (Рисунок 1).

Рисунок 1.png

Рисунок 1 – ЕИП НСУД. Просмотр таблицы ВД: “Реестр страховых компаний” со списком атрибутов таблицы.

После того, как витрина данных (ВД) будет развёрнута на сервере, необходимо загрузить структуру данных витрины из ЕИП НСУД через CSV-uploader. Но заполнить её необходимыми данными нужно будет позднее.

Для реализации передачи blob-объектов нужно выполнить следующие шаги:

Примечание: Передача объектов с использованием хранилища данных описана в статье Использование Blob Адаптера для обмена blob объектами.

Для взаимодействия с витриной данных (ВД) нужен особый сервис, который совместим с S3. Таким сервисом является программное обеспечение MinIO.

Установка и настройка хранилища blob-объектов MinIO

Предполагается, что хранилище объектов будет располагаться на сервере вместе с витриной данных (ВД). Рассмотрим один из вариантов установки сервиса MinIO на ОС Linux Centos:

Загрузите двоичный файл сервера MinIO с официального сайта командой ниже:

wget https://dl.min.io/server/minio/release/linux-amd64/minio

Результат выполнения команды (Рисунок 2):

Рисунок 2.jpg

Рисунок 2 – Результат загрузки файла сервера MinIO.

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

sudo chmod +x minio

Переместите файл в каталог /usr/local/bin для того, чтобы сценарий запуска systemd искал сервис MinIO в нужном месте. Теперь можно описать юнит-файл, который будет запускаться автоматически при запуске системы.

Примечание: в целях безопасности рекомендуется не запускать сервер MinIO от имени суперпользователя root.

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

sudo useradd -r minio-user -s /sbin/nologin

Данная команда устанавливает /sbin/nologin в качестве оболочки для пользователя minio-user, что позволяет пользователю не входить в систему каждый раз, когда это потребуется.

Далее необходимо изменить владельца двоичного файла minio, передав права собственности пользователю minio-user:

sudo chown minio-user:minio-user /usr/local/bin/minio

Создайте каталог, в котором сервер MinIO будет хранить файлы:

sudo mkdir /usr/local/share/minio 

Сделайте пользователя minio-user владельцем каталога следующей командой:

sudo chown minio-user:minio-user /usr/local/share/minio 

Большинство конфигурационных файлов хранятся в каталоге /etc. Создайте в нем конфигурационный каталог и для сервера MinIO, и выдайте права для пользователя minio-user командами ниже:

sudo mkdir /etc/minio
sudo chown minio-user:minio-user /etc/minio 

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

sudo nano /etc/default/minio 

Скопируйте и измените следующие переменные среды из примера ниже:

MINIO_ACCESS_KEY="minio"
MINIO_VOLUMES="/usr/local/share/minio/"
MINIO_OPTS="-C /etc/minio --address your_server_ip:8000"
MINIO_SECRET_KEY="minio124"

Результат по примеру представлен ниже (Рисунок 3):

Рисунок 3.jpg

Рисунок 3 – редактирование конфигурационного файла minio.

В данной конфигурации были описаны следующие переменные:

  • MINIO_ACCESS_KEY: задаёт логин пользователя minio для доступа к пользовательскому интерфейсу хранилища данных через браузер.
  • MINIO_SECRET_KEY: задаёт закрытый ключ для входа в хранилище данных MinIO. В этом мануале указано условное значение minio124, но для защиты настоящего сервера рекомендуется задать более надёжный пароль.
  • MINIO_VOLUMES: задаёт рабочий каталог сервера для хранения данных (который создали ранее).
  • MINIO_OPTS: определяет, где и как сервер обслуживает данные. Флаг -C указывает minio как каталог конфигурации (который создали ранее), а флаг –address указывает IP-адрес и порт, к которым привяжется сервер MinIO.

Важно: если IP-адрес не указан, Minio привяжется к каждому адресу на сервере, включая localhost и все IP-адреса, связанные с Docker, на котором уже развёрнута витрина данных (ВД). Поэтому рекомендуется указать конкретный IP-адрес. В примере указан порт 8000, так как он не используется витриной, а значит не помешает взаимодействию и работе с витриной данных (ВД).

Сохраните и закройте конфигурационный файл.

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

Создание сервиса systemd для MinIO

Сценарий systemd будет искать учетную запись пользователя и группу по имени minio-user, которого создали ранее.

Загрузите официальный файл сервиса MinIO, используя следующую команду:

curl -O https://raw.githubusercontent.com/minio/minio-service/master/linux-systemd/minio.service

Результат выполнения команды (Рисунок 4):

Рисунок 4.jpg

Рисунок 4 – Загрузка файла-сервиса minio.service.

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

sudo mv minio.service /etc/systemd/system

Чтобы проверить содержимое minio.service перед его использованием, откройте его в любом текстовом редакторе. Для этого переходим в каталог /etc/system/system:

cd /etc/systemd/system
nano minio.service

Результат выполнения команд (Рисунок 5):
Рисунок 5.jpg

Рисунок 5 – Окно редактирования файла-сервиса.

Данный юнит-файл будет запускать сервер MinIO через пользователя minio-user. С помощью описанных ранее переменных среды, этот процесс будет происходить автоматически при запуске системы.

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

sudo systemctl daemon-reload

Далее необходимо включить сервис MinIO в автозагрузку:

sudo systemctl enable minio

После чего появится следующая фраза: Created symlink from /etc/systemd/system/multi-user.target.wants/minio.service to /etc/systemd/system/minio.service.

Теперь, когда скрипт systemd успешно настроен, пришло время запустить сервер следующей командой:

sudo systemctl start minio

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

sudo systemctl status minio

Статус работы сервера представлен ниже (Рисунок 6):

Рисунок 6.png

Рисунок 6 – Результат проверки статуса работы сервера MinIO.

Предполагалось, что при установке ПО витрины данных и Агента ПОДД по рекомендации необходимо было отключить Firewall. Если это было сделано ранее, то дополнительных действий для открытия порта 8000 не требуется, иначе необходимо задать правило в брандмауэре для открытия этого порта.

Загрузка данных в хранилище данных MinIO

Для того, чтобы убедиться, что сервер MinIO работает штатно, откройте графический интерфейс браузера. Введите IP-адрес сервера MinIO с портом 8000 и авторизуйтесть под учётной записью, созданной ранее (Рисунок 7).

Рисунок 7.png
Рисунок 7 – Авторизация в сервере MinIO.

Cоздайте каталог для хранения blob-объектов и поменяйте настройку параметра Access Policy на public, что позволит задать публичную ссылку объекту хранилища (Рисунок 8):

Рисунок 8.png
Рисунок 8 – Создание каталога photo в хранилище данных на сервере MinIO.

Далее загрузите объекты в ранее созданный каталог. При просмотре содержимого каталога можно найти прямую ссылку на объект нажатием на плашку Share из просмотра объекта на панели справа (Рисунок 9):

Рисунок 9.png
Рисунок 9 – Просмотр загруженных объектов в хранилище данных на сервере MinIO.

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

Наполнение витрины данных (ВД)

В столбце с атрибутами для передачи объектов помещается название объекта из хранилища данных сервера MinIO. В примере данной статьи этим объектом является логотип (картинка с расширением .jpg) страховой компании. После загрузки данных в витрину можно просмотреть  содержимое её таблиц (Рисунок 10).

Рисунок 10.png
Рисунок 10 – Просмотр содержимого таблицы ВД “Реестр страховых компаний”.

Настройка BLOB-адаптера

Далее необходимо внести соответствующие изменения в конфигурационный файл BLOB-адаптера под ранее созданный функционал. Если BLOB-адаптер был развёрнут по шагам из инструкции установки выше, то каталог с файлами модуля адаптера должен располагаться по пути: /opt/blob-adapter. Перейдите в данный каталог и откройте файл конфигурации с помощью редактора следующими командами:
cd /opt/blob-adapter
nano application.yml

В стандартной конфигурации (Рисунок 11) необходимо вписать префикс витрины данных в топики blob.rq, blob.rs и blob.err (с точкой в конце). Также вписать IP-адрес сервера, на котором развернут BLOB-адаптер. В строке host необходимо указать адрес хранилища сервера MinIO, в port прописать порт хранилища, который задавали ранее (в примере 8000). В строке path-prefix необходимо вписать название каталога объектов из хранилища MinIO.

Рисунок 11.png

Рисунок 11 – Редактирование конфигурационного файла BLOB-адаптера.

Cохраните изменённые настройки и закройте редактор. Чтобы настройки применились, перезапустите BLOB-адаптер.

Реализация передачи blob-объектов

Для того, чтобы реализовать передачу blob-объектов, Агенту-Потребителю необходимо направить регламентированный запрос (РЗ) в витрину данных (ВД).

Задача BLOB-адаптера заключается в том, что при получении запроса (РЗ) от Агента-Потребителя адаптер ищет в нём параметр с типом данных BYNARY (Рисунок 12). Если такой параметр есть в запросе, то BLOB-адаптер идёт в хранилище данных, находит там объект с таким названием, переходит по ссылке и возвращает бинарный объект Агенту-Потребителю в формате Base64.

Рисунок 12.jpg

Рисунок 12 – Отправка РЗ в витрину с использованием сервиса Postman.

Для того, чтобы наглядно увидеть, какой объект передаётся, необходимо воспользоваться сервисом DBeaver (Рисунок 13). Как настроить Агента для получения данных через DBeaver описано в соответствующей статье.

Рисунок 13.png

Рисунок 13 – Отправка РЗ в витрину с использованием сервиса DBeaver.

Авторизуйтесь, чтобы оставить комментарий к статье