La maggior parte di noi, notando un nuovo termine nell'ecosistema IT durante un blog o una conferenza, prima o poi si pone una domanda simile: “Cosa significa? Una nuova parola di moda, un 'buzzword' o davvero qualcosa che merita attenzione, studio e promette nuovi orizzonti?” È esattamente quello che è successo a me con il termine GitOps qualche tempo fa. Armato di numerosi articoli già esistenti e delle conoscenze dei miei colleghi in azienda, , ho cercato di capire cos'è questo termine e come il suo utilizzo possa apparire nella pratica.
A proposito, la novità del termine GitOps è confermata anche da un sondaggio che abbiamo recentemente condotto: più della metà degli intervistati non ha ancora iniziato a lavorare con i suoi principi.
Quindi, il problema della gestione dell'infrastruttura non è nuovo. Molti provider di servizi cloud sono disponibili al pubblico da oltre un decennio e, apparentemente, dovrebbero rendere il lavoro delle squadre responsabili dell'infrastruttura semplice e senza complicazioni. Tuttavia, rispetto al processo di sviluppo delle applicazioni (dove il livello di automazione raggiunge nuovi orizzonti), i progetti infrastrutturali includono ancora spesso molte attività manuali e richiedono conoscenze specialistiche, soprattutto considerando le attuali esigenze di resilienza, flessibilità, scalabilità ed elasticità.
I servizi cloud hanno soddisfatto con successo queste esigenze e sono stati un importante impulso allo sviluppo dell'approccio. IaCE non c'è da meravigliarsi. Infatti, hanno reso possibile configurare un centro di elaborazione dati completamente virtuale: non ci sono server fisici, rack, componenti di rete, e tutta l'infrastruttura può essere descritta tramite script e file di configurazione.
Qual è quindi la differenza? GitOps da IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Tutto il codice è conservato in un repository git.
La versione del codice non è obbligatoria.
Descrizione dichiarativa del codice / Idempotenza
È consentita sia la descrizione dichiarativa che quella imperativa
Le modifiche sono effettive tramite meccanismi di Merge Request / Pull Request
L'approvazione, l'approvazione e la collaborazione non sono obbligatorie
Il processo di distribuzione degli aggiornamenti è automatizzato
Il processo di distribuzione degli aggiornamenti non è standardizzato (automatico, manuale, copia dei file, utilizzo della riga di comando, ecc.)
In altre parole GitOps è nato grazie all'applicazione dei principi IaC. Innanzitutto, ora era possibile memorizzare l'infrastruttura e le configurazioni esattamente come le applicazioni. Il codice può essere facilmente memorizzato, condiviso, confrontato e fruibile tramite le funzionalità di versioning. Versioni, rami, cronologia. E tutto questo in un luogo accessibile a tutto il team. Pertanto, lo sviluppo naturale è stato l'uso dei sistemi di controllo versione. In particolare, git, come il più popolare.
D'altro canto, è emersa l'opportunità di automatizzare i processi di gestione dell'infrastruttura. Ora è possibile farlo più rapidamente, in modo più sicuro e a costi inferiori. Inoltre, i principi del CI/CD erano già noti e popolari tra gli sviluppatori di software. Era necessario solo trasferire e applicare le conoscenze e competenze già acquisite in un nuovo ambito. Tuttavia, queste pratiche andavano oltre la definizione standard di Infrastruttura come codice, dando origine al concetto. GitOps.
Curiosità GitOps, ovviamente, è anche il fatto che non si tratta di un prodotto, un plugin o una piattaforma legata a qualche fornitore. È più una parodia e un insieme di principi, simile a un altro termine a noi familiare: DevOps.
In azienda abbiamo sviluppato due definizioni di questo nuovo termine: teorica e pratica. Iniziamo con la definizione teorica:
GitOps è una metodologia che utilizza i principi avanzati del DevOps, normalmente impiegati nello sviluppo di applicazioni, come il controllo versioni, la collaborazione, la conformità e il CI/CD, applicandoli per affrontare le sfide dell'automazione della gestione dell'infrastruttura.
Tutti i processi GitOps lavoro utilizzando strumenti già esistenti. Tutto il codice infrastrutturale è conservato in un repository git familiare, 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 ripetibilità.
Dal punto di vista pratico, descriviamo GitOps nel seguente modo:
L'infrastruttura come codice l'abbiamo già discussa, come uno degli elementi chiave di questa formula. Immaginiamo ora gli altri membri coinvolti.
Merge Request (nome alternativo di Pull Request). In termini di processo, un MR è una richiesta di applicazione delle modifiche al codice e di successivo unione dei rami. Tuttavia, in termini di strumenti che utilizziamo, si tratta piuttosto di un'opportunità per avere un quadro completo di tutte le modifiche apportate: non solo il code diff, raccolto da un certo numero di commit, ma anche contesto, risultati dei test e risultato finale atteso. Se parliamo di codice infrastrutturale, ci interessa sapere come cambierà esattamente l'infrastruttura, quanti nuovi risorse verranno aggiunti o rimossi, e quali cambiamenti ci saranno. È preferibile avere queste informazioni in un formato più conveniente e facilmente leggibile. Nel caso dei fornitori di cloud, sarebbe utile sapere quali conseguenze finanziarie comporterà questa modifica.
Ma un MR è anche uno strumento di collaborazione, interazione e comunicazione. È il luogo in cui entra in gioco il sistema di controlli e bilanciamenti. Dai semplici commenti alle approvazioni formali e alle affermazioni.
E l'ultima componente: CI/CD, come già sappiamo, consente di automatizzare il processo di implementazione delle modifiche infrastrutturali, testando (da semplici controlli di sintassi ad analisi statiche del codice più complesse). Inoltre permette di rilevare successivamente il drift: le differenze tra lo stato attuale e quello desiderato del sistema. Ad esempio, a seguito di modifiche manuali non autorizzate o di guasti di sistema.
Sì, il termine GitOps non ci presenta niente di assolutamente nuovo, non inventa la ruota, ma applica solo l'esperienza accumulata in un nuovo campo. Ma è proprio qui che sta la sua forza.
E se per caso ti interessa sapere come appare tutto questo nella pratica, ti invitiamo a guardare il nostro , in cui spiego passo dopo passo come utilizzare GitLab per:
Realizzare i principi fondamentali di GitOps
Creare e apportare modifiche all'infrastruttura cloud (prendendo come esempio Yandex Cloud)
Automatizzare il rilevamento del drift del sistema dallo stato desiderato attraverso un monitoraggio attivo
https://bit.ly/34tRpwZ
Fonte: habr.com
