Развертывание Spring Boot REST: нужен ли нам TomCat?

Question

Я видел проект Spring Boot Rest, который генерирует WAR и затем развертывается в контейнере Tomcat.Интересно, является ли это лучшей практикой, потому что я также читал, что в Spring Boot новый финальный исполняемый файл JAR также содержит встроенное серверное решение, такое как Tomcat?

Теперь я видел похожую статью, в которой рассказывается о Spring Boot, который поддерживает оба способа, но никто не говорил о плюсах и минусах каждого из них.

Может кто-нибудь указать на лучшую практику развертывания пружиныпроект boot rest?

Я думаю о том, чтобы докернизировать JAR, содержащий встроенный сервер, но мне интересно, есть ли какие-либо недостатки по сравнению с развертыванием WAR на Tomcat?

Answer 1

Общая рекомендация (из 12 Factor App ) в отношении среды приложения и зависимостей - "Явно объявлять и изолировать зависимости".

Двенадцатикратное приложение никогда не опирается на неявное существование всей системы пакеты

Имея это в виду, следует больше тяготеть к использованию встроенного контейнера как части явной зависимости, а не к требованию, которое необходимо выполнять отдельно. Существует несколько вариантов встроенного контейнера в артефакте jar (например, tomcat, jetty, undertow, netty) и их соответствующая конфигурация также обширна, поэтому рекомендуется использовать их в производственной среде (я часто их использовал). Однако могут быть определенные моменты, когда вместо этого вы захотите создать войну, например, файл войны можно будет развернуть на любом полноценном сервере приложений EE (Weblogic, Wildfly и т. Д.), Который может требоваться вашей средой. С войной количество ваших вариантов с точки зрения сервера приложений увеличивается. Лично для меня баночка с пружинным ботинком со встроенным котом оказалась довольно эффективной. С опцией встроенного контейнера вам нужна виртуальная машина с установленной ОС и Java, и вы готовы к работе.

Однако существует специальное ограничение, связанное с JSP, как упоминалось здесь в документации по Spring Boot, которое объясняет вескую причину, по которой вам может потребоваться упаковать как war, но все же запустить как jar.