Облегчаем вес приложения при деплое на сервер приложений Apache Tomcat

[Akvel]

А как часто вы удаленно разворачиваете приложения, что вам потребовалось оптимизировать процесс?

[Sauron]

Требуется вносить правки и выкладывать их на сервер до 20 раз на день.

[png]

попробуйте JRebel.

[AlexanderYastrebov]

Может rsync и нежатый war?

[AlexanderYastrebov]

Ну и как фантазия на вашу тему, можно подумать над лоадером который будет получать список зависимостей из pom'а (или что вы там используете) и подгружать их.

[ksi]

Мы пришли именно к этому. Деплой ускорился в сотни раз (по версии rsync)

[alienff]

А maven не тоже самое делает? Зачем велосипед изобретать?

[artspb]

А как maven может помочь в данном случае? Вариант ставить на production Hudson/Jenkins не устраивает. Разве что сборка артифактов непосредственно на сервере, но это, на мой взгляд, не выглядит удобным…

[alienff]

Поможет тем, что один раз загрузит в свой репозиторий все зависимости, а потом будет только собирать проект из свежих исходников.
Просто
lib spring_2.5.6 /lib
lib hibernate_3.3.0 /lib
настолько похоже на
dependency
group org.springframework /group
…
что я сразу про него и подумал. И вместо ${catalina.home}/repo/ ~/.m2/repository. Тоже самое, на мой взгляд.

[artspb]

Не могу понять, где вы предлагаете собирать артифакты? Если локально, то это не решает проблему передачи большого объема по сети. Если на сервере, то это, на мой взгляд, не самая лучшая идея.

[alienff]

На сервере. Поставить там maven, git или какая там система контроля версий используется. Вытягивать очередной релиз или прямо head, если, как пишет автор, изменения 30 раз в день, собирать и выкладывать.
Почему, по-вашему, это не самая лучшая идея?

[artspb]

Эта идея, как мне кажется, подходит для тестового сервера, но тогда уз лучше Jenkins развернуть для автоматизации сборки и кучи других плюшек. На production же важна производительность, поэтому дополнительно нагружать сервер сборкой не рационально. Хотя мне сложно представить ситуацию, когда «боевой» сервер нужно обновлять 30 раз в день…

[nanotime]

А я на продакшне опасался бы использовать какую-то непонятную thirdparty библиотеку.

[alexey_lahtadir]

Ну я делаю как правило проще. У меня один репозиторий на весь проект, куда я заливаю все-все либы. Проще потом если что сравнивать список изменений по папкам. Лично мне так весьма удобно.

[alexey_lahtadir]

У нас есть часть проектов которые до сих пор не в мавене. И не все с мавеном работают. Мы, например, пришли к нему только недавно, но сбоку на стороне сервера до сих пор еще не делаем. При это насколько я понимаю процесс больше растягивается по времени. Либо перекидывать туда исходники, либо там их гитом клонировать и там уже собирать и подбрасывать котенку.

[norguhtar]

Рабочий вариант кстати. У меня именно так деплоинг делается.

[alexey_lahtadir]

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

[1nd1go]

Класть библиотеки в ${tomcat.home}/lib дело очень неблагодарное и зачастую опасное.

vs.

Как это работает:

— Кладете данную библиотеку в ${tomcat.home}/lib
— В ${catalina.home} создается папка repo. <...> Создаем директорию ${catalina.home}/repo/hibernate_3.3.0, в которую складываем все нужные библиотеки.

Не понял в чем разница?

Но вообще поступить можно проще. Вы сделайте сборку на сервере из исходников, в одной сети с продакшен сервером. Можно вообще поставить там Hudson какой-нить и он будет еще и деплоить на продакшен.

[alexey_lahtadir]

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

[1nd1go]

Ну это сразу видно что китаец придумал.
(It took me 10mins to deploy such a war so to fix a typo in the HTML code. — ну а зайти и поменять html файл по горячему конечно никак)

К сожалению, это абсолютно не переносимое решение, и сильный выстрел в ногу. Настоятельно рекомендую перенести svn и сборку поближе к продакшену.

_{Пожалуйста, прекратите называть Tomcat «котенком»}

[bald2b]

«20 деплоев в день» обычно означают мелкие изменения, можно же только измененные .class, .jsp или .tag заменять в горячем режиме?
А сборка из исходников на стороне продакшна как-то чревато утечкой исходников.

[alexey_lahtadir]

Ну мелкие не мелкие, но очень неприятно вначале вычленять все эти 2-5 ресурса из классов и веб-ресурсов, а потом на сервере искать места куда их нужно вставлять

[antonarhipov]

Вброшу сюда вариант для решения проблемы. JRebel — хоть и не бесплатный, имеет возможность удалённого обновления: zeroturnaround.com/jrebel/remoting
Получается так: изменил код, нажал Ctrl+S, нажал кнопочку для синхронизации — изменённые классы улетели на сервер. Всё. Никакой сборки и закачиваний на сервер, и перезапуска кота делать не надо.