Chi lavora con il codice è abituato a un'idea semplice: il repository Git contiene la versione ufficiale, ogni modifica passa da una revisione e la cronologia racconta chi ha cambiato cosa. GitOps estende la stessa idea all'infrastruttura e ai rilasci: ciò che gira in produzione deve corrispondere, sempre, a ciò che è scritto in un repository.
I principi
GitOps si basa su quattro principi, spesso formulati così:
- Dichiarativo: lo stato desiderato del sistema è descritto in file, non in sequenze di comandi.
- Versionato e immutabile: quei file stanno in Git, con la cronologia completa di ogni modifica.
- Applicato automaticamente: un agente legge il repository e porta il sistema allo stato descritto.
- Riconciliato continuamente: l'agente controlla di continuo che il sistema reale non si discosti da quello dichiarato e, se succede, lo corregge o lo segnala.
La conseguenza pratica è che non si fanno modifiche direttamente sui sistemi. Per rilasciare una nuova versione si modifica un file nel repository, si apre una richiesta di revisione e, una volta approvata e unita, l'agente applica il cambiamento.
Push e pull
Le pipeline tradizionali seguono un modello push: al termine dei test, la pipeline si collega al cluster o al server e vi applica le modifiche. Per farlo deve possedere credenziali di accesso alla produzione.
GitOps usa di solito un modello pull: un agente che gira dentro il cluster osserva il repository e scarica le modifiche. La differenza ha conseguenze importanti.
| Aspetto | Modello push | Modello pull |
|---|---|---|
| Chi applica le modifiche | La pipeline di CI | Un agente nel cluster |
| Credenziali di produzione | Nella pipeline | Solo nel cluster |
| Rilevamento delle modifiche manuali | Assente | Continuo |
| Accesso di rete necessario | Dalla CI verso il cluster | Dal cluster verso Git |
Con il modello pull il cluster non deve accettare connessioni dall'esterno per ricevere i rilasci, e il servizio di CI non conserva chiavi di produzione. Se la pipeline viene compromessa, l'attaccante non ottiene direttamente l'accesso al cluster.
Come si organizza il lavoro
Una struttura frequente prevede due tipi di repository.
- Il repository dell'applicazione contiene il codice. La sua pipeline esegue i test, costruisce l'immagine container e la pubblica con un'etichetta univoca.
- Il repository di configurazione contiene i manifesti che descrivono cosa deve girare in ciascun ambiente: quale immagine, quante repliche, quali parametri.
Al termine della build, la pipeline dell'applicazione apre automaticamente una modifica al repository di configurazione, aggiornando l'etichetta dell'immagine per l'ambiente di staging. Il rilascio in produzione è un'altra modifica allo stesso repository, approvata da chi ne ha la responsabilità.
Tenere separati i due repository evita che ogni modifica al codice generi rilasci non voluti e permette di dare permessi diversi a chi sviluppa e a chi approva i rilasci in produzione.
Gli strumenti
Gli strumenti GitOps più diffusi sono pensati per Kubernetes:
- Argo CD offre un'interfaccia grafica che mostra lo stato di ogni applicazione, le differenze tra repository e cluster e la cronologia delle sincronizzazioni;
- Flux è più minimale, si configura interamente tramite file e si integra con gli strumenti di gestione dei pacchetti di Kubernetes.
Entrambi leggono manifesti scritti direttamente o generati con strumenti come Helm e Kustomize. Il principio è applicabile anche fuori da Kubernetes, per esempio con infrastruttura come codice applicata automaticamente all'unione di una modifica, ma è lì che ha trovato la sua forma più matura.
Il nodo dei segreti
Se tutto deve stare in Git, dove vanno le password? Non in chiaro, ovviamente. Le soluzioni principali sono due:
- segreti cifrati nel repository, con strumenti come Sealed Secrets o SOPS: il file è cifrato e solo il cluster possiede la chiave per decifrarlo;
- riferimenti a un secret manager esterno: nel repository c'è solo il nome del segreto, e un componente nel cluster recupera il valore dal servizio dedicato.
La seconda soluzione è di solito preferibile per i segreti più sensibili, perché rotazione e revoca avvengono in un unico punto.
Rollback e verifica
Uno dei vantaggi più concreti di GitOps è il rollback: tornare alla versione precedente significa annullare un commit. La cronologia di Git diventa anche un registro degli interventi: chi ha rilasciato cosa, quando e con l'approvazione di chi. In ambienti con requisiti di verifica o certificazione, questo registro si ottiene senza strumenti aggiuntivi.
Quando conviene
GitOps dà il meglio con molti servizi, più ambienti e più persone che rilasciano. Per un singolo server con un'applicazione, un agente di riconciliazione è spesso una complessità superflua: una pipeline che applica le modifiche dopo i test ottiene buona parte dei benefici. Nel mio lavoro lo propongo quando i rilasci sono frequenti e serve sapere con certezza, in ogni momento, cosa sta girando in produzione.
In sintesi
- GitOps fa di un repository Git l'unica fonte di verità su ciò che gira in ogni ambiente.
- Le modifiche passano solo da commit revisionati; un agente le applica e corregge le deviazioni.
- Il modello pull tiene le credenziali di produzione dentro il cluster e fuori dalla pipeline.
- Argo CD e Flux sono gli strumenti più diffusi; i segreti vanno cifrati o letti da un secret manager.
- Il rollback diventa un semplice ritorno a un commit precedente, ma per progetti piccoli l'approccio può essere eccessivo.
