← Ir a portada

Desplegar vía Jenkins una aplicación y sus librerías por separado

Objetivo: Crear una tarea Jenkins (proyecto maven) para desplegar un .war sin sus dependencias y sincronizar estas. El objetivo que perseguimos es, al hilo del post anterior , poder hacer despliegues enviando al servidor remoto el mínimo de información repetida de un despliegue al siguiente.

Para ello partiendo de una tarea maven de Jenkins añadiremos una serie de pasos extras. El desglose de lo que buscamos conseguir es:

  1. Preparar Tomcat para que trabaje con librerías compartidas.
  2. Construya un .war sin sus librerias de dependencias.
  3. Almacene las librerias en un directorio.
  4. Sincronice las librerias con el servidor.
  5. Envíe el nuevo .war.
  6. Reinicie Tomcat.

Los puntos 1 y 2 quedaban cubiertos en un post anterior así que continuamos:

3: Almacenar las librerías en un directorio.

Este enlace del plugin maven dependency explica como hacer que en la construcción las dependencias se copien a un directorio definido por nosotros, esta parte iría incluida en el fichero pom de producción del que hablábamos en el post anterior.

4: Sincronizar las librerías con el servidor remoto:

Tras la construcción habrá que sincronizar las librerías con el servidor, para ello ejecutaremos un rsync, introduciéndolo como orden shell en la tarea Jenkins, para evitar re-enviar las librerías si solo ha cambiado la fecha de estas utilizaremos el flag –size-only para que solo se tenga en cuenta el tamaño del fichero:

rsync -av –size-only origen destino

5: Enviar el nuevo fichero .war al servidor:

Aquí tenemos varias alternativas, el plugin “Publish over FTP” de Jenkins o bien ejecutar un comando shell que envíe el fichero (por ejemplo scp).

6: Reiniciar Tomcat:

Este reinicio es necesario para que Tomcat tenga en cuenta las posibles nuevas librerías que se hayan enviado.

Actualización:

Vía Luís me llega una posible complicación de trabajar con esta configuración y es los posibles conflictos entre diferentes versiones de una misma librería que sea utilizada por dos aplicaciones que corren al tiempo en el mismo servidor Tomcat.

Una de las maneras de resolver este conflicto sería dejando de marcar en el fichero pom.xml de el proyecto dicha librería como “provided” ya que así la librería pasaría a estar incluida en el .war de la aplicación.

Como podemos ver en la documentación del proyecto Apache Tomcat el orden de carga de las librerías de Tomcat, hará que la carga de las librerías propias empaquetadas en el .war las coloque prioritariamente de cara al uso, así si tenemos dos aplicaciones que usan, por ejemplo, primefaces en diferentes versiones, deberíamos empaquetar cada aplicación con esta librería en la versión que le corresponda.

Puede que esa solución no parezca especialmente limpia porque tenemos que conocer todas las dependencias de todos los programas antes de hacer un pase a producción y el pase de una aplicación podría implicar en tener que volver a desplegar otra aplicación que no lo precise. Efectivamente es un handicap, pero como explicamos al inicio de estos dos post relacionados, el objetivo es que el fichero .war de nuestra aplicación pierda “michelines” de cara al envío al servidor.

 

Apuntes relacionados:

Deja un comentario