Tekton e Jenkins a confronto: qual è l'opzione migliore per le pipeline CI/CD su Red Hat OpenShift?

Tekton è nato dal progetto Knative ed è stato supportato da Red Hat, che lo ha riconosciuto come il futuro di tutti gli aspetti relativi alla pipeline di Red Hat OpenShift. Nel 2018, quando ho sentito parlare per la prima volta di Tekton, la mia prima reazione è stata: "Quale problema dovrebbe risolvere?" Dopotutto, conosco Jenkins e mi piace come progetto, quindi perché dovrei imparare a utilizzare una nuova tecnologia quando quella che ho già funziona bene?

Red Hat nominata Leader nel Gartner® Magic Quadrant™ 2023

Grazie alla completezza della sua visione e alla sua capacità di esecuzione, Red Hat è stata nominata tra le aziende leader del Magic Quadrant™ del 2023 per la gestione dei container.

Leggi il report

Ogni volta che ponevo la domanda: "Perché Tekton è meglio di Jenkins?", la risposta più comune era: "Tekton è cloud native", in genere seguita dal silenzio o da un cambio di discorso molto rapido. Quindi ho cercato una definizione chiara di "cloud native", aspettandomi che arrivasse un'illuminazione. 

Nel 2018 la Cloud Native Computing Foundation (CNCF) ha pubblicato questa definizione: "Le tecnologie cloud native permettono alle organizzazioni di sviluppare ed eseguire applicazioni scalabili in ambienti moderni e dinamici come cloud pubblici, privati e ibridi".

Una spiegazione che non è particolarmente illuminante. Per di più, io ho anche un attaccamento irrazionale nei confronti degli strumenti che utilizzo da anni e che funzionano bene. Per convincermi a dare il benservito al buon vecchio Jenkins, dovevo essere sicuro che il gioco valesse davvero la candela. Tekton doveva offrirmi molto più di quello che già avevo per spingermi ad abbandonare Jenkins. 

Alla fine sono arrivato alla conclusione che Tekton si integra meglio nell'ambito OpenShift/k8s e ha il potenziale di offrire nuove opportunità che non credo siano disponibili con Jenkins.

Il resto dell'articolo illustrerà più nel dettaglio il mio ragionamento. Se anche tu ti stai ponendo queste domande, spero che possa trovare alcune delle risposte che cerchi.

La mia esperienza con Jenkins

Bisogna essere onesti: per quanto sia un'istituzione, Jenkins è vecchio. Ha fatto la sua comparsa intorno al 2005 e da allora non è cambiato molto. Il suo principale punto di forza è l'ampia selezione di plugin che permettono di interfacciarsi facilmente con qualsiasi strumento. Ma questo è anche un punto debole, perché questi plugin hanno un ciclo di vita del software indefinito. Se si verifica un problema, in genere è necessario aggirarlo. 

Jenkins è basato su Java; è risaputo che consuma molta memoria e risorse del processore, che è costantemente in esecuzione e, dati i costi aggregati delle risorse di elaborazione, questo potrebbe diventare un problema.

Quando non esistevano ancora i container, non era strano avere un Jenkins "grande", vale a dire che l'intero reparto di sviluppo utilizzava un singolo server Jenkins, che si trasformava in un collo di bottiglia. Dal momento che Jenkins aveva difficoltà a elaborare il grande carico che gravava su di esso, spesso capitava che andasse in sovraccarico e dovesse essere riavviato, tornando al punto di partenza. 

Poi sono arrivati i container: ora ogni team può disporre di un server Jenkins e configurarlo a proprio piacimento. Ma questo ha causato un altro problema: la proliferazione incontrollata, con tutti quei server Jenkins che per la maggior parte del tempo non fanno granché, ma consumano molta energia e risorse. Per non parlare dei numerosi e diversi tipi di codice delle pipeline diffusi da ciascun team.

Quindi non sarebbe male disporre di uno strumento con un impatto molto ridotto, che possa essere decentralizzato per ciascun team ma che allo stesso tempo incoraggi ad avere pipeline simili tra loro. Tienilo a mente, perché torneremo sull'argomento più avanti.

I modelli di sequenziamento dei processi

In un sistema software serve un modo per organizzare la sequenza delle chiamate di servizio e/o delle fasi del processo per ottenere un risultato, e ci sono due modi conosciuti per farlo.

Il primo è l'orchestrazione, caratterizzata dal modello Process Manager.

Fonte: questo file è concesso in licenza da Creative Commons Attribution-Share Alike 4.0 International license.

Il Process Manager si comporta effettivamente come un direttore d'orchestra, ed è proprio a questo che si deve il nome di orchestrazione.

Jenkins è un esempio di questo modello: proprio come un direttore d'orchestra, gestisce i processi. Codificando il processo attraverso JenkinsFile, definisci il processo. Tutto ciò che viene trasmesso da Jenkins tramite le sue numerose interfacce basate su plugin viene rimandato al Process Manager dopo il completamento. A questo punto, può iniziare la fase successiva del processo. Nella maggior parte dei casi si tratta di un comportamento sincrono. 

Questo modello è descritto come "intrinsecamente fragile" nel libro Refactoring to Patterns (Kerievsky 2004), perché se qualcuno decidesse di riavviare il Process Manager, tutte le attività in esecuzione in quel momento verrebbero interrotte. Pertanto, è noto che questa modalità non funziona particolarmente bene con i processi di lunga durata. 

Esaminiamo ora il secondo modello di sequenziamento. La foto qui sotto mostra il pubblico che fa la ola in uno stadio.

Fonte: questo file è concesso in licenza da Creative Commons Attribution-Share Alike 2.0 Generic license.

Ogni persona del pubblico sa quando deve alzarsi in piedi e tirare su le mani; nessuno dà loro indicazioni. In un grande stadio di calcio, succedono troppe cose perché l'orchestrazione possa gestire tutto. Questo è un esempio del prossimo modello di sequenziamento che analizzeremo, chiamato coreografia.

L'orchestrazione è la scelta progettuale più ovvia di cui si accontenta la maggior parte degli sviluppatori, ma la coreografia generalmente consente una riscrittura/progettazione notevolmente migliorata che funziona in modo ottimale in combinazione con gli eventi.

Questo aspetto è molto importante in un mondo di microservizi, in cui potrebbe essere necessario mettere in sequenza centinaia di servizi. Allo stesso modo, quando potrebbero verificarsi attività di pipeline di lunga durata, come configurazione, test e smantellamento, lo stile coreografico è un modello molto più robusto e pratico.

Le pipeline Tekton sono sviluppate da container separati che vengono sequenziati tramite eventi Kubernetes interni sul server API K8. Sono un esempio del tipo di sequenziamento detto coreografia basata sugli eventi. Non esiste un unico Process Manager che si blocchi, si riavvii, monopolizzi le risorse o fallisca in altri modi. Tekton consente a ciascun pod di creare un'istanza quando è necessario per eseguire qualsiasi fase del processo di pipeline di cui è responsabile. Al termine si spegne, liberando le risorse utilizzate per altre attività.

L'ideale di basso accoppiamento e cadenza grazie al riutilizzo

Tekton mostra anche ciò che nell'architettura software viene descritto come basso accoppiamento. Prendiamo ad esempio l'immagine seguente di un trenino giocattolo:

"Toy train for wood tracks" di Ultra-lab, concesso in licenza da CC BY-SA 2.0. 

Il treno e i suoi vagoni si collegano tramite magneti, quindi si può giocare solo con la locomotiva, con tutte le carrozze collegate oppure con tutte le varianti intermedie. 

Si può anche modificare l'ordine dei vagoni; ad esempio, il verde chiaro e il giallo possono essere invertiti. Se si ha a disposizione un altro set simile, si possono spostare tutti i vagoni da un trenino all'altro per formare un "super treno".

Questo spiega perché il "basso accoppiamento" è l'architettura ottimale per la progettazione di software: promuove in modo intrinseco il riuso, e questa è una parte importante dell'etica alla base di Tekton. I componenti, una volta creati, possono essere condivisi tra i progetti con estrema facilità.

Restando in tema, dovremmo esplorare il contrario del basso accoppiamento, ovvero l'accoppiamento stretto. Prendiamo in considerazione un altro giocattolo:

"09506_Pull-Along Caterpillar" di PINTOY^®, concesso in licenza da CC BY-SA 2.0. 

Anche questo bruco in legno ha diverse sezioni, ma sono fisse, il che significa che l'ordine non può essere modificato. Non è possibile avere meno segmenti o aggiungerne altri per creare un super bruco. Se un bambino o una bambina volesse un bruco con solo tre segmenti, dovrebbe convincere i suoi genitori ad acquistarne un altro.

Da questo esempio possiamo capire che l'accoppiamento stretto non promuove il riutilizzo, anzi, impone la duplicazione.

Sì, è vero che le pipeline di Jenkins possono essere a basso accoppiamento e il codice può essere condiviso tra i progetti, ma questo non è scontato e dipende in gran parte dal modo in cui sono state progettate le pipeline. 

L'alternativa è utilizzare una pipeline Jenkins per tutti i progetti, ma si tratta di un metodo restrittivo, e ben presto ci si troverà di fronte un progetto con esigenze diverse rispetto a questo approccio universale. Ciò significa che l'integrità della progettazione a pipeline singola verrà compromessa. 

Tekton è di natura dichiarativa e le sue pipeline sono molto simili all'esempio del trenino in legno. L'oggetto di alto livello "Pipeline" in Tekton rappresenta la locomotiva. La pipeline contiene una serie di attività che possono essere considerate come i vagoni. Pipeline diverse possono contenere le stesse attività, a cui sono stati semplicemente attribuiti nuovi parametri per poterle riutilizzare. In questo modo, le attività a basso accoppiamento a cui possono essere assegnati parametri vengono concatenate per formare pipeline. Tekton promuove fortemente il basso accoppiamento, quindi la possibilità di riutilizzo risulta immediata. Ciò significa che il lavoro di un progetto può essere ripreso, scomposto e utilizzato altrove.

Tekton ha anche definizioni di oggetti Kubernetes aggiuntive, che si integrano molto facilmente con un approccio "tutto è codice" e con GitOps. Il codice della pipeline può essere facilmente applicato al cluster insieme alle altre configurazioni di cluster/spazio dei nomi.

Perché questo è importante?

Perché la nozione di ambienti formali e fissi di sviluppo, test e UAT è in gran parte un concetto antiquato, che risale ai tempi in cui bisognava acquistare server fisici e definirne l'utilizzo. 

Ma questo approccio è legato al passato. Nel mondo dell'OpenShift e del "tutto è codice", della contrapposizione tra server unici e indispensabili e componenti numerosi e sostituibili, non c'è motivo per cui questi ambienti non possano essere creati come istanze in modo dinamico utilizzando pipeline e test e poi messe in esecuzione. Una volta completati, possono essere eliminati completamente per far posto ad altri test, ecc. 

Per la maggior parte delle aziende non funziona ancora così. Forse questo è dovuto anche al fatto che gli strumenti che avevamo a disposizione finora non erano particolarmente adatti.

Conclusioni

Ci stiamo ancora mettendo al passo con tutte le opportunità offerte da tecnologie come OpenShift, che in passato, semplicemente, non erano realizzabili. 

Con tutte le risorse di elaborazione che restano inattive almeno per la maggior parte delle serate, non c'è limite alle possibilità di automatizzare i test per fornire software migliori. Stavo meditando su queste idee da tempo, ma Jenkins non mi è mai sembrato lo strumento giusto per questo tipo di lavoro. Quando ho iniziato a utilizzare Tekton con una mentalità aperta, ho capito subito che era la soluzione perfetta. 

Tekton si integra da zero con l'API Kubernetes e il modello di sicurezza e promuove fortemente l'accoppiamento basso e il riutilizzo. È basato sugli eventi e segue il modello coreografico, quindi è utile per controllare il processo di test di lunga durata. Gli artefatti della pipeline non sono altro che risorse Kubernetes aggiuntive (definizioni di pod, account di servizio, segreti e così via) che si adattano facilmente al mondo del "tutto è codice", in linea con il resto dell'ecosistema di tipo k8.

Ogni team applicativo può disporre di un proprio codice delle pipeline, che, quando non è in esecuzione, si riduce a zero, in modo da ottenere i vantaggi del "Jenkins distribuito" senza tutti i carichi inattivi. Apache Maven ha avuto così tanto successo così in fretta perché è stato un punto di svolta. Ha imposto un modo rigido di strutturare un progetto Java, il che significava che gli sviluppatori potevano facilmente capire la configurazione di build tra i progetti. Tekton fa lo stesso con le pipeline e rende il riutilizzo delle attività semplice e scontato.

Cruise Control è stato il primo strumento di CI nei primi anni 2000 e, per esperienza personale, era difficile da usare. All'epoca, Jenkins sembrava un miglioramento radicale rispetto alle opzioni che erano a disposizione prima. Nel mondo di OpenShift/k8s, Tekton appare davvero come il prossimo passo avanti nella tecnologia delle pipeline.

Scopri di più

• CI/CD cloud native su Red Hat OpenShift