Сборка DSpace ( Получение исходных кодов и сборка из таковых и установка web-приложений "DSpace v6". )

OS: "Linux Ubuntu 18.04.1 LTS (Bionic Beaver)".
Apps: Java, Apache Maven, Ant, Tomcat, Nginx, PostgreSQL, patch.

Задача: описание этапов сборки из исходных кодов и развёртывания комплекса web-приложений ("сервлетов") репозитория цифровых документов "DSpace v6", в среде контейнеризатора "Apache Tomcat".

Это вторая часть развёрнутой инструкции, описывающая сборку и установку web-приложений "DSpace", а подготовка системного и прикладного программного окружения разбиралась в предыдущей публикации.

Последовательность дальнейших действий такова:



Получение дистрибутива "DSpace" и наложение "патча".

На странице ленты релизов https://github.com/DSpace/DSpace/releases сайта проекта ищем то, что нас интересует - в частности, по состоянию на Март 2019 есть сборка "DSpace 6.3" от 27 Июня 2018 - последний стабильный релиз ветви "v6".

Обращаю внимание на то, что после официальной сборки "DSpace 6.3" от 27 Июня 2018 до Апреля 2019 в исходный код уже внесли около пятидесяти некритичных правок - есть смысл взять проект в его свежем состоянии, прямо из Git-репозитория:


Для простоты я скопировал ветку "dspace-6_x" в свой Git-репозиторий и в дальнейшем работал уже с ней:



Упреждая события подскажу, что запуск "DSpace v6" на "базе данных" от предыдущей версии (например "v5") вызовет автоматическую процедуру обновления структуры и переиндексации содержимого БД. Сразу отмечу, что автоматическое обновление структуры не отработает из-за некорректного скрипта "V6.0_2015.03.07__DS-2701_Hibernate_migration.sql", пытающегося создать "индекс", когда это сделать невозможно. Я сделал для исправления конфликтов и недочётов простейший "патч", меняющий порядок создания "индексов" и дополняющий логику удаления некоторых колонок таблиц каскадированием:



Применение "патча" элементарно:



Учитывая простоту "патча" легко проверить, не налагался ли он уже на файл, запустив проверку возможности процедуры отката изменений (полезно в автоматизации) - например; далее мы видим результат прогона теста на файле с уже применённым к нему "патчем":


Предварительное конфигурирование web-проекта "DSpace".

Перед сборкой Java-приложений из комплекта модулей и исходного кода дистрибутива необходимо задать ряд специфичных для нашего инстанса сервиса параметров, которые будут применены к соответствующим компонентам проекта "DSpace" (обращаю внимание на то, что в именах параметров важен регистр символов):



Скорректируем настройки журналирования web-приложений "DSpace", ограничив время их хранения:



Настройки журналирования входящего в дистрибутив "DSpace" сервера полнотекстового поиска "Solr" вынесены в отдельный файл конфигурации, в котором полезно внести унифицирующие правки для автоматизации ротации:



Аналогично изменяем настройки журналирования входящего в дистрибутив "DSpace" сервиса согласований URI документов в CNRI:



Я стараюсь разносить логику и содержимое, так что журналы событий web-приложений символической ссылкой направляю в более соответствующую им поддиректорию "/var/log":


Cборка Java-приложений проекта посредством "Maven".

Сборка Java-компонентов проекта осуществляется инструментарием "Apache Maven", руководствующимся настройками из файлов "pom.xml". Результирующие файлы выкладываются в автоматически создаваемую для этого директорию "./dspace/target/dspace-installer/", заданную по умолчанию в применяемом при сборке плагине "Apache Maven Assembly" (при желании можно изменить месторасположение, изменив его в файле "assembly.xml").

Запускаем сборку компонентов проекта (по умолчанию в конфигурации с использованием СУБД "PostgreSQL"):



В случае сбоя на этапе сборки какого-то конкретного модуля можно запустить его заново индивидуально:


В нашем случае результаты предварительной сборки выкладываются в директорию "/usr/local/src/dspace/dspace/target/dspace-installer/", а исходные файлы остаются при этом неизменными.

Исправление недочётов сборки.

При сборке посредством "Maven" в соответствии с заданными разработчиками в "pom.xml" правилами в комплекте "DSpace" для подсистемы "Solr" не поставляется две Java-библиотеки, без которых "Apache Solr Webapp" даже не запустится, записав в журнал событий что-то вроде следующего:



Необходимые Java-библиотеки имеются в пакете компонентов "DSpace XML-UI" - просто копируем их оттуда:


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

Подготовка к инсталляции Java-приложений проекта посредством "Ant".

Вторым проходом инструментарием "Apache Ant" произведём финальную обработку настроек компонентов "DSpace" и выгрузку готовых web-приложений в указанное место файловой системы. Утилита "ant" руководствуется настройками из файлов "build.xml".

В соответствии с предопределённым разработчиками "DSpace" порядком вторым этапом предполагается инсталляция непосредственно в месторасположение web-приложения, заданное заранее в файле "dspace.conf". Я такого не люблю, предпочитая вначале полностью собирать приложение, а уже потом рассредотачивать файлы в соответствии с политикой обновления сервиса - потому направляем инсталлятор в удобное место.

Создаём подставную директорию для "инсталляции":


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




Сразу после завершения компоновки нужно найти в конфигурационных файлах готовых к применению компонентов проекта путь к подставной инсталляционной директории и заменить его на реальное месторасположение файлов проекта:


Исправление недочётов компоновки.

Важный нюанс - для "DSpace v6" в описаниях параметров сборки некоторых компонентов указывается обязательная зависимость от устаревшего уже в "Java 7" модуля "Servlet API v2.5", на замену которому пришёл "Servlet API v3". Так вот, в современных сборках на "Java v8-11" и "Tomcat v8/9", по умолчанию работающих на современном API и укомплектованных современным модулем "Servlet API v3", попытка инсталлятора "DSpace" подсунуть модуль предыдущей версии вызовет конфликт и отказ в работе, сопровождаемый примерно такими сообщениями в журнале событий:



В "DSpace v7" эту проблему устранили "патчем" обновляющим требования к зависимостям для сборщика "Maven".

На первом этапе я решил проблему создав аналогичный "патч", указав в конфигурационном файле "./dspace/pom.xml" на то, что необходимая библиотека "Servlet API" будет предоставлена извне и нет необходимости в её сборке и включению в проект как таковой. Однако это повлекло за собой некоторые неудобства, в основном выражающиеся в том, что сборка посредством "Apache Ant" опиралась на эту самую библиотеку, и приходилось указывать утилите путь к внешним, что неудобно - проще оказалось удалять лишний файл Java-библиотеки после сборки, перед развёртыванием web-проекта:


Несмотря на то, что настройки "DSpace" уже с версии "v5" полностью вынесены в конфигурационный файл "dspace.conf", ему тем не менее очень хочется обнаружить файл "local.cfg" (хоть бы и пустой) - на обработку этой "сбойной" ситуации тратится время, так что просто создаём заглушку:


Подготовка к развёртыванию web-приложений и компонентов "DSpace".

По завершению сборки компонентов "DSpace" мы получим нижеперечисленный набор web-приложений, из которых не все могут понадобится в реальной эксплуатации:


Лично нам нужны только три web-приложения:


Кроме размещаемых в "./webapps" web-приложений при сборке проекта "DSpace" создаётся несколько директорий, которые должны быть размещены в "/var/lib/dspace". Часть из них обязательные, а некоторые будут созданы автоматически по необходимости:


Некоторые директории не нужны, если не задействован соответствующий функционал:


Основной объём данных, которыми оперируют четыре нужным нам web-приложения "DSpace", сосредоточены в трёх местах:


Развёртывание web-приложений "DSpace".

По умолчанию в "Apache Tomcat" включено автоматическое развёртывание web-приложений, дистрибутивы которых размещаются в типовой директории "./webapps" - если это не так, то следующие опции активируют автоматическую распаковку WAR/EAR-архивов, их развёртывание и последующее удаление предыдущих версий (если таковые обнаружены) с переводом трафика на новые web-приложения:



Как вариант, учитывающий замену конфигурационных файлов вне web-приложений, можно остановить контейнеризатор, заменить файлы web-проекта целиком вручную и запустить "Tomcat", тем самым побудив его инициализировать приложения заново:


Процесс запуска "Tomcat" и развёртывания web-приложений небыстрый, обычно не менее двух-трёх минут - в это время можно заглянуть в журналы событий "Systemd" и контейнеризатора, а потом и самого "DSpace":


Первичная настройка web-приложений "DSpace".

После инсталляции для доступа к web-панели администрирования "DSpace" необходимо создать локального пользователя (их может быть несколько), обладающего максимальными привилегиями - делается это посредством специализированной CLI-утилиты:




Сразу можно проверить успешность создания аккаунта пользователя, залогинившись в web-интерфейсе (по адресу вроде "https://dspace.example.net/xmlui/admin/panel?tab=Configuration") и ознакомившись с некоторыми параметрами конфигурации web-приложения.

Как правило для интеграции со сторонними информационными системами необходим "OAI-PMH Interface" - простейшим запросом "https://dspace.example.net/oai/request?verb=Identify" проверяем его доступность:


Налаживаем регулярное исполнение фоновых задач.

Некоторые задачи web-приложения "DSpace" должны исполнятся регулярно, по расписанию (ссылка на полный перечень рекомендаций) - например здесь мы настроим запуск процедуры обновления "карты сайта", выдаваемой в оптимизированном для поисковых машин XML-формате, а также оптимизацию "базы данных" полнотекстового поискового индекса "Apache Solr":



Есть смысл один раз запустить первую процедуру вручную и проверить, обновилась ли "карта сайта":


Нагрузочное тестирование.

После запуска web-сервиса возможно захочется протестировать, как скоро он сломается под возрастающей нагрузкой. Для этого можно воспользоваться утилиткой "Siege".

Тестируем "DSpace" в сценарии "250 пользователей 10 минут упорно ходят по сайту":


Запускал в два-три потока, с разных компьютеров одновременно - через пару минут после начала "DSpace" почти перестал отзываться, потери составляли до 10%, но сервис в целом при этом не ломался и сразу после снятия нагрузки начинал работать нормально.