GitOps con Argo CD: deploy dichiarativi, drift detection e rollback su Kubernetes

Che cos'è il GitOps

Il GitOps è un modo di gestire l'infrastruttura in cui lo stato desiderato del sistema è descritto in modo dichiarativo dentro un repository Git, e un componente automatico si occupa di far combaciare la realtà del cluster con quella descrizione. Git diventa l'unica fonte di verità: ogni modifica è un commit, con autore, revisione e storia. Non si eseguono più comandi manuali sul cluster: si cambia il repository e il sistema si adegua.

Perché Argo CD

Argo CD è un controller che gira dentro Kubernetes e osserva uno o più repository. Quando il contenuto del repo cambia, confronta i manifest con ciò che è realmente in esecuzione e applica le differenze. Offre una dashboard che mostra, per ogni applicazione, se è allineata (Synced) o se qualcosa è stato modificato fuori da Git (OutOfSync). Questo rende visibile in pochi secondi lo stato di decine di servizi.

Drift detection e rollback

Il drift è la deriva tra ciò che è scritto in Git e ciò che gira davvero: una modifica d'emergenza con kubectl, un operatore che cambia una risorsa, una regressione. Argo CD evidenzia il drift e, a seconda della configurazione, può segnalarlo o correggerlo da solo (self-heal). Il rollback è altrettanto semplice: poiché ogni stato è un commit, tornare indietro significa ripuntare l'applicazione a una revisione precedente, senza ricostruire nulla a mano.

Come adottarlo senza rischi

Conviene procedere per gradi. All'inizio si tiene Argo CD in sola osservazione, con sync manuale: si vede il drift ma si applica a mano, per prendere confidenza. Poi si abilita il sync automatico sui namespace non critici (ambienti di sviluppo e staging) e infine, quando il team si fida del flusso, anche in produzione, con le dovute protezioni: finestre di manutenzione, approvazioni e politiche di sicurezza sui repository.

Quando non serve

Il GitOps dà il meglio quando si gestiscono più ambienti e più servizi su Kubernetes. Per un singolo servizio su una VM, o per sperimentazioni usa-e-getta, l'overhead può non valere la candela. La regola pratica è semplice: se stai già scrivendo manifest dichiarativi e vuoi tracciabilità e ripetibilità, il GitOps è il passo naturale successivo.