Anche in presenza di piattaforme come Kubernetes, che permettono di gestire l’organizzazione dei container, non è sempre semplice gestire e predisporre delle applicazioni basate sui container in esecuzione su sistemi a cluster o nel cloud. L’approccio di GitOps mira a sfruttare le esperienze e gli strumenti tratti dal lavoro dello sviluppatore per facilitare l’impiego delle applicazioni. Alla base ci sono quattro principi:

• La descrizione dichiarativa: le risorse vengono descritte con un linguaggio formale chiarendone lo stato di riferimento auspicato.
• Automazione: la trasposizione delle descrizioni dal repository all’ambiente di runtime deve essere totalmente automatizzata e riproducibile e deve condurre allo stesso risultato anche se viene effettuata più volte.
• «Single Source of Truth»: lo stato del sistema deve essere descritto in modo esaustivo e univoco. Esiste una sola fonte da cui poter consultare lo stato generale del sistema.
• Reconciliation: gli operatori di software sincronizzano lo stato attuale del sistema con quello auspicato. Non appena si constatano delle divergenze, vengono apportati interventi mirati.

GitOps come modello di esercizio per Kubernetes

Per garantire l’impiego di un sistema software, è necessaria una catena di fornitura che metta a disposizione le diverse versioni dei software consentendo anche di modificare le configurazioni. In questo modo, si crea un collegamento tra Continuous Delivery (CD) e il concreto deployment e funzionamento dell’applicazione. L’approccio di Kubernetes consente una descrizione dichiarativa delle risorse. In tale contesto, è possibile descrivere lo stato dell’attuale applicazione  (ad es. tre istanze dell’applicazione X nella versione Y con due CPU e 500 MB RAM ciascuna) e Kubernetes esegue il necessario affinché le relative componenti vengano avviate. Sfruttando questa procedura è già possibile attuare i primi due principi di base di GitOps mediante Kubernetes.

GitOps è la «Single Source of Truth» e, come suggerisce il suo nome, si serve della gestione delle versioni Git. Così lo stato del sistema auspicato viene sempre salvato con trasparenza e risulta aggiornato e documentabile nell’ambiente designato. La tracciabilità consente di reperire le modifiche rendendo più semplice anche il rollback a una versione precedente. Un ulteriore vantaggio di Git consiste nella possibilità di consultare, tramite un sistema di branching, le modifiche apportate mediante richieste di pull, permettendo quindi di individuare eventuali errori di configurazione prima che questi compromettano il sistema stesso.

Il quarto (e imprescindibile) principio di base di GitOps consiste nella sincronizzazione dello stato del runtime al cluster Kubernetes con lo stato auspicato nel repository Git. Per farlo viene impiegato un cosiddetto operatore GitOps, una componente software specializzata, che viene installata su Kubernetes per svolgere tale operazione in modo automatizzato. In tal senso, PostFinance utilizza il tool «Argo CD».

I vantaggi di GitOps

• Maggiore produttività: un’automatizzazione coerente consente di focalizzarsi sulla configurazione di base in fase di sviluppo/utilizzo. L’implementazione automatica permette di ottimizzare i tempi di esecuzione.
• Tooling condiviso: sia gli sviluppatori sia gli utenti utilizzano Git, un tool di grande efficacia.
• Stabilità ed affidabilità: tutte le modifiche sono tracciabili. I rollback sono più semplici e, in caso di emergenza, è possibile effettuare rapidamente un’operazione completa di recovery grazie a una descrizione dichiarativa.
• Coerenza e standardizzazione: GitOps è un modello di esercizio che rende uniforme il processo di deployment

Ecco perché utilizziamo GitOps nell’ambito dell’IT per il settore del digital commerce

PostFinance utilizza il primo grande GitOps case nell’ambito dell’IT per il settore del digital commerce. La ragione risiede nel fatto che siamo migrati sulla piattaforma Kubernetes (on-premise) ed eravamo alla ricerca di una soluzione che ci permettesse di gestire i nostri sistemi garantendone la massima efficacia. Nonostante fosse relativamente recente, abbiamo scelto GitOps poiché permette di sviluppare uno standard per implementare le applicazioni su tali cluster. Dallo scorso autunno, infatti, ci troviamo su questo stack nell’ambito del Digital Commerce.

Da marzo 2020 gestiamo i nostri workload Kubernetes tramite GitOps. Le nostre esperienze in questa prima fase sono state estremamente positive. Da un lato, apprezziamo la facilità con cui vengono distribuiti i nuovi workload (funzioni, servizi ecc). Il sistema consente di eseguire continue modifiche in un modo estremamente più semplice e in tempi più brevi. Dall’altro, tenendo conto di tale flusso di cambiamenti, abbiamo potuto contare sempre e comunque su sistemi affidabili. La ricerca di differenze nella configurazione tra diversi ambienti si riduce alla configurazione nel repository Git. La reconciliation dell’operatore ci aiuta a esercitare un controllo costante sui sistemi consentendoci di individuare ed eliminare in modo standardizzato eventuali errori indesiderati.

Infine, ma non per importanza, siamo soggetti a rigorose regolamentazioni in materia di tracciabilità e «Segregation of Duties» nell’ambito del Digital Commerce. Con GitOps siamo riusciti a trovare il giusto equilibrio tra tutte queste disposizioni grazie al pensiero DevOps. Per noi oggi i cambiamenti produttivi non sono più delle semplici richieste di pull che confluiscono nella produzione in modo diretto e automatizzato dopo un processo di verifica e fusione.