GitOps e Kubernetes: CI/CD per applicazioni Cloud Native

GitOps è un paradigma volto ad implementare Continuous Deployment e/o Continuous Delivery per applicazioni Cloud Native. Tramite l’uso di strumenti già familiari allo sviluppatore si concentra su un’esperienza che veda lo sviluppatore coinvolto anche nelle attività inerenti all’infrastruttura.

Possiamo pensare a GitOps come a una raccolta di buone pratiche per gestire la consegna di applicazioni containerizzate e dell’infrastruttura sulla quale queste girano.

GitOps si basa su 4 principi:

• Primo principio: l’intero sistema deve essere descritto in maniera dichiarativa; per questo motivo la natura dichiarativa di Kubernetes e il modello Controller sono ideali a fare GitOps.
• Secondo principio: lo stato desiderato del sistema deve essere versionato in un repository Git. Se un repository Git contiene i file che descrivono in modo dichiarativo lo stato desiderato del sistema, allora Git diventa sia la singola fonte di verità per lo stato del nostro sistema che il singolo luogo in cui operiamo tutti gli ambienti.
• Terzo principio: tutti i cambiamenti che sono stati approvati e committati in un repository possono essere applicati automaticamente al nostro sistema. Questo non vuol dire che è necessario avere l’automatismo per fare GitOps, ma che se il contesto lo consente è raccomandato automatizzare la procedura.
• Quarto principio, detto principio dell’osservabilità: questo principio dice che il sistema deve essere osservabile dagli agenti software che devono poterne verificare lo stato attuale rispetto allo stato desiderato, e in caso di discordanza agire per riportare i due stati alla pari. In un contesto GitOps+Kubernetes, questo è il Kubernetes operator.

Notiamo quindi che si rende necessario un nuovo attore per fare GitOps in Kubernetes: il GitOps Operator.

POTREBBE INTERESSARTI ANCHE: 3 errori comuni durante l’adozione di Kubernetes

Quindi, di cosa ho bisogno per fare GitOps?

Come accennato poco fa, si profila necessario un nuovo attore: il GitOps operator, ovvero un Kubernetes operator che segue il loop control pattern del Kubernetes controller e si occupa della parte di automazione della delivery e del monitoraggio. Ci sono diversi GitOps operators, tra cui i principali sono Flux CD, Argo CD e Jenkins-X.

• Flux CD, sviluppata da Weave Works (che ha coniato il termine GitOps) è un’applicazione scritta in Go che installa un operator nel cluster di destinazione, un tool che gestisce tutto da command line facilitandone probabilmente l’automazione. Attualmente è in fase di sviluppo una nuova versione di Flux, riscrittura completa basata sul progetto GitOps Toolkit. Questa nuova versione introdurrà interessanti novità, come un supporto a repository multipli.
• Argo CD fa parte di Argo Project, un insieme di strumenti nativi Kubernetes per il deploy e per l'esecuzione di job e applicazioni sviluppati da Inuit, una enterprise USA che lavora nel settore del software finanziario. Argo ha un’interfaccia grafica eccellente e include uno strumento a riga di comando. Inoltre è flessibile: può essere utilizzato su ogni tipo di progetto, da quelli più piccoli a progetti enterprise grazie a funzionalità quali Single Sign On e gestione centralizzata multi-progetto multi-cluster.
• Jenkins-X è una soluzione CI/CD per applicazioni Cloud Native basate su Kubernetes. Non si tratta di un singolo prodotto ma di un pacchetto di strumenti preconfigurati, installabili in modo automatico e opinionato. L’intera installazione è gestita da riga di comando (jx) che, tramite una procedura guidata, permette in poco tempo di avere una piattaforma completa. Jenkins-X si prefigura quindi come una soluzione all-in-one che può essere utilizzata per l’intero processo CI/CD.
  Jenkins-X è un progetto open-source, con un supporto enterprise offerto da CloudBees, e fa parte della Continuous Delivery Foundation (CDF).

• Inoltre, chi già utilizza GitLab EE, versione premium di GitLab, avrà a disposizione a partire dalla release 13.4 l’integrazione di un Kubernetes Agent, ovvero un tool nativo che permetterà di fare GitOps senza bisogno di appoggiarsi ad altri prodotti. Il progetto è nato da una collaborazione di Argo con Flux e Amazon AWS. 

Perchè ve lo stiamo dicendo? Non è raro che alcune funzionalità premium, dopo qualche release, passino anche alla versione free. Vale la pena quindi di tenere d’occhio questa funzionalità di GitLab e come si evolverà lo strumento nella sua versione free.

La pipeline CI/CD di tipo GitOps

Prima di vedere la pipeline CI/CD di tipo GitOps, è bene analizzare una tipica pipeline CI/CD di Kubernetes, detta anche Push Model.

Credits: GitOps, Push-Based Deployments

Questo modello segue una pipeline che, come potete vedere, potremmo definire unilineare e unidirezionale: parte dallo sviluppatore, attraversa tutti i passaggi della CI e, infine, è lo stesso tool di CI che si occupa anche del Continuous Deployment dell’applicazione nel suo ambiente di destinazione.

Questo processo, sebbene non intrinsecamente errato, può dimostrare alcune debolezze: in primis la necessità di fornire al tool di CI/CD le credenziali dell’ambiente di destinazione. In secondo luogo vediamo un tool di CI che non è in grado di notificare discrepanze tra lo stato desiderato e quello attuale e ci costringe ad installare un secondo tool che si occupi di monitorare lo stato dell’applicazione.

Credits: GitOps, Pull-Based Deployments

Nel Modello Pull-Based, nonché il modello di pipeline CI/CD GitOps, vediamo invece una prima differenza principale, ovvero la presenza di due repository posti a inizio e fine del processo di CI. In questo modello infatti il tool di CI non si occupa più del deployment ma sarà un operator come quelli visti in precedenza, installato nell’ambiente target. Restando in ascolto di eventuali modifiche effettuate nel registry docker e nell’environment repository, il tool si occuperà di far coincidere lo stato attuale dell’ambiente con quello dell’environment repository, ovvero lo stato desiderato.

Vediamo quindi come in questo modello vengono spezzate l’unidirezionalità e l’unilinearità del modello Push-Based, aumentando sicurezza ed efficienza.

GitOps: benefici e sfide (e come affrontarle)

GitOps senza dubbio può portare molti benefici. Come prima cosa, rende il sistema totalmente osservabile, tanto da te quanto da un tool automatizzato. Esso ti assicura che ciò tu vedi nell’environment repository è effettivamente quello che c’è nel cluster Kubernetes, effettuando autonomamente le implementazioni necessarie per far coincidere lo stato attuale del sistema con lo stato desiderato (di conseguenza aumenta anche la verificabilità!).

Inoltre, GitOps condivide un essenziale benefit con Kubernetes: il modello dichiarativo su cui si basa il lavoro degli operator, grazie ai quali potrai aumentare la produttività. Infine il modello Pull rende i sistemi più sicuri semplificando il problema di dover esporre le API di Kubernetes alla tua Continuous Integration.

Per essere sicuri di godere appieno di questi benefici, però, occorre prestare attenzione a dei punti che, se non gestiti in modo opportuno, potrebbero risultare in problematiche. È importante sfruttare l’environment repository e le pipeline per prevenire più possibile il push simultaneo sullo stesso repository. Se Git trovasse il remote non più allineato perché, nel frattempo, un’altra pipeline ha pushato sullo stesso repository e sullo stesso branch non riuscirebbe più a pushare le modifiche.

Quali sono quindi i nostri suggerimenti per evitare queste problematiche? 

Come prima cosa, se possibile, consigliamo di usare sempre due repository, uno per il codice della vostra applicazione e l’altro come storage per i vostri manifest. Inoltre, ricordiamo sempre di non mettere mai dati sensibili nell'environment repository. È vero che GitHub aiuta a rendere il sistema più sicuro, ma è comunque buona precauzione prendere questa accortezza.

Seguendo questi due semplici consigli e le best practices potrete creare applicazioni moderne e Cloud Native godendo di tutti i benefici che il paradigma GitOps ha da offrire e continuerà ad offrire con il suo sempre crescente sviluppo.