Jenkins

Jenkins: Gestión del deployment y las ejecuciones de Talend

Introducción a Jenkins como gestor de ejecuciones de job de Talend

Talend Open Studio (TOS)

TOS,  tiene una oferta de módulos importante que no supone mayor impedimento para al desarrollo de jobs muy potentes. En cambio, a la hora de ejecutar el paquete Java compilado, se echa de menos a la funcionalidad de planificación y seguimiento que ofrece el TAC (con licencias on-premise) o la TMC (en el caso de licencias Cloud).

Planificador de tareas de Windows

La solución en plataforma Windows, es el “viejo” planificador de tareas de Windows

Basta con unos cuantos jobs para llegar a un cierto nivel de caos.

Hay que diseñar job específicamente con salida de consola a ficheros para poder saber lo que pasa en caso de fallo en la ejecución. No es muy posible gestionar ejecuciones en varias máquinas y menos ejecutar jobs en instancia de cloud.

Jenkins al rescate

Hemos estado buscando una solución para crear un marco de ejecución más eficiente y con más flexibilidad para job de Talend. Proponemos el uso de Jenkins junto con Nexus, ambos de código libre y gratuitos.

Jenkins es originalmente, una aplicación para desarrollo o integración continuo. Por lo tanto, está integrado con los repositorios comunes de manera nativa o mediante cienes de plugins. Jenkins un proyecto basado en Java, muy activo, lo que asegura una buena protección contra los fallos de sus bibliotecas y módulos.

Hemos elegido asociarlo con Nexus y así tener un almacenamiento con versionado de los diferentes ejecutables compilados desde TOS. De paso, si es necesario, podemos ejecutar otros script tales como Python o cualquier otro si fuese necesario.

Que hace Jenkins?

Un instalación típica de Jenkins, se compone de un controlador y de un nodo. El nodo puede ser la misma máquina que el controlador, pero no se aconseja para entorno de producción por razón de seguridad dado que Jenkins tiene muchos derechos. En cambio el agente, está diseñado para ejecutar las tareas mandadas por el controlador con el menor impacto posible en la maquinas huéspedes que pueden ser además tanto una maquinas física, una máquina virtual, un contenedor Docker o incluso una instancia de cloud.

El agente ejecuta el código Java que le transmite el controlador, en nuestro caso eligiendo la versión adecuada en el repositorio de Nexus.

Freestyle versus Pipeline

En Jenkins, la unidad de código que se ejecuta se llama proyecto, los hay de varios tipos. Hemos elegido 2 tipos: Freestyle y Pipeline.

Freestyle

Un proyecto freestyle se configura seleccionando los pasos en una interfaz de menú que lista todas las posibilidades tanto como proceso antes de ejecución, de trigger o de tratamiento después de ejecución.

Es fácil de realizar un proyecto pero solo se ve como un único bloque de ejecución. Además es tedioso copiarlo y usarlo como plantilla.

Pipeline

Jenkins, da la posibilidad de escribir todos los pasos de un proyecto con lenguaje Groovy en un bloque de texto de tipo “Jenkins File”. Se copia fácilmente, puede incluir paso de ejecución condicional, lectura de fichero externos… Groovy está derivado de Java y tiene acceso a todas sus bibliotecas. Esta herramienta proporciona más funcionalidades de  planificación más avanzadas que las herramientas de Talend en las versiones de subscripción.

Como vamos a bajar un ejecutable desde un repositorio para poder ejecutarlo en un agente, puede haber fallos en diferentes etapas. La vista de ejecución permite identificar inmediatamente donde ocurrió el fallo y consultar el log del paso correspondiente.

Plugins

A la hora de elegir de instalar un plugin, hay que tomar en cuenta si el proyecto es suficiente activo para asegurar una reacción rápida en caso de fallo de seguridad.

Hay plugins que cubren casi cualquier necesidad. Presentamos una lista de los que pueden ser útiles.

  • Locale: Para cambiar el idioma de la aplicación diferente del navegador, aconsejado para seguir los tutoriales que son mayoritariamente en inglés.
  • Nexus Platform: Permite la integración con Nexus, no sirve para cargar código en el repositorio.
  • Job Configuration History: Guarda copia de todo los cambio de configuración y Job. Permite comparar y restaurar versión antigua de un elemento.
  • Calendar View: Nos da una vista de calendario de los proyectos planificados incluyendo el resultado para el pasado.
  • PowerShell plugin Version: En caso de usar powershell permite de disponer de sus funciones dentro de un proyecto. En plataforma windows permite de diseñar pipeline más eficientes.
  • Role-based Authorization Strategy: Añade una gestión fina de los accesos y capacidades, necesario para un uso en producción.
  • Versions Node Monitors plugin: Ayuda a asegurar que los nodos de ejecución tienen la versión de Java y del agente adecuada para correcta actuación del controlador.
  • Blue Ocean: Nuevo interfaz pensada para proyecto de tipo pipeline hospedados en gestor de contenido como GIT por ejemplo.
  • Docker: Permite de instalar un nodo en un contenedor Docker
  • Naginator: permite una gestión fina en caso de fallo de ejecución en un proyecto de tipo freestyle.

Solamente, es una pequeña selección que nos da una idea de la amplitud de la oferta que tiene Jenkins gracias a la comunidad de código libre.

En la siguiente parte, vamos a detallar la implementación de nuestra solución incluso la configuración de Jenkins.

Implementación de Jenkins: Parámetros y Elementos externos.

Como se ha visto anteriormente se ha elegido  el flujo de trabajo siguiente: Los paquetes ejecutables obtenidos por el Build de Talend Open Studio (TOS), se almacenan con versionado en un repositorio de Nexus. Jenkins sacará la versión de producción. Puede ser una versión especifica o la última versión.

El paquete ejecutable Java es un archivo comprimido zip, que se debe extraer al espacio de trabajo de Jenkins. Jenkins, a continuación, lanza uno de los scripts del paquete que son bat, powershell ou shell según la plataforma del agente.

Un ejemplo de script Groovy completo (Jenkins File) se presentará más adelante.

La instalación de Nexus se realiza según el procedimiento detallado en le página de Sonatype https://help.sonatype.com/repomanager3/product-information/download

Nexus puede instalarse en cualquier máquina de la red, siempre que se pueda acceder desde el agente y el controlador de Jenkins. El código del servidor Nexus está en forma de archivo comprimido. El servidor se lanza mediante comando “nexus run/start”. El comando exacto se encuentra en la página de https://help.sonatype.com/repomanager3/installation-and-upgrades/installation-methods. Ejecutar Nexus como servicio en el servidor necesita pasos diferente descritos por plataforma https://help.sonatype.com/repomanager3/installation-and-upgrades/run-as-a-service. Se crea un repositorio de tipo Maven / Hosted que es el tipo adecuado para los artefactos de Java tales como un paquete construido por Talend.

En Jenkins, para que la magia actué, hay que realizar esos ajustes:

  • Labels: Etiqueta para identificar la máquina aunque en principio, el controlador no servirá para ejecuciones, suelen identificar el sistema operativo o propiedades que permite al controlador de elegir la máquina para ejecutar una determinada tarea.
  • # of executors: En el caso de máquina de producción que se usa solamente como controlador 0, sino el nombre de hilos paralelos que se pueden ejecutar.
  • URL IP y puerto de acceso en la red, evitando localhost
  • En el apartado “Nexus Repository Manager 3.x Server” se configura el acceso de escritura al servidor Nexus y así poder cargar los artefactos Java de Talend desde un proyecto de Jenkins.
  • En los ajustes a nivel de nodo, las variables globales para identificar el camino de acceso a carpetas de datos y/o herramientas. En el caso de plataforma basada en Unix hay que tener wget instalado. Se configuran a nivel de nodo, ya que pueden ser diferentes en cada máquina.

Con esos ajustes básicos, el controlador está preparado para funcionar, pero le falta definir nodos de ejecución. Por defecto ya existe el nodo del controlador (Built-In)

Hay una sección de configuración que permite agregar nuevos nodos

En general, lo mejor es instalar el código del agente automáticamente desde el controlador conectándolo por SSH. En cambio, si el nodo es una maquina Windows, se aconseja de instalar manualmente el agente en la maquina y lanzarlo. El controlador genera una línea de comando única que permite al agente Windows de llamar al controlador cuando está activo.

Una vez acabada la configuración, se puede probar un primero proyecto freestyle para cargar nuestro primero artefacto en el repositorio Nexus.

Se crea un nuevo elemento de tipo “Freestyle Project”

Se añade un paso de publicación a Nexus 3

Puesto que hemos configurado el servidor se nos aparece en el menú

Se escoge en el segundo menú el repositorio donde se quiere subir el artefacto

Ponemos los identificadores del paquete et del artefacto que queremos subir

Guardar y ejecutar (Build en el idioma de Jenkins)

Jenkins nos indica que el build (la subida del artefacto, en nuestro caso) se ha ejecutado con éxito. Y podemos navegar en Nexus para ver el artefacto que acabamos de subir.

De la misma manera podríamos componer un proyecto para automatizar las etapas para seleccionar un artefacto de Nexus, descomprimir el archivo y ejecutar el script lanzador de Java. Como ya vimos, hacer un seguimiento de etapas múltiples vistas como un solo bloque, no es lo más cómodo. Sobre todo que Jenkins dispone de una modalidad que nos permite de ver el resultado de cada etapa por separado.

En la siguiente parte, veremos que los proyectos de tipo pipeline son la herramienta ideal para un seguimiento fino de ejecuciones de pasos multiples.

ADJUNTOS:

script Nexus_DL_Execute_Pipeline .txt

script Nexus_DL_Execute_Pipeline ps.txt

script Nexus_DL_Execute_Pipeline multi.txt

Procedimiento y script de ejecución

Ahora que tenemos un controlador Jenkins configurado con nodo para ejecución y repositorio de Nexus para almacenar los artefactos, podemos montar un flujo de trabajo que nos permite un buen seguimiento y de fácil manejo para adaptarlo a varios jobs.

Cuando tenemos desarrollado un job en Talend Open Studio (TOS), llega el momento de pasar a producción.

La única opción de ejecución del job fuera del Studio, pasa por compilarlo (Build) y ejecutar el paquete con Java.

Como en la segunda parte, tenemos el paquete subido como artefacto en Nexus y un sistema de ejecución basado en Jenkins totalmente configurado.

Podemos ejecutar el proyecto pipeline de Jenkins desarrollado para las siguientes etapas:

  1. Paso previo de borrado del espacio de trabajo (donde se van a guardar los ficheros necesarios en el agente.
  1. Un paso para determinar la versión del artefacto que queremos ejecutar, puede ser versión última escogida programáticamente o versión configurada a mano.
  1. Descarga de la versión escogida del artefacto desde Nexus al espacio de trabajo.
  1. Extracción de los ficheros contenidos en el archivo comprimido.
  1. Ejecución del script lanzador correspondiendo al sistema operativo, powershell (extensión .ps1) para windows o bash Shell (extensión .sh) para las máquinas de tipo Unix.

Cabe notar que en Windows se podría usar el script .bat igualmente presente sin cambio ninguno. Pero como se necesita powershell para lectura de Nexus y descompresión, elegimos Powershell para más consistencia.

Detalle del script del pipeline

Para simplificar vamos a repasar la sintaxis y las etapas del script que henos creado, para simplificar vamos a ver la versión para plataforma Windows con Powershell aunque tenemos versión para plataformas Unix y multiplataforma que compartiremos de todos modos.

La declaración pipeline es obligatoria. agent, nos permite especificar que el script debe usar nodos con etiqueta Windows.  

El bloque environment permite de definir variable de entorno, son válidas dentro del pipeline y solo de lectura. stages, indica que es el bloque donde se pone el código de los pasos, cada uno tiene la etiqueta stage con el nombre por lo cual se identificará.

Cada stage tiene pasos identificados por steps el comando del paso “clean WS” es un comando que permite de borrar el contenido de la carpeta que servirá de espacio de trabajo, De no hacerlo, se podría re-usar ficheros de la ejecución precedente.

Aquí usamos un paso que contiene comandos de powershell para acceder al fichero descriptivo del paquete a través de la API de Nexus y determinar la última versión. En el caso de querer una versión fija, se inicializa sencillamente.

Se guardan dos fichero en el workspace, uno para poder inicializar el valor de esta última versión en otra instancia de powershell otro con el comando para lazar el script ps1. stash, que está comentado, permite guardar ficheros para uso en otros proyectos.

Descarga el artefacto necesario desde Nexus, se obtiene un fichero zip en espacio de trabajo.

Único comando de powershell para extraer el fichero de propiedades y las dos carpetas del paquete Java construido por Talend.

Comando powershell ejecuta el lanzador .ps1 en la carpeta del proyecto.

Cuando vamos al panel de control del proyecto vemos el resultado de las ejecuciones y el paso que dio lugar al fallo si hubo.

Ademas, podemos ver el log de cada paso. En el ejemplo debajo, la salida de consola del job de Talend.

En la siguiente parte veremos como ampliar la funcionalidad del pipeline base con trigger.

Trigger por otro proyecto por detección de cambio de fichero

La potencia de Jenkins se apoya bastante en sus plugins que simplifican la programación. Pero algunos tienen límites. Es el caso de uno que se llama File Trigger que no funciona con pipelines.

En algunos casos, puede ser útil de disparar un job basado en existencia o propiedad de un fichero. De hecho es un tipo de trigger que ofrece el TAC.

La relación de Jenkins con el sistema de ficheros de la maquina huésped no permite acceder fuera del workspace. Por lo tanto, hay que recurrir al shell o powershell para capturar propiedades de ficheros.

Para simplificar la escritura del pipeline y poder usar de nuevo parte de código, aconsejamos de escribir los proyectos de detección de ficheros por separado y aprovechar los ajustes de disparo de los proyectos.

Se puede elegir de arrancar el build de un proyecto a partir del resultado de otro:

  • Estable
  • Inestable
  • Fallo

Detección de fichero

Aquí ponemos ejemplo de pipeline para detección de presencia de un fichero

Primera etapa, llamada al sistema operativa mediante shell o powershell. Se almacena el path del fichero en una variable de entorno que solo será accesible desde este pipeline.   El resultado del test de existencia del fichero se almacena en una variable EXISTE que se usará en el paso siguiente

Este paso es muy sencillo, ajusta el estado del build del proyecto a inestable en caso de no estar presente el fichero.

En la vista de seguimiento del pipeline, vemos que cuando un build es inestable, el color del paso es amarillo mientras que cuando el build es estable aparece en verde. En el ejemplo se ha detectado aparición del fichero vigilado en la ejecución #5

Cambios en ficheros

En este ejemplo nos interesa vigilar si un fichero ha cambiado por lectura de su propiedad de fecha de modificación (en plataforma Windows, la fecha de creación también).

Se pueden poner el camino de acceso de varios ficheros como variable de entorno limitadas a este pipeline

Este proceso necesita recordar los valores de sus última ejecución para comparar los valores actuales.  

Luego se usa la función de bash shell o powershell adecuada a la plataforma. El resultado de las lectura se grava en forma de fichero en el workspace.

Se cargan en variables el contenido del fichero de fecha da la última ejecución y de la ejecución actual y se comparan.

Se ajusta el estado del build del proyecto a inestable en caso de tener diferencias.

En la vista de seguimiento del pipeline, vemos que la ejecución numero #1 resulta en fallo. Eso es porque no hay fichero de ejecución precedente para realizar la comparación.  

La #2 nos devuelve un build inestable, con su paso de color amarillo porque se ejecutó a mano inmediatamente después con las mismas versiones de los ficheros vigilados.  

En cambio el build #3 es estable aparece en verde porque la aplicación fuente ya había guardado una nueva versión de al menos uno de los ficheros.

Llegado el final de nuestra presentación del abanico de posibilidades que tiene usar Jenkins como planificador.

En una primera parte vimos la arquitectura de la solución que hemos implementado.

En la segunda, repasamos los ajustes de Jenkins y los otros elementos necesarios para la solución.

La tercera, la hemos dedicado a detallar los pasos del script de tipo pileline desarrollado para ejecución de jobs de Talend con versionado de artefactos en repositorio Nexus.

Acabamos de ver cómo aprovechar la riqueza de Groovy añadido al shell del sistema operativo. En función de los comentarios, podemos estudiar y desarrollar nuevos articulos.

Adjuntos:

  • File_Exist_Trigger_Pipeline.txt
  • File_Change_Trigger_Pipeline.txt