GitOps at the Edge
Negli ultimi due anni abbiamo visto sempre più aziende adottare GitOps, un paradigma DevOps che utilizza Git come repository.
GitOps esiste da alcuni anni, ma recentemente ha preso piede grazie ai container e alla complessità legata all'implementazione e alla gestione coerenti degli ambienti runtime dei container.
Qual è il problema che GitOps sta tentando di risolvere? GitOps automatizza le operazioni software in modo che le aziende possano migliorare l'ingegneria del software. Consente ai team responsabili delle applicazioni di rilasciare soluzioni più frequentemente e di gestire le applicazioni cloud-native in modo più efficace.
Questo blog esplora se GitOps può essere applicato alle topologie edge, in particolare creando pipeline CI/CD in grado di implementare applicazioni su dispositivi edge. L'edge comprende dispositivi edge che arrivano fino al cloud, con edge aziendale e edge di rete lungo il percorso.
GitOps è una pratica DevOps che utilizza Git come singola fonte affidabile in cui è memorizzato lo stato di configurazione desiderato. 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:
Il modello GitOps usa come base il pattern del controller. Ciò è ulteriormente aiutato dal pattern dell'operatore, dal punto di vista di Kubernetes o OpenShift, dove gli operatori sono estensioni software che utilizzano risorse personalizzate per gestire le applicazioni e i loro componenti.
Vale la pena menzionare Argo CD, uno strumento GitOps che supporta i workflow GitOps. Argo CD è uno strumento dichiarativo open source per l'integrazione continua e la distribuzione continua (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 attivo 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 conservare tutta la configurazione dell'infrastruttura memorizzata come codice. GitOps utilizza un repository Git come singola fonte affidabile per le definizioni dell'infrastruttura. Git tiene traccia di tutte le modifiche alla gestione del codice.
- PR o MR: GitOps utilizza le pull request (PR) o le merge request (MR) come meccanismo di modifica per tutti gli aggiornamenti dell'infrastruttura. È qui che i team possono collaborare tramite recensioni e commenti ed è qui che 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.
In un blog precedente abbiamo discusso di DevOps nel dominio dell'edge computing; qui, diamo un'occhiata a come GitOps può essere applicato all'edge computing. Abbiamo accennato ai tre edge dell'edge domputing:
- Enterprise edge
- Network edge
- Device edge (far edge)
Ci sono poi il cloud o il data center aziendale. Diamo un'occhiata approfondita a queste aree. Oltre agli ambienti edge, la Figura 4 illustra anche le tre aree di GitOps: infrastruttura, servizi e applicazioni.
Data center cloud/aziendale
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.
Network edge
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:
Enterprise edge
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 nell'implementazione delle applicazioni e nell'utilizzo del repository Git come singola fonte affidabile. I team ITOps desiderano ottenere in modo autonomo l'implementazione, la gestione e le operazioni delle applicazioni dei nodi periferici, il che è facilitato dall'uso degli operatori Red Hat OpenShift.
Device edge (far edge)
Il beneficio di GitOps è evidente sia al network edge che all'enterprise edge. I dispositivi edge presentano una sfida diversa, perché la capacità di storage e calcolo di alcuni di questi dispositivi non è sufficiente 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.
Utilizzando GitOps, puoi risolvere i problemi di proliferazione delle configurazioni delle infrastrutture e delle applicazioni. L'operatore GitOps integrato in Red Hat OpenShift semplifica l'implementazione di una pipeline basata su Argo-CD. I clienti di IBM Cloud Paks, incluso IBM Cloud Pak for Network Automation, possono utilizzare gli operatori Red Hat per installare risorse e utilizzare il framework GitOps per automatizzare e controllare il processo di implementazione.
L'IBM Cloud Native Toolkit è un ottimo punto di partenza. Si tratta di una raccolta di asset open source che aiutano nello sviluppo di applicazioni e nelle attività di implementazione.
Un ringraziamento speciale a Hollis Chui e Kavitha Bade per la revisione dell'articolo.