manager desplegar deployar deploy java tomcat deployment jvm war

java - desplegar - tomcat manager



Desplegar WAR o JAR "gordo"? (3)

Estoy notando que muchos proyectos (DropWizard, Grails, etc.) comienzan a adoptar la noción de un JAR "gordo" (que utiliza un servidor web incorporado como Jetty o Tomcat) en comparación con el despliegue tradicional de WAR. Ambos métodos implican un solo proceso JVM (es decir, sin importar cuántos WAR se implementen en Tomcat, es el mismo proceso JVM).

¿En qué circunstancias es preferible cualquiera de los métodos de despliegue sobre el otro?


Aquí hay algunas razones:

A favor de JAR:

  1. Simple de construir y desplegar.
  2. Los servidores embebidos como Jetty son fáciles de operar.
  3. Las aplicaciones son fáciles de iniciar para los usuarios y también pueden ejecutarse en sus computadoras personales, porque son ligeras.
  4. Iniciar y detener aplicaciones requerirá menos conocimientos que la administración de servidores web.

A favor de WAR o EAR:

  1. El servidor proporcionaría funciones como implementación, reinicio, seguridad, etc. para múltiples aplicaciones web simultáneamente.
  2. Quizás un equipo de implementación independiente pueda manejar el inicio y la detención de las aplicaciones.
  3. Si a sus supervisores les gusta seguir las reglas, les complacerá descubrir que no los está rompiendo.

Dicho esto, siempre puede proporcionar 2 o 3 tipos de ejecutables para satisfacer todas las necesidades. Cualquier herramienta de compilación lo hace fácil.


Estoy pensando en la perspectiva del usuario. Puede envolver este jar de un solo usuario dentro de un .exe o .dmg y simplemente instalarlo sin la necesidad de tener instrucciones adicionales sobre cómo implementar. Además, como está haciendo la implementación solo para un servidor en particular, puede aprovechar ese servidor en particular


Distribuir una aplicación con un servidor web incorporado permite realizar una configuración independiente y ejecutarla simplemente llamando a java -jar application.jar .

Sin embargo, puede haber usuarios que quieran controlar qué servidor web se usa o que quieren implementar múltiples aplicaciones en un solo servidor web (por ejemplo, para evitar choques de puertos, especialmente con los puertos 80 y 8080). En ese caso, un frasco "grueso" puede causar problemas o al menos algún código innecesario y, por lo tanto, una huella de memoria mayor.

En mi humilde opinión, el mejor enfoque para esos dos casos sería proporcionar dos artefactos: un contenedor "gordo" para una configuración independiente (más fácil) y una guerra / oído solo para aplicaciones para aquellos que desean implementar la aplicación en su propio contenedor.