GitOps è un framework operativo che prende le best practice DevOps utilizzate per lo sviluppo di applicazioni come il controllo delle versioni, la collaborazione, la conformità e CI/CD (Continuos Integration / Continuous Deployment) per applicarle all’automazione dell’infrastruttura. Gli esperti aiutano a capire sia il contesto operativo che le opportunità applicative del GitOps.
Git e GitOps: le origini di uno sviluppo Agile
La premessa di contesto è Git, un software per il controllo delle versioni open source creato nel 2005 da Linus Torvalds (il papà di Linux). L’obiettivo di Git? Essere uno strumento capace di semplificare lo sviluppo del kernel Linux. Talmente facile da usare che è poi diventato uno degli strumenti di controllo delle versioni tra i più diffusi. Quando si parla di GitOps, dunque, si fa riferimento a una serie di procedure e infrastrutture basate su Git. Attraverso un processo di automazione che utilizza l’Infrastructure as Code e le migliori pratiche di sviluppo, con GitOps i team possono gestire l’infrastruttura con gli stessi strumenti e processi che utilizzano per programmare le applicazioni.
GitOps: a cosa serve e come funziona
Se è vero che il ciclo di vita dello sviluppo del software è stato ampiamente automatizzato, è vero anche che l’infrastruttura è rimasta un processo che richiede ancora parecchio lavoro manuale da parte degli specialisti. L’evolutiva della domanda impone agli sviluppatori maggiore velocità distributiva, scalabilità ed elasticità infrastrutturale per gestire efficacemente le risorse cloud necessarie a modalità di rilascio continue. GitOps viene utilizzato per automatizzare il processo di provisioning dell’infrastruttura. Le organizzazioni con una cultura DevOps matura possono distribuire il codice alla produzione centinaia di volte al giorno attraverso best practice di sviluppo come:
- il controllo della versione
- la revisione del codice
- le pipeline CI/CD che automatizzano i test
- le implementazioni
Analogamente al modo in cui i team utilizzano il codice sorgente dell’applicazione, i team operativi che adottano il GitOps utilizzano i file di configurazione archiviati come codice (Infrastruttura as a Code). I file di configurazione di GitOps generano lo stesso ambiente infrastrutturale ogni volta che questo viene distribuito: ogni volta che viene compilato, il codice sorgente del programma genera gli stessi binari applicativi.
Kubernetes e GitOps
Quando si pensa alle implementazioni di Kubernetes, la domanda fondamentale è: come posso automatizzare? In un mondo pieno di meccanismi e strumenti incentrati sulla metodologia DevOps, distribuire manualmente un’applicazione su Kubernetes è un processo complicato. Gli ingegneri del software possono evitare le operazioni manuali delle distribuzioni Kubernetes adottando il GitOps. Vediamo come i tester possono utilizzare GitOps per i loro ambienti Kubernetes.
Perché GitOps?
Nella sua forma più semplice, GitOps segue un procedimento analogo alla gestione della configurazione, originariamente progettata per fare in modo che più server si connettano a un server principale per recuperare le informazioni di configurazione (per esempio, come installare un’applicazione o un servizio come SQL Server che esegue uno script per una certa automazione). L’obiettivo? Garantire che i servizi abbiano sempre la stessa configurazione in esecuzione, in modo che questa sia esattamente quella che un ingegnere del software si aspetta. GitOps è un modo per distribuire automaticamente e definire esattamente ciò che gli sviluppatori vogliono eseguire: dalle distribuzioni Kubernetes ai servizi o a qualsiasi altro carico di lavoro che si sceglie di eseguire su un cluster Kubernetes.
Un esempio di configurazione
Il server principale, come nella gestione della configurazione, è un sistema di controllo del codice sorgente basato su Git. Per esempio, il codice in un account GitHub è la fonte di verità per ciò che un team dovrebbe distribuire. Kubernetes viene quindi configurato per avere un controllo degli intervalli esaminati periodicamente da GitHub, confermando che ciò che è in esecuzione su Kubernetes equivale a quanto è trascritto nel controllo del codice sorgente. In caso contrario, Kubernetes tenta di recuperare le configurazioni del codice dal controllo del codice sorgente. A un livello più alto, gli sviluppatori possono utilizzare GitOps per garantire che Kubernetes esegua applicazioni, servizi e/o distribuzioni esattamente come ci si aspetta che questi vengano eseguiti.
Quali sono gli strumenti GitOps
Tra soluzioni proprietarie e opensource, esistono diversi strumenti GitOps che gli ingegneri possono utilizzare per testare le loro distribuzioni automatizzate su Kubernetes. Di seguito le opzioni più diffuse.
Flux CD
I neofiti del GitOps tendono a scegliere Flux CD. Flux CD è un operatore GitOps e viene eseguito come applicazione di distribuzione su un cluster Kubernetes. Il tool viene utilizzato per sincronizzare i file manifest da un sistema di controllo del codice sorgente basato su Git, come GitHub, per garantire che ciò che è in esecuzione nel cluster Kubernetes sia ciò che è presente nei manifesti di GitOps. Flux CD garantisce che il cluster Kubernetes esegua le applicazioni corrette da Git guardando i manifesti di Kubernetes per vedere se si verificano modifiche. Se si verifica una modifica, Flux CD distribuisce le nuove modifiche al cluster Kubernetes.
Argo CD
Argo CD è uno strumento di distribuzione (anche continua) configurato specificamente per il GitOps. Questo controller è di natura dichiarativa, il che significa che descrive cosa stanno facendo le distribuzioni, ma non come lo stanno facendo. Argo CD ha anche capacità di sincronizzazione per garantire che il cluster Kubernetes esegua le applicazioni specifiche e i manifest Kubernetes dichiarati nel controllo del codice sorgente. Analogamente a Flux CD, Argo CD ha funzionalità di sincronizzazione migliori in virtù della sua distribuzione multi-cluster, caratterizzata da un’interfaccia utente che gli sviluppatori possono utilizzare per semplificare la gestione.
Weave
Weave ha un’opzione open source gratuita, chiamata GitOps Core, e una versione a pagamento, chiamata GitOps Enterprise. Simile ad Argo CD, Weave GitOps Core è uno strumento di distribuzione continua open source utilizzato per le applicazioni Kubernetes. La versione enterprise fornisce un cruscotto utente per la gestione, la collaborazione con i team oltre a funzionalità di sicurezza aggiuntive.
Come iniziare i test di GitOps
Prima di iniziare a testare GitOps, i tecnici avranno bisogno di 4 componenti:
- un cluster Kubernetes
- un sistema di controllo del codice sorgente
- un account GitHub
- un’applicazione da distribuire
#1 un cluster Kubernetes
Il punto di partenza è un cluster Kubernetes. I tester possono utilizzare GitOps su qualsiasi tipo di cluster Kubernetes, come AKS in Azure o EKS in AWS, utilizzandolo anche se il team esegue Kubernetes in locale o gestisce direttamente i nodi master e di lavoro. Il framework funzionerà anche nel caso un cluster Kubernetes in esecuzione abbia una risorsa disponibile per distribuire uno degli strumenti GitOps succitati.
#2 Sistema di controllo del codice sorgente
Dopo che il cluster Kubernetes è attivo e funzionante, i tester dovranno configurare un sistema di controllo del codice sorgente basato su Git. Il sistema di controllo del codice sorgente è il luogo in cui il team memorizzerà i manifesti di Kubernetes per distribuzioni, servizi, ingressi e così via. Come suggeriscono gli esperti, i tester che desiderano iniziare con un sistema di controllo del codice sorgente gratuito basato su Git dovrebbero prendere in considerazione GitHub.
#3 un account GitHub
Successivamente, il team dovrà decidere quale sistema GitOps desidera utilizzare. Per esempio, scegliendo Flux CD i membri del team dovranno eseguire la configurazione di installazione per distribuire lo strumento al cluster Kubernetes che, una volta distribuito, verificherà costantemente il sistema di controllo del codice sorgente basato su Git per confermare le configurazioni del file manifest di Kubernetes.
#4 un’applicazione da distribuire
Una volta configurati il cluster Kubernetes, il controllo del codice sorgente e lo strumento GitOps, qualcuno del team dovrà creare un file manifest Kubernetes che potrà valere per qualsiasi applicazione. Dopo aver configurato tutto ciò, i tester di un team possono eseguire test GitOps per garantire che i manifesti di Kubernetes nel controllo del codice sorgente vengano distribuiti e sincronizzati correttamente in un cluster Kubernetes.
