Diferencias entre Tekton y Jenkins

Has alguna vez te has preguntado cuáles son las diferencias entre Jenkins y Tekton? Hola, soy Christine y hoy les voy a hablar sobre las diferencias entre estas dos herramientas de CI/CD que tienen el mismo objetivo pero lo logran de maneras diferentes. Empecemos por lo básico, para entender Jenkins y Tekton, primero necesitamos comprender la Integración Continua y la Entrega Continua, o CI/CD, en resumen. CI/CD es el proceso de automatizar el desarrollo de software a través de pruebas, compilación y implementación de aplicaciones. Jenkins y Tekton son dos herramientas de CI/CD diseñadas para crear lo que se conoce como «pipelines» de CI/CD. Para obtener más información sobre Integración Continua y Entrega Continua, pueden ver los videos que se encuentran en la descripción a continuación. Pero hoy, solo les hablaré de las similitudes y diferencias entre las dos herramientas.

Tekton

Para entender Tekton, primero debemos comprender Kubernetes. Kubernetes es una plataforma de orquestación de contenedores diseñada para automatizar la implementación, administración y escalado de aplicaciones. Tekton se ejecuta en Kubernetes, lo que le permite trabajar con tus procesos de CI/CD en el mismo clúster que tus aplicaciones. Esto te permite escalar fácilmente tus cargas de trabajo simplemente agregando nodos a tu clúster. Tekton viene con un conjunto de recursos personalizados de Kubernetes que te brindan los bloques de construcción necesarios para configurar y administrar fácilmente tus pipelines. Puedes automatizar Tekton tanto a través de la línea de comandos como a través de la interfaz de usuario en el navegador.

Arquitectura

Para explicar mejor los pipelines de CI/CD, daré un ejemplo sencillo. Imagina que tienes una aplicación que deseas implementar en producción y quieres automatizar este proceso utilizando Tekton. Para simplificarlo aún más, vamos a realizar las siguientes operaciones: prueba, compilación e implementación. Cada una de estas operaciones se convierte en un paso, que es el bloque de construcción más pequeño de Tekton. Los pasos son donde puedes especificar tus comandos, argumentos e imágenes a ejecutar en tus procesos. Una vez que hayas creado tus pasos, puedes organizarlos en lo que se llama tareas. Una tarea puede tener un solo paso o múltiples pasos, dependiendo del orden y la secuencia en que los coloques en tus archivos. Una tarea se ejecuta en un pod, que es una única instancia de un proceso en ejecución en tu clúster de Kubernetes. Pero hoy no vamos a entrar en detalle sobre pods o clústeres. Si deseas profundizar más, nuevamente te recomiendo ver los videos en la descripción a continuación. Lo genial de las tareas es que una vez definidas, las puedes reutilizar en cualquier pipeline que desees. Por ejemplo, si tienes otro pipeline dedicado exclusivamente a la prueba de aplicaciones y quieres utilizar la misma tarea de prueba porque tiene exactamente lo que estás buscando, simplemente tendrías que hacer referencia al nombre de la tarea en tu otro pipeline. No es necesario volver a escribir nada o duplicarlo. Eso nos lleva al siguiente tema, que son los pipelines.

Pipelines

Los pipelines son una forma de organizar aún más tus tareas controlando su ejecución. Los pipelines te permiten organizar tareas de forma concurrente o secuencial, dependiendo del orden en que las coloques. Tanto pipelines como tareas son recursos personalizados de Tekton que te permiten controlar lo que se ingresa y lo que se produce a partir de las tareas. Por ejemplo, una entrada sería el código fuente de tu aplicación que se está ejecutando a través del pipeline, y un ejemplo de salida sería la imagen producida por tu tarea de compilación. Estas entradas y salidas se llaman recursos de pipeline, y puedes definirlos en tus tareas o pipelines, o puedes colocarlos en su propio archivo, dependiendo de lo organizado que quieras ser. Los pipelines organizan la ejecución de las tareas, las tareas organizan la ejecución de los pasos, y los pasos ejecutan lo que estás intentando hacer.

¿Cómo podemos automatizar aún más este proceso? ¿Qué activa nuestros pipelines? Se trata de un concepto llamado «pipeline run». Un «run» dispara nuestro pipeline, y puedes declararlo en la plantilla de desencadenador. Los desencadenadores de Tekton te permiten detectar y extraer información de eventos de varias fuentes que te permiten ejecutar tus tareas y pipelines. ¿Qué significa exactamente eso? Un ejemplo de un evento sería, supongamos que queremos activar este pipeline cada vez que uno de nuestros desarrolladores compromete cambios en el código. Hay un concepto llamado «event listener» que escucha eventos específicos, en este caso, estará escuchando cuando uno de nuestros desarrolladores haga un commit. Una vez que eso sucede, lo detectará y disparará nuestro pipeline.

Como puedes ver, el proceso de Tekton es muy estructurado. Para visualizarlo aún más, cada uno de estos conceptos es solo un archivo: el «event listener», la plantilla de desencadenador, el pipeline y cada tarea individual son su propio archivo. Esto es una de las características más importantes de Tekton, es orientado a objetos, modular y lo hace muy fácil de reutilizar, personalizar y organizar. Es muy flexible.

Almacenamiento

¿Cómo o dónde almacena Tekton sus datos de CI/CD? La respuesta a eso es «workspaces». Los workspaces son como un sistema de archivos muy grande. Permiten que las tareas declaren una parte de ese sistema de archivos para usarlo como almacenamiento. ¿Qué estamos almacenando? Las entradas y salidas de todo este proceso. Yendo un poco más allá, hay un concepto llamado «persistent volume claim» (PVC) que te permite definir específicamente la ubicación de ese volumen de almacenamiento y permite que las tareas los compartan entre los procesos. Esto se puede definir típicamente en la plantilla de desencadenamiento. Otra cosa que también puedes definir en nuestra plantilla de desencadenador son las «service accounts». Las cuentas de servicio manejan las credenciales o la autenticación con Tekton. Por ejemplo, si tienes contraseñas, tokens o claves SSH y deseas asegurarte de que todo esté seguro antes de ejecutar tus pasos, Tekton ejecuta esta inicialización de credenciales en cada pod antes de ejecutar los pasos, lo que mantiene todo el proceso seguro, lo cual es muy importante.

Jenkins

Ahora que tenemos una buena comprensión de Tekton, pasemos a Jenkins. La mayor diferencia entre las dos es que mientras Tekton se ejecuta en Kubernetes, Jenkins se ejecuta en sus propios servidores o máquinas virtuales. Jenkins está basado exclusivamente en Java. Podrías preguntarte cómo puede Jenkins competir con Tekton si solo admite características escritas en Java. La respuesta a eso son los «plugins» de Jenkins. Los plugins de Jenkins amplían la capacidad de proyectos escritos en otros lenguajes además de Java. Por ejemplo, si quieres usar un sistema de control de versiones como GitHub, necesitarías instalar el plugin de GitHub en tu máquina Jenkins para poder trabajar con él. Es muy fácil de instalar, hay más de mil plugins diferentes de Jenkins y los administras e instalas a través de lo que se llama la UI (Interfaz de Usuario) de Jenkins. Al igual que Tekton, puedes trabajar con Jenkins a través de la interfaz de usuario o la línea de comandos, pero en su mayoría, las personas usan la interfaz de usuario, y es allí donde puedes administrar tus pipelines.

La estructura de archivos

En cuanto a la estructura de archivos, es donde difieren Jenkins y Tekton. Jenkins almacena sus configuraciones en lo que se llama un «Jenkinsfile», que es un solo archivo grande. Siguiendo el mismo ejemplo que usé anteriormente, tienes una aplicación que deseas implementar en producción y deseas automatizar este proceso utilizando Jenkins. Lo que harías es crear un «Jenkinsfile» y declarar tu pipeline de Jenkins. Quieres realizar pruebas para asegurarte de que no haya errores o bugs, luego quieres compilarlo y finalmente implementarlo. En Jenkins, estos se llaman «stages», mientras que en Tekton se llaman «tasks». Y dentro de cada uno de estos stages, tendrás tus steps, que es realmente lo importante de lo que estás tratando de hacer. Aquí es donde tienes tus scripts, comandos, argumentos, parámetros, todo está en los steps. Como puedes ver, al mirar la estructura, ya es un poco diferente, tenemos un pipeline de tres partes definido en un solo archivo, mientras que aquí tenemos unos seis archivos diferentes. El «Jenkinsfile» te permite configurar no solo tus pipelines, sino que puedes hacer muchas otras cosas también. Por ejemplo, puedes definir funciones como exportar archivos o funciones de seguridad que deseas ejecutar en todo el proceso. Hay métodos para la autenticación, por ejemplo, hay un método llamado «credentials» donde puedes definir tus credenciales aquí y esto se ocupa de los secretos y la autenticación para iniciar el pipeline, similar al «event listener» y Tekton. Hay un concepto aquí llamado «web hooks», que es muy similar, lo programarías para escuchar eventos específicos. Por ejemplo, cada vez que un desarrollador realiza cambios en el código o crea una solicitud de extracción, lo definirías de la siguiente manera y una vez que ocurre ese evento, se dispararía tu pipeline.

En cuanto al almacenamiento, conceptualmente, Jenkins y Tekton son bastante similares. Ambos utilizan sistemas de archivos, solo que Jenkins organiza sus directorios un poco diferente. Jenkins tiene un directorio principal llamado «Jenkins home» y dentro de este directorio tendrás muchos otros directorios donde almacenarás tus registros de compilación, configuraciones, artefactos, por ejemplo, hay un directorio de plugins donde guardarás tus plugins, o puedes tener un directorio de secretos donde guardarás tus secretos, pero lo más importante es, en mi opinión, el directorio de workspace es donde trabajarás más. El directorio de workspace es tu directorio de trabajo, donde ejecutas tus pipelines. Cada vez que ejecutas un pipeline, se generan algunos artefactos, que son como archivos o imágenes, algo así como las salidas en Tekton, y tú quieres usarlos en tu próxima ejecución o próxima etapa, así que debes guardarlos en tu workspace para que no se borren por completo con la siguiente compilación. Lo haces almacenándolos en tu workspace o archivándolos en otro lugar.

Ahora que tenemos una buena comprensión de ambas herramientas, podemos ver cómo, conceptualmente, Jenkins y Tekton son muy similares. Al final del día, simplemente intentan automatizar el ciclo de vida del desarrollo de software. Intentan facilitar la vida del desarrollador eliminando todos los pasos manuales tanto como sea posible. Veamos un resumen de lo que acabo de explicar:

Preguntas frecuentes (FAQ)

A continuación, responderemos algunas de las preguntas frecuentes que suelen surgir sobre Jenkins y Tekton:

¿Puedo utilizar Plugins en Tekton?
No, Tekton no utiliza plugins de la misma manera que Jenkins. Sin embargo, Tekton ofrece una amplia gama de recursos personalizados de Kubernetes que permiten la flexibilidad y la personalización necesarias para tus pipelines de CI/CD.

¿Es necesario tener experiencia en programación para utilizar Jenkins o Tekton?
Si bien tener experiencia en programación puede ser útil, no es estrictamente necesario para utilizar Jenkins o Tekton. Ambas herramientas ofrecen interfaces visuales y pueden ser utilizadas por personas que no tienen un conocimiento profundo de programación. Sin embargo, tener conocimientos básicos de scripting o programación puede ayudarte a aprovechar al máximo estas herramientas.

¿Cuál es la mejor opción entre Jenkins y Tekton?
No hay una respuesta definitiva a esta pregunta, ya que la elección entre Jenkins y Tekton depende de tus necesidades y preferencias específicas. Jenkins es una herramienta más establecida y ampliamente utilizada, mientras que Tekton es una herramienta más moderna y centrada en Kubernetes. Si ya estás utilizando Kubernetes en tu infraestructura y valoras la integración nativa con esta plataforma, entonces Tekton puede ser la mejor opción para ti. Sin embargo, si ya tienes una infraestructura basada en Jenkins y estás satisfecho con su rendimiento, es posible que no tengas que cambiar a Tekton. La elección debe basarse en una evaluación exhaustiva de tus requisitos y capacidades existentes.

Espero que esta explicación te haya sido útil. Si tienes alguna otra pregunta, no dudes en hacérnosla saber en los comentarios. Nos despedimos y te invitamos a leer más artículos relacionados en nuestro blog. ¡Hasta luego!

Mila y César

Hola, somos Mila Jiménez y César Sánchez. Dos apasionados de la ciberseguridad con muchos años de experiencia. Hemos trabajado en muchas empresas del mundo TI y ahora nos apetece compartir nuestro conocimiento con cualquiera que lo necesite.

¡Si te gusta nuestro contenido puedes invitarnos a un café AQUÍ!