GitOps è la prossima grande novità in DevOps?
Molte organizzazioni ora vedono DevOps come parte della loro strategia di trasformazione digitale, poiché questa metodologia incoraggia una cultura di responsabilità condivisa, trasparenza e feedback più rapidi. Eppure, mentre il divario tra i team di sviluppo e quelli delle operazioni si riduce, lo stesso succede con i processi.
Lo stesso accade con Git, il sistema di controllo delle versioni attualmente più utilizzato a livello globale. Man mano che le aziende adottano le metodologie DevOps, lo stesso fanno gli strumenti, determinando un'evoluzione verso GitOps, un insieme di pratiche che consentono agli sviluppatori di svolgere più task legati alle operazioni IT.
Che cos'è GitOps?
In sostanza, GitOps è un'infrastruttura e un insieme di procedure operative basate su codice che utilizzano Git come sistema di controllo del codice sorgente. È un'evoluzione di Infrastructure as Code (IaC) e una best practice DevOps che sfrutta Git come unica origine di riferimento e unico meccanismo di controllo per la creazione, l'aggiornamento e l'eliminazione dell'architettura di sistema. Più semplicemente, è la pratica che consiste nell'utilizzare le pull request Git per verificare e distribuire automaticamente le modifiche all'infrastruttura di sistema.
Oltre a Git come meccanismo DevOps chiave, GitOps viene utilizzato anche per descrivere gli strumenti che potenziano le funzionalità predefinite di Git. Questi strumenti sono stati utilizzati principalmente con modelli operativi per infrastrutture e applicazioni basate su Kubernetes. Ci sono continui sviluppi e discussioni all'interno della comunità DevOps per portare gli strumenti GitOps su altre piattaforme non Kubernetes, come Terraform.
GitOps garantisce che l'infrastruttura cloud di un sistema sia immediatamente riproducibile in base allo stato di un repository Git. Le pull request modificano lo stato del repository Git. Una volta approvate e sottoposte a merge, le pull request riconfigurano e sincronizzano automaticamente l'infrastruttura live con lo stato del repository. Questo flusso di lavoro delle pull request con sincronizzazione in tempo reale è l'essenza principale di GitOps.
materiale correlato
Scheda di riferimento rapido di Git
Scopri la soluzione
Impara a utilizzare Git con Bitbucket Cloud
La storia di GitOps
Git è uno strumento mission-critical per lo sviluppo di software che rende disponibili flussi di lavoro di pull request e revisione del codice. Le pull request promuovono la visibilità nelle modifiche apportate a una base di codice e incoraggiano la comunicazione, la discussione e la revisione delle modifiche.
Le pull request sono una funzione fondamentale nello sviluppo di software collaborativo e hanno cambiato il modo in cui i team e le aziende compilano il software. Le pull request apportano trasparenza e misurabilità a un processo che in precedenza era poco chiaro. Le pull request Git hanno contribuito all'evoluzione dei processi DevOps nello sviluppo del software. Gli amministratori di sistema, che in genere erano riluttanti al cambiamento, stanno ora adottando nuove pratiche di sviluppo software come Agile e DevOps.
L'amministrazione dei sistemi come mestiere ha una storia poco chiara. In precedenza, gli amministratori di sistema gestivano l'hardware manualmente connettendosi ai computer ed effettuandone il provisioning in un rack di server fisico o tramite un'API di provisioning cloud. Oltre al processo di provisioning manuale, veniva inoltre svolto regolarmente un numero elevato di operazioni di configurazione manuale. Gli amministratori conservavano raccolte personalizzate di configurazioni e script imperativi, le mettevano insieme e le sistemavano in posizioni diverse. Questi script potevano interrompersi in qualsiasi momento o andare persi. La collaborazione era un task impegnativo in quanto le toolchain personalizzate non venivano documentate o condivise con regolarità.
Il movimento DevOps è nato da questo brodo primordiale dell'amministrazione dei sistemi. DevOps ha preso in prestito le migliori idee dalla progettazione software e le ha applicate all'amministrazione dei sistemi, dove gli strumenti messi insieme sono diventati codice controllato dalla versione.
IAC è una delle più grandi rivelazioni di DevOps. In precedenza gli amministratori di sistema preferivano gli script imperativi personalizzati per la configurazione dei sistemi. Il software imperativo segue una serie di passaggi per raggiungere lo stato desiderato, ad esempio:
Il software imperativo è spesso soggetto ad errori ed è facile da danneggiare se viene modificata la sequenza degli eventi. Lo sviluppo di software moderno si è allontanato dai modelli imperativi per dirigersi verso modelli di software dichiarativi.
Il software dichiarativo segue una dichiarazione dello stato previsto anziché una sequenza di comandi. Ecco un confronto tra istruzioni DevOps imperative e dichiarative.
Le istruzioni imperative potrebbero essere:
- Installare un sistema operativo su questo computer
- Installare queste dipendenze
- Scaricare il codice da questo URL
- Spostare il codice in questa directory
- Ripetere questi passaggi per 3 volte per altri 3 computer
La versione dichiarativa sarebbe invece: Il software di questo URL è installato su 4 computer in questa directory.
IaC incoraggia e promuove l'uso degli strumenti dichiarativi di amministrazione del sistema rispetto alle soluzioni imperative personalizzate. Ciò ha portato alla nascita di tecnologie come Docker Containers, Ansible, Terraform e Kubernetes, che utilizzano file di configurazione dichiarativi statici. La leggibilità da parte dell'uomo e lo stato riproducibile coerente sono annoverati tra i risultati positivi. Questi file di configurazione sono stati naturalmente aggiunti a Git per il monitoraggio e la revisione. Ci stiamo avvicinando a GitOps, ma non ci siamo ancora.
Molti dei problemi tradizionali di amministrazione del sistema sono stati risolti a questo punto della storia di DevOps. I file e gli strumenti di configurazione sono ora archiviati in una posizione centrale e sono documentati e accessibili da molti membri del team. I commit e le pull request venivano utilizzati per tenere traccia delle modifiche alla configurazione e favorire la discussione e la revisione della collaborazione. L'unico problema rimasto in questa fase riguarda il fatto che la configurazione sembra ancora disconnessa dal sistema live. Una volta che una pull request di configurazione viene approvata e sottoposta a merge nel repository, il sistema live viene aggiornato manualmente in modo da corrispondere allo stato del repository statico. Questo è esattamente il problema risolto da GitOps.
L'idea di GitOps è stata inizialmente pensata e condivisa da WeaveWorks, una società di gestione Kubernetes aziendale e da allora è proliferata in tutta la comunità DevOps. GitOps è un'estensione di IaC e della configurazione dichiarativa descritta sopra. GitOps aggiunge un po' di magia al flusso di lavoro delle pull request per la sincronizzazione dello stato del sistema live con quello del repository di configurazione statico.
I vantaggi di GitOps
Molti dei vantaggi offerti da GitOps coincidono con quelli del flusso di lavoro di sviluppo software del branch di funzioni Agile. Il primo grande vantaggio è la facilità di adozione dovuta all'utilizzo di strumenti comuni. Git è di fatto lo standard dei sistemi di controllo delle versioni ed è uno strumento di sviluppo software comune per la maggior parte degli sviluppatori e dei team software. In funzione di questo, gli sviluppatori che hanno familiarità con Git possono diventare collaboratori interfunzionali e partecipare a GitOps con più facilità.
L'utilizzo di un sistema di controllo delle versioni consente ai team di tenere traccia di tutte le modifiche alla configurazione di un sistema. Ciò rende disponibile un'"origine di riferimento" e un prezioso audit trail da esaminare se qualcosa si interrompe o presenta un comportamento imprevisto. I team possono esaminare la cronologia di GitOps e vedere quando è stata introdotta una regressione. Inoltre, questo audit trail può essere utilizzato come riferimento per il controllo della conformità o della sicurezza. La cronologia di GitOps può essere utilizzata anche come prova quando vengono modificati o aggiornati elementi come i certificati di crittografia.
GitOps fornisce trasparenza e chiarezza maggiori sulle esigenze di infrastruttura delle organizzazioni con un repository centrale. Il fatto che tutte le configurazioni di sistema si trovino in un repository centrale aiuta a ridimensionare il contributo dei membri del team. Le pull request effettuate tramite i servizi Git ospitati come Bitbucket dispongono di strumenti avanzati per la revisione del codice e l'aggiunta di commenti alle discussioni. Questo crea circuiti di comunicazione passivi tramite cui l'intero team di progettazione può osservare e monitorare le modifiche all'infrastruttura.
GitOps può incrementare notevolmente la produttività dei team DevOps. Permette loro di sperimentare rapidamente nuove configurazioni dell'infrastruttura. Se le nuove modifiche non si comportano come previsto, il team può utilizzare la cronologia di Git per ripristinarle a uno stato valido noto. Questo aspetto è incredibilmente importante poiché rende disponibile la nota funzione di "annullamento" in un'infrastruttura complessa.
Come funziona GitOps
Le procedure GitOps vengono eseguite da un sistema di orchestrazione sottostante. GitOps stesso è un modello di best practice agnostico. Molte soluzioni GitOps più diffuse oggi utilizzano principalmente Kubernetes come sistema di orchestrazione. Stanno arrivando sul mercato alcuni set di strumenti GitOps alternativi che supportano la modifica diretta di Terraform.
Per effettuare un'installazione completa di GitOps, è necessaria una piattaforma pipeline. Jenkins, Bitbucket Pipelines o CircleCi sono alcuni degli strumenti di pipeline più diffusi complementari a GitOps. Le pipeline automatizzano e colmano il divario tra le pull request Git e il sistema di orchestrazione. Una volta che gli hook della pipeline sono stabiliti e attivati dalle pull request, i comandi vengono eseguiti sul pezzo di orchestrazione.
Un nuovo schema o componente specificamente introdotto con GitOps è l'"operatore" GitOps, un meccanismo che si trova tra la pipeline e il sistema di orchestrazione. Una pull request avvia la pipeline che poi attiva l'operatore. L'operatore esamina lo stato del repository e l'avvio dell'orchestrazione e li sincronizza. L'operatore è il componente magico di GitOps.
Esempi di GitOps
Immagina che un team abbia identificato un collo di bottiglia nelle prestazioni o un picco di traffico e che si accorga che il bilanciamento del carico non funziona come previsto. Il team esamina il repository GitOps contenente la configurazione dell'infrastruttura e trova un file specifico che configura e distribuisce il bilanciamento del carico. I membri del team possono rivedere tale file sul proprio sito di hosting Git online. Dopo qualche revisione e discussione, si accorgono che alcuni dei valori di configurazione del bilanciamento del carico non sono ottimali e che devono essere modificati.
Un membro del team apre una nuova pull request che ottimizza i valori del bilanciamento del carico. La pull request viene rivista e approvata da un secondo membro del team che ne esegue il merge nel repository. Tale merge avvia una pipeline GitOps, che attiva l'operatore GitOps. L'operatore rileva che la configurazione del bilanciamento del carico è stata modificata e verifica con lo strumento di orchestrazione dei sistemi che non corrisponde alla configurazione attiva nel cluster del team.
L'operatore segnala al sistema di orchestrazione di aggiornare la configurazione del bilanciamento del carico. L'agente di orchestrazione si occupa del resto delle attività e distribuisce automaticamente il bilanciamento del carico appena configurato. Il team quindi monitora il sistema live appena aggiornato per vederlo tornare a uno stato integro. Questo è lo scenario GitOps ideale. Ampliamolo ulteriormente per dimostrare l'utilità di GitOps.
Immaginiamo che invece di modificare leggermente i valori del bilanciamento del carico per renderli più ottimali, il team prenda la decisione più aggressiva di distribuire un tipo di bilanciamento del carico completamente nuovo. I membri del team ritengono che l'attuale bilanciamento del carico sia sostanzialmente difettoso e vogliono provare un'opzione alternativa. Il flusso di lavoro è lo stesso di quello seguito per la modifica dei valori di configurazione. Il team crea una pull request che introduce una configurazione del bilanciamento del carico completamente nuova ed elimina la vecchia. Tale configurazione viene quindi approvata e distribuita nella pipeline.
Purtroppo il team rileva che questo nuovo tipo di bilanciamento del carico è incompatibile con alcuni altri servizi all'interno del cluster. Il nuovo bilanciamento del carico causa gravi errori di traffico e interrompe le operazioni degli utenti. Per fortuna, dato che dispone di una pipeline GitOps completa, il team può annullare rapidamente queste modifiche al bilanciamento del carico. Effettuerà quindi un'altra pull request che ripristinerà il repository al precedente bilanciamento del carico funzionale noto che verrà rilevato dalla pipeline GitOps e distribuito automaticamente e che migliorerà rapidamente l'infrastruttura e il punteggio di affidabilità del team.
Riepilogo
GitOps è uno schema di flusso di lavoro incredibilmente potente per la gestione dell'infrastruttura cloud moderna. Sebbene si concentri principalmente sulla gestione dei cluster Kubernetes, la community DevOps applica e pubblica soluzioni GitOps ad altri sistemi non Kubernetes. GitOps può offrire molti vantaggi ai team di progettazione, tra cui migliori comunicazione, visibilità, stabilità e affidabilità del sistema. Uno dei requisiti principali per l'uso di GitOps è disporre di una moderna piattaforma Git ospitata, come Bitbucket.
Condividi l'articolo
Argomento successivo
Letture consigliate
Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.
Blog di Bitbucket
Percorso di apprendimento DevOps
