GitOps descrive un modo di operare e gestire il software utilizzando metodologie radicate nel sistema di controllo della versione Git. L'uso di flussi di lavoro basati su GitOps semplifica lo sviluppo, la distribuzione, la manutenzione e la collaborazione sul software richiedendo che le caratteristiche del sistema siano definite come file in un repository Git.
Il ruolo di Git come unica fonte è implicito nella terminologia. Tuttavia, l'effettiva implementazione dei processi guidati da GitOps è stata storicamente aperta all'interpretazione. Questa ambiguità è stata ora risolta dagli standard OpenGitOps che definiscono i principi che portano a sistemi ripetibili.
GitOps e DevOps presentano alcuni principi e obiettivi comuni. La metodologia DevOps è incentrata sul cambiamento culturale e ha soprattutto lo scopo di mettere a disposizione dei team operativi e di sviluppo uno strumento per collaborare insieme.
GitOps offre invece gli strumenti e un framework che consentono di applicare le procedure DevOps, quali collaborazione, CI/CD e controllo delle versioni, all'automazione delle infrastrutture e al deployment delle applicazioni.
Gli sviluppatori possono continuare a utilizzare i repository di codice che conoscono già, mentre i team operativi possono introdurre altri componenti necessari.
In questo articolo, esamineremo quali sono i principi, perché sono importanti e come puoi usarli per creare software scalabile e manutenibile. Gli standard sono stati sviluppati utilizzando le informazioni di oltre 90 aziende leader e parti interessate nel gruppo di lavoro GitOps.
Il primo principio afferma che tutti i sistemi gestiti da GitOps devono avere il proprio stato espresso in modo dichiarativo. Dovresti definire come appare lo stato ideale in quel momento, invece di fornire istruzioni specifiche su come assemblarlo.
La configurazione dichiarativa separa lo stato desiderato di un sistema dalla procedura utilizzata per passare a quello stato. Questo è più gestibile e più facile da ragionare nel tempo; i contributori devono solo descrivere il sistema come dovrebbe apparire ora, eliminando la necessità di scrivere migrazioni che influiscono sui cambiamenti di esso.
La mancata definizione dei passaggi esatti che consentono di ottenere lo stato consente di risparmiare tempo di sviluppo e aumenta la flessibilità di distribuzione. Puoi avviare un'istanza della tua applicazione in un nuovo ambiente semplicemente applicando l'ultima definizione di stato dal tuo repository.
La configurazione dichiarativa è comunemente usata con strumenti Infrastructure-as-Code come Ansible e Terraform. Scrivi file di configurazione che definiscono i componenti dell'infrastruttura che desideri siano disponibili. Gli strumenti convertono le tue dichiarazioni in chiamate e comandi API che forniscono le risorse necessarie. La piattaforma di orchestrazione dei container Kubernetes è un altro esempio di sistema dichiarativo.
Il secondo principio di OpenGitOps afferma che lo stato del sistema deve essere sottoposto a versionamento completo per tutta la sua durata. È qui che entra in gioco Git, che ti consente di eseguire il commit dei file di configurazione, unire le modifiche di altri collaboratori ed evolvere il tuo stato nel tempo.
In combinazione con le definizioni dello stato dichiarativo, il controllo delle versioni offre un modo garantito per ripristinare il sistema se le cose vanno male. Estrarre un commit precedente e riapplicare i file di configurazione ripristinerà il sistema al suo stato in quel momento.
La memorizzazione dello stato in questo modo aiuta anche a rafforzare l'immutabilità. L' unico metodo per applicare le modifiche alla tua infrastruttura dovrebbe essere la modifica dei file nel tuo repository. Seguendo questo principio, puoi affermare che lo stato del sistema rispecchia effettivamente le dichiarazioni nella tua fonte. È da evitare la mutazione dello stato modificando direttamente i componenti dell'infrastruttura poiché creerà discrepanze tra lo stato reale del sistema e lo stato "desiderato" nel repository di gestione.
L'obiettivo finale di GitOps è automatizzare il più possibile la gestione dei sistemi. L'utilizzo di un approccio basato su pull per applicare le modifiche aiuta a facilitare questo. Gli agenti in esecuzione all'interno della tua infrastruttura dovrebbero estrarre periodicamente lo stato corrente dal tuo repository Git e applicare eventuali modifiche.
I modelli di distribuzione tradizionali basati su push in genere funzionano inviando modifiche all'infrastruttura come parte di uno script di pipeline CI/CD. Anche se sembra automatizzato, è un passaggio aggiuntivo che crea un punto di accoppiamento tra il repository di origine e l'infrastruttura. In un modello basato su pull, un agente all'interno dell'ambiente esegue il polling del repository di origine e rileva automaticamente le modifiche.
Questo modello crea un'infrastruttura autosufficiente meno suscettibile alla "deriva". La deriva si verifica quando le modifiche all'interno dell'ambiente introducono discrepanze rispetto allo stato dichiarato dal repository. In un modello di distribuzione basato su push, la deriva non verrebbe risolta fino a quando l'esecuzione dello script successiva non avvierà un altro push. I metodi basati su pull riducono al minimo la deriva effettuando regolarmente il polling e riapplicando lo stato più recente.
Anche l'uso di un Agent-pull è un vantaggio per la sicurezza. Gli approcci basati su push richiedono in qualche modo di esporre la tua infrastruttura. Ciò è necessario affinché il server di controllo del codice sorgente possa inviare lo stato aggiornato ed eseguire i comandi. Eseguendo un agent all'interno della tua infrastruttura, elimini la necessità di fornire un percorso verso di essa. È possibile rafforzare i controlli del firewall per consentire a tutti gli accessi esterni all'ambiente.
Allo stesso modo, non è più necessario generare credenziali che forniscano l'accesso alla tua infrastruttura. Una compromissione di un server CI utilizzato in un modello basato su push potrebbe far trapelare le chiavi che proteggono i tuoi ambienti live. Invertire questo flusso fornendo agli agent-pull un token di accesso per la tua piattaforma di hosting Git è meno rischioso che aprire i tuoi ambienti all'accesso esterno.
Il principio finale di OpenGitOps riguarda la riconciliazione continua. Ciò è consentito dall'uso combinato di definizioni di stato dichiarativo con agenti basati su pull.
I tuoi agent monitorano continuamente lo stato dei tuoi sistemi. Intervengono per riconciliare gli ambienti allo stato dichiarato quando vengono apportate modifiche o si verifica una deriva naturale. Ciò contrasta con i modelli tradizionali in cui le implementazioni sono processi lineari che si avviano, eseguono una sequenza di comandi e terminano lasciando l'infrastruttura in piedi autonomamente.
La riconciliazione continua identifica i flussi di lavoro GitOps come processi dinamici che si adattano alle mutevoli condizioni in tempo reale. Lungi dalle semplici implementazioni "imposta e dimentica", gli agent GitOps sono componenti attivi che lavorano costantemente per mantenere lo stato desiderato. Ciò ti consente di concludere la giornata con la certezza che le distribuzioni funzionino ancora come previsto.
Di seguito sono riportati i passaggi per adottare GitOps per l'integrazione e la distribuzione continue.
- Crea un nuovo repository.
- Crea una nuova directory, aprila ed esegui un "git init" per creare un nuovo repository git.
- Crea una copia di lavoro di un repository locale eseguendo il comando "git clone /path della directory.
- Per l'utilizzo di un server remoto, è necessario immettere nome utente e password.
- Crea i file richiesti secondo i requisiti dell'applicazione.
- Quindi usando "git add" aggiungi quei file nel repository al login.
- Dopo aver aggiunto i file, esegui il commit usando il comando "git commit -m "Commit message".
- Le modifiche vengono eseguite sul workspace locale, ora per inviare tali modifiche al repository remoto, esegui "git push origin", approva la revisione del codice e unisci a Git.
- Dopo che il codice è stato inviato al repository Git, la pipeline CI si avvia automaticamente ed esegue i test.
- Quindi crea una nuova immagine salvata in Registry, per esempio Docker Hub.
- Git avvia il processo CI, crea la pipeline, esegue test, crea una nuova immagine e la deposita in un registro.
- Il Deployment Automator controlla il registro delle immagini, rivede l'immagine. Quindi estrae la nuova immagine dal registro e aggiorna il file YAML di quel progetto nel repository di configurazione.
- Il Deployment Synchronizer è installato nel cluster e rileva che il cluster non è aggiornato. Estrae le modifiche nei manifesti dal repository di configurazione e quindi distribuisce la nuova funzionalità alla produzione.
I principi di OpenGitOps descrivono quattro caratteristiche comuni dei sistemi che vengono gestiti in modo efficace utilizzando un flusso di lavoro basato su GitOps. Formalizzano le caratteristiche chiave delle implementazioni di successo, offrendo un punto di riferimento per i team DevOps con cui confrontare i propri sistemi.
Come mostrano questi principi, GitOps è più di semplici file di configurazione in un repository Git. È una metodologia coesa per definire, implementare e mantenere un sistema; mentre i repository Git sono vitali per il controllo delle versioni, altri componenti come agenti software basati su pull sbloccano il pieno potenziale della strategia.
L'adozione efficace di un flusso di lavoro GitOps che incorpora i principi di OpenGitOps può aumentare il throughput, migliorare l'integrità della distribuzione e ridurre al minimo il tempo impiegato per l'utilizzo e la manutenzione dell'infrastruttura. L'approccio semplifica l'ispezione dello stato del sistema e l'esecuzione o il rollback di modifiche utilizzando Git e il tuo editor di codice preferito. Spetta quindi all'integrazione dell'agent dell'infrastruttura rilevare e applicare tali modifiche, eliminando l'interazione umana con le implementazioni e i rischi che essa comporta.
Programmatore informatico italiano, mi occupo di sviluppo sia Front-end che Back-end presso una grande azienda. La programmazione è stata la mia passione, insieme allo sport e al teatro che pratico tutt'ora. Ho deciso di aprire questo blog per dare consigli e condividerli con chi, come me, porta con sé questa passione. [..]
