Обновление приложения
Процедура обновления приложения заключается в переходе с текущей версии на более новую. Процедура обновления включает несколько этапов.
Особенности и рекомендации по обновлению
Версия 4.16
Изменились рекомендуемые версии СУБД:
- Microsoft SQL Server рекомендуемая версия 2019;
- Oracle рекомендуемая версия 19.
Диалект Hibernate для Microsoft SQL Server 2008 не поддерживается. Перед обновлением необходимо изменить диалект в конфигурационном файле dbaccess.properties:
hibernate.dialect=ru.naumen.core.server.hibernate.NauSQLServer2012Dialect (для Microsoft SQL Server 2012/2014/2016/2019);
Для Linux для поддержки Java 17 в файле setenv.sh проверьте наличие параметров и при отсутствии добавьте их:
--add-opens java.base/java.net=ALL-UNNAMED \
--add-opens java.base/jdk.internal.loader=ALL-UNNAMED \
--add-opens java.base/java.lang.reflect=ALL-UNNAMED \
--add-opens java.base/java.nio=ALL-UNNAMED
Версия 4.15 и выше
В Java 11.0.11 и выше TLSv1/TLSv1.1 шифрование считается устаревшим и отключено по умолчанию.
При обновлении со старых версий Java убедитесь, что сервисы, с которыми настроена интеграция с шифрованием трафика, поддерживают TLSv1.2 или TLSv1.3.
Для клиентов, имеющих тестовый стенд, рекомендуется после обновления на версию 4.15.0 и выше выполнить одно из действий:
- перенести каталог <data.dir>/service/ с рабочего стенда на тестовый;
- сохранить пароли с рабочего стенда на тестовый.
Это поддержит корректную работу подключений конфигурации импорта, почты и CTI на тестовых стендах.
При переносе дампов со стендов, на которых работало приложение версии 4.15.0 и выше, необходимо также копировать каталог по указанному пути и складывать на новой инсталляции по такому же пути. В противном случае на вновь поднятом стенде могут стать неработоспособны подключения к почтовым серверам, CTI и конфигурациями импорта.
Версия 4.15 и ниже
Особенности и рекомендации по обновлению на версию 4.15 и ниже
После обновления на версию 4.15 (или после запуска приложения на версии впервые) необходимо сделать резервную копию каталога <data.dir>/service/, где <data.dir> каталог с оперативными данными приложения.
Путь к каталогу <data.dir>/service/ задается в основном конфигурационном файле приложения dbaccess.properties в параметре data.dir.
Каталог <data.dir>/service/ будет создан автоматически после первой операции шифрования/дешифрования пароля. Например, после создания подключения к источнику данных при импорте.
Если приложение установлено по рекомендациям, приведенным в настоящем руководстве, то путь к каталогу будет следующий:
Версия 4.14.5
При обновлении приложения с версий, более старых, чем 4.14.5 на версию 4.14.5 и более новые необходимо внести изменения в настройки логирования. Параметры логирования приложения задаются в конфигурационном файле log4j2.properties.
При обновлении приложения с версии меньше, чем 4.7.6 на версию 4.11.5 будет очищена JMS очередь (действия по событиям, построение отчетов, выгрузка списков и т.д.). Чтобы этого не произошло, необходимо сделать промежуточное обновление на любую версию на любую версию между 4.7.6 и 4.11.5.
При обновлении приложения с версии меньше, чем 4.5.8, на более новую, может возникнуть задержка при первом запуске приложения, т.к. в базе данных создаются индексы в таблице TBL_EVENT с целью увеличения производительности операций при работе приложения с данной таблицей.
Продолжительность задержки может составить от несколько минут до нескольких десятков минут. И зависит от множества факторов. Ожидаемое время задержки можно определить при обновлении тестового приложения.
Версия 4.11. Проверка успешной совместной компиляции скриптовых модулей при обновлении на 4.11.0.14 и выше
При обновлении на версию 4.11.0.14 и выше в консоли необходимо выполнить скрипт для проверки успешной совместной компиляции скриптовых модулей.
После выполнения скрипта необходимо вручную исправить ошибки компиляции (например, изменить имена классов, которые совпадают в нескольких модулях). После исправления ошибок, необходимо повторно выполнить скрипт.
* @versions 4.9.0.46, 4.10.0.40, 4.11.0.13
* @author tshajkemelov
* @since Feb 25, 2020
/**
* Скрипт для проверки успешной совместной компиляции скриптовых модулей
*
*/
import org.codehaus.groovy.control.CompilationUnit
import org.codehaus.groovy.control.Phases
import ru.naumen.core.server.script.ScriptModulesService
import ru.naumen.core.server.script.conf.ScriptModule
import ru.naumen.core.server.script.spi.NauCompilerConfiguration
import ru.naumen.core.server.script.spi.ScriptServiceImpl
/**
* Скомпилировать скриптовые модули
*
* @param modules скриптовые модули
*/
static void compileModules(final Collection<ScriptModule> modules) throws ClassNotFoundException
{
final NauCompilerConfiguration configuration = new NauCompilerConfiguration()
final GroovyClassLoader classLoader = new GroovyClassLoader(ScriptServiceImpl.class.getClassLoader(), configuration)
final CompilationUnit compilationUnit = new CompilationUnit(configuration, null, classLoader)
modules.each {final module -> compilationUnit.addSource(module.getCode(), module.getScript())}
compilationUnit.compile(Phases.CLASS_GENERATION)
}
final ScriptModulesService scriptModulesStorageService = beanFactory.getBean(ScriptModulesService.class)
final Collection<ScriptModule> modules = new ArrayList<>(scriptModulesStorageService.getModules())
compileModules(modules)
Процедура обновления
Проверка соответствия текущих компонентов требованиям новой версии
Перед обновлением удостоверьтесь, что текущее аппаратное и программное обеспечение соответствует требованиям.
Особое внимание следует уделить версиям Apache Tomcat и OpenJDK. Старые версии программного обеспечения часто несовместимы с новой версией приложения. Рекомендуется обновить их вместе с приложением.
Перед обновлением приложения оповестите всех пользователей системы о предстоящих работах, так как данные, добавленные или измененные с момента начала обновления, могут быть утеряны.
После оповещения пользователей остановите приложение.
Резервное копирование при обновлении
Важным этапом процедуры обновления является резервное копирование. При выполнении процедуры обновления происходит перенос данных. В ходе переноса могут возникать ошибки и сбои, способные повлечь за собой порчу или утрату данных. В случае отсутствия резервной копии восстановление испорченных и потерянных данных будет невозможно.
Выполните резервное копирование исполняемых файлов приложения и базы данных, с которой работает приложение.
Установка новой версии приложения
Убедитесь, что версии Apache Tomcat и OpenJDK, используемые приложением, соответствуют требованиям.
На Linux все операции с файлами приложения необходимо выполнять от имени того пользователя, с правами которого приложение запускается (по умолчанию nausd4).
Установка новой версии приложения:
-
Создайте в директории <app_dir>/deploy/ каталог <dd_mm_yyyy>, соответствующий текущей дате.
для ОС Linux: /opt/nausd4/deploy/2015-04-24
- Сохраните в созданный каталог предоставленный вам файл новой версии приложения, вида sdng-war-4.X.X.X.war.
-
Выполните контроль целостности war-файла путем сравнения его хэш-суммы SHA-1 с хэш-суммой, полученной вместе с дистрибутивом у вашего менеджера.
Для ОС Linux:
sha1sum /opt/naumen/nausd4/deploy/2020-01-24/sdng-war-*.war
Если вычисленная хэш-сумма не соответствует предоставленной, то проводить обновление этим дистрибутивом нельзя.
- Удалите каталог <app_dir>/tomcat/webapps/sd/ и текущую версию приложения <app_dir>/tomcat/webapps/sd.war.
- Скопируйте на место удаленных файлов новую версию приложения и переименуйте файл в sd.war.
- Удалите содержимое каталога <app_dir>/tomcat/temp.
В директории <app_dir>/tomcat/webapps должен быть только один каталог с файлами приложения. Если будет два каталога с файлами приложения, то Tomcat попытается запустить приложение два раза, что приведет к частичной или полной неработоспособности приложения.
Недопустимо просто переименовать каталог или файл sd.war со старой версией приложения и оставить его в той же директории.
Каталог со старой версией необходимо удалить.
Если после запуска приложение автоматически не разворачивается и на экране отображается "Ошибка 404", то необходимо вручную распаковать установленный sd.war (как ZIP-архив) в каталог <app_dir>/tomcat/webapps/sd/.
Выполните запуск приложения, согласно рекомендациям.
В процессе запуска рекомендуется контролировать сообщения, выводимые в журналах работы приложения.
Обязательно сохраните лог первого запуска приложения после обновления, в котором содержится важная информация о миграциях в базе данных.
Проверка работоспособности приложения
После завершения процесса обновления и запуска приложения выполните проверку работоспособности приложения.
Если в ходе проверки работоспособности обнаруживаются ошибки, то проведите процедуру восстановления резервных копий исполняемых файлов приложения и базы данных и вернитесь к эксплуатации старой версии приложения. Проведите диагностику состояния для выяснения причин неисправности.
О проблемах, возникших после обновления приложения, необходимо сообщать на cs@itsm365.com.
Если при проверке работоспособности приложения ошибок не выявлено, то процедура обновления приложения при переходе с одной версии на другую проведена успешно, и пользователи могут приступить к работе с новой версией приложения.