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.
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:
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:
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:
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 artículos.