Развертывание Java Webapp: взорваться или не взорваться?
Очень простой вопрос. У меня есть файл .war(~ 40 МБ), который будет запущен на JBoss.
Какова наилучшая практика для развертывания: следует ли развертывать военный файл в разобранном формате? Или нет?
Я спрашиваю, потому что если его взорвать, то у меня есть выбор для обновления моего файла свойств в любое время, когда я выбираю (и не нужно делать новую войну при каждом изменении файла свойств).
Но я не уверен, что лучше всего использовать развертывание войны в разобранном формате.
Пожалуйста, помогите мне понять.:)
Ответы
Ответ 1
Модификация взорванного содержимого, безусловно, быстрее и эффективнее, но одним из них является аудит и отслеживание. Одно из преимуществ только развертывания WAR файлов и обработки их как "запечатанных" заключается в том, что любые сделанные вами изменения должны быть зафиксированы в вашей системе управления исходным кодом. Вы, конечно, не хотите, чтобы люди могли изменять все, что пожелает, в конфигурации вашего приложения без какого-либо аудита.
Разделение проблем Java EE обычно означает, что разработчик WAR не является тем же лицом, что и администратор для сервера приложений. Если у разработчика нет прямого доступа, это означает, что люди, которые не знают приложение полностью, вносят изменения.
Я не защищаю экстремальный менталитет, который запрещает разработчикам модифицировать взрывоподобную WAR, просто указывая альтернативный взгляд на ваше рассмотрение.
Ответ 2
Если военный файл будет развернут в разобранном формате? Или нет?
Это зависит от нескольких факторов:
- Вам потребуется, чтобы администраторы приложений-серверов изменяли содержимое WAR файла после развертывания? Если ответ "да", особенно в тех случаях, когда речь идет о свойствах или файлах конфигурации, вы должны использовать взорванный формат. Это облегчит внесение изменений в файлы без необходимости переделки полного файла WAR.
- Как вы распространяете изменения в производстве? Если вы не предварительно компилируете свои JSP файлы, и если вы планируете развертывать более новые версии JSP, скопировав их в область, содержащую взорванный WAR файл, то совершенно очевидно, что повторное развертывание огромного WAR файла не является оптимальное решение. Однако имейте в виду, что это будет зависеть от ваших методов развертывания. Часто легче проверить, что файл WAR в производстве является репликой сгенерированной сборки из управления версиями, с одним хэшем файла WAR. Если вы развертываете инкрементные изменения, вы обнаружите, что хэши будут необходимы для каждого развернутого файла.
- Как скоро вы хотите, чтобы ваше приложение было развернуто и доступно? Эта точка тривиальна, но достаточно примеров приложений, которые занимают несколько минут, потому что сервер приложений занят взрывами WAR файла и воссозданием необходимых артефактов. Это может привести к значительному времени простоя, если поведение сервера должно взорвать WAR файл при каждом перезапуске сервера приложений. Поскольку я не знаю о поведении JBoss или конкретной версии, о которой идет речь, я предлагаю вам убедиться в этом самостоятельно, чтобы вы могли ограничить время простоя до приемлемого уровня.
Ответ 3
Если вам нужно изменить конфигурацию в вашем .war без повторного развертывания, я бы предпочел развернуть взорванное. В противном случае я бы предпочел развернуть файл (тогда jboss будет извлекать файл в tmp/deploy/..
)
Ответ 4
Он все равно взорвался, так что вы можете изменить свойства, даже если они развернуты как война... это не имеет значения. В среде разработки по крайней мере.
Однако, если вы развертываете в разобранном формате для производства, чтобы вы могли изменять файлы свойств, это не большая проблема, которую вам нужно изменить с помощью свойств (производства) после развертывания? И не вы использовали войну или нет.