При обновлении критического для бизнеса приложения необходимо сделать несколько вещей. Во-первых, протестировать работоспособность его новой версии на продуктивной среде (т.н. sanity check). Во-вторых, при этом необходимо не нарушить работу уже развернутой версии, а так же сохранить данные пользовательских сессий до момента удаления старой версии приложения. В данной заметке мы рассмотрим сценарий обновления приложения, позволяющий решить данные задачи.
В качестве тестового приложения будем использовать веб-приложение, представляющее собой сервлет, выводящий версию и количество обслуживаемых в рамках пользовательской сессии запросов. Соответственно количество обслуженных запросов берется из сессии, увеличивается на единицу и в ней же сохраняется.
Прежде чем тестировать обновление приложения нам необходимо развернуть на сервере его старую версию. Сделать это можно с помощью консольной утилиты weblogic.Deployer:
На странице Deployments консоли управления WebLogic видно, что приложение DeployDemo, имеющее версию 1.0.0, успешно развернуто и находится в состоянии Active - готово к обслуживанию пользовательских запросов.
Наберем в строке браузера URL-приложения, http://localhost:8301/deploy/demo.html, и обновим несколько раз страницу. Видно, что в окно браузера выводится версия приложения - 1.0.0 и увеличивающееся с каждым обновлением количество обслуженных запросов.
Продемонстрируем, что в случае обновления приложения путем его повторного развертывания, данные сессии теряются.
Снова обновим несколько раз страницу, таким образом, чтобы число обслуженных запросов стало отличаться от единицы. Тем самым мы эмулируем наличие пользовательских данных в сессии, которые не должны потеряться до финального удаления старой версии приложения.
Предположим, что мы создали war-архив с новой версией приложения, выводящей в качестве значения параметра Version: - 1.0.1. Нам необходимо развернуть данную новую версию приложения на сервере, протестировать ее и в случае успеха - активизировать. Тем самым новая версия приложения станет доступна пользователям. При этом пользователи, уже работающие со старой версией, т.е. имеющие незавершенные сессии, должны не потерять свои данные и продолжить работу в течение всего цикла обновления приложения до момента удаления старой версии.
Для распространения приложения на сервере служит команда distribute консольной утилиты weblogic.Deployer.
В результате успешного выполнения данной команды на сервере появляется новая версия приложения DeployDemo (версия 1.0.1), находящаяся в состоянии Prepared.
Предыдущая версия приложения (1.0.0) так же переходит в состояние Prepared, но при этом продолжает обслуживать запросы как в рамках уже начатых
так и в рамках новых пользовательских сессий.
Для тестирования новой версии приложения необходимо стартовать ее в административном режиме, тогда данная версия станет доступна для обслуживания запросов, поступающих по административному каналу домена (Administrator Channel). Запустить приложение в административном режиме можно, выполнив команду start с указанием ключа -adminmode.
После успешного выполнения данной команды новая версия приложения переходит в состояние Admin.
При этом пользовательские запросы, как в рамках существующих, так и в рамках новых сессий, обслуживаются по прежнему старой версией приложения.
Перезапустим Firefox, чтобы начать новую пользовательскую сессию и зайдем на приложение по административному каналу, используя URL https://ADMIN_SERVER:ADMINISTRATION_PORT/deploy/demo.html. Видно, что запросы по административному каналу обслуживает новая версия приложения.
Если обновить несколько раз окно браузера, то видно, что количество обработаных запросов растет. Т.е. приложение работает так, как от него ожидается.
Корректная работа приложения позволяет принять решение о вводе новой версии в промышленную эксплуатацию. Для этого необходимо ее стартовать для обслуживания запросов пользователей, выполнив команду start без указания режима -adminmode.
Новая версия приложения при этом переходит в состояние Active. Старая версия - в промежуточное состояние stop Running.
При этом новая версия приложения перестает быть доступной по административному каналу.
Но сессия администратора сохраняется при доступе к приложению по обычному пользовательскому URL.
Запущенная ранее в Internet Explorer пользовательская сессия так же сохраняется, причем обслуживает пользовательские запросы в рамках данной сессии старая версия приложения (версия 1.0.0).
После некоторого срока можно предположить, что активных пользовательских сессий, в рамках которых запросы обслуживаются старой версией приложения уже нет, и мы не хотим поддерживать эту версию. Тогда ее нужно удалить. Сделать это можно с помощью команды undeploy.
В случае успешного завершения данной команды старая версия приложения удаляется из списка Deployments.
Если обновить страницу браузера в рамках живущей сессии, обслуживаемой старой версией приложения, то становится видно, что началась новая сессия и запросы обслуживает уже новая версия программы.
Поддержка сервером приложений Oracle WebLogic нескольких версий одного и того же приложения, а так же возможность тестирования приложения по административному каналу, позволяет обеспечить высокую доступность критических для бизнеса ресурсов в режиме 24x7 даже при проведении работ на сервере. При этом пользователи могут продолжать работу с приложением и не замечать того, что оно обновилось до момента отмирания сессии и, например, повторной авторизации. Такое поведение защищает от потери любых пользовательских данных сохраненных в сессии.
Довольных вам пользователей и меньше проблем при администрировании!
Понравилось сообщение - подпишитесь на блог и Twitter
Тестовое приложение
В качестве тестового приложения будем использовать веб-приложение, представляющее собой сервлет, выводящий версию и количество обслуживаемых в рамках пользовательской сессии запросов. Соответственно количество обслуженных запросов берется из сессии, увеличивается на единицу и в ней же сохраняется.
Прежде чем тестировать обновление приложения нам необходимо развернуть на сервере его старую версию. Сделать это можно с помощью консольной утилиты weblogic.Deployer:
C:\Users\psamolisov>java -Dweblogic.security.TrustKeyStore=DemoTrust weblogic.Deployer -username weblogic -password 12345678 -adminurl t3s://localhost:9012 -deploy -upload -name DeployDemo -appversion 1.0.0 -targets ws_server1 C:\Work\Develop\_Java\my-learning\DeployDemo\DeployWeb\deploy\DeployWeb.war
На странице Deployments консоли управления WebLogic видно, что приложение DeployDemo, имеющее версию 1.0.0, успешно развернуто и находится в состоянии Active - готово к обслуживанию пользовательских запросов.
Наберем в строке браузера URL-приложения, http://localhost:8301/deploy/demo.html, и обновим несколько раз страницу. Видно, что в окно браузера выводится версия приложения - 1.0.0 и увеличивающееся с каждым обновлением количество обслуженных запросов.
Продемонстрируем, что в случае обновления приложения путем его повторного развертывания, данные сессии теряются.
C:\Users\psamolisov>java -Dweblogic.security.TrustKeyStore=DemoTrust weblogic.Deployer -username weblogic -password 12345678 -adminurl t3s://localhost:9012 -deploy -upload -name DeployDemo -appversion 1.0.0 -targets ws_server1 C:\Work\Develop\_Java\my-learning\DeployDemo\DeployWeb\deploy\DeployWeb.war
Снова обновим несколько раз страницу, таким образом, чтобы число обслуженных запросов стало отличаться от единицы. Тем самым мы эмулируем наличие пользовательских данных в сессии, которые не должны потеряться до финального удаления старой версии приложения.
Процедура разворачивания и тестирования новой версии
Предположим, что мы создали war-архив с новой версией приложения, выводящей в качестве значения параметра Version: - 1.0.1. Нам необходимо развернуть данную новую версию приложения на сервере, протестировать ее и в случае успеха - активизировать. Тем самым новая версия приложения станет доступна пользователям. При этом пользователи, уже работающие со старой версией, т.е. имеющие незавершенные сессии, должны не потерять свои данные и продолжить работу в течение всего цикла обновления приложения до момента удаления старой версии.
Для распространения приложения на сервере служит команда distribute консольной утилиты weblogic.Deployer.
C:\Users\psamolisov>java -Dweblogic.security.TrustKeyStore=DemoTrust weblogic.Deployer -username weblogic -password 12345678 -adminurl t3s://localhost:9012 -distribute -upload -name DeployDemo -appversion 1.0.1 -targets ws_server1 C:\Work\Develop\_Java\my-learning\DeployDemo\DeployWeb\deploy\DeployWeb.war
В результате успешного выполнения данной команды на сервере появляется новая версия приложения DeployDemo (версия 1.0.1), находящаяся в состоянии Prepared.
Предыдущая версия приложения (1.0.0) так же переходит в состояние Prepared, но при этом продолжает обслуживать запросы как в рамках уже начатых
так и в рамках новых пользовательских сессий.
Для тестирования новой версии приложения необходимо стартовать ее в административном режиме, тогда данная версия станет доступна для обслуживания запросов, поступающих по административному каналу домена (Administrator Channel). Запустить приложение в административном режиме можно, выполнив команду start с указанием ключа -adminmode.
C:\Users\psamolisov>java -Dweblogic.security.TrustKeyStore=DemoTrust weblogic.Deployer -username weblogic -password 12345678 -adminurl t3s://localhost:9012 -start -adminmode -name DeployDemo -appversion 1.0.1
После успешного выполнения данной команды новая версия приложения переходит в состояние Admin.
При этом пользовательские запросы, как в рамках существующих, так и в рамках новых сессий, обслуживаются по прежнему старой версией приложения.
Перезапустим Firefox, чтобы начать новую пользовательскую сессию и зайдем на приложение по административному каналу, используя URL https://ADMIN_SERVER:ADMINISTRATION_PORT/deploy/demo.html. Видно, что запросы по административному каналу обслуживает новая версия приложения.
Если обновить несколько раз окно браузера, то видно, что количество обработаных запросов растет. Т.е. приложение работает так, как от него ожидается.
Ввод новой версии в промышленную эксплуатацию
Корректная работа приложения позволяет принять решение о вводе новой версии в промышленную эксплуатацию. Для этого необходимо ее стартовать для обслуживания запросов пользователей, выполнив команду start без указания режима -adminmode.
C:\Users\psamolisov>java -Dweblogic.security.TrustKeyStore=DemoTrust weblogic.Deployer -username weblogic -password 12345678 -adminurl t3s://localhost:9012 -start -name DeployDemo -appversion 1.0.1
Новая версия приложения при этом переходит в состояние Active. Старая версия - в промежуточное состояние stop Running.
При этом новая версия приложения перестает быть доступной по административному каналу.
Но сессия администратора сохраняется при доступе к приложению по обычному пользовательскому URL.
Запущенная ранее в Internet Explorer пользовательская сессия так же сохраняется, причем обслуживает пользовательские запросы в рамках данной сессии старая версия приложения (версия 1.0.0).
После некоторого срока можно предположить, что активных пользовательских сессий, в рамках которых запросы обслуживаются старой версией приложения уже нет, и мы не хотим поддерживать эту версию. Тогда ее нужно удалить. Сделать это можно с помощью команды undeploy.
C:\Users\psamolisov>java -Dweblogic.security.TrustKeyStore=DemoTrust weblogic.Deployer -username weblogic -password 12345678 -adminurl t3s://localhost:9012 -undeploy -name DeployDemo -appversion 1.0.0
В случае успешного завершения данной команды старая версия приложения удаляется из списка Deployments.
Если обновить страницу браузера в рамках живущей сессии, обслуживаемой старой версией приложения, то становится видно, что началась новая сессия и запросы обслуживает уже новая версия программы.
Выводы
Поддержка сервером приложений Oracle WebLogic нескольких версий одного и того же приложения, а так же возможность тестирования приложения по административному каналу, позволяет обеспечить высокую доступность критических для бизнеса ресурсов в режиме 24x7 даже при проведении работ на сервере. При этом пользователи могут продолжать работу с приложением и не замечать того, что оно обновилось до момента отмирания сессии и, например, повторной авторизации. Такое поведение защищает от потери любых пользовательских данных сохраненных в сессии.
Довольных вам пользователей и меньше проблем при администрировании!
Понравилось сообщение - подпишитесь на блог и Twitter
5 комментариев:
Интересно, а в случае distribute развертываний приложений WebLogic предоставляет полностью изолированный namespace для http/iiop/rmi протоколов?
Т.е. если в подобном приложении испольщуется iiop - для него тоже будет отдельный порт?
JDNI реестры тоже изолированные?
Нет, я так понимаю никаких отдельных портов не предусмотрено. Ситуация аналогична HTTP-сессии: если RMI-соединение уже установлено, то клиент будет продолжать работать с предыдущей версией приложения, если активировали новую версию и устанавливается новое соединение, то будет использоваться новая версия приложения. Т.е. какого-то резервирования портов нет.
Административный канал - это не резервирование порта, это возможность работать с приложениями, запущенными в специальном режиме и недоступными обычным пользователям.
Естественно данный способ обновления имеет ограничения. Если, например, обе версии пишут в базу и в новой версии был исправлен баг, то живые пользовательские сессии, продолжающие использовать старую версию приложения будут по-прежнему плодить записи с багом. Поэтому нужно внимательно смотреть подходит ли такой способ обновления для конкретно вашего случая. Подробности описаны в документации. Там же, кстати, написано и про JNDI.
>Подробности описаны в документации. Там же, кстати, написано и про JNDI.
Спасибо, почитал. Мне больше всего было интересно - если приложение содержит EJB бины как будет разруливаться конфликт имен при регистрации. В документации предлагают использовать local scope.
Т.е. в таком версионированном режиме поддержка фич Java EE органичена, но в любом случае это больше чем в WebSphere.
Павел, Здравствуйте! Если не сложно, помогите, пожалуйста, советом.
Встала задача реализовать интеграцию данных между salesforce и другой CRM. И с той и с другой стороны торчат REST API, возможно еще CometD для стриминга из SalesForce и JMS со стороны другой CMS. Что выбрать в качестве framework решения? Вроде бы Spring integration неплохой, но и apache camel хвалят с его мудреным синтаксисом... Я не имел опыта работы ни со спрингом ни с camel, привык писать все вручную ) Но начальство требует поддерживаемость и расширяемость, так что надо что то использовать без вариантов. Ваше слово?
Здравствуйте.
Я тоже не работал ни со Spring Integration, ни с Apache Camel. При решении вашей задачи я бы подумал на перспективу и попробовал бы какую-нибудь ESB, возможно с открытыми исходниками. По крайней мере задача оркестровки веб-сервиса и JMS-очереди на той же OSB решается довольно просто.
Отправить комментарий
Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!