Tekton vs. Jenkins: ¿cuál conviene para los canales de CI/CD en Red Hat OpenShift?

Tekton surgió del proyecto Knative y, posteriormente, recibió el respaldo de Red Hat como el futuro de todos los canales en Red Hat OpenShift. En 2018, cuando se comenzó a hablar sobre Tekton, mi primera reacción fue preguntarme: "¿Qué problema queremos solucionar con esto?". Después de todo, conozco Jenkins y estoy conforme con él, así que ¿cuál sería la ventaja de enfrentar la curva de aprendizaje de una nueva tecnología cuando lo que tengo ahora funciona bien?

Gartner reconoció a Red Hat como empresa líder en el informe de 2023 Gartner® Magic Quadrant™

Red Hat ocupó el puesto más alto en el Magic Quadrant de Gartner de 2023 para la gestión de contenedores no solo por su capacidad de ejecución, sino también por la integridad de su visión.

Lea el informe

Cada vez que preguntaba por qué Tekton es mejor que Jenkins, la respuesta solía ser que Tekton se desarrolla en la nube, y generalmente luego había silencio o se cambiaba de tema. Así que decidí buscar una definición clara de "desarrollo en la nube", con la intención de finalmente descubrir lo que significa este concepto. 

En 2018, la fundación Cloud Native Computing Foundation (CNCF) publicó esta definición: "Las tecnologías desarrolladas en la nube permiten que las empresas diseñen y ejecuten aplicaciones adaptables en entornos modernos y dinámicos, como las nubes públicas, privadas e híbridas".

No encontré una explicación clara allí. Además, tengo un gran apego irracional a las herramientas que utilizo desde hace años y funcionan bien. Para poder renunciar al viejo confiable Jenkins, necesitaba estar mucho más convencido de que el césped realmente era más verde en la casa del vecino: la oferta de Tekton debía superar con creces lo que Jenkins ya me aportaba. 

Finalmente, mi conclusión fue que Tekton se integra mejor a los entornos de OpenShift y Kubernetes y tiene potencial para nuevas oportunidades, lo cual no creo que pueda ofrecer Jenkins.

Si tiene estos mismos interrogantes, espero que encuentre las respuestas que busca en el resto del artículo.

Mi experiencia con Jenkins

Seamos sinceros: Jenkins es excelente pero antiguo. Apareció alrededor del año 2005 y, desde entonces, no ha cambiado mucho. Su mayor ventaja es la gran selección de complementos que ofrece, que le permite utilizar fácilmente casi cualquier cosa. Sin embargo, también es una debilidad, dado que esos complementos tienen un ciclo de vida indeterminado del sistema de software. Si ocurre un problema, por lo general tiene que ingeniárselas para poder seguir trabajando. 

Jenkins está basado en Java y consume mucha memoria y procesador, ya que está en constante funcionamiento, por lo que los costos agregados que conllevan los recursos informáticos podrían representar un problema.

Antes de que comenzaran a utilizarse los contenedores, Jenkins era el servidor "gigante" que utilizaban todos los equipos de desarrollo y, en consecuencia, esto ocasionaba un bloqueo. Como tenía dificultades para procesar la gran carga de trabajo que recibía, solía decirse que Jenkins se había metido en un enorme embrollo, así que debía reiniciarse. Entonces, había que volver a comenzar desde cero. 

Ahora, gracias a la llegada de los contenedores, cada equipo puede tener su propio servidor Jenkins y configurarlo como lo desee. Pero esto ha dado lugar a otro problema: la enorme expansión de Jenkins. Todos esos servidores están en funcionamiento con poca carga casi todo el tiempo, pero no dejan de gastar recursos. Además, cada equipo propaga muchos tipos distintos de código de canal.

Por lo tanto, sería ideal contar con una solución que ocupe poco espacio, pueda desconcentrarse en cada equipo y persiga firmemente la igualdad de condiciones en todos los canales. Luego volveremos a este tema, así que no se olvide de lo que hablamos.

Acerca de los modelos de secuenciación de los procesos

En los sistemas de software, hay dos maneras aceptadas de organizar la secuencia de las llamadas de servicios o las etapas de procesos para lograr un resultado.

El primer patrón es el tipo denominado coordinación, que está tipificado por el patrón Process Manager (administrador de procesos).

Fuente: este archivo está sujeto a la licencia Creative Commons Attribution-Share Alike 4.0 International.

Process Manager efectivamente se comporta como el director que coordina una orquesta, lo cual deriva en la denominación "coordinación".

Un ejemplo de este patrón es Jenkins, que actúa como administrador de procesos, es decir, como el director. Debe codificar el proceso con el archivo JenkinsFile y definir el proceso. Todo lo que Jenkins envía a través de sus distintas interfaces basadas en complementos regresa al administrador como tarea completada, por lo que puede comenzar la siguiente etapa del proceso. En la mayoría de los casos, esto parece realizarse de forma sincrónica. 

El patrón Process Manager se describe como "inherentemente frágil" en el libro Refactoring to Patterns (Kerievsky, 2004), ya que si alguien decidiera reiniciar el administrador de procesos, se dañaría todo lo que se encontrara en ejecución. Por lo tanto, está comprobado que el diseño no funciona muy bien con procesos de ejecución prolongada. 

Ahora, demos un vistazo al segundo patrón de secuenciación. En la siguiente fotografía, podemos ver una multitud haciendo la ola en un estadio.

Fuente: este archivo está sujeto a la licencia Creative Commons Attribution-Share Alike 2.0 Generic.

Cada persona del público sabe en cuándo debe ponerse de pie y levantar la mano; nadie da indicaciones. En un estadio grande, ocurren demasiadas cosas al mismo tiempo como para que la coordinación se haga cargo de ellas. Esto es un ejemplo del siguiente tipo de patrón de secuenciación, denominado coreografía.

La coordinación es la primera opción de diseño para la mayoría de los desarrolladores, pero la coreografía, a veces relegada, suele ser la opción de diseño o reescritura mejorada ideal para funcionar con eventos.

Esto es muy importante en el mundo de los microservicios, donde podría ser necesario organizar la secuencia de una gran cantidad de servicios. Al mismo tiempo, en un contexto con actividades de canales de duración prolongada de tipo stand-up (activación), test (prueba) y tear-down (eliminación), el patrón de coreografía es un modelo mucho más sólido y práctico.

Los canales de Tekton se diseñan a partir de contenedores diferentes que se secuencian a través de eventos internos de Kubernetes en el servidor de la API de Kubernetes. Estos son un ejemplo del tipo de secuenciación de coreografía basada en eventos. No hay un único administrador de procesos que los bloquee o reinicie, acapare los recursos o genere fallas. Tekton permitirá que cada pod cree las instancias en el momento adecuado para ocuparse de la etapa del proceso del canal que le corresponda. Cuando finalice, se apagará, y los recursos quedarán disponibles para otra tarea.

El ideal del bajo acoplamiento y la cadencia con la reutilización

Tekton también cuenta con lo que se describe en la arquitectura de software como bajo acoplamiento. Observe la siguiente imagen del tren de juguete:

"Toy train for wood tracks" de Ultra-lab está sujeto a la licencia CC BY-SA 2.0. 

La conexión entre la locomotora y los vagones es magnética, por lo que el niño puede usar la locomotora sola o con todos los vagones y, obviamente, cualquier opción intermedia. 

También puede cambiar el orden de los vagones; por ejemplo, se pueden invertir el verde claro y el amarillo si así lo desea. Si tuviera un segundo tren similar, todos los vagones de un tren podrían sumarse al otro para formar un "supertren".

Este ejemplo demuestra el motivo por el cual el "bajo acoplamiento" es la arquitectura óptima para el diseño de software. Por naturaleza, promueve la reutilización, que es un principio esencial de Tekton. Una vez que se diseñan los elementos, se pueden compartir entre distintos proyectos con mucha facilidad.

Por otro lado, debemos hablar de lo contrario al bajo acoplamiento, es decir, alto acoplamiento. Pasemos a otro juguete:

"09506_Pull-Along Caterpillar" de PINTOY^® está sujeto a la licencia CC BY-SA 2.0. 

La oruga también tiene varias secciones, pero son fijas, así que no se puede cambiar el orden. No puede quitar partes ni agregar otras para formar una superoruga. Si el niño solo quisiera tres segmentos en su oruga, tendría que convencer a sus padres de que compraran una oruga diferente.

En este ejemplo, podemos ver que el alto acoplamiento no promueve la reutilización, sino que en realidad obliga a recurrir a la duplicación.

Sí, reconozco que se puede aplicar el bajo acoplamiento en los canales de Jenkins y que se puede compartir el código entre proyectos. Sin embargo, no siempre es posible, ya que depende en gran medida del diseño de los canales. 

La alternativa es usar un canal de Jenkins para todos los proyectos. Pero esto tiene limitaciones y, muy pronto, se encontrará con un proyecto con necesidades que no se pueden satisfacer usando el enfoque único. Es decir, no se cumple la integridad del diseño de canal único. 

Tekton es declarativo por naturaleza, y sus canales se parecen mucho al ejemplo del tren de madera. Superficialmente, puede representar al canal como la locomotora. El canal contiene un conjunto de tareas que puede identificar como los vagones. Distintos canales pueden incluir las mismas tareas, pero reparametrizadas y reutilizadas. Por lo tanto, las tareas de bajo acoplamiento y reparametrizables se encadenan para formar canales. Tekton favorece considerablemente el bajo acoplamiento, lo cual facilita la posibilidad de reutilizar las tareas. Es decir, se puede tomar, incorporar y utilizar el trabajo de un proyecto en otro.

Tekton también consiste simplemente en más definiciones de objetos de Kubernetes, por lo cual se adaptan con mucha facilidad a un enfoque de todo como código y GitOps. El código del canal podría aplicarse al clúster junto con las configuraciones de otros clústeres y espacios de nombres. 

La importancia de todo esto

Es importante porque la noción de los entornos formales de desarrollo, pruebas y tipo de UAT es un concepto relativamente antiguo. Estos entornos fijos se remontan a la época en la que había que comprar servidores físicos y luego designarles su uso. 

Así solía hacerse. En el mundo de OpenShift y todo como código, de la oposición entre servidores únicos e indispensables y elementos numerosos y remplazables, no hay ninguna razón por la cual no se puedan crear instancias de estos entornos de forma dinámica con canales y pruebas y luego ejecutarlas. Una vez completadas, pueden eliminarse nuevamente en su totalidad para dar lugar a otras pruebas y demás procesos. 

Definitivamente, este no es el caso de la mayoría de las empresas. Quizás una de las razones sea que las herramientas que hemos tenido disponibles hasta el día de hoy no sean las más adecuadas.

Conclusión

El mundo todavía trata de ponerse al día con todas las oportunidades que nos ofrecen las tecnologías como OpenShift, las cuales no se podían concretar en el pasado. 

Las oportunidades de automatizar las pruebas para ofrecer un mejor software son infinitas, ya que los recursos informáticos pasan inactivos la mayor parte de las noches como mínimo. He estado pensando en estas ideas durante mucho tiempo, pero nunca creí que Jenkins fuera la herramienta adecuada para este tipo de trabajo. La primera vez que reflexioné sobre Tekton con la mente abierta, descubrí de inmediato que era la opción perfecta. 

Tekton se integra desde cero al modelo de seguridad y la API de Kubernetes, y favorece considerablemente el bajo acoplamiento y la reutilización. Se basa en eventos y sigue el modelo de coreografía, por lo que es ideal para controlar el proceso de prueba de larga duración. Los elementos de los canales son simplemente recursos de Kubernetes adicionales (definiciones de pods, cuentas de servicio, secretos, etc.), que pueden prestarse fácilmente a la tecnología de todo como código, a la par del resto del ecosistema de Kubernetes.

Cada equipo de aplicaciones puede tener su propio código de canal, que, cuando no se esté ejecutando, se reducirá a cero, para que aproveche las ventajas del servidor Jenkins distribuido sin todas las cargas inactivas. Apache Maven tuvo tanto éxito en muy poco tiempo porque supuso un punto de inflexión: impuso una forma reglamentada de diseñar un proyecto Java, por lo cual los desarrolladores podían resolver la configuración de compilaciones entre proyectos con facilidad. Tekton hace lo mismo con los canales y simplifica la reutilización de tareas para que sea intuitiva.

Cruise Control fue la primera herramienta de integración continua (CI) a principios de la década de 2000, pero, en mi experiencia, era difícil de usar. En esa época, parecía que Jenkins daba un salto de calidad radical en comparación con lo que ya existía. En el mundo de OpenShift y Kubernetes, estoy convencido de que Tekton es el futuro de la tecnología de canales.

Más información

• CI/CD en la nube con Red Hat OpenShift