Развертывание с нулевым временем простоя (и откат) в Tomcat;

Если вы думали, что Tomcat не может стать лучше, вы ошиблись. Tomcat 7 представляет так называемое параллельное развертывание . Это было сделано SpringSource / VMWare .

Проще говоря, параллельное развертывание — это возможность параллельного развертывания нескольких версий вашего веб-приложения, что делает все версии доступными по одному и тому же URL-адресу.

Подумай об этом на минуту. Если у вас есть новая версия вашего приложения, вы можете просто вставить ее в Tomcat, на котором запущена старая, и это будет Just Work ™. На самом деле, они оба будут работать. Tomcat управляет всеми сессиями и маршрутизацией трафика между версиями приложений. Не нужно перезагружать Tomcat . Не нужно останавливать обработку запросов. Нет необходимости говорить с вашим боссом о простоях. Не нужно, чтобы ваш босс говорил с клиентами о простоях.

Давайте посмотрим это в действии, не так ли? Используя приведенные ниже команды, вы можете создать минимальное веб-приложение, чтобы продемонстрировать эту функцию.

Теперь у вас есть два веб-приложения с именами foo ## 001.war и foo ## 002.war . ## 001 и ## 002 обозначают номера версий файлов WAR. Каждая из них имеет свою собственную страницу индекса, которая показывает текущее время и является ли это старым или новым веб-приложением. Люди, создавшие эту функцию, выбрали удивительно простое решение для того, чтобы сказать Tomcat, что является альтернативной версией чего-либо. Все, что вам нужно сделать, это прикрепить ## <version> к имени файла WAR. Просто и эффективно, хотя и немного странно.

Теперь разверните «старую» версию веб-приложения.

Откройте браузер, введите URL-адрес WAR-файла (например, http: // localhost: 8080 / foo ) и просмотрите время. Обратите внимание, что вы не видите номер версии в URL. Страница автоматически обновляется каждую секунду. Под поверхностью Tomcat установит сеанс с вашим браузером. Подробнее об этом позже.

Теперь разверните «новую» версию веб-приложения.

Обратите внимание, что в уже открытом окне браузера время идет, и оно все еще показывает старую версию. Откройте второй браузер и в этом браузере тоже откройте http: // localhost: 8080 / foo . Для достижения наилучших результатов используйте совершенно другой браузер, чтобы избежать любой странности сеанса. Я использовал Safari и Opera для теста.

Вы должны увидеть, что второй браузер забирает новое веб-приложение, в то время как первый браузер все еще обслуживается старым веб-приложением.

Довольно аккуратно, а?

Хорошо, так вы испортили развертывание и хотите откатиться назад? Просто, просто удалите новую версию, и Tomcat автоматически вернется к использованию старой версии. Хорошая работа. Попробуй это сейчас:

Вы заметите, что веб-страницы автоматически переключаются на использование старой версии приложения.

Вам нужно будет разработать собственную стратегию развертывания. Вы можете позволить старым версиям стечь. После истечения всех сеансов старого приложения вы можете удалить старые развертывания из Tomcat . С другой стороны, вы можете просто оставить старый код развернутым. Это не принесет никакого вреда.

Есть несколько вещей, которые следует учитывать, когда вы хотите начать использовать версионные файлы WAR с вашим сервером Tomcat . Поэтому, прежде чем уйти и изменить стратегию развертывания в своей компании, проверьте список ниже.

1. Внутренние кэши должны быть сквозными и быстро истекать
2. Вам нужно, чтобы сессии были включены
3. Куда ведет логирование?
4. Дисковые файлы и каталоги должны быть общими
5. Нет прослушивателей сокетов TCP
6. Ваши приложения должны быть в состоянии удалить

Я объясню каждый из них по порядку. Большинство вариаций на тему; подумайте, какие предположения делает ваш код в отношении ресурсов машины.

Внутренние кэши должны быть сквозными и быстро истекать

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

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

Если вы выполняете какое-либо кэширование в памяти в своем веб-приложении, не используйте параллельное развертывание, пока не убедитесь, что кэши не будут обслуживать недопустимо устаревшую информацию.

Вам нужно, чтобы сессии были включены

Tomcat использует собственное управление сеансами, чтобы определить, какие запросы должны обрабатываться какой версией веб-приложения. Если вы перешли к реализации обработки сеансов самостоятельно или отключили обработку сеансов в Tomcat , параллельное развертывание не будет работать для вас.

Куда ведет логирование?

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

Дисковые файлы и каталоги должны быть общими

Намерение разработчиков Java EE всегда предусматривало независимость веб-приложений от базовой машины и файловых систем. Если ваше приложение использует файлы данных, подумайте, что произойдет, когда две версии вашего веб-приложения начнут их читать и записывать.

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

Нет прослушивателей сокетов TCP

Некоторые приложения обслуживают не только HTTP-запросы. У них есть свои собственные обработчики сокетов TCP для обслуживания клиентов. Развертывая более одной версии веб-приложения, вы получаете более одного слушателя. Очевидно, это не сработает. Только один слушатель может прослушивать любой данный порт.

Ваши приложения должны быть в состоянии удалить

Если вы хотите иметь возможность откатить испорченные выпуски, или если вы хотите очистить старые, неиспользуемые версии вашего веб-приложения, ваше веб-приложение должно быть полностью развернуто. К счастью, Tomcat помогает вам и в этом.

Я надеюсь, что эти предупреждения не оттолкнули вас от использования развертывания без простоев в Tomcat . Возможно, вам придется решить несколько вопросов, чтобы он работал чисто. Но давайте посмотрим правде в глаза: если ваше приложение будет делать меньше предположений о ресурсах, вы все равно получите более надежное приложение.

PS. Мне нравится использовать номера ревизий SVN в качестве схемы именования версий WAR. Таким образом, мои WAR-файлы называются foo ## <svn revision = ””>. War . Единственное, на что нужно обратить внимание, это то, что версии сравниваются как строки для определения порядка версий. Таким образом, вам может потребоваться обнулить номера версий для обеспечения правильного порядка.

Ссылка: развертывание с нулевым временем простоя (и откат) в Tomcat; пошаговое руководство и контрольный список от нашего партнера по JCG Киса Яна на форуме Java Monitor