Cómo pasar a serverless con Talend con CI/CD y los contenedores

Cómo pasar a serverless con Talend con CI/CD y los contenedores

  • Thibaut Gourdel
    Thibaut Gourdel is Technical Product Marketing Jr at Talend since 2017. His area of interest includes cloud technologies, containerization, serverless computing and data stream processing.

¿Por qué deberíamos prestar atención a la CI/CD y a los contenedores?

La integración continua, entrega y el despliegue continuos, conocido como CI/CD, se ha convertido en una etapa tan fundamental de todo proyecto de software de éxito que son innegables las ventajas que puede reportar a su proyecto. Al mismo tiempo, los contenedores son ya prácticamente omnipresentes y gozan de gran aceptación entre los desarrolladores. A la hora de la verdad, la CI/CD permite a los usuarios ganar confianza en las aplicaciones que están creando por cuanto las verifica y valida continuamente. Por otro lado, la contenedorización le aporta la agilidad para distribuir y ejecutar su software construyendo tan solo una vez y pudiendo desplegar “en cualquier lugar” gracias al formato estándar que las empresas pueden adoptar. Estas prácticas habituales de DevOps permiten no caer en el efecto "¡en mi máquina funcionaba!". Como consecuencia directa, mejoran el tiempo de llegada al mercado y permiten entregas más frecuentes.

¿Qué lugar tienen en el entorno Talend?

En Talend queremos brindarle la posibilidad de formar parte de esta revolución dándole acceso a lo mejor de ambos mundos. Desde el lanzamiento de Talend 7.0 ya puede crear sus tareas de Talend dentro de imágenes de Docker gracias a la compilación Maven de serie. Además, queremos ayudarle a conectar sin fisuras este proceso a su canalización de CI/CD.

¿Y la tecnología serverless?

La parte serverless la encontraremos al final. Se refiere a la forma en la que desplegaremos nuestras tareas de Talend. En realidad, al enviar nuestras tareas en contenedores tenemos libertad para desplegar las tareas de integración donde queramos. Entre estas posibilidades cada vez es más prominente una nueva categoría de servicios que definimos como serverless (sin servidor). La mayoría de los grandes proveedores de cloud empiezan a ofertar servicios serverless para contenedores como AWS Fargate o Azure Container Instances, por poner algunos ejemplos. Le permiten ejecutar contenedores sin tener que gestionar infraestructura (ni servidores ni clústeres). Tan solo se le factura por el uso que dé a sus contenedores.

Estas nuevas prestaciones fueron presentadas en Talend Connect US 2018 durante la ponencia inaugural y han sido ilustradas con una demostración en directo de toda una canalización, desde la compilación hasta la ejecución de la tarea, en AWS Fargate y en Azure ACI. En esta entrada del blog vamos a utilizar Jenkins para crear una canalización de CI/CD. Se trata de crear nuestras tareas dentro de imágenes de Docker, poniéndolas a disposición en un registro de Docker y, en última instancia, invocando AWS Fargate y Azure ACI para que las ejecuten.

Esquema sobre el salto a serverless con Talend a través de CI/CD y contenedores

Veamos cómo podemos reproducir ese proceso. Si desean seguir nuestros pasos, comprueben que cumplen los siguientes requisitos.

Requisitos

  • Talend Studio 7.0 o superior
  • Talend Cloud Spring 18’ o superior
  • Tener un servidor de Jenkins disponible
  • Su servidor de Jenkins debe tener acceso a un daemon de Docker instalado en la misma máquina
  • Talend CommandLine instalado en la máquina de Jenkins
  • Nexus, versión 2 o 3
  • Tenga instalado Talend CI Builder configurado junto con su Talend CommandLine.

* Todos los componentes de Talend mencionados están disponibles en la prueba de 30 días de Talend Cloud

Entorno Talend

Si no tiene experiencia con Talend, he aquí una presentación general de sus distintos componentes. Empiece con Talend Cloud, donde tendrá que crear un proyecto en la Talend Management Console (TMC o Consola de gestión de Talend) y luego deberá configurar su proyecto para utilizar un repositorio Git donde almacenar los artefactos de su tarea. También tendrá que configurar los ajustes de Nexus en la TMC para indicar a su servidor alojado de Nexus que guarde las bibliotecas externas que su tarea necesite. La cuenta de Talend Cloud facilita toda la gestión del proyecto y los artefactos en la TMC.

A continuación deberá instalar Studio y conectarlo a la cuenta de Talend Cloud. Studio es el principal entorno de diseño de Talend y es donde creará sus tareas de integración. Cuando inicie sesión con Studio a la cuenta cloud siguiendo estos pasos, verá los proyectos desde la TMC y utilizará el proyecto que está configurado en el repositorio Git. Siga los pasos que aparecen abajo para añadir los complementos necesarios a Studio.

Los dos últimos componentes que necesita son Ci Builder y Talend CommandLine o cmdline (si usa la prueba de cloud, la herramienta CommandLine está incluida en los archivos de instalación de Studio). Al instalar o utilizar la herramienta CommandLine por primera vez tendrá que asignarle una licencia también, para lo que puede utilizar la misma de Studio. Las herramientas CommandLine y CI Builder son los componentes que le permiten extraer el código de la tarea en Studio (en realidad, en Git) y crear y desplegar procesos totalmente ejecutables por medio de scripts. CI Builder, junto con el perfil de Studio, es lo que determina si se tratará de un entorno de ejecución de Talend Cloud o de un contenedor. ¡Estos son los pasos para empezar!

1) Cree un proyecto en Talend Cloud

En primer lugar, tendrá que crear un proyecto en su cuenta de Talend Cloud y vincularlo a un repositorio GitHub. Consulte la documentación para realizar esta operación.

No se olvide de configurar su Nexus en su cuenta de Talend Cloud. Siga la documentación de configuración de su Nexus con Talend cloud. Como recordatorio, su Nexus debe tener los siguientes repositorios:

  • releases
  • snapshots
  • talend-custom-libs-release
  • talend-custom-libs-snapshot
  • talend-updates
  • thirdparty

2) Añada los perfiles de Maven Docker a Studio

Este paso ya no es necesario en Talend Studio 7.1 y superiores. Sáltese esta parte si dispone de esta versión u otra superior, dado que los perfiles Maven Docker ahora los genera Talend Studio. Talend también presenta compatibilidad con OpenJDK 8 en su versión 7.1, lo que significa que puede utilizar imágenes de base OpenJDK de Docker en el entorno de producción.

Vamos a configurar Studio añadiendo los perfiles de Maven Docker a la configuración de los archivos POM de nuestro proyecto y nuestra tarea. Busque los dos archivos que necesitará aquí: project.xml y standalone-job.xml.

Puede hacerlo en su Studio, en el menú Project Properties -> Build -> Project / Standalone Job (Propiedades del proyecto > Crear > Proyecto/ Tarea independiente).

Tan solo tiene que cambiarlos por los que haya copiado más arriba. No es necesario ningún cambio más.

En realidad, lo que estamos haciendo es añadir un nuevo perfil llamado “docker” por medio del componente fabric8 de Maven. Al crear nuestras tareas con este perfil de Maven, se usará openjdk:8-jre-slim como imagen de base y después se le añadirán los archivos JAR de nuestras tareas junto con un pequeño script que indique cómo ejecutar la tarea. Cabe mencionar que Talend no es compatible con OpenJDK ni con Alpine Linux. A efectos de verificación exclusivamente, puede conservar la imagen openjdk:8-jre-slim, pero de cara a la producción tendrá que crear su propia imagen de base de Java Oracle. Para obtener más información, consulte nuestra documentación sobre plataformas compatibles.

3) Configure Jenkins

Una vez más, si usa Talend Studio 7.1 o superior, utilice este archivo de script para canalizaciones en lugar del que aparece más abajo. Ha sido adaptado con las modificaciones y mejoras que incluye la versión Talend 7.1. Combina la compilación de la imagen de Docker con la publicación en un registro de Docker en un único comando de Maven.

Este tercer paso consiste en configurar nuestro servidor de Jenkins. En esta entrada no abordaremos la configuración inicial de Jenkins. Si no lo ha utilizado jamás, consulte la Guía de inicio de Pipeline de Jenkins. Una vez finalizada la configuración inicial, utilizaremos los complementos de Maven, Git, Docker, Pipeline y Blue Ocean para realizar nuestra canalización de CI/CD.

Vamos a guardar nuestro archivos de ajustes de Maven en Jenkins. En los ajustes de Jenkins (Manage Jenkins), vaya a “Managed files” y cree un archivo con el ID “maven-file”. Copie este archivo en él como indica la captura de pantalla de abajo. Acuérdese de modificar la ruta de CommandLine conforme a sus propios ajustes y consigne sus propias credenciales de Nexus y la URL.

Antes de adentrarnos en los pormenores de la canalización, también tendrá que definir ciertas credenciales. Para ello vaya a “Manage Jenkins” (Gestionar Jenkins) y “Configure credentials” (Configurar credenciales), y luego a la izquierda, a “Credentials” (Credenciales). Fíjese en esta captura de pantalla:

Cree cuatro credenciales para GitHub, Docker Hub, AWS y Azure. Si tiene pensado utilizar AWS, no hace falta que indique sus credenciales para Azure, y al revés. Acuérdese de configurar su ACCESS KEY (Clave de acceso) como nombre de usuario y su SECRET ACCESS KEY (Clave de acceso secreta) como contraseña para las credenciales de AWS.

Por último, antes de pasar a la canalización, tenemos que poner dos imágenes de CLI Docker a disposición de la máquina de Jenkins. Jenkins utilizará imágenes de Docker con AWS y Azure CLI para ejecutar comandos de CLI en los distintos servicios. Es una forma sencilla de utilizar estas CLI sin tener que instalarlas en la máquina. Estas son las imágenes que vamos a utilizar:

  • vfarcic/aws-cli (docker pull vfarcic/aws-cli:latest; docker tag vfarcic/aws-cli:latest aws-cli)
  • microsoft/azure-cli:latest (docker pull microsoft/azure-cli:latest; docker tag microsoft/azure-cli:latest azure-cli)

Por supuesto, puede utilizar otras imágenes si así lo desea.

Estas imágenes de Docker tienen que extraerse en la máquina de Jenkins y así en esta canalización podremos utilizar el complemento de Jenkins Docker para usar la función “withDockerContainer(‘image’)” para ejecutar los comandos de CLI que verá más adelante. Tiene más información acerca de la ejecución de etapas de compilación en un contenedor de Docker en esta documentación de Jenkins.

Una vez satisfechos todos los requisitos previos, vamos a crear un "New item" (Elemento nuevo) en la página principal y elegiremos "Pipeline" (Canalización).

Una vez creado, ya puede configurar su canalización. Aquí es donde definirá su script de canalización (lenguaje Groovy).

Encontrará el script aquí.

Examinemos este archivo e iré destacando las etapas más importantes.

En la parte superior del archivo puede configurar sus propios ajustes a través de variables de entorno. Tiene un ejemplo que puede seguir con un proyecto llamado “TALEND_JOB_PIPELINE” y una tarea “test”. El nombre Git de proyecto debería coincidir con el de su repositorio GitHub. Por ese motivo aparece el nombre en mayúscula. Fíjese que en este script usamos el nombre de tarea como el nombre de imagen de Docker, de modo que no puede utilizar guiones bajos en el nombre de su tarea. Si quiere utilizar un guión bajo, tendrá que definir otro nombre sin guión para su imagen de Docker. Puede invalidar el nombre de imagen de Docker con la opción -Dtalend.docker.name=NAME en su comando de Maven. Deben configurarse las siguientes variables de entorno:

env.PROJECT_GIT_NAME = 'TALEND_JOB_PIPELINE'
env.PROJECT_NAME = env.PROJECT_GIT_NAME.toLowerCase()
env.JOB = 'test'
env.VERSION = '0.1'
env.GIT_URL = 'https://github.com/tgourdel/talend-pipeline-job.git'
env.TYPE = "" // if big data = _mr
env.DOCKERHUB_USER = "talendinc"

En este archivo, todos los pasos vienen definidos por una "stage" (etapa). Las dos primeras etapas sirven para extraer la versión más reciente de la tarea mediante un complemento de Git.

Luego viene la compilación de la tarea en sí. Como ve, estamos utilizando el complemento de Maven. Los ajustes están en el archivo Config de Jenkins. Este es el archivo que añadimos antes a la configuración de Jenkins con el ID maven-file.

En las etapas “Build, Test and Publish to Nexus” (Crear, probar y publicar en Nexus) y “Package Jobs as Container” (Empaquetar tareas como contenedor), la línea que debe modificarse es:

-Dproduct.path=/cmdline -DgenerationType=local -DaltDeploymentRepository=snapshots::default::http://nexus:8081/repository/snapshots/ -Xms1024m -Xmx3096m

Aquí tendrá que indicar su propia ruta al directorio de CommandLine (relativa al servidor de Jenkins) y la URL de su Nexus.

Una vez compilada la tarea en una imagen de Docker, vamos a enviar la imagen al registro de Docker Hub. Para este paso y el siguiente utilizaremos las CLI para emplear los distintos elementos de terceros. Como el daemon de Docker debería estar ejecutándose en la máquina de Jenkins, puede usar directamente la CLI de Docker. Utilizaremos la función withCredentials() para obtener su nombre de usuario y contraseña para Docker Hub:

stage ('Push to a Registry') {
            withCredentials([usernamePassword(credentialsId: 'dockerhub', passwordVariable: 'dockerhubPassword', usernameVariable: 'dockerhubUser')]) {
               sh 'docker tag $PROJECT_NAME/$JOB:$VERSION $DOCKERHUB_USER/$JOB:$VERSION'
               sh "docker login -u ${env.dockerhubUser} -p ${env.dockerhubPassword}"
               sh "docker push $DOCKERHUB_USER/$JOB:$VERSION"
           }
}

La etapa “Deployment environment” (Entorno de desarrollo) no es otra cosa que una interacción con el usuario mientras se ejecuta la canalización. Le pregunta si desea desplegar su contenedor en AWS Fargate o Azure ACI. Puede eliminar este paso si prefiere una compilación continua hasta el despliegue. Incluimos este paso como demostración.

Las próximas dos etapas son el despliegue en AWS Fargate o Azure ACI en sí. En cada una de las dos etapas tendrá que modificar sus propios ajustes. Por ejemplo, en la etapa de despliegue a AWS Fargate tendrá que modificar esta línea:

aws ecs run-task --cluster TalendDeployedPipeline --task-definition TalendContainerizedJob --network-configuration awsvpcConfiguration={subnets=[subnet-6b30d745],securityGroups=[],assignPublicIp=ENABLED} --launch-type FARGATE

Deberá modificar el nombre de su clúster de Fargate y la definición de su tarea. Sepa que tendrá que crearlos en su consola de AWS. Puede consultar la documentación para realizar esta operación. En el momento de redacción de este texto, AWS Fargate tan solo está disponible en la región del Norte de Virginia, pero se incluirán otras regiones en el futuro. El contenedor que tendrá definido en su definición de tarea es el que se creará en su cuenta de Docker Hub con el nombre de su tarea como nombre de imagen. Por ejemplo, con la configuración por defecto del script de canalización sería talendinc/test:0.1.

p>Lo mismo podemos decir de Azure ACI, en el que deberá indicar su propio grupo de recursos e instancia de contenedor.

4) Configure CommandLine

En realidad, Maven utilizará CommandLine para crear su tarea. CommandLine puede emplearse en dos modalidades: script y servidor. Aquí vamos a utilizar CommandLine como servidor. En primer lugar tendrá que indicar el área de trabajo de su CommandLine (que en nuestro caso será el área de trabajo de Jenkins). Modifique el archivo command-line.sh como sigue con su propia ruta al área de trabajo de Jenkins (dependerá del nombre de canalización que haya elegido en el paso anterior):

./Talend-Studio-linux-gtk-x86_64 -nosplash -application org.talend.commandline.CommandLine -consoleLog -data $WORKSPACE startServer -p 8002

Su instancia de Jenkins especificará la variable $WORKSPACE y será sustituida por el área de trabajo de Jenkins de su canalización. Gracias a esta variable de entorno que facilita Jenkins, podrá ejecutar distintas canalizaciones con distintas áreas de trabajo de Jenkins y CommandLine se adaptará a su propia área de trabajo según convenga.

Como verá en las Opciones de Maven del script de Groovy, el parámetro -Dgeneration.type=local está especificado. Esto significa que CommandLine se inicializará para realizar la compilación y luego se desactivará. Con esta opción evitaremos dejar CommandLine ejecutándose indefinidamente y usaremos la variable $WORKSPACE para cambiar el área de trabajo según la canalización que ejecutemos.

Por último debemos modificar el archivo /configuration/maven_user_settings.xml. Para ello copie y pegue este archivo con la URL y la información de acceso de su propio Nexus.

5) Ejecute la canalización

Una vez realizada toda la configuración necesaria, ya puede ejecutar su canalización. Para ello vaya a la vista Open Blue Ocean y haga clic en el botón “run” (Ejecutar). Activará la canalización y debería poder ver el progreso de la misma:

Captura de pantalla de Pipeline de Jenkins para crear tareas de Talend en contenedores de Docker

Pipeline de Jenkins crea tareas de Talend en contenedores de Docker

La canalización, a efectos de este ejercicio, le preguntará dónde quiere desplegar su contenedor. Elija AWS Fargate o Azure ACI. Tomemos el ejemplo de Fargate.

Una vez realizado el despliegue, su clúster de Fargate debería tener una tarea pendiente:

Si entra al detalle de su tarea una vez ejecutada, debería poder acceder a los registros de su tarea:

Ahora puede ejecutar su tarea de integración de Talend empaquetada en un contenedor de Docker en cualquier lugar, como por ejemplo:

  • AWS Fargate
  • Azure ACI
  • Google Container Engine
  • Kubernetes u OpenShift
  • Y muchos más...

Gracias a las capacidades de CI/CD de Talend puede automatizar todo el proceso, desde la compilación a la ejecución de sus tareas.

Si desea ser agnóstico en cuanto a su tecnología cloud y aprovechar la portabilidad de los contenedores, este ejemplo muestra cómo puede utilizar una herramienta de CI/CD (Jenkins, en nuestro caso) para automatizar la compilación y ejecutar en distintos servicios de contenedores cloud. Esto tan solo es un ejemplo entre muchos, pero poder crear sus tareas como contenedores le abre las puertas a todo un nuevo mundo para sus tareas de integración. Según cuál sea su caso práctico, podría pasar que invirtiera mucho menos dinero gracias a estos nuevos servicios serverless (como Fargate o Azure ACI). También podría dedicar menos tiempo a configurar su infraestructura y centrarse en diseñas sus tareas.

Join The Conversation

0 Comments

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *