GitOps: tutto ciò che c’è da sapere sull’infrastruttura IT automatizzata

GitOps è un framework operativo che mediante un approccio dichiarativo permette di gestire infrastrutture e applicazioni e di controllarle grazie a Git. Gli obiettivi di tale metodo sono l’automazione dei processi, il risparmio di tempo e una collaborazione migliore e più sicura tra i singoli team sui repository.

L’automazione gioca un ruolo fondamentale nello sviluppo di software. È questo uno dei motivi per cui DevOps ha avuto un successo così eclatante. Alla base troviamo l’idea di “Infrastructure as Code (IaC)”, finalizzata a mappare le infrastrutture e le configurazioni di un sistema informatico e a renderle quindi riproducibili. GitOps rappresenta l’estensione logica di questo approccio. Dal 2017, il software open source Git regola l’intero processo di gestione di un’applicazione, dall’amministrazione allo sviluppo finale del software in quanto “single source of truth” (SSOT). A tal fine, GitOps definisce uno stato di riferimento e verifica l’infrastruttura finché tale stato non viene raggiunto e, se necessario, la modifica.

Weaveworks mette a disposizione una serie di best practice per uniformare i singoli metodi di monitoraggio dei container. Queste regole si possono applicare a Kubernetes e ad altre tecnologie con un background cloud per renderle più facili da gestire. Git deriva da un sistema di controllo delle versioni sviluppato da Linus Torvald nel 2005 e consente a diversi team di sviluppo di lavorare insieme a un progetto. Eventuali modifiche vengono applicate solo previo unanime consenso e a condizione che vengano mantenuti gli stati di sviluppo più datati. Questo consente di lavorare contemporaneamente su aspetti diversi e unirli alla fine. Se abbiamo risvegliato la vostra curiosità, nella nostra Digital Guide trovate un tutorial completo su Git.

Nel caso di GitOps, lo stato di destinazione di un sistema viene prima descritto in modo dichiarativo. Successivamente, le modifiche vengono apportate secondo il principio di Git per mezzo di richieste pull. Una volta eseguite, cambiano il repository Git. In un ambiente GitOps, quando viene inviata una richiesta pull, l’operatore GitOps si attiva, memorizza il commit e richiede lo stato corrente via Git. Lo stato corrente viene poi confrontato con lo stato desiderato nel repository. Nel momento in cui sono approvate, le modifiche vengono accorpate allo stato precedente e trasferite direttamente all’infrastruttura live. In questo modo si ottengono processi più rapidi e fluidi, ma soprattutto un sistema più stabile e affidabile.

Grazie a principi chiaramente definiti e immutabili, i flussi di lavoro GitOps sono in grado di funzionare sempre in modo affidabile. Innanzitutto, si tratta dei sistemi dichiarativi descritti, già noti ad altri cloud nativi. Una descrizione dichiarativa fa sì che l’intero sistema possa essere considerato come codice e sottoposto al controllo delle versioni. Questo contribuisce alla sicurezza e alla stabilità dell’intero sistema, poiché le deviazioni dalla versione Git possono essere immediatamente riconosciute e segnalate. In più, le chiavi SSH permettono di rintracciare sempre l’origine del codice. Grazie alla dichiarazione preventiva, anche le modifiche possono essere automatizzate e si possono individuare e correggere tempestivamente le possibili fonti di errore.

La filosofia principale di DevOps è sempre stata quella di avvicinare sviluppo ed esecuzione per ottimizzare i flussi di lavoro. Dal momento che i singoli team lavorano a stretto contatto, il prodotto finale sarà migliore e le modifiche potranno essere apportate in modo più rapido e accurato. Questo approccio viene ripreso da GitOps e applicato coerentemente alla parte di esecuzione (operazioni). GitOps si concentra interamente su Git, mentre DevOps e DevSecOps sono più che altro un’idea di fondo che promuove la collaborazione tra aree precedentemente separate e si basa su pipeline CI e CD. A ogni modo, si possono combinare entrambi gli approcci.

A differenza di Continuous Delivery e Continuous Integration, GitOps ricava tutte le informazioni importanti direttamente da Git secondo il principio pull senza ricorrere al deployment tramite un server CI. L’uso del server CI con GitOps è ancora possibile, tuttavia si limita a eseguire le fasi di costruzione e di test. Per saperne di più su Continuous Integration, Continuous Delivery e Continuous Deployment, consultate la Digital Guide.

Data la sua versatilità, probabilmente Kubernetes rappresenta la piattaforma più importante per la gestione di applicazioni basate su container. Esso funziona anche in modo dichiarativo e tiene conto dello stato di destinazione di un sistema. Pertanto, può funzionare perfettamente con GitOps e persino agire come operatore. Tuttavia, per una migliore visione d’insieme e per motivi di sicurezza, è importante che il codice sorgente e la configurazione rimangano separati. Lo stato attuale può essere memorizzato in un repository Git separato. Inoltre, occorre avvalersi di strumenti di sincronizzazione appropriati che impediscano l’accesso non autorizzato ed eventuali errori.

Al momento esistono numerosi strumenti per GitOps che puntano a semplificare e migliorare in modo significativo l’automazione, ad esempio strumenti per lavorare con Kubernetes che agiscono come operatori e si fanno carico dell’implementazione di GitOps. L’operatore (o custom controller) più rinomato è Flux. Tra le alternative troviamo ArgoCD o Fleet. Tra gli strumenti più importanti per una maggiore sicurezza si annoverano SOPS di Mozilla e Sealed Secrets di Bitnami. Cluster API e Fleet sono particolarmente adatti per essere utilizzati con i cluster Kubernetes. In generale, il mercato è relativamente vasto, pertanto esiste uno strumento adatto a quasi tutte le applicazioni.

Per rispondere finalmente alla domanda su quanto GitOps sia davvero valido e adatto ai vostri scopi, è opportuno valutarne i vantaggi e gli svantaggi.

• Produttività: attraverso l’automazione è possibile apportare un numero nettamente superiore di modifiche in tempi più brevi. Questo consente agli sviluppatori di portare avanti i progetti in modo molto più efficace.
• Sicurezza e stabilità: la precisione dei controlli consente di rilevare più rapidamente gli errori e di correggerli automaticamente. Ciò contribuisce a ottenere maggiore sicurezza e stabilità. Il ripristino delle versioni precedenti è molto più semplice sia grazie a rollback resilienti sia grazie all’approccio pull che evita complicazioni indesiderate.
• Omogeneità: attraverso GitOps i flussi di lavoro sono unificati. La collaborazione è migliore e più semplice e consente di entrare più rapidamente nel flusso di lavoro anche ai nuovi arrivati.

• Separazione di CI e CD: considerata la rigida separazione tra CI e CD nell’approccio GitOps, potrebbe rivelarsi difficile eseguire i test in seguito al deployment.
• Visione d’insieme poco chiara: specialmente nel caso di ambienti multipli, è facile che GitOps risulti disorientante. La presenza di numerosi repository e configurazioni può contribuire a generare confusione.