GitOps: confronto tra i metodi Pull e Push

Nota di traduzione.: Nella comunità Kubernetes sta guadagnando sempre più popolarità una tendenza chiamata GitOps, di cui abbiamo avuto personalmente conferma, visitando KubeCon Europe 2019. Questo termine è stato coniato relativamente di recente dal capo dell'azienda Weaveworks — Alexis Richardson — e si riferisce all'utilizzo di strumenti familiari agli sviluppatori (soprattutto Git, da cui il nome) per risolvere le sfide operative. In particolare, si tratta dell'operatività di Kubernetes tramite l'archiviazione delle sue configurazioni in Git e il rilascio automatico delle modifiche nel cluster. Di due approcci a questo rilascio parla Matthias Jg in questo articolo. Lo scorso anno

(in realtà, formalmente è avvenuto ad agosto 2017 — nota del traduttore) è emerso un nuovo approccio per il deployment delle applicazioni in Kubernetes. Si chiama GitOps e si basa sul concetto fondamentale che il monitoraggio delle versioni dei deployment avviene in un ambiente Git sicuro. è emerso un nuovo approccio per il deployment delle applicazioni su Kubernetes. Si chiama GitOps e si basa sull'idea fondamentale che il tracciamento delle versioni dei deployment avvenga in un ambiente sicuro di un repository Git.

Versionamento dei deployment e cronologia delle modifiche:

1. Versionamento dei deployment e cronologia delle modifiche. Lo stato dell'intero cluster è memorizzato nel repository Git e i deployment vengono aggiornati solo tramite commit. Inoltre, tutte le modifiche possono essere tracciate attraverso la cronologia dei commit.
2. . È semplicerestituire modifiche ai deployment; passati stati sono sempre disponibili. git reset consente di ripristinare le modifiche nei deployment; gli stati precedenti sono sempre disponibili.
3. . Di solito, un sistema Git contiene molti dati riservati, quindi la maggior parte delle aziende presta particolare attenzione alla sua protezione. Di conseguenza, questa protezione si applica anche alle operazioni sui deployment.. Di solito, un sistema Git contiene molti dati riservati, quindi la maggior parte delle aziende presta particolare attenzione alla sua sicurezza. Di conseguenza, questa protezione si estende anche alle operazioni sui deployment.
4. . La maggior parte dei sistemi Git supporta politiche per diversi branch — ad esempio, solo le pull request possono aggiornare il master, e le modifiche devono essere verificate e approvate da un altro membro del team. Come per il controllo degli accessi, le stesse politiche si applicano agli aggiornamenti dei deployment.. La maggior parte dei sistemi Git supporta inizialmente politiche per diversi rami: ad esempio, solo le pull request possono aggiornare il master e le modifiche devono essere verificate e approvate 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 dodici mesi due approcci hanno guadagnato particolare popolarità. Uno è basato sul push, l'altro sul pull. Prima di esaminarli, diamo un'occhiata a come appaiono i tipici deployment di Kubernetes.

Negli ultimi anni, in Kubernetes si sono consolidati diversi metodi e strumenti per i deployment:

Basati su modelli nativi Kubernetes/Kustomize

1. Basato su modelli nativi di Kubernetes/Kustomize. Questo è il modo più semplice per distribuire applicazioni su Kubernetes. Lo sviluppatore crea file YAML di base e li applica. Per evitare di scrivere costantemente gli stessi modelli, è stato sviluppato Kustomize (che trasforma i modelli Kubernetes in moduli). Nota di traduzione.: Kustomize è stato integrato in kubectl con il rilascio di Kubernetes 1.14.
2. Chart di Helm. I chart Helm permettono di creare set di modelli, container init, sidecar, ecc., che vengono utilizzati per il deployment delle applicazioni con possibilità di configurazione più flessibili rispetto all'approccio basato su modelli. Questo metodo si basa su 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 consente l'aggiornamento e il rollback. È importante notare che, essenzialmente, Helm inserisce semplicemente i valori necessari nei modelli e poi li applica così come si fa in un approccio tradizionale (per maggiori dettagli su come funziona tutto ciò e come si può utilizzare, leggi il nostro articolo su Helm — nota del traduttore.). Esiste una grande varietà di Chart di Helm pronti, che coprono un ampio spettro di compiti.
3. Strumenti alternativi. Ci sono molti strumenti alternativi. Tutti loro hanno in comune il fatto che trasformano certi file-modello in chiari file YAML di Kubernetes e poi li applicano.

Nel nostro lavoro utilizziamo costantemente i Chart di Helm per strumenti importanti (poiché molte cose sono già pronte, il che semplifica notevolmente la vita) e file YAML 'puliti' di Kubernetes per distribuire le nostre applicazioni.

Pull & Push

In uno dei miei recenti post sul blog, ho presentato uno strumento Weave Flux, consentendo di fare commit dei modelli nel repository Git e aggiornare il deployment dopo ogni commit o push del container. La mia esperienza mostra che questo strumento è uno dei più importanti nel promuovere l'approccio pull, quindi farò spesso riferimento ad esso. Se desiderate saperne di più su come utilizzarlo, ecco il link all'articolo.

NB! Tutti i vantaggi dell'utilizzo di GitOps rimangono per entrambi gli approcci.

Approccio basato su Pull

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 il Docker Registry associati. Se ci sono delle modifiche, lo stato del cluster viene aggiornato dall'interno. Si considera generalmente che questo processo sia piuttosto sicuro, poiché nessun cliente esterno ha accesso ai diritti di amministratore del cluster.

Pro:

1. Nessun cliente esterno ha il diritto di apportare modifiche al cluster, tutti gli aggiornamenti vengono applicati dall'interno.
2. Alcuni strumenti consentono anche di sincronizzare gli aggiornamenti dei chart di Helm e di collegarli al cluster.
3. Il Docker Registry può essere scansionato per nuove versioni. Se viene rilasciata una nuova immagine, il repository Git e il deployment vengono aggiornati alla nuova versione.
4. Gli strumenti pull possono essere distribuiti in diversi spazi dei nomi con repository Git e diritti di accesso diversi. 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 lo spazio globale.
5. In generale, gli strumenti sono piuttosto leggeri.
6. In combinazione con strumenti come l'operatore Bitnami Sealed Secrets, i segreti possono essere archiviati in forma crittografata nel repository Git e estratti all'interno del cluster.
7. Non esiste un collegamento con i pipeline CD, poiché i deployment avvengono all'interno del cluster.

Contro:

1. Gestire i segreti dei deployment dai chart Helm è più complesso rispetto a quelli normali, poiché inizialmente devono essere generati in forma, ad esempio, di segreti sigillati, quindi decrittografati da un operatore interno e solo dopo diventano disponibili per lo strumento di pull. Dopodiché è possibile avviare il 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 impegnarlo in Git.
2. Adottando un approccio pull, ti trovi legato a strumenti che operano con i pull. Questo limita le possibilità di personalizzare il processo di distribuzione dei deployment nel cluster. Ad esempio, lavorare con Kustomize diventa complicato, poiché deve essere eseguito prima che i modelli finali arrivino in Git. Non sto dicendo che non si possano utilizzare strumenti separati, ma è più difficile integrarli nel processo di distribuzione.

Approccio basato su Push

Nell'approccio push, un sistema esterno (principalmente pipeline CD) avvia le distribuzioni nel cluster dopo un commit nel repository Git o in caso di esecuzione riuscita di una pipeline CI precedente. In questo approccio, il sistema ha accesso al cluster.

Pro:

1. La sicurezza è definita dal repository Git e dalla pipeline di build.
2. Distribuire i chart Helm è più semplice, poiché c'è supporto per i plugin Helm.
3. Gestire i segreti è più facile, poiché i segreti possono essere utilizzati nelle pipeline e anche memorizzati in Git in forma crittografata (a seconda delle preferenze dell'utente).
4. Assenza di legame con strumenti specifici, poiché possono essere utilizzati tutti i loro tipi.
5. Gli aggiornamenti delle versioni dei container possono essere avviati dalla pipeline di build.

Contro:

1. I dati per accedere al cluster si trovano all'interno del sistema di build.
2. L'aggiornamento dei contenitori dei deployment è comunque più semplice con un processo di pull.
3. Forti dipendenze dal sistema CD, poiché le pipeline necessarie potrebbero essere state originariamente scritte per i Gitlab Runners, e poi il team decide di passare ad Azure DevOps o Jenkins… e sarà necessario migrare un gran numero di pipeline di build.

Conclusioni: Push o Pull?

Come spesso accade, ogni approccio ha i suoi pro e contro. Alcuni compiti sono più facili da eseguire con un metodo e più difficili con un altro. All'inizio eseguivo i deployment 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 poi ho iniziato a riscontrare difficoltà nel lavoro con i chart di Helm. A quel tempo, Weave Flux offriva solo una versione embrionale dell'Operator per Helm Chart, 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 al di fuori di esso, il che aumenta così tanto la sicurezza da giustificare lo sforzo aggiuntivo.

Riflettendo un po', sono giunto a una conclusione inattesa, che non è così. Parlando di componenti che richiedono la massima protezione, la lista includerebbe i repository di segreti e i sistemi CI/CD, i repository Git. Le informazioni al loro interno sono molto vulnerabili e necessitano di una protezione massima. Inoltre, se qualcuno riesce ad infiltrarsi nel tuo repository Git e può effettuare push di codice, avrà la possibilità di distribuire tutto ciò che desidera (indipendentemente dall'approccio scelto, che sia pull o push) e infiltrarsi nei sistemi del cluster. Pertanto, i componenti più importanti che richiedono protezione sono il repository Git e i sistemi CI/CD, e non le credenziali del cluster. Se hai politiche e misure di sicurezza ben configurate per sistemi di questo tipo, e le credenziali del cluster vengono estratte nei pipeline solo sotto forma di segreti, la protezione aggiuntiva dell'approccio pull potrebbe rivelarsi meno preziosa di quanto inizialmente previsto.

Quindi, se l'approccio pull è più laborioso e non offre guadagni in termini di sicurezza, non sarebbe logico utilizzare solo l'approccio push? Ma qualcuno potrebbe obiettare che con l'approccio push sei troppo legato al sistema CD e, forse, sarebbe meglio evitarlo, in modo che in futuro sia più semplice effettuare migrazioni.

A mio avviso (come sempre), bisognerebbe utilizzare ciò che si adatta meglio al caso specifico o combinare. 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 Helm al cluster e consente di creare segreti senza problemi. Penso che non ci sarà mai una soluzione unica adatta a tutti i casi, poiché ci sono sempre molti dettagli e variano a seconda del caso d'uso specifico. In ogni caso, raccomando vivamente GitOps: semplifica notevolmente la vita e aumenta la sicurezza.

Spero che la mia esperienza su questo argomento possa aiutarti a capire quale metodo sia più adatto per il tuo tipo di deployment, e sarei felice di conoscere la tua opinione.

P.S. Nota del traduttore

Tra i contro del modello pull c'è il fatto che è difficile caricare in Git i manifesti renderizzati, tuttavia non c'è lo svantaggio che il pipeline CD nel modello pull vive separatamente dal rilascio e praticamente diventa un pipeline di categoria Continuous Apply. Pertanto, saranno necessari ancora più sforzi per raccogliere lo stato di tutti i deployment e fornire in qualche modo accesso ai log/stato, preferibilmente con riferimento al sistema CD.

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

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

1. Il modello pull è adatto per l'aggiornamento dei componenti di sistema su un gran numero di cluster (vedi l'articolo sul addon-operator).
2. Il modello push basato su GitLab CI si adatta bene al rilascio delle applicazioni tramite chart Helm. Inoltre, il rilascio dei deployment nell'ambito dei pipeline viene monitorato tramite uno strumento werf. A proposito, nel contesto di questo nostro progetto abbiamo sentito costantemente "GitOps" quando abbiamo discusso le problematiche attuali degli ingegneri DevOps al nostro stand a KubeCon Europe'19.

P.P.S. dal traduttore

Leggi anche nel nostro blog:

• «Consigli e trucchi per Kubernetes: traduzione delle risorse operative nel cluster sotto Helm 2»;
• «Presentiamo la libreria kubedog per il monitoraggio delle risorse Kubernetes»;
• «Espandiamo e completiamo Kubernetes (panoramica e video della presentazione)»;
• «Consigli per creare flussi di lavoro personalizzati in GitLab CI».

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.

Utilizzi GitOps?

• Sì, approccio pull

• Sì, push

• Sì, pull + push

• Sì, qualcosa di diverso

• No

Hanno votato 30 utenti. 10 utenti si sono astenuti.

Fonte: habr.com