Maven - развертывание больших военных файлов

Question

Этот вопрос чем-то похож на этот Лучший способ развернуть большой * .war на tomcat , так что сначала это хорошее чтение, но продолжайте читать мой q, в конце он другой ...

Используя maven 2, мои военные файлы ужасно велики (60M).Я развертываю их на нескольких серверах Tomcat, и просто копирование файлов занимает слишком много времени (примерно 1 м на войну).

Кроме того, я добавил слой RPM, который упакует войну в файл RPM.(используя плагин Maven RPM).Когда RPM будет выполнен на целевом компьютере, он очистит, «установит» войну (просто скопирует ее), остановит и запустит tomcat (так мы делаем здесь, без горячего развертывания) и создаст соответствующий файл контекста вместо.Все это прекрасно работает.
Проблема, однако, заключается в том, что файлы RPM слишком велики и медленно копируются.Естественно, то, что занимает почти все пространство, - это файл военных действий.

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

Файлы военных действий содержат:

1. Приложений jar
2. сторонние файлы jar
3. ресурсы (файлы свойств и другие ресурсы)
4. Файлы WEB-INF, такие как JSP, web.xml, struts.xml и т. Д.

Большую часть пространства занимают сторонние банки №2.
Банки сторонних производителей также устанавливаются на внутренний сервер Nexus, который есть в нашей компании, поэтому я могу воспользоваться этим.

Вы, наверное, уже догадались, поэтому планируется создать «тонкие войны», в которые войдут только файлы приложений (созданные моей компанией), ресурсы и материалы WEB-INF, и добавьте интеллектуальность в сценарий установки RPM, который 'При необходимости скопирую сторонние jar-файлы.
RPM позволяет запускать произвольные сценарии до или после установки, поэтому планируется использовать mvn, написать список сторонних зависимостей при сборке войны и добавить егоs ресурс для RPM, а затем при установке RPM скрипт установки RPM будет запускать список необходимых сторонних jar-файлов и загружать новые jar-файлы из nexus, только если они еще не существуют.
RPM придется удалитьбанки, если они не используются.
RPM также придется либо перестроить войну для Tomcat, чтобы взорвать ее, либо добавить сторонние банки в Common / lib или что-то в этом роде, хотя у нас есть несколько веб-приложений на одного кота, такэто усложнит ситуацию в этом смысле.Может быть, взорвать банку самостоятельно, а затем скопировать сторонние банки в WEB-INF / lib

Ваш вклад приветствуется:)

Answer 1

У нас есть каталог на целевых машинах со всеми используемыми нами банками сторонних производителей (около 110 МБ).Банки используют соглашение о кодировании имен, которое включает их номер версии (asm-3.2.jar, asm-2.2.3.jar ...).При добавлении новой версии третьей стороны мы не удаляем старую версию.

При развертывании наши jar-файлы содержат только классы бизнес-логики и ресурсы, которые мы компилируем в сборке (без сторонней).Путь к классу определен в манифесте jar , где мы выбираем, какую третью сторону он должен использовать во время выполнения.Мы делаем это с помощью ant, без участия maven, и у нас в системе более 25 видов сервисов (очень «так», хотя мне это не нравится из-за жужжания).Этот jar бизнес-логики является единственным jar в пути к классу jvm при запуске процесса, и он также имеет номер версии нашего репо кода.Если вы вернетесь к более старой версии (отката) нашего кода, который может использовать более старую стороннюю версию jar, она все равно будет работать, поскольку мы не удаляем старые jar.Новые сторонние файлы jar следует распространять на рабочие машины до того, как это сделает бизнес-код, который их использует.Но как только они появятся, их не будут подталкивать при каждом развертывании.

В целом мы склоняемся к простоте (то есть не к OSGi) и не используем Maven.

Answer 2

Я бы советовал против предложенного вами плана. Это звучит как множество движущихся частей, которые, вероятно, трудно проверить и / или диагностировать при возникновении проблемы.

У нас нет проблемы «больших» WAR, но у нас есть проблема в том, что большинству наших WAR нужны точно такие же сторонние библиотеки на пути к классам. Решение, которое мы нашли (сработало очень хорошо), заключалось в использовании OSGi для модульного построения нашего приложения. Мы используем Felix в качестве нашего контейнера OSGi, который работает внутри Tomcat. Затем мы развертываем все наши зависимости / библиотеки в Felix один раз . Затем мы внедряем «тонкие» WAR, которые просто ссылаются на зависимости OSGi, импортируя нужные пакеты из пакетов, которые им нужны.

Это имеет несколько других преимуществ:

• Развертывание новых версий пакетов OSGi во время работы старых не является проблемой, которая не допускает простоев (аналогично горячему развертыванию).
• Если вам нужно обновить одну из ваших зависимостей (например, Spring 2.5 -> 3.0), вам нужно только обновить пакет Spring, работающий в OSGi; нет необходимости доставлять (или упаковывать) новые WAR, если API не изменились. Все это (еще раз) можно сделать на работающем контейнере OSGi, не нужно ничего отключать.
• OSGI гарантирует, что ваши пакеты не разделяют пути к классам. Это помогает поддерживать ваш код в чистоте, потому что каждая WAR нуждается только в знании того, о чем она заботится.

Настройка ваших WARs на «OSGi ready» не тривиальна, но хорошо документирована. Попробуйте проверить Как начать работать с OSGi или просто Google для сторонних руководств. Поверьте мне, первоначальные инвестиции сэкономят вам много времени и много головной боли в будущем.

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