Primeros pasos con Spring Cloud Data Flow: ejecución local.

0
505

0. Índice de contenidos.

1. Introducción.

En este tutorial vamos a ver cómo hacer nuestras primeras pruebas con Spring Cloud Data Flow (SCDF) en nuestra máquina local, sin entrar aún ni en el despliegue en la nube ni, como consecuencia, en el despliegue de contenedores. Veremos simplemente, cómo montar el servicio en local haciendo uso de un repositorio de Maven y desplegando batches como procesos locales.

Tampoco veremos la parte de streaming, eso lo dejaremos para futuros tutoriales; seguimos en la línea de tutoriales anteriores, donde la idea es hacer uso de la parte de procesamiento de datos masivos en batch. Podéis encontrar las referencias a los tutoriales previos a continuación:

2. Entorno.

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 15′ (2.3 GHz Intel Core i9, 32GB DDR4).
  • Sistema Operativo: Mac OS Mojave 10.14.6
  • OpenJDK: 12.0.2
  • Spring Cloud Data Flow 2.7.0

3. Instalación para impacientes…

Para los más impacientes, la forma más rápida de disponer de SCDF en tú máquina local y hacer las primeras pruebas es descargarse el bundle:

Y, a continuación, ejecutarlo como un proceso java, sin más:

Podréis comprobar en la salida por consola, el correcto arranque del servicio y acceder al dashboard web a través de la siguiente url Spring Cloud Data Flow Dashboard URL.

También en esa salida por consola podréis comprobar como en esta primera ejecución en local y por defecto:

  • que no está preparado para k8s:
  • que haremos estas primeras pruebas con una base de datos H2, también local y en memoria, con lo que, cuando termine el proceso java perderemos todos los datos; recordar que esa base de datos sirve para el registro de las aplicaciones, tareas y el estado de la ejecución de las mismas:
  • que está habilitado únicamente el despliegue local:

Lo primero que veréis al acceder al dashboard es la sección de aplicaciones vacía, como se muestra a continuación:

sección de aplicaciones

Vamos a probar a añadir alguna aplicación predefinida, seleccionando la siguiente opción, en la que se usa un repositorio de Maven público para realizar la descarga del artefacto a desplegar, en esta nuestra primera ejecución local.

Lista sección de aplicaciones

Una vez importados tendremos las siguientes aplicaciones disponibles.

Aplicaciones disponibles

Haremos nuestra primera prueba con la app de Timestamp batch que está preparada para imprimir la fecha actual en el log, no hace más que eso en su ejecución, como un proceso batch.
Existe una tarea de timestamp que está pensada para su ejecución dentro de un flujo de streaming de datos, esta, por ahora, no la vamos a usar.

Podéis apreciar que se muestra asociado a la aplicación tanto el número de versión como la URI donde se encuentra el artefacto, que será usado por el módulo SPI de SCDF para ejecutar la tarea, en este caso en local.

4. Tu primera tarea… chispas.

Una vez tenemos nuestra primera aplicación, aunque insulsa, vamos a ver cómo configurar una tarea asociada a la misma.

Para ello, desde la sección de tareas, que estará vacía, pulsamos sobre «crear tarea».

Sección de tareas

Se mostrará una interfaz como la siguiente en la que a la izquierda aparecerán todas las aplicaciones de distintos tipos que están previamente registradas.

interfaz en la que a la izquierda aparecerán todas las aplicaciones de distintos tipos que están previamente registradas

Para crear una tarea basada en una aplicación, no tenemos más que arrastrarla hacia el editor visual de la derecha y conectar el punto de inicio y fin del flujo. También podríamos escribir en la parte superior en un lenguaje DSL el flujo de ejecución de las tareas, pero para este primer uso, basta con dejarlo como en la imagen y pulsar sobre crear tarea.

Editor visual

Se mostrará una ventana emergente como la siguiente, en la que podremos darle un nombre y una descripción a la tarea:

ventana emergente

Tras pulsar sobre crear la tarea, podremos visualizarla en el listado, como sigue:

listado de tareas

Las tareas no tienen versiones, son las aplicaciones en las que se basan las que se versionan.

A continuación vamos a acceder al detalle de la tarea, desde el cuál podemos comprobar como se encuentra en estado «desconocido» puesto que aún no se ha ejecutado nunca, ese estado se mapea con el estado de la última ejecución de la tarea:

detalle de la tarea

Desde esa misma pantalla de detalle de la tarea podemos pulsar sobre ejecutar tarea y acceder a una ventana como la siguiente, desde la cual podemos ejecutarla, redefiniendo:

  • argumentos: esto es, parámetros que preparemos para su sobrescritura desde las ejecuciones, como nombres o prefijos de ficheros a leer, fechas de ejecuciones para buscar ficheros por patrones… cualquier parametrización de la tarea que sea susceptible o necesaria desde el punto de vista de operaciones.
  • Properties: de la propia configuración de entorno de la task, propiedades de Spring Boot o de la propia Task de Spring Cloud.

En este primera ejecución podríamos configurar el patrón de la fecha que mostrará la task, que es lo que podría recibir la misma como podéis ver aquí: TimestampBatchTaskProperties.java.

Configuración

Tras pulsar sobre «ejecutar la tarea» podréis ver en la consola de la ejecución del proceso del dataflow una salida como la siguiente:

Y accediendo al directorio que se indica podemos encontrar un fichero stdout.log con la salida por consola del proceso de la propia task en el que podremos encontrar dos trazas en concreto con algo similar a lo siguiente:

Que es el resultado de la ejecución del código de la aplicación de la tarea que hemos lanzado, lo podéis consultar aquí:
TimestampBatchTaskConfiguration.java

No es más que una prueba dentro ahora de nuestro sandbox de una ejecución de una tarea que lanza dos jobs de prueba.

Una vez lanzados, ahora en el listado de tareas, aparecerá como completada.

listado de tareas completas

Accediendo de nuevo al detalle de la misma podemos ver los pormenores de la ejecución, con un listado a la derecha de todas las ejecuciones de la tarea:

detalle de la tarea donde podemos ver los pormenores de la ejecución, con un listado a la derecha de todas las ejecuciones de la tarea

Información, abajo a la izquierda, de la última ejecución, desde la que podemos acceder incluso a los logs:

Información de la última ejecución

Podemos acceder en detalle a la ejecución de esa tarea número 1:

detalle de la ejecución

Y desde el detalle de la tarea al listado de los jobs que se han ejecutado dentro de la misma, también pulsando sobre el enlace de cada uno de ellos en la sección «Job Executions Ids».

listado de los jobs que se han ejecutado

Desde el detalle de los jobs, se puede acceder al detalle de los steps, en este caso, solo tiene uno:

detalle de los steps

Pero nos sirve para ver el nivel de detalle de la información que tenemos en la ejecución de cada step:

nivel de detalle de la información

Recuerdo que el dataflow dispone de toda esta información porque las task comparten la base de datos del propio dataflow para ir alimentando dicha información y mantener el estado de su ejecución; se puede ver un poco más arriba como en las properties de la ejecución de las tareas, el dataflow le pasa la cadena de conexión, usuario y contraseña necesarios a las aplicaciones que ejecutan las tasks para poder acceder a dicha base de datos.

Por último, y ya saliendo a la sección de «Audit records», podemos ver cómo se quedan registradas todas las acciones que vamos lanzando desde el dashboard a modo de proceso de auditoría

Registro acciones que vamos lanzando desde el dashboard

Teniendo la integración con Spring Security y autenticando a nuestros operadores en el acceso al SCDF en la columna «Created by» deberían aparecer las acciones nominativas.

5. Feature flags.

La propia arquitectura de SCDF está diseñada en base a componentes que podemos habilitar o deshabilitar, de tal modo que podemos arrancar el servidor con la parte de procesamiento de streamings deshabilitada, como sigue:

De este modo, no aparecerán visibles si quiera en la interfaz las opciones de streaming y no tendremos los posibles errores en la consola que habréis podido ver si habéis seguido el tutorial.

6. Conclusiones.

Sirva este tutorial para tener una primera toma de contacto, insisto que solo en la parte batch de Spring Cloud Data Flow.

Lo siguiente sería ver cómo usar SCDF dentro de un cluster de k8s, lejos de la «simplista» ejecución de tareas locales; pero la operativa de cómo trabajar de modo operador, con tareas manuales sería la misma independiente de la plataforma y del modo de despliegue de las tareas.

Recordad también que lo ideal es tener el pipeline de despliegue de las tareas batch integrado con el api de SCDF de modo que la promoción entre entornos y la configuración de versiones de las aplicaciones, tareas, ejecución y calendarización esté totalmente controlada e integrada en el pipeline de construcción.

Stay tuned!

Jose

Dejar respuesta

Please enter your comment!
Please enter your name here