Che cos'è GitOps?

Sebbene gran parte del ciclo di sviluppo del software sia stato automatizzato, l'infrastruttura rimane un processo perlopiù manuale che richiede l'intervento di team specializzati. Al giorno d'oggi, l'automazione dell'infrastruttura è un requisito da cui non si può più prescindere. L'infrastruttura moderna deve essere elastica, in modo da poter gestire efficacemente le risorse cloud necessarie per garantire l'esecuzione continua dei deployment.

Le applicazioni moderne e cloud native sono sviluppate nell'ottica della velocità e della scalabilità. Le organizzazioni che hanno già maturato una profonda cultura DevOps sono in grado di distribuire codice in produzione centinaia di volte al giorno. I team DevOps possono raggiungere questo obiettivo adottando le migliori best practice di sviluppo come il controllo della versione, la revisione del codice e le pipeline CI/CD che automatizzano i test e i deployment.

GitOps viene utilizzato per automatizzare il processo di provisioning dell'infrastruttura, in particolare dell'infrastruttura cloud moderna. Analogamente ai team che sfruttano il codice sorgente dell'applicazione, i team operativi che adottano GitOps utilizzano i file di configurazione archiviati come codice (Infrastructure as Code). I file di configurazione GitOps generano lo stesso ambiente infrastrutturale ogni volta che viene eseguito il deployment, proprio come il codice sorgente produce gli stessi binari dell'applicazione ogni volta che il codice stesso viene sviluppato.

GitOps non è un singolo prodotto, né un plugin o una piattaforma. Non esiste una sola risposta a questa domanda: il modo migliore per mettere in pratica GitOps varia a seconda delle esigenze e degli obiettivi specifici del team. Tuttavia, prima di iniziare a utilizzare GitOps, occorre approntare alcuni accorgimenti, come l'utilizzo di un repository GitOps dedicato per tutti i membri del team per condividere le configurazioni e il codice, l'automatizzazione del deployment delle modifiche al codice e la configurazione di avvisi da notificare al team ogni volta che vengono apportate delle modifiche.

GitOps richiede tre componenti principali:

IaC:

GitOps utilizza un repository Git come unica fonte di riferimento per le definizioni dell'infrastruttura. Git è un sistema di controllo della versione open-source che monitora le modifiche alla gestione del codice, mentre un repository Git è una cartella .git contenuta in un progetto che tiene traccia di tutte le modifiche apportate ai file di quel determinato progetto nel corso del tempo. L'espressione Infrastructure as Code (IaC) definisce la pratica di mantenere memorizzata come codice l'intera configurazione dell'infrastruttura. Lo stato effettivo desiderato potrebbe anche non essere archiviato come codice (ad esempio, il numero di repliche o di pod).

RM:

GitOps utilizza le richieste di merge (RM) o le richieste di pull (RP) come meccanismo di modifica per tutti gli aggiornamenti dell'infrastruttura. La RM o la RP sono le sedi in cui i team possono collaborare inserendo commenti, proponendo revisioni e approvando formalmente le modifiche. Un commit di merge viene eseguito sul ramo principale (o trunk) e funge da log o traccia di controllo.

CI/CD:

GitOps automatizza gli aggiornamenti dell'infrastruttura utilizzando un flusso di lavoro Git con integrazione e distribuzione continue (CI/CD). Una volta eseguito il merge del codice, la pipeline CI/CD mette in atto la modifica nell'ambiente. Qualsiasi deriva della configurazione, come modifiche manuali o errori, viene sovrascritta dall'automazione GitOps in modo che l'ambiente converga nello stato desiderato definito in Git. GitLab utilizza le pipeline CI/CD per gestire e implementare l'automazione GitOps, tuttavia è possibile utilizzare anche altre forme di automazione, come gli operatori delle definizioni.

Quando si punta a rafforzare la collaborazione fra i reparti, il cambiamento può rivelarsi ostico e GitOps non fa eccezione. Passare a GitOps vuol dire adottare un framework che richiede un certo grado di disciplina e impegno da parte degli utenti. I team che lo scelgono sono chiamati a prestare particolare attenzione.

Per quando conceda ampi margini di collaborazione, GitOps può rivelarsi uno strumento poco immediato per alcune persone e organizzazioni. In base al processo di approvazione GitOps, gli sviluppatori apportano le modifiche al codice e creano una richiesta di merge, un approvatore esegue il merge delle modifiche e infine viene effettuato il deployment. Questa sequenza introduce nell'infrastruttura un elemento di "modifica effettuata dall'autore del commit", un passaggio apparentemente noioso e dispendioso in termini di tempo per gli specialisti abituati ad apportare modifiche manuali con rapidità.

È importante che tutti i membri del team documentino sistematicamente cosa accade nelle richieste di merge e nei ticket. Per quanto sia difficile resistere alla tentazione di modificare un elemento direttamente in produzione o di cambiarlo manualmente, GitOps funziona meglio se viene lasciato poco spazio al cowboy engineering.

GitOps offre molti vantaggi, tra cui una maggiore efficienza e sicurezza, una migliore esperienza d'uso per gli sviluppatori, costi ridotti e deployment più rapidi.

Grazie a GitOps, le organizzazioni possono gestire l'intera infrastruttura e il ciclo di sviluppo delle applicazioni utilizzando un unico strumento centralizzato. Ne consegue un miglioramento in termini di qualità della collaborazione e del coordinamento fra i vari team, così come un minor numero di errori e una risoluzione più rapida dei problemi.

Inoltre, GitOps può aiutare le organizzazioni a sfruttare i container e i microservizi e a mantenere un certo grado di coerenza in tutta l'infrastruttura, dalle configurazioni dei cluster Kubernetes alle immagini Docker, passando per le istanze cloud e qualsiasi elemento disponibile a livello locale.

Esistono alcune differenze fondamentali tra GitOps e DevOps. In primo luogo, GitOps si basa essenzialmente sull'automazione e sugli strumenti di gestione e di deployment delle modifiche al codice, mentre DevOps si concentra maggiormente sulla comunicazione e sulla collaborazione fra i team. Inoltre, GitOps viene in genere utilizzato in combinazione con tecnologie di containerizzazione come Kubernetes, mentre DevOps può essere impiegato con qualsiasi tipo di applicazione.

GitOps è un ramo di DevOps che si concentra sull'utilizzo dei repository di codice Git per gestire l'infrastruttura e i deployment del codice applicativo. La differenza principale tra i due è che la fonte di riferimento per lo stato del deployment in GitOps corrisponde al repository Git, mentre in DevOps tale ruolo è demandato ai file di configurazione dell'applicazione o del server.

Per flusso di lavoro GitOps si intende un approccio sistematico e con controllo della versione alla gestione dell'infrastruttura e delle applicazioni. Ciò vuol dire approcciarsi alle operazioni di sistema con lo stesso rigore che ci si aspetterebbe dalla codebase. In GitOps, i repository Git fungono da unica fonte di riferimento per le configurazioni di sistema e dell'infrastruttura.

Le modifiche alle configurazioni vengono apportate tramite richieste di pull, garantendo revisioni paritarie e tracce di controllo per gli aggiornamenti. Gli strumenti automatizzati implementano questi cambiamenti, permettendo l'esecuzione di deployment coerenti e riproducibili. Questa metodologia garantisce un'elevata velocità, agevola la collaborazione fra i membri del team e aumenta l'efficienza operativa grazie a una documentazione chiara e una tracciabilità evidente.

Componenti chiave di un flusso di lavoro GitOps

Un flusso di lavoro GitOps si basa su quattro componenti fondamentali, ognuno dei quali svolge un ruolo essenziale ai fini dell'ottimizzazione del deployment e della gestione delle applicazioni.

1. Repository Git: rappresenta l'elemento essenziale che funge da unica fonte di riferimento sia per il codice dell'applicazione che per la sua configurazione. Memorizzando tutte le informazioni critiche nel repository Git, i team sono in grado di garantire coerenza e trasparenza durante l'intero ciclo di sviluppo.

2. Pipeline di distribuzione continua (CD): la pipeline CD automatizza i processi di sviluppo, test e deployment dell'applicazione colmando il divario fra la scrittura e il deployment del codice e agevolando la transizione dagli ambienti di sviluppo a quelli di produzione, garantendo al contempo la conformità dell'applicazione rispetto agli standard di qualità.

3. Strumento di deployment dell'applicazione: questo strumento si occupa di eseguire il deployment dell'applicazione nell'ambiente desiderato. Gestisce l'orchestrazione e la gestione delle risorse applicative, facendo in modo che il deployment dell'applicazione venga eseguito in modo corretto ed efficiente, secondo le configurazioni definite nel repository Git.

4. Sistema di monitoraggio: essenziale per il mantenimento dell'integrità dell'applicazione, il sistema di monitoraggio vigila sulle prestazioni. Raccoglie dati e fornisce al team di sviluppo approfondimenti e feedback utili, permettendo agli sviluppatori di prendere decisioni consapevoli e affrontare rapidamente eventuali problemi.

Insieme, questi componenti creano un flusso di lavoro GitOps coerente che non solo migliora l'efficienza e l'affidabilità dei deployment dell'applicazione ma si allinea anche alle moderne pratiche DevOps mettendo in primo piano l'automazione, il monitoraggio e il miglioramento continuo.