GitOps: gestire l'infrastruttura come se fosse codice

Hai mai deployato in produzione e poi passato venti minuti a cercare di ricordare cosa avevi cambiato?

Hai mai fatto una modifica "rapida" direttamente sul cluster con kubectl apply e tre giorni dopo scoperto che lo staging non corrispondeva più alla produzione?

Hai mai perso un'ora a capire chi aveva toccato la configurazione del load balancer, e perché?

Se hai risposto sì a una di queste domande, GitOps non è una buzzword che puoi ignorare. È la risposta strutturata a problemi che hai già incontrato.

😯​ Il problema che GitOps risolve

Prima di parlare di GitOps, bisogna parlare del modo in cui la maggior parte dei team gestisce l'infrastruttura.

Lo scenario tipico assomiglia a questo: uno sviluppatore finisce una feature, lancia una pipeline CI che esegue i test, poi, in qualche modo, il codice arriva in produzione. "In qualche modo" è il punto critico. Potrebbe essere uno script di deploy, un comando manuale, una combinazione di entrambi. Lo stato reale del cluster è nella testa delle persone che ci hanno lavorato, non da nessuna parte scritta.

Questo funziona. Finché non smette di farlo.

Il problema non è che le cose vanno male. Il problema è che quando vanno male, non hai un punto di riferimento univoco. Non puoi rispondere con certezza alle domande più semplici: cosa sta girando in produzione adesso? Quando è cambiato? Chi lo ha cambiato? Come torno allo stato precedente?

GitOps risponde a tutte e quattro.

😎​ Cos'è GitOps, in una frase

GitOps è un modo di gestire l'infrastruttura in cui Git è l'unica fonte di verità per lo stato desiderato del sistema.

Non "uno dei posti dove guardi". L'unico.

Tutto quello che deve girare in produzione, deployment, configurazioni, secrets (cifrati), networking, risorse Kubernetes, esiste come file in un repository Git. Se non è nel repo, non dovrebbe esistere nel cluster. Se è nel repo, deve esistere nel cluster.

La conseguenza logica è radicale: non si fa mai kubectl apply a mano. Non si modifica la configurazione direttamente sul cluster. Non si lancia uno script di deploy dalla propria macchina. Ogni cambiamento passa attraverso Git, una commit, una pull request, una review.

🧐​ Come funziona in pratica

Il meccanismo centrale di GitOps è un componente chiamato operatore (o agent) che gira nel cluster e fa una cosa sola: confronta continuamente lo stato desiderato (quello nel repo Git) con lo stato reale (quello nel cluster), e riconcilia le differenze.

Il flusso ha questo aspetto:

Non c'è nessun passo manuale dopo il merge. Non c'è nessuno script che "sai tu come si lancia". L'operatore, tipicamente ArgoCD o Flux, è sempre in ascolto, sempre in sync.

Questo pattern ha un nome preciso: reconciliation loop. È lo stesso principio che governa i controller di Kubernetes internamente. GitOps lo porta al livello del deploy applicativo.

📌 I quattro principi fondamentali

Il termine GitOps è stato coniato da Alexis Richardson, CEO di Weaveworks, nel 2017. Weaveworks ha poi formalizzato quattro principi che definiscono un sistema GitOps corretto:

1. Il sistema è descritto in modo dichiarativo Non "esegui questi comandi per arrivare allo stato X", ma "lo stato X è questo". Kubernetes è dichiarativo per natura, i file YAML descrivono cosa deve esistere, non come crearlo. GitOps fa lo stesso con l'intera infrastruttura.

2. Lo stato desiderato è sotto version control Git. Punto. Non un database, non una UI, non la memoria di un collega. Git dà diff, storia, rollback, blame. È l'audit log gratuito che ogni team di infrastruttura dovrebbe avere.

3. I cambiamenti approvati sono applicati automaticamente Nessun intervento manuale tra "merge su main" e "in produzione". L'automazione non è un'opzione, è il meccanismo.

4. Gli agent software garantiscono la correttezza e avvisano delle deviazioni Se qualcuno fa una modifica manuale al cluster, per emergenza, per sbaglio, per curiosità, l'operatore lo rileva e o lo corregge automaticamente o avvisa. Lo stato reale non può divergere dallo stato desiderato senza che qualcuno lo sappia.

🙋‍♂️​ La differenza con CI/CD classico

A questo punto potresti pensare: ma non è quello che fa già la mia pipeline?

No, e la differenza è importante.

Una pipeline CI/CD classica è push-based: quando c'è un evento (un commit, un tag), la pipeline si attiva, esegue dei passi, e spinge i cambiamenti al cluster. La pipeline ha credenziali per accedere al cluster. Se la pipeline fallisce a metà, il cluster può trovarsi in uno stato parziale. Non c'è nessun meccanismo che garantisce che il cluster rimanga nello stato che la pipeline ha creato, qualcuno può sempre entrare e cambiare qualcosa direttamente.

GitOps è pull-based: l'operatore che gira nel cluster va a prendere lo stato desiderato dal repo. Il cluster non espone endpoint per essere modificato dall'esterno, è lui che si aggiorna. Questo inverte il modello di sicurezza: non devi dare credenziali di produzione alla tua pipeline CI. La pipeline scrive sul repo, l'operatore fa il resto.

🧑‍💻 Un esempio concreto

Immagina di avere un servizio api-gateway che gira su Kubernetes. Con GitOps, il tuo repo di infrastruttura ha una struttura simile a questa:

Vuoi aggiornare la versione dell'immagine in produzione. Non apri un terminale. Non lanci kubectl set image. Apri una pull request che modifica deployment.yaml:

La PR viene revisionata, approvata, mergiata. ArgoCD rileva il cambiamento nel repo entro pochi secondi, applica il nuovo deployment, e aggiorna lo stato nel cluster. Se qualcosa va storto, fai git revert sulla commit e ArgoCD porta il cluster alla versione precedente automaticamente.

Il rollback non è un'operazione speciale. È un commit.

🟢​ Perché questo cambia le cose per un dev

Se sei un developer che non si occupa principalmente di infrastruttura, GitOps ti riguarda più di quanto pensi.

Diventa leggibile cosa c'è in produzione. Puoi aprire il repo, guardare i YAML, e sapere esattamente cosa sta girando. Nessun "chiedi a Marco che sa come funziona il deploy".

Il deploy è una PR come le altre. Stessa review, stesso processo, stesso tool. Non c'è un sistema parallelo da imparare.

Il debug diventa tracciabile. "Quando è cambiato?" non richiede di interrogare log dispersi. git log ti dice tutto: chi, cosa, quando, e con quale messaggio di commit.

Il recovery è deterministico. Se la produzione esplode, non cerchi lo stato "buono" nella testa di qualcuno. È nel repo. Puoi riportare il cluster a qualsiasi commit della storia.

🛠️​ Gli strumenti principali

Due operatori dominano l'ecosistema GitOps per Kubernetes:

ArgoCD: UI grafica, ottima visibilità sullo stato del cluster, più semplice da adottare se il tuo team è abituato a lavorare con tool visivi. È un'applicazione che gira nel cluster e si controlla anche via CLI o API.

Flux: più orientato al GitOps "puro", meno UI e più API-first. Più flessibile per setup complessi, preferito da chi vuole un'integrazione profonda con Helm e Kustomize.

Entrambi sono CNCF projects. Entrambi fanno bene il loro lavoro. La scelta dipende più dalla cultura del team che dalle funzionalità tecniche.

❌​ Quando GitOps non è la risposta giusta

GitOps non è la soluzione a tutto, e vale la pena dirlo chiaramente.

Se non sei già su Kubernetes (o un sistema dichiarativo simile), GitOps aggiunge complessità senza portare i benefici principali. Il principio di reconciliation loop funziona perché Kubernetes è già dichiarativo. Su un server bare metal con deploy via script, stai costruendo su fondamenta diverse.

Se sei un team di una persona con un'app semplice, l'overhead di mantenere un repo di infrastruttura separato, configurare ArgoCD, e gestire la separazione tra repo applicativo e repo infrastrutturale potrebbe non valere il guadagno. Un buon CI/CD con deployment automatico può bastare.

Se la tua organizzazione non è pronta per "nessun deploy manuale", GitOps crea attrito, non lo risolve. Il principio che lo stato del cluster è sacro e non si tocca a mano richiede disciplina e buy-in dal team. Senza quello, diventa il sistema ufficiale che nessuno usa davvero.

📍​ Da dove si parte

Se vuoi capire GitOps sul campo senza partire da zero, il percorso più diretto è:

1. Prendi un cluster Kubernetes esistente (anche Minikube o Kind in locale va benissimo)
2. Installa ArgoCD la documentazione ufficiale ha un getting started che funziona in 10 minuti
3. Crea un repo Git con un deployment YAML di un'app di test
4. Connetti ArgoCD al repo e guarda cosa succede quando modifichi il YAML
5. Prova a modificare qualcosa direttamente sul cluster con kubectl e osserva la drift detection

Non serve un'infrastruttura reale per capire il meccanismo. Il loop di reconciliation si capisce meglio vedendolo in azione che leggendone la descrizione.

🎯​ Il punto vero

GitOps non è una tecnologia. È un'idea operativa: se non è nel repo, non dovrebbe esistere.

Sembra semplice. Le conseguenze non lo sono. Cambia come fai review, come fai rollback, come dai accesso, come fai audit, come onboardi nuovi membri del team. Cambia il rapporto tra developer e infrastruttura, da "roba opaca che gestisce qualcun altro" a "codice che posso leggere, modificare e versionare".

In un'epoca in cui l'AI genera configurazioni, infrastruttura-as-code e deployment a velocità crescente, avere Git come unica fonte di verità non è un lusso. È l'unico modo per sapere con certezza cosa sta girando nel tuo sistema.