¿Mejores prácticas para implementar aplicaciones web Java con un tiempo de inactividad mínimo?

Actualización:

Desde que se escribió esta respuesta por primera vez, ha surgido una mejor manera de implementar archivos war en tomcat con cero tiempo de inactividad. En versiones recientes de tomcat puede incluir números de versión en sus nombres de archivo war. Así, por ejemplo, puede implementar los archivos ROOT##001.war y ROOT##002.war en el mismo contexto simultáneamente. Todo después de ## es interpretado como un número de versión por tomcat y no parte de la ruta de contexto. Tomcat mantendrá todas las versiones de su aplicación en ejecución y atenderá nuevas solicitudes y sesiones a la versión más reciente que está completamente activa mientras completa con gracia las solicitudes antiguas y sesiones en la versión con la que comenzaron. La especificación de los números de versión también se puede hacer a través del tomcat manager e incluso las tareas catalina ant. Más información aquí.

Respuesta original:

Rsync tiende a ser ineficaz en los archivos comprimidos, ya que su algoritmo de transferencia delta busca cambios en los archivos y un pequeño cambio un archivo sin comprimir, puede alterar drásticamente el resultado versión comprimida. Por esta razón, podría tener sentido sincronizar un archivo war sin comprimir en lugar de una versión comprimida, si el ancho de banda de la red resulta ser un cuello de botella.

¿Qué tiene de malo usar la aplicación Tomcat manager para realizar sus implementaciones? Si no desea cargar el archivo war completo directamente a la aplicación Tomcat manager desde una ubicación remota, puede sincronizarlo (sin comprimir por las razones mencionadas anteriormente) a una ubicación de marcador de posición en la caja de producción, reempaquetarlo a una guerra, y luego dárselo al gerente local. Existe una buena tarea ant que se incluye con Tomcat, lo que le permite programar implementaciones utilizando la aplicación Tomcat manager.

Hay un defecto adicional en su enfoque que no ha mencionado: Mientras su aplicación se implementa parcialmente (durante una operación rsync), su aplicación podría estar en un estado inconsistente donde las interfaces cambiadas pueden estar fuera de sincronización, las dependencias nuevas/actualizadas pueden no estar disponibles, etc. También, dependiendo de cómo el tiempo que tarda su trabajo de rsync, su aplicación puede reiniciarse varias veces. ¿Es consciente de que puede y debe desactivar el comportamiento de escucha de archivos modificados y reinicio en Tomcat? En realidad, no se recomienda para los sistemas de producción. Siempre puede hacer un reinicio manual o con scripts ant de su aplicación utilizando la aplicación Tomcat manager.

Su aplicación no estará disponible para los usuarios durante un reinicio, por supuesto. Pero si estás tan preocupado por la disponibilidad, seguramente tener servidores web redundantes detrás de un equilibrador de carga. Al implementar un archivo war actualizado, puede hacer que el equilibrador de carga envíe temporalmente todas las solicitudes a otros servidores web hasta que finalice la implementación. Enjuague y repita para sus otros servidores web.

En cualquier entorno donde el tiempo de inactividad es una consideración, seguramente está ejecutando algún tipo de clúster de servidores para aumentar la confiabilidad a través de la redundancia. Me gustaría tomar un host fuera del clúster, actualizarlo, y luego lanzarlo de nuevo en el clúster. Si tiene una actualización que no puede ejecutarse en un entorno mixto (se requiere un cambio de esquema incompatible en la base de datos, por ejemplo), tendrá que eliminar todo el sitio, al menos por un momento. El truco es traer los procesos de reemplazo antes tirando los originales.

Usando tomcat como ejemplo - puede usar CATALINA_BASE para definir un directorio donde se encontrarán todos los directorios de trabajo de tomcat, separados del código ejecutable. Cada vez que despliego software, lo despliego a un nuevo directorio base para que pueda tener nuevo código residente en el disco junto al código antiguo. Luego puedo iniciar otra instancia de tomcat que apunta al nuevo directorio base, poner todo en marcha y ejecutarlo, luego intercambiar el proceso anterior (número de puerto) con el nuevo en el balanceador de carga.

Si me preocupa conservar los datos de la sesión a través del conmutador, puedo configurar mi sistema de manera que cada host tenga un socio al que replica los datos de la sesión. Puedo soltar uno de esos hosts, actualizarlo, traerlo de vuelta para que recoge los datos de la sesión de copia de seguridad, y luego cambiar los dos hosts. Si tengo varios pares en el clúster, puedo soltar la mitad de todos los pares, luego hacer un cambio de masa, o puedo hacer un par a la vez, dependiendo de la requisitos de la liberación, requisitos de la empresa, etc. Personalmente, sin embargo, prefiero simplemente permitir que los usuarios finales sufran la pérdida muy ocasional de una sesión activa en lugar de tratar de actualizar con sesiones intactas.

Todo es un compromiso entre la infraestructura de TI, la complejidad del proceso de lanzamiento y el esfuerzo del desarrollador. Si su clúster es lo suficientemente grande y su deseo lo suficientemente fuerte, es bastante fácil diseñar un sistema que se pueda intercambiar sin tiempo de inactividad para la mayoría de las actualizaciones. Los grandes cambios de esquema a menudo fuerzan el tiempo de inactividad real, ya que el software actualizado generalmente no puede acomodar el esquema anterior, y probablemente no pueda salirse con la suya copiando los datos a una nueva instancia de base de datos, actualizando el esquema y luego cambiando los servidores a la nueva base de datos, ya que habrá perdido cualquier dato escrito en la antigua después de que la nueva base de datos se clonó de ella. Por supuesto, si tiene recursos, puede encargar a los desarrolladores que modifiquen la nueva aplicación para usar nuevos nombres de tabla para todas las tablas que se actualizan, y puede poner disparadores en su lugar en la base de datos viva que actualizará correctamente las nuevas tablas con los datos a medida que se escriben en las tablas antiguas por la versión anterior (o tal vez usar vistas para emular un esquema del otro). Abra los nuevos servidores de aplicaciones y cámbielos al clúster. Hay un montón de juegos que puedes jugar para minimizar el tiempo de inactividad si tienes los recursos de desarrollo para construirlos.

Tal vez el mecanismo más útil para reducir el tiempo de inactividad durante actualizaciones de software es asegurarse de que su aplicación puede funcionar en un modo de solo lectura. Eso ofrecerá alguna funcionalidad necesaria a sus usuarios, pero le dejará con la capacidad de realizar cambios en todo el sistema que requieran modificaciones en la base de datos y cosas por el estilo. Coloque su aplicación en modo de solo lectura, luego clone los datos, actualice el esquema, muestre los nuevos servidores de aplicaciones en la nueva base de datos y, a continuación, cambie el equilibrador de carga para usar los nuevos servidores de aplicaciones. Su único tiempo de inactividad es el tiempo necesario para cambiar al modo de solo lectura y el tiempo necesario para modificar la configuración de su balanceador de carga (la mayoría de los cuales pueden manejarlo sin ningún tipo de tiempo de inactividad).

Mi consejo es usar rsync con versiones explosionadas pero desplegar un archivo war.

1. Cree una carpeta temporal en el entorno en vivo donde tendrá una versión explosionada de la aplicación web.
2. Versiones explotadas de Rsync.
3. Después de rsync exitoso, cree un archivo war en una carpeta temporal en la máquina de entorno en vivo.
4. Reemplace la antigua guerra en el directorio de despliegue del servidor con una nueva de la carpeta temporal.

Se recomienda reemplazar la guerra antigua por una nueva en JBoss contenedor (que se basa en Tomcat) beacause it'a atómica y operación rápida y es seguro que cuando el deployer se iniciará toda la aplicación estará en estado de implementación.

¿No puede hacer una copia local de la aplicación web actual en el servidor web, rsync a ese directorio y luego tal vez incluso utilizando enlaces simbólicos, de una sola vez, apuntar a Tomcat a una nueva implementación sin mucho tiempo de inactividad?

Su enfoque para rsync la guerra extraída es bastante bueno, también el reinicio ya que creo que un servidor de producción no debería tener activado el despliegue en caliente. Entonces, el único inconveniente es el tiempo de inactividad cuando necesita reiniciar el servidor, ¿verdad?

Asumo que todo el estado de su aplicación se mantiene en la base de datos, por lo que no tiene ningún problema con algunos usuarios que trabajan en una instancia de servidor de aplicaciones mientras que otros usuarios están en otra instancia de servidor de aplicaciones. En caso afirmativo,

Ejecutar dos servidores de aplicaciones: Inicie el segundo servidor de aplicaciones (que escucha en otros puertos TCP) e implemente su aplicación allí. Después de la implementación, actualice la configuración de Apache httpd (mod_jk o mod_proxy) para que apunte al segundo servidor de aplicaciones. Reiniciando correctamente el proceso httpd de Apache. De esta manera, no tendrá tiempo de inactividad y los nuevos usuarios y solicitudes se redirigirán automáticamente al nuevo servidor de aplicaciones.

Si puede hacer uso del soporte de clústeres y replicación de sesiones del servidor de aplicaciones, será incluso suave para los usuarios que actualmente están conectados, ya que el segundo servidor de aplicaciones se resincronizará tan pronto como se inicie. Luego, cuando no haya accesos al primer servidor, apáguelo.

Esto depende de la arquitectura de su aplicación.

Una de mis aplicaciones se encuentra detrás de un proxy de equilibrio de carga, donde realizo una implementación escalonada, erradicando de manera efectiva el tiempo de inactividad.

Hot Deploy a Java EAR to Minimize or Eliminate Downtime of an Application on a Server or How to "hot" deploy war dependency in Jboss using Jboss Tools Eclipse plugin might have some options for you.

La implementación en un clúster sin tiempo de inactividad también es interesante.

JavaRebel tiene hot-code deployement también.

Si los archivos estáticos son una gran parte de su gran GUERRA (100Mo es bastante grande), colocarlos fuera de la GUERRA y desplegarlos en un servidor web (por ejemplo, Apache) frente a su servidor de aplicaciones podría acelerar las cosas. Además de eso, Apache generalmente hace un mejor trabajo en el servicio de archivos estáticos que un motor servlet (incluso si la mayoría de ellos hicieron un progreso significativo en esa área).

Entonces, en lugar de producir una gran GUERRA gorda, póngala a dieta y produzca:

• una CREMALLERA grande y gorda con archivos estáticos para Apache
• una GUERRA menos gorda para el motor servlet.

Opcionalmente, ir más allá en el proceso de hacer la GUERRA más delgada: si es posible, desplegar Grails y otros JARs que no cambian con frecuencia (que es probablemente el caso de la mayoría de ellos) a nivel de servidor de aplicaciones.

Si tiene éxito en producir una GUERRA más ligera, no me molestaría en rsyncing directorios en lugar de archivos.

Fortalezas de este enfoque:

1. Los archivos estáticos pueden ser "desplegado" en Apache (por ejemplo, usar un enlace simbólico apuntando al directorio actual, descomprimir los nuevos archivos, actualizar el enlace simbólico y voilà).
2. La GUERRA será más delgada y tomará menos tiempo desplegarla.

Debilidad de este enfoque:

1. Hay un servidor más (el servidor web) por lo que esto agrega (un poco) más complejidad.
2. Tendrá que cambiar los scripts de compilación (no es un gran problema IMO).
3. Necesitará cambiar la lógica de rsync.

No estoy seguro de si esto responde a su pregunta, pero solo compartiré sobre el proceso de implementación que uso o encuentro en los pocos proyectos que hice.

Similar a usted, no recuerdo haber hecho un redespliegue o actualización completa de la guerra. La mayoría de las veces, mis actualizaciones están restringidas a unos pocos archivos jsp, tal vez una biblioteca, algunos archivos de clase. Soy capaz de administrar y determinar cuáles son los artefactos afectados, y por lo general, empaquetamos esas actualizaciones en un archivo zip, junto con un script de actualización. Voy a ejecutar el actualizar script. El script hace lo siguiente:

• Copia de seguridad de los archivos que se sobrescribirán, tal vez a una carpeta con la fecha y hora de hoy.
• Desempaquetar mis archivos
• Detener el servidor de aplicaciones
• Mueve los archivos sobre
• Inicie el servidor de aplicaciones

Si el tiempo de inactividad es una preocupación, y por lo general lo son, mis proyectos suelen ser HA, incluso si no comparten el estado, sino que utilizan un enrutador que proporciona enrutamiento de sesión pegajoso.

Otra cosa que tengo curiosidad sería, ¿por qué la necesidad de rsync? Debe poder saber cuáles son los cambios requeridos, determinándolos en su entorno de preparación/desarrollo, no realizando comprobaciones delta con live. En la mayoría de los casos, tendría que ajustar su rsync para ignorar los archivos de todos modos, como ciertos archivos de propiedades que definen los recursos que utiliza un servidor de producción, como la conexión a la base de datos, el servidor smtp, etc.

Espero que esto sea útil.

En ¿cuál es su conjunto PermSpace? Yo esperaría ver esto crecer también, pero ¿debería bajar después de la recolección de las viejas clases? (¿o el ClassLoader sigue sentado?)

Pensando en outloud, podría rsync a un directorio separado con nombre de versión o fecha. Si el contenedor admite enlaces simbólicos, ¿podría detener SIGSTOP el proceso raíz, cambiar la raíz del sistema de archivos del contexto a través de un enlace simbólico, y luego SIGCONT?

En cuanto al contexto inicial se reinicia. Todos los contenedores tienen opciones de configuración para deshabilitar la redistribución automática en el archivo de clase o los cambios estáticos de recursos. Probablemente no pueda deshabilitar las redistribuciones automáticas en la web.xml cambia por lo que este archivo es el último en actualizar. Así que si deshabilita para volver a implementar automáticamente y actualizar la web.xml como el último verá el contexto restart después de toda la actualización.

Subimos la nueva versión de la aplicación web a un directorio separado, luego movemos para intercambiarlo con el que se está ejecutando, o usamos enlaces simbólicos. Por ejemplo, tenemos un enlace simbólico en el directorio webapps de tomcat llamado "myapp", que apunta a la aplicación web actual llamada "myapp-1.23". Subimos la nueva webapp a "myapp-1.24". Cuando todo esté listo, detenga el servidor, elimine el enlace simbólico y cree uno nuevo que apunte a la nueva versión, luego inicie el servidor de nuevo.

Desactivamos la recarga automática en producción servidores para el rendimiento, pero aún así, tener archivos dentro de la aplicación web que cambian de una manera no atómica puede causar problemas, ya que los archivos estáticos o incluso las páginas JSP podrían cambiar de maneras que causan enlaces rotos o peor.

En la práctica, las aplicaciones web se encuentran realmente en un dispositivo de almacenamiento compartido, por lo que los servidores agrupados, con equilibrio de carga y conmutación por error tienen el mismo código disponible.

El principal inconveniente de su situación es que la carga tomará más tiempo, ya que su método permite que rsync solo transfiere archivos modificados o agregados. Usted podría copiar la antigua carpeta webapp a la nueva primero, y rsync a eso, si hace una diferencia significativa, y si realmente es un problema.

Tomcat 7 tiene una buena característica llamada " parallel deployment " que está diseñada para este caso de uso.

La esencia es que se expande el .la guerra en un directorio, ya sea directamente bajo webapps/ o se enlazan. Las versiones sucesivas de la aplicación están en directorios llamados app##version, por ejemplo myapp##001 y myapp##002. Tomcat se encargará de las sesiones existentes que van a la versión anterior, y las nuevas sesiones que van a la nueva versión.

El problema es que tienes que ser muy cuidadoso con PermGen leaks. Esto es especialmente cierto con Grails que utiliza una gran cantidad de PermGen. VisualVM es tu amigo.

Simplemente use 2 o más servidores tomcat con un proxy sobre él. Ese proxy puede ser de apache / nignix / haproxy.

Ahora en cada uno de los servidores proxy hay url "in" y "out" con puertos configurados.

Primero copie su guerra en el tomcat sin detener el servicio. Una vez que war se despliega, se abre automáticamente por el motor tomcat.

Tenga en cuenta la comprobación cruzada unpackWARs="true" y autoDeploy="true" en el nodo "Host" dentro del servidor.xml

Se ve como esto

  <Host name="localhost"  appBase="webapps"
        unpackWARs="true" autoDeploy="true"
        xmlValidation="false" xmlNamespaceAware="false">

Ahora vea los registros de tomcat. Si no hay ningún error, significa que está funcionando correctamente.

Ahora visita todas las API para probar

Ahora ven a tu servidor proxy .

Simplemente cambie el mapeo de url de fondo con el nombre de la nueva guerra. Dado que el registro con los servidores proxy como apache / nignix / HAProxy tomó mucho menos tiempo, sentirá un tiempo de inactividad mínimo

Refiérase { https://developers.google.com/speed/pagespeed/module/domains para mapear urls

Está utilizando Resin, Resin ha incorporado soporte para el control de versiones de aplicaciones web.

Http://www.caucho.com/resin-4.0/admin/deploy.xtp#VersioningandGracefulUpgrades

Actualización: Su proceso de vigilancia también puede ayudar con problemas de permgenspace.

No es una "mejor práctica", sino algo en lo que acabo de pensar.

¿Qué tal desplegar la webapp a través de un DVCS como git?

De esta manera puedes dejar que git averigüe qué archivos transferir al servidor. Usted también tiene una buena manera de salir de ella si resulta ser reventado, solo hacer una reversión!

Escribí un script bash que toma unos pocos parámetros y rsyncs el archivo entre servidores. Acelera la transferencia rsync mucho para archivos más grandes:

Https://gist.github.com/3985742