La maggior parte di noi, notando un nuovo termine nel blog IT o in una conferenza, prima o poi si pone una domanda simile: "Che cos'è? È solo un termine alla moda, un 'buzzword', o è davvero qualcosa che merita attenzione, studio e promette nuovi orizzonti?" Anch'io mi sono trovato nella stessa situazione con il termine GitOps un po' di tempo fa. Armato di una vasta gamma di articoli esistenti e la conoscenza dei colleghi della società , ho cercato di capire di cosa si trattasse e come il suo utilizzo potrebbe apparire nella pratica.
A proposito, la novità del termine GitOps è confermata da un sondaggio che abbiamo recentemente condotto: più della metà degli intervistati non ha ancora iniziato a lavorare con i suoi principi.
Dunque, il problema della gestione dell'infrastruttura non è nuovo. Molti fornitori di servizi cloud sono disponibili al pubblico da oltre un decennio e, a quanto pare, avrebbero dovuto semplificare il lavoro dei team responsabili dell'infrastruttura. Tuttavia, rispetto al processo di sviluppo delle applicazioni (dove il livello di automazione raggiunge orizzonti sempre nuovi), i progetti infrastrutturali comportano ancora molte attività eseguite manualmente e richiedono conoscenze e specialisti particolari, soprattutto considerando le attuali esigenze di resilienza, flessibilità, scalabilità ed elasticità.
I servizi cloud hanno soddisfatto con successo questi requisiti e sono stati proprio loro a dare un impulso significativo allo sviluppo dell'approccio IaC. Ed è comprensibile. Infatti, essi hanno reso possibile configurare un data center virtuale completo: niente server fisici, rack, componenti di rete; tutta l'infrastruttura può essere descritta tramite script e file di configurazione.
Dunque, qual è esattamente la differenza GitOps di IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Tutto il codice è memorizzato in un repository git
La versioning del codice non è obbligatoria
Descrizione dichiarativa del codice / Idempotenza
È permesso sia una descrizione dichiarativa che imperativa
Le modifiche entrano in vigore tramite meccanismi di Merge Request / Pull Request
La concordanza, l'approvazione e la collaborazione non sono obbligatorie
Il processo di rilascio degli aggiornamenti è automatizzato
Il processo di rilascio degli aggiornamenti non è normalizzato (automatico, manuale, copia di file, tramite linea di comando, ecc.)
In altre parole GitOps è nato proprio grazie all'applicazione dei principi IaC. Innanzitutto, le infrastrutture e le configurazioni possono ora essere memorizzate esattamente come le applicazioni. Il codice è facile da conservare, condividere, confrontare e sfruttare le capacità di versioning. Versioni, branch, storia. E tutto questo in un luogo accessibile a tutto il team. Pertanto, l'uso di sistemi di controllo versione è stata un'evoluzione logica. In particolare, git, come il più popolare.
D'altra parte, è emersa la possibilità di automatizzare i processi di gestione dell'infrastruttura. Ora è possibile farlo più velocemente, in modo più affidabile e a costi inferiori. Inoltre, i principi del CI/CD erano già noti e popolari tra gli sviluppatori di software. Era solo necessario trasferire e applicare le già consolidate conoscenze e competenze in un nuovo ambito. Queste pratiche, tuttavia, andavano oltre la definizione standard di Infrastruttura come Codice, da cui è nato il concetto GitOps.
Curiosità GitOps, ovviamente, sta anche nel fatto che non si tratta di un prodotto, un plugin o una piattaforma legata a un particolare fornitore. È piuttosto una paradigma e un insieme di principi, simile a un altro termine a noi familiare: DevOps.
Nell'azienda Abbiamo elaborato due definizioni di questo nuovo termine: teorica e pratica. Iniziamo con la teoria:
GitOps è una metodologia che utilizza i principi avanzati del DevOps applicati allo sviluppo delle applicazioni, come il controllo delle versioni, la collaborazione, l'approvazione, il CI/CD, e li applica per risolvere le sfide dell'automazione nella gestione dell'infrastruttura.
Tutti i processi GitOps lavorano utilizzando strumenti già esistenti. Tutto il codice infrastrutturale è conservato nel già noto repository git, le modifiche seguono lo stesso processo di approvazione di qualsiasi altro codice software e il processo di distribuzione è automatizzato, riducendo al minimo gli errori umani, aumentando l'affidabilità e la riproducibilità.
Da un punto di vista pratico, descriviamo GitOps nel seguente modo:
L'Infrastruttura come Codice è stata già discussa come uno degli elementi chiave di questa formula. Ora immaginiamo gli altri partecipanti.
Merge Request (nome alternativo di Pull Request). Nel processo MR, si tratta di una richiesta per applicare modifiche al codice e successivamente unire i rami. Ma per quanto riguarda gli strumenti che utilizziamo, è più che altro la possibilità di ottenere una visione completa di tutte le modifiche apportate: non solo le differenze di codice, raccolte da un certo numero di commit, ma anche il contesto, i risultati dei test e il risultato finale atteso. Se parliamo di codice infrastrutturale, ci interessa sapere come cambierà effettivamente l'infrastruttura, quanti nuovi risorse saranno aggiunti o rimossi, modificati. Preferibilmente in un formato più comodo e leggibile. Nel caso dei provider cloud, sarebbe utile sapere quali conseguenze finanziarie comporterà questa modifica.
Ma MR è anche uno strumento di collaborazione, interazione, comunicazione. Il luogo in cui entra in gioco il sistema di controlli e bilanciamenti. Dai semplici commenti alle approvazioni formali e alle approvazioni.
E l'ultimo componente: CI/CD, come sappiamo, consente di automatizzare il processo di introduzione delle modifiche infrastrutturali, testando (da un semplice controllo di sintassi a un'analisi statica del codice più complessa). E anche successivamente rilevare il drift: le differenze tra lo stato reale e quello desiderato del sistema. Ad esempio, a causa di modifiche manuali non autorizzate o di un guasto dei sistemi.
Sì, il termine GitOps non introduce nulla di completamente nuovo, non inventa la ruota, ma semplicemente applica l'esperienza accumulata in un nuovo ambito. Ma è proprio in questo che risiede la sua forza.
E se ti interessa sapere come si presenta tutto ciò nella pratica, ti invitiamo a guardare il nostro in cui ti spiego passo dopo passo come utilizzare GitLab:
Attuare i principi fondamentali di GitOps
Creare e modificare l'infrastruttura cloud (esempio di Yandex Cloud)
Automatizzare il rilevamento del drift del sistema rispetto allo stato desiderato mediante monitoraggio attivo
https://bit.ly/34tRpwZ
Fonte: habr.com
