GitOps: tutto ciò che c’è da sapere sull’in­fra­strut­tu­ra IT au­to­ma­tiz­za­ta

GitOps è un framework operativo che mediante un approccio di­chia­ra­ti­vo permette di gestire in­fra­strut­tu­re e ap­pli­ca­zio­ni e di con­trol­lar­le grazie a Git. Gli obiettivi di tale metodo sono l’au­to­ma­zio­ne dei processi, il risparmio di tempo e una col­la­bo­ra­zio­ne migliore e più sicura tra i singoli team sui re­po­si­to­ry.

L’au­to­ma­zio­ne gioca un ruolo fon­da­men­ta­le nello sviluppo di software. È questo uno dei motivi per cui DevOps ha avuto un successo così eclatante. Alla base troviamo l’idea di “In­fra­struc­tu­re as Code (IaC)”, fi­na­liz­za­ta a mappare le in­fra­strut­tu­re e le con­fi­gu­ra­zio­ni di un sistema in­for­ma­ti­co e a renderle quindi ri­pro­du­ci­bi­li. GitOps rap­pre­sen­ta l’esten­sio­ne logica di questo approccio. Dal 2017, il software open source Git regola l’intero processo di gestione di un’ap­pli­ca­zio­ne, dall’am­mi­ni­stra­zio­ne allo sviluppo finale del software in quanto “single source of truth” (SSOT). A tal fine, GitOps definisce uno stato di ri­fe­ri­men­to e verifica l’in­fra­strut­tu­ra finché tale stato non viene raggiunto e, se ne­ces­sa­rio, la modifica.

Wea­veworks mette a di­spo­si­zio­ne una serie di best practice per uni­for­ma­re i singoli metodi di mo­ni­to­rag­gio dei container. Queste regole si possono applicare a Ku­ber­ne­tes e ad altre tec­no­lo­gie con un back­ground cloud per renderle più facili da gestire. Git deriva da un sistema di controllo delle versioni svi­lup­pa­to da Linus Torvald nel 2005 e consente a diversi team di sviluppo di lavorare insieme a un progetto. Eventuali modifiche vengono applicate solo previo unanime consenso e a con­di­zio­ne che vengano mantenuti gli stati di sviluppo più datati. Questo consente di lavorare con­tem­po­ra­nea­men­te su aspetti diversi e unirli alla fine. Se abbiamo ri­sve­glia­to la vostra curiosità, nella nostra Digital Guide trovate un tutorial completo su Git.

Nel caso di GitOps, lo stato di de­sti­na­zio­ne di un sistema viene prima descritto in modo di­chia­ra­ti­vo. Suc­ces­si­va­men­te, le modifiche vengono apportate secondo il principio di Git per mezzo di richieste pull. Una volta eseguite, cambiano il re­po­si­to­ry Git. In un ambiente GitOps, quando viene inviata una richiesta pull, l’operatore GitOps si attiva, memorizza il commit e richiede lo stato corrente via Git. Lo stato corrente viene poi con­fron­ta­to con lo stato de­si­de­ra­to nel re­po­si­to­ry. Nel momento in cui sono approvate, le modifiche vengono accorpate allo stato pre­ce­den­te e tra­sfe­ri­te di­ret­ta­men­te all’in­fra­strut­tu­ra live. In questo modo si ottengono processi più rapidi e fluidi, ma so­prat­tut­to un sistema più stabile e af­fi­da­bi­le.

Grazie a principi chia­ra­men­te definiti e im­mu­ta­bi­li, i flussi di lavoro GitOps sono in grado di fun­zio­na­re sempre in modo af­fi­da­bi­le. In­nan­zi­tut­to, si tratta dei sistemi di­chia­ra­ti­vi descritti, già noti ad altri cloud nativi. Una de­scri­zio­ne di­chia­ra­ti­va fa sì che l’intero sistema possa essere con­si­de­ra­to come codice e sot­to­po­sto al controllo delle versioni. Questo con­tri­bui­sce alla sicurezza e alla stabilità dell’intero sistema, poiché le de­via­zio­ni dalla versione Git possono essere im­me­dia­ta­men­te ri­co­no­sciu­te e segnalate. In più, le chiavi SSH per­met­to­no di rin­trac­cia­re sempre l’origine del codice. Grazie alla di­chia­ra­zio­ne pre­ven­ti­va, anche le modifiche possono essere au­to­ma­tiz­za­te e si possono in­di­vi­dua­re e cor­reg­ge­re tem­pe­sti­va­men­te le possibili fonti di errore.

La filosofia prin­ci­pa­le di DevOps è sempre stata quella di av­vi­ci­na­re sviluppo ed ese­cu­zio­ne per ot­ti­miz­za­re i flussi di lavoro. Dal momento che i singoli team lavorano a stretto contatto, il prodotto finale sarà migliore e le modifiche potranno essere apportate in modo più rapido e accurato. Questo approccio viene ripreso da GitOps e applicato coe­ren­te­men­te alla parte di ese­cu­zio­ne (ope­ra­zio­ni). GitOps si concentra in­te­ra­men­te su Git, mentre DevOps e DevSecOps sono più che altro un’idea di fondo che promuove la col­la­bo­ra­zio­ne tra aree pre­ce­den­te­men­te separate e si basa su pipeline CI e CD. A ogni modo, si possono combinare entrambi gli approcci.

A dif­fe­ren­za di Con­ti­nuous Delivery e Con­ti­nuous In­te­gra­tion, GitOps ricava tutte le in­for­ma­zio­ni im­por­tan­ti di­ret­ta­men­te da Git secondo il principio pull senza ricorrere al de­ploy­ment tramite un server CI. L’uso del server CI con GitOps è ancora possibile, tuttavia si limita a eseguire le fasi di co­stru­zio­ne e di test. Per saperne di più su Con­ti­nuous In­te­gra­tion, Con­ti­nuous Delivery e Con­ti­nuous De­ploy­ment, con­sul­ta­te la Digital Guide.

Data la sua ver­sa­ti­li­tà, pro­ba­bil­men­te Ku­ber­ne­tes rap­pre­sen­ta la piat­ta­for­ma più im­por­tan­te per la gestione di ap­pli­ca­zio­ni basate su container. Esso funziona anche in modo di­chia­ra­ti­vo e tiene conto dello stato di de­sti­na­zio­ne di un sistema. Pertanto, può fun­zio­na­re per­fet­ta­men­te con GitOps e persino agire come operatore. Tuttavia, per una migliore visione d’insieme e per motivi di sicurezza, è im­por­tan­te che il codice sorgente e la con­fi­gu­ra­zio­ne rimangano separati. Lo stato attuale può essere me­mo­riz­za­to in un re­po­si­to­ry Git separato. Inoltre, occorre avvalersi di strumenti di sin­cro­niz­za­zio­ne ap­pro­pria­ti che im­pe­di­sca­no l’accesso non au­to­riz­za­to ed eventuali errori.

Al momento esistono numerosi strumenti per GitOps che puntano a sem­pli­fi­ca­re e mi­glio­ra­re in modo si­gni­fi­ca­ti­vo l’au­to­ma­zio­ne, ad esempio strumenti per lavorare con Ku­ber­ne­tes che agiscono come operatori e si fanno carico dell’im­ple­men­ta­zio­ne di GitOps. L’operatore (o custom con­trol­ler) più rinomato è Flux. Tra le al­ter­na­ti­ve troviamo ArgoCD o Fleet. Tra gli strumenti più im­por­tan­ti per una maggiore sicurezza si an­no­ve­ra­no SOPS di Mozilla e Sealed Secrets di Bitnami. Cluster API e Fleet sono par­ti­co­lar­men­te adatti per essere uti­liz­za­ti con i cluster Ku­ber­ne­tes. In generale, il mercato è re­la­ti­va­men­te vasto, pertanto esiste uno strumento adatto a quasi tutte le ap­pli­ca­zio­ni.

Per ri­spon­de­re fi­nal­men­te alla domanda su quanto GitOps sia davvero valido e adatto ai vostri scopi, è opportuno valutarne i vantaggi e gli svantaggi.

• Pro­dut­ti­vi­tà: at­tra­ver­so l’au­to­ma­zio­ne è possibile apportare un numero net­ta­men­te superiore di modifiche in tempi più brevi. Questo consente agli svi­lup­pa­to­ri di portare avanti i progetti in modo molto più efficace.
• Sicurezza e stabilità: la pre­ci­sio­ne dei controlli consente di rilevare più ra­pi­da­men­te gli errori e di cor­reg­ger­li au­to­ma­ti­ca­men­te. Ciò con­tri­bui­sce a ottenere maggiore sicurezza e stabilità. Il ri­pri­sti­no delle versioni pre­ce­den­ti è molto più semplice sia grazie a rollback re­si­lien­ti sia grazie all’approccio pull che evita com­pli­ca­zio­ni in­de­si­de­ra­te.
• Omo­ge­nei­tà: at­tra­ver­so GitOps i flussi di lavoro sono unificati. La col­la­bo­ra­zio­ne è migliore e più semplice e consente di entrare più ra­pi­da­men­te nel flusso di lavoro anche ai nuovi arrivati.

• Se­pa­ra­zio­ne di CI e CD: con­si­de­ra­ta la rigida se­pa­ra­zio­ne tra CI e CD nell’approccio GitOps, potrebbe rivelarsi difficile eseguire i test in seguito al de­ploy­ment.
• Visione d’insieme poco chiara: spe­cial­men­te nel caso di ambienti multipli, è facile che GitOps risulti di­so­rien­tan­te. La presenza di numerosi re­po­si­to­ry e con­fi­gu­ra­zio­ni può con­tri­bui­re a generare con­fu­sio­ne.