Me preguntaba si existe una "manera sencilla" de volver a implementar un WAR de Java en un servidor de producción (sin clúster, sin OSGi).¿Despliegue suave de WAR en producción?
Todo lo que se me ocurre es detener el servidor, actualizar el archivo, reiniciar el servidor. Y 10 minutos antes, tengo que mostrar una advertencia de mantenimiento en el sitio.
¿Cuál es su enfoque?
En primer lugar, la implementación en caliente no siempre funciona. Pasamos mucho tiempo para asegurarnos de que cada módulo nuevo esté cargado y decidimos que no vale la pena. Entonces, lo que está haciendo puede sonar mal, pero es la forma más confiable de implementar una nueva GUERRA.
Nuestro enfoque actual es utilizar un interruptor con balanceador de carga en frente de todos los servidores. Ejecutamos al menos 2 instancias de los servidores de aplicaciones. Cuando apagamos un servidor para mantenimiento, el tráfico pasa automáticamente al otro.
Algunos de los conmutadores son realmente económicos. Si no tiene suficiente carga para justificar un nuevo cuadro y sus 2 instancias se pueden ejecutar en el mismo cuadro.
En algunos casos, los conmutadores pueden ahorrar dinero. Por ejemplo, tenemos una página SSL que solía usar 6 cuadros y ahora funciona bien en 2 cuadros con aceleración SSL en el conmutador.
suena muy inteligente, pero me pregunto: ¿cómo manejas el estado? Cuando toma uno, obviamente todo el estado debe estar disponible en otro recurso (DB, cache, 2nd app?). Y en segundo lugar, ¿qué tan bien funciona? -basado en mis humildes experiencias de java framework (jsf, seam, wicket) esperaría que tuvieras que saltar bastantes aros cuando no usaras 'sesiones adhesivas' en un clúster. – stephanos
Buena pregunta. El servidor sin estado ha sido un requisito aquí durante tanto tiempo que lo doy por sentado. Si tiene estado en el servidor, tiene que hacer algún truco en equilibrador de carga, como enrutamiento rígido basado en IP de origen o cookies. –
Puede echar un vistazo a JRebel, aunque no lo usaría en producción. En producción hacemos básicamente lo mismo, aunque nuestro jefe sigue soñando con redespliegues calientes. Desafortunadamente, se admiten principalmente en papel: en las aplicaciones más complejas, siempre ocurre algo mal con las reencapsulaciones en caliente. Lo mismo es aún más cierto para las redistribuciones en caliente incrementales ...
y deja que el AS lo tome desde allí, aunque con servicios 24/7 muy ocupados, me imagino que esto no sería una opción.
hm, intenté esto una vez con Jetty, tal vez hice algo así. mal, pero no pasó nada después de unos minutos; probablemente cada AS maneje de manera diferente. ¿En qué AS realmente hiciste esto? – stephanos
Es configurable: puede hacer que Tomcat y JBoss funcionen de esa manera. Me sorprendería saber que Jetty no te permite configurarlo de manera similar. Solo como una cuestión de terminología, Tomcat y Jetty son contenedores de servlets, JBoss (y Glassfish, JOnAS, etc.) son servidores de aplicaciones. –
Algunos servidores de aplicaciones admiten la redistribución sin interrupción del servicio. Esto es al menos cierto para WebLogic, vea Using Production Redeployment to Update Applications. Tenga en cuenta que esto es no implementación en caliente (y NUNCA usaría implementación en caliente con servidores de producción).
Sin la compatibilidad del servidor de aplicaciones, me temo que no podrá realizar redespliegues "suaves" reales. Si desea minimizar el tiempo de inactividad, un enfoque es implementar la nueva aplicación en paralelo (en el mismo servidor u otro) y cambiar las reglas de enrutamiento cuando finalice. Pero los clientes perderán su sesión.
Por lo general, es posible optimizar el tiempo de arranque. Nuestra aplicación web comienza con Jetty en 5-7 segundos. Otros servidores web Java son peores, porque comienzan muy lento.
Además, como soy consciente (no lo hice), el servidor web front-end (como apache, usamos lighttpd) podría configurarse para mantener la solicitud un cierto período de tiempo (hasta 30 segundos en el nuestro) mientras que el embarcadero no está listo. Por lo tanto, simplemente reiniciamos el Jetty durante la implementación, y los usuarios solo tienen varios segundos de retraso en el peor de los casos, lo que generalmente parece un problema de conexión a Internet.
¡buena idea con el tiempo de espera! Gracias – stephanos
Como ZZ Coder ya mencionó el equilibrador de carga es una buena solución, especialmente para grandes despliegues. Para mi propio proyecto utilizo la funcionalidad de proxy HTTP inverso del servidor web nginx. Redirige todos los paquetes http de un contexto web específico (visto desde Internet) a un servidor dentro de mi red.La configuración es muy fácil:
location /best-app-ever/ { proxy_pass host-address:8080/some-app-1.1 root /home/www/some-app-1.1 }
versión de conmutación debe ser suave también. Suponiendo que ya ha implementado una nueva versión de la aplicación simplemente de modificación del archivo de configuración de nginx y aplicar los cambios:
location /best-app-ever/ { proxy_pass host-address:8080/some-app-1.2 root /home/www/some-app-1.2 }
sudo nginx -t
sudo service nginx restart
se le advertirá que, en caso de que su aplicación web es con estado y/o contiene algunos procesos en ejecución o programados, la implementación y el des-despliegue pueden no ser tan fluidos.
¿por qué detener el servidor, actualizar el archivo, reiniciar el servidor y no solo anular la implementación/implementar? Tenemos varios .war webapps en nuestros servidores de producción y, por lo general, solo anulamos/redesplegamos: ¿no es necesario tener todo el servidor con todas las aplicaciones web abajo? – NoozNooz42
@nooz: bueno, solo ejecuto 1 aplicación en el servidor. No pude encontrar tutoriales/guías para volver a implementar con Jetty, todo lo que encuentro es cómo hacer esto para un rápido desarrollo – stephanos
oh, ya veo ... no sé sobre Jetty (quizás otros lo comenten) . Pero con Tomcat hay varias formas de anular la implementación/redistribución de un solo .war (solía hacerlo desde una tarea Ant pero ahora estoy usando la aplicación manager). Esto ahorra el tiempo necesario para apagar/reiniciar Tomcat. – NoozNooz42