GitOps è una metodologia per gestire e deployare applicazioni e infrastrutture usando i Git repository come unica fonte di verità. È un approccio particolarmente vicino a chi lavora nel mondo DevOps e cloud-native, che porta le pratiche di IaC e CI/CD a un livello successivo: tutto passa da Git, tutto è tracciabile, tutto è riproducibile.
Dietro questa metodologia esiste una community e il “GitOps Working Group” che definisce principi volutamente agnostici su cui basarsi:
- Dichiarativo: un sistema gestito da GitOps deve avere il suo stato desiderato espresso in modo dichiarativo: si descrive cosa si vuole, non come ottenerlo passo per passo.
- Versionato e immutabile: lo stato desiderato deve essere salvato in uno state store che garantisca immutabilità, versionamento e storia completa dei cambiamenti. Git è lo strumento più comune per questo, ma il principio riguarda le proprietà dello store, non lo strumento in sé.
- Pull automatico: i software agent osservano lo state store e scaricano automaticamente le dichiarazioni dello stato desiderato dalla sorgente. Non è il sistema CI/CD che fa push verso il sistema, è il sistema stesso che fa pull.
- Riconciliazione continua: i software agent osservano continuamente lo stato reale del sistema e cercano di allinearlo a quello desiderato. Questo “reconcile loop” è l’elemento cardine di GitOps: osserva lo stato corrente, lo compara con quello dichiarato nel repository e, se trova differenze, interviene per correggerle. Non è un’operazione saltuaria, ma un processo continuo che mantiene il sistema allineato nel tempo, scoraggia modifiche manuali e garantisce che qualsiasi deriva venga rilevata e corretta automaticamente.
Quindi possiamo intuire che lavorare con la metodologia GitOps ha caratteristiche ben precise. Lo stato desiderato deve essere espresso in modo dichiarativo, come già visto nei principi: al contrario dell’approccio imperativo, in cui si descrive passo per passo come arrivare al risultato, qui si dichiara cosa si vuole ottenere, rendendo il tutto più facile da capire, modificare e revisionare. Il formato deve essere leggibile per un umano: capire lo stato del sistema e le differenze tra una versione e l’altra deve essere semplice e immediato, il che è fondamentale per fare review efficaci, individuare errori rapidamente e ridurre il rischio che una modifica passi inosservata.
La code review deve essere veloce, con modifiche piccole e flusso fluido. Quando il processo di review è snello, si evita la tentazione di raggruppare troppe modifiche in un unico commit, spesso non correlate tra loro: una scorciatoia apparente che in realtà complica la revisione e aumenta il rischio di errori. Come le AI, anche noi abbiamo un contesto e, spoiler, è decisamente più piccolo di quanto pensiamo. Il codice deve essere versionato: avere una storia completa delle modifiche e un audit trail diventano quasi gratuiti, così come gestire in modo granulare chi ha accesso e chi può apportare cambiamenti.
Infine, le pull devono essere automatiche: è il sistema stesso che si occupa di recuperare lo stato desiderato dalla sorgente, senza intervento manuale, garantendo che il sistema sia sempre allineato a ciò che è dichiarato nel repository.
Questi elementi, tutti insieme e in sinergia, definiscono cosa significa fare GitOps in modo efficace. Ma quando ha senso valutarne l’adozione o meno?
Quando usarlo?
Se hai un cluster Kubernetes, dovresti prendere in considerazione GitOps. Non solo per gestire le applicazioni che ci girano sopra, ma anche per gestire l’infrastruttura stessa: dalla definizione dei namespace, passando per la gestione dei permessi, fino all’installazione di servizi. Se esiste un manifesto Kubernetes, molto probabilmente è già un ottimo segnale.
Quando non usarlo?
GitOps, ovviamente, non è la risposta a tutte le situazioni. Se il team è piccolo e l’infrastruttura semplice, potrebbe risultare un overhead elevato impostare il workflow e seguirlo correttamente, almeno all’inizio. Può diventare complicato anche in ambienti dove la quantità di commit è alta e, di conseguenza, anche le PR review: il rischio è che diventi un collo di bottiglia. Soprattutto se la code review, come detto sopra, non è veloce.
Può essere controproducente anche quando la metodologia non è ancora stata assimilata davvero: si finisce per avere metà delle cose gestite tramite Git e metà a mano, il che è peggio di non usarlo affatto. Il segnale che GitOps sta funzionando è quando, di fronte a un problema in produzione, il primo istinto è risolverlo passando dal repository e non intervenendo direttamente sul cluster.
Chi fa il lavoro sporco?
Esistono diversi tool che implementano il pattern, ma i nomi più gettonati e da cui consiglierei di partire sono ArgoCD e Flux. Entrambi sono progetti Graduated della CNCF, quindi entrambi hanno un ottimo biglietto da visita.
- ArgoCD, probabilmente il più diffuso e mio preferito: la UI è chiara e permette di visualizzare lo stato dei cluster e le differenze tra stato desiderato e attuale.
- Flux, da prendere in considerazione perché incarna maggiormente la filosofia GitOps nella sua forma più pura, con una curva di apprendimento, a mio parere, leggermente più alta rispetto ad ArgoCD.
GitOps oltre la gestione applicativa
Una delle cose che mi piace di più è che GitOps non si limita a gestire le applicazioni che girano sul cluster: può gestire anche l’infrastruttura stessa. Namespace, permessi, CRD, componenti di sistema.
Chi ha provato a gestire un Helm chart con Terraform sa cosa vuol dire: installare il provider, configurarlo, definire la risorsa helm_release, gestire i values. Funziona, ma con GitOps lo risolvi con un semplice manifest yaml, dove le diff sono leggibili e chiare, cosa che con Terraform e Helm non è sempre garantita.
Con GitOps dichiari lo stato desiderato, punti al chart, definisci i values inline o in un file dedicato, e il tool si occupa del resto. Se qualcuno modifica manualmente una risorsa sul cluster, intenzionalmente o meno, il sistema la riporta allo stato dichiarato su Git. Con Terraform, quel drift non lo vedi finché non esegui un terraform plan, o finché non hai una pipeline dedicata che lo controlla per te.
Non significa che non uso più Terraform: per provisioning di infrastruttura cloud, reti, database, è ancora lo strumento giusto. Ad ogni tool il suo utilizzo migliore. Per tutto quello che vive dentro il cluster Kubernetes, GitOps è una soluzione più naturale e più leggibile.
Guardando GitOps attraverso la lente del framework CAMS, il quadro diventa ancora più chiaro. Automatizza i processi di deploy e riconciliazione, rende ogni cambiamento tracciabile e misurabile attraverso la storia del repository, favorisce la collaborazione e la trasparenza grazie a un formato leggibile e condiviso e, non da ultimo, spinge verso una cultura in cui le modifiche passano da un processo strutturato invece che da interventi manuali. Adottarlo porta a un miglioramento concreto della produttività, stabilità, affidabilità e sicurezza: non come effetto collaterale, ma come conseguenza naturale di un approccio ben assimilato.
Bonus: vuoi provare?
Ho preparato un playground locale che avvia un cluster Kubernetes con kind e installa ArgoCD tramite Terraform. Troverete qualche esempio, per cominciare e per vedere il reconcile loop in azione.
