GitOps: un'altra parola d'ordine o una svolta nell'automazione?

La maggior parte di noi, notando un altro nuovo termine nella blogosfera o nelle conferenze IT, prima o poi pone una domanda simile: “Cos'è questo? Solo un’altra parola d’ordine, una “parola d’ordine” o qualcosa a cui vale davvero la pena prestare molta attenzione, studiare e promettere nuovi orizzonti? A me è successa la stessa cosa con il termine GitOps qualche tempo fa. Armato di molti articoli esistenti, nonché della conoscenza dei colleghi dell'azienda GitLab, ho cercato di capire che tipo di bestia sia questa e come potrebbe essere il suo utilizzo nella pratica.

A proposito, sulla novità del termine GitOps Il nostro recente sondaggio dice anche: più della metà degli intervistati non ha ancora iniziato a lavorare con i suoi principi.

Quindi il problema della gestione delle infrastrutture non è nuovo. Molti fornitori di servizi cloud sono a disposizione del grande pubblico da una buona dozzina di anni e, a quanto pare, avrebbero dovuto rendere semplice e chiaro il lavoro dei team responsabili dell'infrastruttura. Tuttavia, se paragonati al processo di sviluppo delle applicazioni (dove l’automazione sta raggiungendo livelli sempre nuovi), i progetti infrastrutturali spesso comportano ancora molte attività manuali e richiedono conoscenze e competenze specializzate, soprattutto visti i requisiti odierni di tolleranza ai guasti, flessibilità, scalabilità ed elasticità.

I servizi cloud hanno soddisfatto questi requisiti con grande successo e sono stati loro a dare un impulso significativo allo sviluppo dell'approccio Iac. Questo è comprensibile. Dopotutto, hanno permesso di configurare un data center completamente virtuale: non ci sono server fisici, rack o componenti di rete; l'intera infrastruttura può essere descritta utilizzando script e file di configurazione.

Quindi qual è esattamente la differenza? GitOps от Iac? È con questa domanda che ho iniziato la mia indagine. Dopo aver parlato con i colleghi, sono riuscito a fare il seguente confronto:

GitOps

Iac

Tutto il codice è archiviato in un repository git

Il controllo delle versioni del codice è facoltativo

Codice dichiarativo Descrizione/Idempotenza

Sono accettabili sia le descrizioni dichiarative che quelle imperative

Le modifiche diventano effettive utilizzando i meccanismi Merge Request/Pull Request

L'accordo, l'approvazione e la collaborazione sono facoltativi

Il processo di distribuzione degli aggiornamenti è automatizzato

Il processo di distribuzione degli aggiornamenti non è standardizzato (automatico, manuale, copia di file, utilizzo della riga di comando, ecc.)

In altre parole GitOps è nata proprio attraverso l'applicazione dei principi Iac. In primo luogo, l'infrastruttura e le configurazioni ora potrebbero essere archiviate allo stesso modo delle applicazioni. Il codice è facile da archiviare, facile da condividere, confrontare e utilizzare le funzionalità di controllo delle versioni. Versioni, rami, storia. E tutto questo in un luogo pubblicamente accessibile a tutto il team. Pertanto, l'uso di sistemi di controllo della versione è diventato uno sviluppo del tutto naturale. In particolare, Git, come il più popolare.

D’altro canto è diventato possibile automatizzare i processi di gestione delle infrastrutture. Ora questo può essere fatto più velocemente, in modo più affidabile ed economico. Inoltre, i principi di CI/CD erano già conosciuti e apprezzati dagli sviluppatori di software. Era solo necessario trasferire e applicare conoscenze e competenze già note a una nuova area. Queste pratiche, tuttavia, andavano oltre la definizione standard di Infrastruttura come codice, da cui il concetto GitOps.

Curiosità GitOps, ovviamente, anche nel fatto che non si tratta di un prodotto, plugin o piattaforma associata ad alcun fornitore. È più un paradigma e un insieme di principi, simili a un altro termine che conosciamo: DevOps.

La società GitLab abbiamo sviluppato due definizioni di questo nuovo termine: teorica e pratica. Cominciamo con la parte teorica:

GitOps è una metodologia che prende i migliori principi DevOps utilizzati per lo sviluppo di applicazioni, come controllo della versione, collaborazione, orchestrazione, CI/CD, e li applica alle sfide dell'automazione della gestione dell'infrastruttura.

Tutti i processi GitOps Lavoro utilizzando gli strumenti esistenti. Tutto il codice dell'infrastruttura è archiviato nel già familiare repository git, le modifiche passano attraverso lo stesso processo di approvazione di qualsiasi altro codice di programma e il processo di implementazione è automatizzato, il che ci consente di ridurre al minimo gli errori umani, aumentare l'affidabilità e la riproducibilità.

Da un punto di vista pratico, descriviamo GitOps следующим обрахом:

Abbiamo già discusso dell'infrastruttura come codice come uno dei componenti chiave di questa formula. Presentiamo il resto dei partecipanti.

Richiesta di unione (nome alternativo richiesta di pull). In termini di processo, MR è una richiesta di applicare modifiche al codice e quindi unire le filiali. Ma in termini di strumenti che utilizziamo, questa è più un'opportunità per avere un quadro completo di tutte le modifiche apportate: non solo il codice diff raccolto da un certo numero di commit, ma anche il contesto, i risultati dei test e il risultato finale atteso. Se parliamo di codice infrastrutturale, allora siamo interessati a come cambierà esattamente l'infrastruttura, quante nuove risorse verranno aggiunte o rimosse, modificate. Preferibilmente in un formato più comodo e facile da leggere. Per i fornitori di servizi cloud è una buona idea sapere quale sarà l'impatto finanziario di questo cambiamento.

Ma la MR è anche un mezzo di collaborazione, interazione e comunicazione. Il luogo in cui entra in gioco il sistema di controlli ed equilibri. Dai semplici commenti alle approvazioni e approvazioni formali.

Ebbene, l'ultimo componente: CI/CD, come già sappiamo, consente di automatizzare il processo di modifica e test dell'infrastruttura (dal semplice controllo della sintassi all'analisi statica del codice più complessa). E anche nel successivo rilevamento della deriva: differenze tra lo stato reale e quello desiderato del sistema. Ad esempio, a seguito di modifiche manuali non autorizzate o di un guasto del sistema.

Sì, il termine GitOps non ci introduce a nulla di completamente nuovo, non reinventa la ruota, ma applica semplicemente l'esperienza già accumulata in una nuova area. Ma è proprio qui che risiede la sua forza.

E se all'improvviso ti interessi come appare tutto nella pratica, allora ti invito a guardare il nostro master class, in cui ti spiego passo dopo passo come utilizzare GitLab:

• Implementare i principi di base di GitOps

• Creare e apportare modifiche all'infrastruttura cloud (utilizzando l'esempio di Yandex Cloud)

• Automatizza il rilevamento della deviazione del sistema da uno stato desiderato utilizzando il monitoraggio attivo

https://bit.ly/34tRpwZ

Fonte: habr.com