🥇GitOps: confronto tra metodi Pull e Push

Nota del traduttore.: Nel mondo di Kubernetes, sta guadagnando popolarità una tendenza chiamata GitOps, di cui abbiamo avuto esperienza personale, partecipando a KubeCon Europe 2019. Questo termine è stato coniato relativamente di recente dal fondatore di Weaveworks — Alexis Richardson — e si riferisce all'uso degli strumenti familiari per gli sviluppatori (principalmente Git, da cui il nome) per affrontare le sfide operative. In particolare, si tratta di gestire Kubernetes memorizzando le sue configurazioni in Git e rilasciando automaticamente le modifiche nel cluster. Matthias Jg parla di due approcci a questo rilascio in questo articolo. il fondatore di Weaveworks, Alexis Richardson, e implica l'uso di strumenti familiari per gli sviluppatori (soprattutto Git, da cui il nome stesso) per affrontare le sfide operative. In particolare, si tratta della gestione di Kubernetes attraverso la memorizzazione delle sue configurazioni in Git e il rilascio automatico delle modifiche nel cluster. Matthias Jg discute di due approcci a questo rilascio in questo articolo.

GitOps: confronto tra i metodi Pull e Push

Lo scorso anno (in realtà, formalmente è accaduto nell'agosto 2017 — nota del traduttore.) è emerso un nuovo approccio per il deployment di applicazioni in Kubernetes. Si chiama GitOps e si basa sull'idea fondamentale che il tracciamento delle versioni dei deployment avviene in un ambiente sicuro di repository Git.

I principali vantaggi di questo approccio sono i seguenti:

Versionamento dei deployment e cronologia delle modifiche. Lo stato dell'intero cluster è conservato in un repository Git e i deployment vengono aggiornati solo tramite commit. Inoltre, tutte le modifiche possono essere tracciate attraverso la cronologia dei commit.
Rollback utilizzando i comandi Git familiari. Semplice git reset consente di ripristinare le modifiche nei deployment; sono sempre disponibili stati precedenti.
Controllo degli accessi pronto. Di solito, il sistema Git contiene molte informazioni confidenziali, quindi la maggior parte delle aziende presta particolare attenzione alla sua protezione. Di conseguenza, questa protezione si estende anche alle operazioni sui deployment.
Politiche per i deployment. La maggior parte dei sistemi Git supporta fin dall'inizio politiche per diversi rami: ad esempio, solo le pull request possono aggiornare il master, e le modifiche devono essere verificate e accettate da un altro membro del team. Come per il controllo degli accessi, le stesse politiche si applicano agli aggiornamenti dei deployment.

Come potete vedere, il metodo GitOps ha molti vantaggi. Negli ultimi anni, due approcci sono diventati particolarmente popolari. Uno è basato su push, l'altro su pull. Prima di considerarli, diamo un'occhiata a come sono tipicamente i deployment di Kubernetes.

Metodi di deployment

Negli ultimi anni, sono emersi diversi modi e strumenti per le distribuzioni in Kubernetes:

Basati sui modelli nativi di Kubernetes/Kustomize. Questo è il modo più semplice per distribuire applicazioni in Kubernetes. Lo sviluppatore crea file YAML di base e li applica. Per evitare di riscrivere continuamente gli stessi modelli, è stato sviluppato Kustomize (che trasforma i modelli di Kubernetes in moduli). Nota del traduttore.: Kustomize è stato integrato in kubectl con il rilascio di Kubernetes 1.14.
Chart Helm. Le Chart Helm consentono di creare set di modelli, init-container, sidecar, ecc., che vengono applicati per il deploy delle applicazioni con possibilità di configurazione più flessibili rispetto all'approccio basato sui modelli. Alla base di questo metodo ci sono file YAML templated. Helm li compila con vari parametri e poi li invia a Tiller—un componente del cluster che li distribuisce nel cluster e permette di eseguire aggiornamenti e rollback. Importante è che Helm inserisce semplicemente i valori necessari nei modelli e poi li applica, proprio come si fa con l'approccio tradizionale. (per ulteriori informazioni su come funziona tutto ciò e come è possibile utilizzarlo, leggi il nostro articolo su Helm — nota di traduzione). Esiste una grande varietà di Helm chart pronti che coprono un'ampia gamma di compiti.
Strumenti alternativi. Ci sono molti strumenti alternativi. Tutti essi condividono il fatto di trasformare alcuni file template in chiari file YAML di Kubernetes e poi applicarli.

Nel nostro lavoro utilizziamo costantemente Helm chart per strumenti importanti (dato che molto è già pronto, il che semplifica notevolmente la vita) e file YAML di Kubernetes 'puliti' per implementare le nostre applicazioni.

Pull & Push

In una delle mie recenti pubblicazioni sul blog ho presentato uno strumento Weave Flux, che consente di fare commit dei template in un repository Git e aggiornare il deployment dopo ogni commit o push del container. La mia esperienza mostra che questo strumento è uno dei principali nel promuovere l'approccio pull, quindi farò spesso riferimento a esso. Se vuoi saperne di più su come utilizzarlo, ecco il link all'articolo.

NB! Tutti i vantaggi dell'uso di GitOps si applicano a entrambi gli approcci.

Approccio basato su Pull

GitOps: confronto tra i metodi Pull e Push

Alla base dell'approccio pull c'è il fatto che tutte le modifiche vengono applicate dall'interno del cluster. All'interno del cluster c'è un operatore che controlla regolarmente i repository Git e Docker Registry associati. Se ci sono modifiche, lo stato del cluster viene aggiornato dall'interno. Questo processo è generalmente considerato molto sicuro, poiché nessun cliente esterno ha accesso ai diritti di amministratore del cluster.

Vantaggi:

Nessun cliente esterno ha il diritto di apportare modifiche al cluster; tutti gli aggiornamenti vengono applicati dall'interno.
Al alcuni strumenti consentono anche di sincronizzare gli aggiornamenti degli Helm chart e collegarli al cluster.
Il Docker Registry può essere scansionato per nuove versioni. Se appare una nuova immagine, il repository Git e il deployment vengono aggiornati alla nuova versione.
Gli strumenti di pull possono essere distribuiti in diversi spazi dei nomi con diversi repository Git e diritti di accesso. Questo consente di applicare un modello multi-tenant. Ad esempio, il team A può utilizzare lo spazio dei nomi A, il team B lo spazio dei nomi B, mentre il team responsabile dell'infrastruttura può utilizzare uno spazio globale.
In generale, gli strumenti sono piuttosto leggeri.
In combinazione con strumenti come l'operatore Bitnami Sealed Secrets, i segreti possono essere memorizzati in forma crittografata nel repository Git ed estratti all'interno del cluster.
Non c'è connessione con i pipeline CD, poiché i deployment avvengono all'interno del cluster.

Svantaggi:

Gestire i segreti dei deployment da Helm chart è più complesso rispetto a quelli normali, poiché inizialmente devono essere generati come sealed secrets, poi decrittografati da un operatore interno e solo dopo diventano disponibili per lo strumento di pull. Successivamente, si può eseguire un rilascio in Helm con i valori già presenti nei segreti distribuiti. Il modo più semplice è creare un segreto con tutti i valori Helm utilizzati per il deployment, decrittografarlo e committarlo in Git.
Utilizzando un approccio pull, ci si ritrova legati agli strumenti che operano sui pull. Questo limita la possibilità di configurare il processo di deployment nei cluster. Ad esempio, lavorare con Kustomize diventa complesso, poiché deve essere eseguito prima che i modelli finali vengano inviati in Git. Non dico che non si possano utilizzare strumenti separati, ma è più difficile integrarli nel processo di deployment.

Approccio basato su Push

GitOps: confronto tra i metodi Pull e Push

Nel modello push, un sistema esterno (principalmente pipeline CD) avvia i deployment nel cluster dopo il commit nel repository Git o dopo il successo dell'esecuzione della pipeline CI precedente. In questo approccio, il sistema ha accesso al cluster.

Pro:

La sicurezza è determinata dal repository Git e dalla pipeline di build.
Distribuire i chart Helm è più semplice, con supporto per i plugin Helm.
Gestire i segreti è più facile, poiché possono essere applicati nelle pipeline e conservati in Git in forma crittografata (a seconda delle preferenze dell'utente).
Assenza di vincoli su strumenti specifici, poiché è possibile utilizzare qualsiasi tipo.
Gli aggiornamenti delle versioni dei container possono essere avviati dalla pipeline di build.

Svantaggi:

I dati per accedere al cluster si trovano all'interno del sistema di build.
L'aggiornamento dei container delle deployment è comunque più semplice con il processo pull.
Dipendenza elevata dal sistema CD, poiché le pipeline necessarie sono probabilmente scritte inizialmente per Gitlab Runners, e poi il team decide di passare a Azure DevOps o Jenkins... e sarà necessario migrare un gran numero di pipeline di build.

Risultati: Push o Pull?

Come spesso accade, ogni approccio ha i suoi pro e contro. Alcuni compiti sono più facili da realizzare con un metodo e più complessi con un altro. Inizialmente, eseguivo le distribuzioni manualmente, ma dopo aver scoperto alcuni articoli su Weave Flux, ho deciso di implementare processi GitOps per tutti i progetti. Per i modelli di base, è stato facile, ma dopo ho iniziato a riscontrare difficoltà nell'utilizzo dei chart di Helm. All'epoca, Weave Flux offriva solo una versione embrionale dell'Helm Chart Operator, ma anche adesso alcune operazioni sono più complesse a causa della necessità di creare manualmente i segreti e applicarli. Si può dire che l'approccio pull è molto più sicuro, poiché le credenziali del cluster non sono accessibili dall'esterno, il che aumenta la sicurezza al punto da giustificare gli sforzi aggiuntivi.

Dopo aver riflettuto un po', sono giunto a una conclusione inaspettata: non è così. Quando si parla dei componenti che richiedono la massima protezione, un elenco di questo tipo includerebbe i repository di segreti e i sistemi CI/CD, oltre ai repository Git. Le informazioni al loro interno sono piuttosto vulnerabili e necessitano della massima protezione. Inoltre, se qualcuno riesce ad accedere al tuo repository Git e può effettuare un push del codice, può distribuire tutto ciò che desidera (indipendentemente dal metodo scelto, sia esso pull o push) e infiltrarsi nei sistemi del cluster. Pertanto, i componenti più critici che richiedono protezione sono i repository Git e i sistemi CI/CD, non le credenziali del cluster. Se hai configurato correttamente politiche e misure di sicurezza per tali sistemi, e le credenziali del cluster vengono estratte nelle pipeline solo sotto forma di segreti, un'ulteriore sicurezza del metodo pull potrebbe non rivelarsi così preziosa come inizialmente si pensava.

Quindi, se l'approccio pull è più laborioso e non offre vantaggi in termini di sicurezza, non sarebbe logico utilizzare solo l'approccio push? Tuttavia, qualcuno potrebbe sostenere che con l'approccio push si è troppo legati al sistema CD e potrebbe essere meglio evitarlo per facilitare future migrazioni.

A mio parere (come sempre), è meglio utilizzare ciò che si adatta meglio al caso specifico o combinarli. Personalmente, utilizzo entrambi gli approcci: Weave Flux per i deployment basati su pull, che includono principalmente i nostri servizi, e l'approccio push con Helm e plugin, che semplifica l'applicazione dei chart di Helm al cluster e permette di creare segreti senza problemi. Penso che non ci sarà mai una soluzione unica adatta a tutte le situazioni, poiché ci sono sempre molte sfumature che dipendono dal caso d'uso specifico. Detto ciò, consiglio vivamente GitOps — rende la vita molto più facile e migliora la sicurezza.

Spero che la mia esperienza su questo argomento possa aiutarti a decidere quale metodo sia più adatto ai tuoi tipi di deployment, e sarò felice di conoscere la tua opinione.

P.S. Nota del traduttore

Tra i difetti del modello pull c'è il fatto che è difficile inserire in Git i manifesti renderizzati, ma non c'è il difetto che il pipeline CD nel modello pull viva separatamente dal rilascio, diventando sostanzialmente un pipeline di categoria. Continuous Apply. Pertanto, saranno necessari ulteriori sforzi per raccogliere lo stato da tutti i deployment e fornire accesso a log/statistiche, preferibilmente collegati al sistema CD.

In questo senso, il modello push permette di fornire almeno alcune garanzie di rilascio, poiché la durata del pipeline può essere allineata alla durata del rilascio.

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

Il modello pull è adatto per l'organizzazione dell'aggiornamento dei componenti di sistema su un gran numero di cluster (vedi l'articolo su addon-operator).
Il modello push basato su GitLab CI è molto utile per il rilascio di applicazioni tramite Helm charts. In questo caso, il rilascio dei deployment all'interno dei pipeline è monitorato tramite uno strumento werf. A proposito, nel contesto di questo nostro progetto, abbiamo sentito spesso "GitOps" quando discutevamo dei problemi attuali degli ingegneri DevOps al nostro stand di KubeCon Europe’19.