Cos'è GitOps

L'attenzione si concentra sull'automazione delle operazioni, basata sui repository Git. Sebbene sia indicato nel nome, Git non è l'unico repository che può essere utilizzato. Sono le interfacce fornite da Git che automatizzano le operazioni. GitOps finisce per utilizzare le informazioni estratte dai metadati di compilazione per determinare quali pacchetti creare, in seguito a una particolare modifica del codice:

Nella sua essenza, il modello GitOps utilizza il pattern del controller. Questo è ulteriormente favorito dal pattern operatore da una prospettiva Kubernetes o OpenShift, in cui gli operatori sono estensioni software che utilizzano risorse personalizzate  per gestire le applicazioni e i loro componenti.

Sarebbe un errore non menzionare Argo CD, uno strumento GitOps che facilita i workflow GitOps. Argo CD è uno strumento dichiarativo open-source per l'integrazione continua e il deployment continuo (CI/CD) delle applicazioni. Implementato come controller Kubernetes, Argo CD monitora continuamente le definizioni e le configurazioni delle applicazioni in esecuzione, confrontando lo stato attuale e live del cluster con lo stato desiderato definito in un repository Git.

Tuttavia, GitOps non è un singolo prodotto, plug-in o piattaforma. I workflow GitOps aiutano i team a gestire l'infrastruttura IT attraverso i workflow che già utilizzano nello sviluppo dell'applicazione. Prendendo in prestito ciò che è scritto in un blog di GitLab, GitOps richiede tre componenti principali: GitOps =IaC + PRs o mRS + CI/CD

• IaC: Infrastructure as Code (IaC) è la pratica di mantenere tutta la configurazione dell'infrastruttura memorizzata come codice. GitOps utilizza un repository Git come singola fonte affidabile per le definizioni di infrastruttura. Git tiene traccia di tutte le modifiche alla gestione del codice.
  
  
• PR o MR: GitOps utilizza una pull request (PR) o una merge request (MR) come meccanismo di modifica per tutti gli aggiornamenti dell'infrastruttura. Qui i team possono collaborare tramite recensioni e commenti e dove avvengono le approvazioni formali.
  
  
• CI/CD: GitOps automatizza gli aggiornamenti dell'infrastruttura utilizzando un workflow Git con Integrazione continua (CI) e distribuzione continua (CD). Quando il nuovo codice viene unito, la pipeline CI/CD esegue la modifica nell'ambiente. Qualsiasi deriva di configurazione, come modifiche o errori manuali, viene sovrascritta dall'automazione di GitOps in modo che l'ambiente converga sullo stato desiderato definito in Git, generando così operazioni continue (CO):

Gli operatori di Red Hat OpenShift semplificano l'installazione e l'orchestrazione automatizzata dei workload complessi. Aiutano a codificare la logica operativa umana per gestire i servizi eseguiti come applicazioni native di Kubernetes, semplificando le operazioni dal secondo giorno. L'operatore è un software in esecuzione in un pod del cluster, che interagisce con il server API Kubernetes. Un operatore OpenShift è essenzialmente un controller personalizzato e può essere, di fatto, un controller specifico dell'applicazione.

Red Hat OpenShift semplifica l'utilizzo di GitOps da parte degli sviluppatori fornendo gli operatori necessari. Una volta implementati, possono essere visualizzati nella sezione degli operatori installati della console OpenShift. L'operatore Red Hat OpenShift GitOps è l'operatore upstream per ArgoCD, mentre l'operatore Red Hat OpenShift Pipelines, anch'esso distribuito, è l'operatore upstream per Tekton. Vedi Figura 3:

Gli operatori e le API correlate possono quindi essere usati per avviare una o più pipeline GitOps implementabili in ambienti diversi, estraendo il risultato della configurazione desiderato da Git. Gli ambienti possono essere i soliti ambienti di sviluppo, test e produzione, ma possono anche estendersi ad ambienti geografici come il cloud enterprise, la rete di telecomunicazioni o i nodi di edge computing.

Le risorse di implementazione sono classificate in tre aree: infrastruttura, servizi e applicazioni. Queste aree semplificano la separazione e la gestione della distribuzione delle risorse correlate:

• L'infrastruttura è il luogo in cui vengono definiti i namespace e lo storage necessari.
• I servizi sono il luogo in cui vengono descritti i vari operatori necessari per configurare le istanze.
• Le applicazioni sono le aree in cui viene enumerata l'applicazione da implementare.

L'edge computing sta assistendo alla proliferazione di cluster OpenShift o Kubernetes nella maggior parte dei centri IT. Ha il potenziale per raggiungere una scala massiccia, da centinaia a migliaia di implementazioni per cliente. Il risultato è che i reparti IT aziendali devono gestire più cluster di runtime di container indipendenti o cooperativi in esecuzione on-premise e/o su cloud pubblici.

Garantire che i cluster abbiano lo stesso stato desiderato, implementando una modifica e ripristinando una modifica su più cloud, è un beneficio principale che GitOps offre alle aziende edge e IoT.

Il paradigma GitOps è applicabile all'edge della rete perché una delle principali sfide che i Communication Service Provider (CSP) devono affrontare è la ricerca dell'orchestrazione, dell'automazione e della gestione delle loro reti. Sebbene il 5G sia un vantaggio per i consumatori, le reti definite dal software (SDN), lo slicing della rete con larghezze di banda diverse e l'implementazione più rapida hanno introdotto sfide per i provider di telecomunicazioni.

Una pipeline di implementazione automatizzata è un modo in cui i CSP possono fornire servizi ai clienti più velocemente. Avere un repository centrale e un approccio dichiarativo al provisioning dell'infrastruttura dei container significa avere un time-to-market più rapido per nuove caratteristiche e richieste di modifica. Un paradigma di questo tipo faciliterà la fornitura di VNF (Virtual Network Functions) e CNF (Cloud-Native Network Functions) all'edge. La containerizzazione dei componenti di rete consente di gestire tali funzioni. Infine, poiché tutte le attività di configurazione sono registrate e memorizzate in Git, la capacità di tenere traccia delle modifiche è critica ai fini della conformità e dell'audit. Nei riferimenti sono presenti un paio di blog correlati di WeaveWorks:

GitOps consente alle organizzazioni di eseguire l'implementazione su più target contemporaneamente. Consente di eseguire più implementazioni granulari. Questo è estremamente utile quando si implementano applicazioni su centinaia e decine di migliaia di nodi edge, che hanno forme e fattori di forma diversi e utilizzano vari protocolli di comunicazione, soprattutto se i nodi edge sono piccoli cluster edge che utilizzano un Intel NUC o NVIDIA Jetson.

Il framework GitOps può essere utile per implementare applicazioni e utilizzare il Git come singola fonte affidabile. I team ITOps cercano la distribuzione autonoma, la gestione e le operazioni delle applicazioni dei nodi edge, facilitati dall'uso di operatori Red Hat OpenShift.

Il beneficio di GitOps è evidente all'edge di rete e all'edge aziendale. I dispositivi far edge rappresentano una sfida diversa perché la capacità di storage e di calcolo di alcuni di questi dispositivi non è abbastanza grande per ospitare servizi GitOps ed eseguire applicazioni.

Il rilascio di distribuzioni Kubernetes leggere, come K3s e K0s, è pensato per i casi d'uso IoT ed edge. La capacità di effettuare una distribuzione Kubernetes leggera su un dispositivo edge ci consente di eseguire uno strumento GitOps come Argo CD. I dispositivi saranno quindi in grado di adottare il modello pull di interrogazione di un repository Git per lo stato desiderato e sincronizzarlo con lo stato attivo del cluster.