alexey_lahtadir Mar 15 2012 at 12:57

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

2 min

4.9K

Java*

Comments 24

Akvel Mar 15 2012 at 13:15

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

Sauron Mar 15 2012 at 13:21

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

png Mar 16 2012 at 23:57

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

AlexanderYastrebov Mar 15 2012 at 13:36

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

AlexanderYastrebov Mar 15 2012 at 13:39

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

ksi Mar 15 2012 at 13:44

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

alienff Mar 15 2012 at 13:43

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

artspb Mar 16 2012 at 05:27

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

alienff Mar 16 2012 at 15:31

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

artspb Mar 16 2012 at 16:34

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

alienff Mar 16 2012 at 19:45

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

artspb Mar 17 2012 at 05:23

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

nanotime Mar 24 2012 at 12:34

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

alexey_lahtadir Mar 16 2012 at 17:57

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

alexey_lahtadir Mar 15 2012 at 14:16

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

norguhtar Mar 15 2012 at 18:28

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

alexey_lahtadir Mar 15 2012 at 14:18

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

1nd1go Mar 15 2012 at 14:24

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

vs.

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

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

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

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

alexey_lahtadir Mar 15 2012 at 14:26

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

1nd1go Mar 15 2012 at 14:36

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

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

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

bald2b Mar 16 2012 at 08:13

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

alexey_lahtadir Mar 16 2012 at 17:55

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

UFO just landed and posted this here

antonarhipov Apr 8 2012 at 16:09

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

Show the best of all time