java - deploy - Consejos para desplegar archivos war frente a jar ejecutable con contenedor integrado

heroku nodejs

Question

Parece que hay una tendencia actual en el espacio java para pasar de implementar aplicaciones web java a un contenedor de servlets java (o servidor de aplicaciones) en forma de un archivo war (o archivo ear) y empaquetar la aplicación como un archivo ejecutable con un servlet incrustado / servidor HTTP como embarcadero. Y me refiero más a la forma en que los marcos más nuevos influyen en cómo se desarrollan e implementan las nuevas aplicaciones en lugar de cómo se entregan las aplicaciones a los usuarios finales (porque, por ejemplo, entiendo por qué Jenkins utiliza un contenedor integrado, muy fácil de tomar y de ) Ejemplos de marcos que adoptan la opción de jar ejecutable: Dropwizard , Spring Boot y Play (bueno, no se ejecuta en un contenedor de servlet pero el servidor HTTP está incrustado).

Mi pregunta es, viniendo de un entorno en el que hemos desplegado nuestras aplicaciones (hasta este momento principalmente Struts2) en un solo servidor de aplicaciones tomcat, qué cambios, mejores prácticas o consideraciones deben hacerse si planeamos utilizar un enfoque de contenedor integrado. ? Actualmente, contamos con aproximadamente 10 aplicaciones locales que se ejecutan en un único servidor tomcat y para estas aplicaciones pequeñas la capacidad de compartir recursos y administrarse en un solo servidor es agradable. Nuestras aplicaciones no están destinadas a ser distribuidas a los usuarios finales para que se ejecuten dentro de su entorno. Sin embargo, si avanzamos si decidimos aprovechar un marco de Java más nuevo, ¿debería cambiar este enfoque? ¿El uso cada vez más frecuente de las implementaciones en la nube (p. Ej., Heroku) estimula el cambio a los frascos ejecutables?

Si ha tenido experiencia en la administración de varias aplicaciones en el estilo de reproducción de la implementación en comparación con la implementación tradicional de archivos de guerra en un solo servidor de aplicaciones, comparta sus ideas.

Answer 1

Una pregunta interesante Esta es solo mi opinión sobre el tema, así que tome todo con un grano de sal. De vez en cuando implementé y administro aplicaciones que usan contenedores de servlets y servidores integrados. Estoy seguro de que todavía hay muchas buenas razones para usar contenedores de servlets, pero trataré de centrarme en por qué son menos populares hoy en día.

Versión corta: los contenedores Servlet son geniales para administrar múltiples aplicaciones en un solo host pero no parecen ser muy útiles para administrar una sola aplicación. Con entornos de nube, una única aplicación por máquina virtual parece preferible y más común. Los marcos modernos quieren ser compatibles con la nube, por lo tanto, el cambio a servidores integrados.

Así que creo que los servicios en la nube son la razón principal para abandonar los contenedores de servlets. Al igual que los contenedores servlet le permiten administrar aplicaciones, los servicios en la nube le permiten administrar máquinas virtuales, instancias, almacenamiento de datos y mucho más. Esto suena más complicado, pero con los entornos en la nube, ha habido un cambio a las máquinas de aplicaciones individuales. Esto significa que a menudo puede tratar toda la máquina como si fuera la aplicación. Cada aplicación se ejecuta en una máquina con el tamaño adecuado. Las instancias de Cloud pueden aparecer y desaparecer en cualquier momento, lo que es ideal para escalar. Si una aplicación necesita más recursos, usted crea más instancias.

Los servidores dedicados, por otro lado, suelen ser potentes pero tienen un tamaño fijo, por lo que puede ejecutar múltiples aplicaciones en una sola máquina para maximizar el uso de los recursos. Administrar docenas de aplicaciones, cada una con sus propias configuraciones, servidores web, rutas y conexiones, etc., no es divertido, por lo que usar un contenedor de servlets te ayuda a mantener todo manejable y a ti mismo cuerdo. Aunque es más difícil de escalar. Los contenedores de servlets en la nube no parecen muy útiles. Tendrían que configurarse para cada instancia pequeña, sin proporcionar mucho valor ya que solo administran una sola aplicación.

Además, las nubes son geniales y las cosas que no son en la nube son aburridas (si aún creemos en la exageración). Muchos marcos intentan ser escalables de manera predeterminada, de modo que puedan implementarse fácilmente en las nubes. Los servidores integrados son rápidos de implementar y ejecutar, por lo que parecen una solución razonable. Los contenedores de servlets generalmente aún son compatibles, pero requieren una configuración más complicada.

Algunos otros puntos:

• El servidor incorporado podría optimizarse para el marco o estar mejor integrado con las herramientas de marcos (como la consola de reproducción, por ejemplo).
• No todos los entornos de nube vienen con imágenes de máquina personalizables. En lugar de escribir scripts de inicialización para descargar y configurar contenedores de servlets, el uso de software dedicado para implementaciones de aplicaciones en la nube es mucho más simple.
• Todavía tengo que encontrar una configuración de Tomcat que no te salude con un error de espacio de generación permanente en cada redistribución de tu aplicación. Tomar un poco más de tiempo para (re) iniciar los servidores integrados no es un problema cuando casi instantáneamente puede cambiar entre instancias de producción y producción sin ningún tiempo de inactividad.
• Como ya se mencionó en la pregunta, es muy conveniente para el usuario final simplemente ejecutar la aplicación.
• Los servidores integrados son portátiles y convenientes para el desarrollo. Hoy todo es rápido , los prototipos y los MVP deben crearse y entregarse lo más rápido posible. Nadie quiere pasar demasiado tiempo configurando un entorno para cada desarrollador.