Как деплоются приложения Java EE?

Question

[mystdeim]

Для Rails-приложений есть классная штука capistrano, описываешь "репепт" и запускашь: качаются зависимости, выкачивается код из центральное хранилища, выполняются миграции бд, вплоть до синхронизации версии руби можно сделать, так же забиваешь перезапуск нужных сервисов при необходимости -- всё просто и понятно.

Интересно посмотреть как обстоят дела в другом лагере.
До этого работал только с Java SE и использовал её только как вспомогательное средство интересно, как деплоят приложения на всякие wildfly и подобные сервера приложений, как устроен zero downtime и миграции бд?
Пока играюсь с wildfly, научился деплоить на локальный хост еарник с помощью maven, возник вопрос как поступают с деплоем, когда нужно обновить частично, только один модуль?

Comments

[sirs]

Существует десятки и сотни способов поставить приложение клиенту на сервер. Это зависит от сервера приложение (если он вообще используется, потому что может быть простой легковесный jar, у которого все есть внутри), от технологий которые используются, например, если клиент использует докер, то это будет просто image. "zero downtime и миграции бд" - тут тоже множество вариантов, как один из вариантов - осуществляем deploy на каждый node поочередно, отключая из продакшена и включая обратно, в базе тоже немало вариантов и т.д. и т.п. Ваш вопрос очень широкий, в общем как и разнообразие технологий и подходов в java

[mystdeim]

интересуют наиболее распространённые обще принятые методики (например capistrano стал стандартом де факто для рейл, думаю что и в джаве сложилось что-то подобное), java ee разве может существовать без сервера приложения?

Answer 1

[Владимир Смирнов]

нужно обновить частично, только один модуль

Соответственно, этот модуль должен быть самостоятельным артефактом Maven. Обычно, артефакт для EAR описывает формирование приложения из других модулей и конфигурационных файлов. Следует разбить приложение на артефакты (обычно jar/war), которые входят в состав EAR.

Вообще, при сборке для промышленной среды надежнее собирать всё приложение (EAR в вашем случае) целиком. А при сборке для окружения разработчика вообще удобнее использовать не сборщик Maven, а среду разработки. Idea, например, прекрасно понимает формат конфигураций Maven и на их основе может создавать свои артефакты (и настоятельно порекомендует это сделать при обнаружении pom.xml). Если собирать артефакты с помощью Idea, то даже при сборке EAR целиком фактически будут обновляться только изменённые файлы, что ускоряет процесс сборки на порядки, в сравнении с Maven. Это достигается за счёт того, что у Idea есть свой контроль версий и она знает что именно следует пересобрать, а что можно оставить как есть. Наибольший выигрыш получается для exploded артефактов (которые не архивируются, а выкладываются в виде структуры папок с файлами), т.к. в таком случае не приходится перепаковывать модули целиком при изменении небольшого количества файлов в них.

Для каждого артефакта Maven Idea создаст две версии своих артефактов - упакованную и не упакованную (exploded). В случае, если ваше приложение состоит из нескольких модулей, может потребоваться ручное вмешательство в сгенерированные артефакты, т.к. exploded-артефакт верхнего уровня в конфигурации по-умолчанию содержит подчинённые артефакты в упакованном виде. Потребуется удалить вариант в упакованном виде и на его место вставить exploded-вариант. Минус состоит в том, что при изменении артефакта Maven, Idea предложит перегенерировать и свои артефакты, все ручные настройки при этом пропадут. Но настройки топологии проекта меняются нечасто, поэтому лишней минутой работы по ручной реконфигурации обычно можно пренебречь...

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

Comments

[mystdeim]

Спасибо за такой развёрнутый ответ, почему вы говорите, что надежнее одим EAR деплоить, а если там много ресурсов, неужели ради одного файла, всё перегружать? И еще такой вопрос, как я понял на wildfly деплой идёт по определённому порту, а как обстоит дело с безопаснотью (в тот же rails идёт подключение по ssh и сам удалённый хост всё выкачивает устанавливает)?

[Владимир Смирнов]

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

"как обстоит дело с безопаснотью" - тут развёрнуто ответить не смогу, т.к. предпочитаю деплоить по старинке - заменять приложение в файловой системе. Вообще, безопасность в Wildfly достаточно развита, коннекторы можно гибко конфигурировать, в т.ч. настройки безопасности: SSL, домены безопасности, источники информации о пользователях/паролях. Вот, например, выдержка из Руководства Администратора Wildfly: WildFly 8 is now distributed secured by default. The default security mechanism is username / password based making use of HTTP Digest for the authentication process

[mystdeim]

Владимир Смирнов: то есть меняете файлик, и мавеном всё перезапускается?

[sirs]

mystdeim: maven ничего не перезапускает, он нужен для сборки артефакта. Очевидно Владимир имел ввиду, что он заходит на сервер по ssh и руками подкладывает свежий артефакт. Wildfly/jboss/tomcat etc видит новый файл war/ear etc и разворачивает приложение