🥇GitOps: confronto tra metodi Pull e Push

Nota. trad.: Nella comunità Kubernetes, una tendenza chiamata GitOps sta guadagnando evidente popolarità, come abbiamo visto personalmente, visitare KubeCon Europe 2019. Questo termine era relativamente recente coniato dal capo di Weaveworks - Alexis Richardson - e prevede l'utilizzo di strumenti familiari agli sviluppatori (in primis Git, da cui il nome) per risolvere problemi operativi. In particolare, stiamo parlando del funzionamento di Kubernetes memorizzando le sue configurazioni in Git e implementando automaticamente le modifiche al cluster. Matthias Jg parla di due approcci a questo lancio in questo articolo.

L'anno scorso, (in effetti, formalmente ciò è avvenuto nell'agosto 2017 - trad. ca.) Esiste un nuovo approccio alla distribuzione delle applicazioni in Kubernetes. Si chiama GitOps e si basa sull'idea di base che le versioni di distribuzione vengono tracciate nell'ambiente sicuro di un repository Git.

I principali vantaggi di questo approccio sono i seguenti::

Versioni della distribuzione e cronologia delle modifiche. Lo stato dell'intero cluster viene archiviato in un repository Git e le distribuzioni vengono aggiornate solo tramite commit. Inoltre, tutte le modifiche possono essere monitorate utilizzando la cronologia dei commit.
Rollback utilizzando comandi Git familiari... pianura git reset consente di reimpostare le modifiche nelle distribuzioni; gli stati passati sono sempre disponibili.
Controllo accessi pronto. In genere, un sistema Git contiene molti dati sensibili, quindi la maggior parte delle aziende presta particolare attenzione alla loro protezione. Di conseguenza, questa protezione si applica anche alle operazioni con distribuzioni.
Politiche per le distribuzioni. La maggior parte dei sistemi Git supporta nativamente policy ramo per ramo: ad esempio, solo le richieste pull possono aggiornare il master e le modifiche devono essere riviste e accettate da un altro membro del team. Come per il controllo degli accessi, le stesse policy si applicano agli aggiornamenti della distribuzione.

Come puoi vedere, ci sono molti vantaggi nel metodo GitOps. Nell’ultimo anno, due approcci hanno guadagnato particolare popolarità. Uno è basato sul push, l'altro è basato sul pull. Prima di esaminarli, diamo un'occhiata a come si presentano le tipiche distribuzioni Kubernetes.

Metodi di distribuzione

Negli ultimi anni, Kubernetes ha stabilito vari metodi e strumenti per le distribuzioni:

Basato su modelli Kubernetes/Kustomize nativi. Questo è il modo più semplice per distribuire applicazioni su Kubernetes. Lo sviluppatore crea i file YAML di base e li applica. Per evitare di riscrivere costantemente gli stessi modelli, è stato sviluppato Kustomize (trasforma i modelli Kubernetes in moduli). Nota. trad.: Kustomize è stato integrato in kubectl con rilascio di Kubernetes 1.14.
Grafici del timone. I grafici Helm consentono di creare set di modelli, contenitori init, sidecar e così via, utilizzati per distribuire applicazioni con opzioni di personalizzazione più flessibili rispetto a un approccio basato su modelli. Questo metodo si basa su file YAML basati su modelli. Helm li riempie con vari parametri e poi li invia a Tiller, un componente del cluster che li distribuisce nel cluster e consente aggiornamenti e rollback. L'importante è che Helm si limiti essenzialmente a inserire i valori desiderati nei template e poi ad applicarli nello stesso modo in cui si fa nell'approccio tradizionale (leggi di più su come funziona e come puoi usarlo nel nostro articolo di Helm - ca. trad.). È disponibile un'ampia varietà di grafici Helm già pronti che coprono un'ampia gamma di attività.
Strumenti alternativi. Esistono molti strumenti alternativi. Ciò che hanno tutti in comune è che trasformano alcuni file modello in file YAML leggibili da Kubernetes e quindi li utilizzano.

Nel nostro lavoro utilizziamo costantemente i grafici Helm per strumenti importanti (poiché hanno già molte cose pronte, il che rende la vita molto più semplice) e file YAML "puri" Kubernetes per la distribuzione delle nostre applicazioni.

Tirare e spingere

In uno dei miei recenti post sul blog, ho introdotto lo strumento Flusso di tessitura, che consente di eseguire il commit dei modelli nel repository Git e aggiornare la distribuzione dopo ogni commit o push del contenitore. La mia esperienza dimostra che questo strumento è uno dei principali nel promuovere l’approccio pull, quindi farò spesso riferimento ad esso. Se vuoi saperne di più su come usarlo, qui collegamento dell'articolo.

NB! Tutti i vantaggi derivanti dall'utilizzo di GitOps rimangono gli stessi per entrambi gli approcci.

Approccio basato sul pull

L'approccio pull si basa sul fatto che tutte le modifiche vengono applicate dall'interno del cluster. All'interno del cluster è presente un operatore che controlla regolarmente i repository Git e Docker Registry associati. Se si verificano modifiche, lo stato del cluster viene aggiornato internamente. Questo processo è generalmente considerato molto sicuro, poiché nessun client esterno ha accesso ai diritti di amministratore del cluster.

pro:

Nessun client esterno ha il diritto di apportare modifiche al cluster; tutti gli aggiornamenti vengono implementati dall'interno.
Alcuni strumenti consentono inoltre di sincronizzare gli aggiornamenti del grafico Helm e collegarli al cluster.
Il registro Docker può essere scansionato per nuove versioni. Se è disponibile una nuova immagine, il repository Git e la distribuzione vengono aggiornati alla nuova versione.
Gli strumenti di pull possono essere distribuiti su diversi spazi dei nomi con diversi repository e autorizzazioni Git. Grazie a ciò è possibile utilizzare un modello multitenant. Ad esempio, il team A potrebbe utilizzare lo spazio dei nomi A, il team B potrebbe utilizzare lo spazio dei nomi B e il team dell'infrastruttura potrebbe utilizzare lo spazio globale.
Di norma, gli strumenti sono molto leggeri.
Combinato con strumenti come operatore Segreti sigillati di Bitnami, i segreti possono essere archiviati crittografati in un repository Git e recuperati all'interno del cluster.
Non esiste alcuna connessione alle pipeline CD poiché le distribuzioni avvengono all'interno del cluster.

Contro:

Gestire i segreti di distribuzione dai grafici Helm è più difficile di quelli normali, poiché prima devono essere generati sotto forma, ad esempio, di segreti sigillati, quindi decrittografati da un operatore interno e solo dopo diventano disponibili per lo strumento di pull. Quindi puoi eseguire il rilascio in Helm con i valori nei segreti già distribuiti. Il modo più semplice è creare un segreto con tutti i valori Helm utilizzati per il deploy, decriptarlo e committarlo su Git.
Quando adotti un approccio pull, diventi legato agli strumenti pull. Ciò limita la possibilità di personalizzare il processo di distribuzione in un cluster. Ad esempio, Kustomize è complicato dal fatto che deve essere eseguito prima che i modelli finali vengano trasferiti su Git. Non sto dicendo che non sia possibile utilizzare strumenti autonomi, ma è più difficile integrarli nel processo di distribuzione.

Approccio basato sul push

Nell'approccio push, un sistema esterno (principalmente pipeline CD) avvia le distribuzioni nel cluster dopo un commit nel repository Git o se la pipeline CI precedente ha esito positivo. In questo approccio, il sistema ha accesso al cluster.

Pro:

La sicurezza è determinata dal repository Git e dalla pipeline di build.
La distribuzione dei grafici Helm è più semplice e supporta i plug-in Helm.
I segreti sono più facili da gestire perché possono essere utilizzati nelle pipeline e possono anche essere archiviati crittografati in Git (a seconda delle preferenze dell'utente).
Non esiste alcun collegamento con uno strumento specifico, poiché è possibile utilizzare qualsiasi tipo.
Gli aggiornamenti della versione del contenitore possono essere avviati dalla pipeline di compilazione.

Contro:

I dati di accesso al cluster si trovano all'interno del sistema di compilazione.
L'aggiornamento dei contenitori di distribuzione è ancora più semplice con un processo di pull.
Forte dipendenza dal sistema CD, poiché le pipeline di cui abbiamo bisogno potrebbero essere state originariamente scritte per Gitlab Runners, e poi il team decide di passare ad Azure DevOps o Jenkins... e dovrà migrare un gran numero di pipeline di build.

Risultati: spingere o tirare?

Come di solito accade, ogni approccio ha i suoi pro e i suoi contro. Alcuni compiti sono più facili da realizzare con uno e più difficili con un altro. All'inizio eseguivo le distribuzioni manualmente, ma dopo essermi imbattuto in alcuni articoli su Weave Flux, ho deciso di implementare i processi GitOps per tutti i progetti. Per i modelli di base è stato facile, ma poi ho iniziato a incontrare difficoltà con i grafici Helm. All'epoca Weave Flux offriva solo una versione rudimentale dell'Helm Chart Operator, ma anche adesso alcuni compiti sono più difficili a causa della necessità di creare manualmente i segreti e applicarli. Si potrebbe sostenere che l'approccio pull è molto più sicuro perché le credenziali del cluster non sono accessibili all'esterno del cluster, rendendolo così tanto più sicuro che vale lo sforzo aggiuntivo.

Dopo averci pensato a lungo, sono giunto alla conclusione inaspettata che non è così. Se parliamo di componenti che richiedono la massima protezione, questo elenco includerà archivi segreti, sistemi CI/CD e repository Git. Le informazioni al loro interno sono molto vulnerabili e necessitano della massima protezione. Inoltre, se qualcuno entra nel tuo repository Git e può inviare codice lì, può distribuire quello che vuole (che sia pull o push) e infiltrarsi nei sistemi del cluster. Pertanto, i componenti più importanti che devono essere protetti sono il repository Git e i sistemi CI/CD, non le credenziali del cluster. Se si dispone di policy e controlli di sicurezza ben configurati per questi tipi di sistemi e le credenziali del cluster vengono estratte nelle pipeline solo come segreti, la sicurezza aggiuntiva di un approccio pull potrebbe non essere così preziosa come si pensava inizialmente.

Quindi, se l'approccio pull richiede più lavoro e non fornisce vantaggi in termini di sicurezza, non è logico utilizzare solo l'approccio push? Ma qualcuno potrebbe obiettare che nell'approccio push si è troppo legati al sistema CD e, forse, è meglio non farlo così sarà più semplice effettuare migrazioni in futuro.

Secondo me (come sempre), dovresti usare ciò che è più adatto al caso particolare o combinare. Personalmente, utilizzo entrambi gli approcci: Weave Flux per distribuzioni basate su pull che includono principalmente i nostri servizi e un approccio push con Helm e plug-in, che semplifica l'applicazione dei grafici Helm al cluster e consente di creare segreti senza problemi. Penso che non esisterà mai un'unica soluzione adatta a tutti i casi, perché le sfumature sono sempre tante e dipendono dall'applicazione specifica. Detto questo, consiglio vivamente GitOps: rende la vita molto più semplice e migliora la sicurezza.

Spero che la mia esperienza su questo argomento ti aiuti a decidere quale metodo è più adatto al tuo tipo di distribuzione e sarei felice di sentire la tua opinione.

PS Nota del traduttore

Lo svantaggio del modello pull è che è difficile inserire manifest renderizzati in Git, ma non c'è lo svantaggio che la pipeline CD nel modello pull viva separatamente dal rollout e diventi essenzialmente una pipeline di categoria Applicazione continua. Pertanto, sarà necessario uno sforzo ancora maggiore per raccogliere il loro stato da tutte le distribuzioni e fornire in qualche modo l'accesso ai registri/stato, preferibilmente con riferimento al sistema CD.

In questo senso, il modello push ci consente di fornire almeno alcune garanzie di rollout, poiché la durata della pipeline può essere resa uguale alla durata del rollout.

Abbiamo provato entrambi i modelli e siamo giunti alle stesse conclusioni dell'autore dell'articolo:

Il modello pull ci è adatto per organizzare gli aggiornamenti dei componenti del sistema su un gran numero di cluster (vedi. articolo sull'operatore aggiuntivo).
Il modello push basato su GitLab CI è particolarmente adatto per l'implementazione di applicazioni utilizzando i grafici Helm. Allo stesso tempo, l'implementazione delle implementazioni all'interno delle pipeline viene monitorata utilizzando lo strumento werf. A proposito, nel contesto di questo nostro progetto, abbiamo sentito il costante "GitOps" quando abbiamo discusso dei problemi urgenti degli ingegneri DevOps nel nostro stand al KubeCon Europe'19.

PPS dal traduttore

Stai usando GitOps?

Sì, avvicinati
Sì, spingi
Sì, tira + spingi
Sì, qualcos'altro
No

30 utenti hanno votato. 10 utenti si sono astenuti.

Fonte: habr.com

GitOps: confronto tra metodi pull e push