GitOps: Comparazione di i metudi Pull and Push

Nota. transl.: In a cumunità Kubernetes, una tendenza chjamata GitOps guadagna una popularità evidente, cum'è avemu vistu personalmente, visità KubeCon Europe 2019. Stu termini era relativamente recente inventatu da u capu di Weaveworks - Alexis Richardson - è significa l'usu di strumenti familiari à i sviluppatori (principalmente Git, da quì u nome) per risolve i prublemi operativi. In particulare, parlemu di u funziunamentu di Kubernetes almacenendu e so cunfigurazioni in Git è automaticamente rolling out cambiamenti à u cluster. Matthias Jg parla di dui approcci à stu rollout in questu articulu.

L 'annu (in fattu, formalmente questu hè accadutu in Aostu 2017 - circa trad.) Ci hè un novu approcciu per implementà applicazioni in Kubernetes. Hè chjamatu GitOps, è hè basatu annantu à l'idea basica chì e versioni di implementazione sò tracciate in l'ambiente sicuru di un repository Git.

I vantaghji principali di stu approcciu sò i seguenti::

1. Versione di implementazione è storia di cambiamentu. U statu di tuttu u cluster hè almacenatu in un repository Git, è e implementazioni sò aghjurnati solu per mezu di commits. Inoltre, tutti i cambiamenti ponu esse tracciati cù a storia di cummit.
2. Rollbacks utilizendu cumandamenti familiari di Git. Semplice git reset permette di resettate cambiamenti in implementazioni; i stati passati sò sempre dispunibili.
3. Prontu cuntrollu di accessu. Di genere, un sistema Git cuntene assai dati sensittivi, cusì a maiò parte di e cumpagnie prestanu una attenzione particulari à a prutezzione. Per quessa, sta prutezzione hè ancu applicata à l'operazioni cù implementazioni.
4. Politiche per l'implementazione. A maiò parte di i sistemi Git supportanu in modu nativu e pulitiche branch-by-branch-per esempiu, solu e richieste di pull ponu aghjurnà u maestru, è i cambiamenti devenu esse riveduti è accettati da un altru membru di a squadra. Cum'è cù u cuntrollu di l'accessu, e stesse pulitiche si applicanu à l'aghjurnamenti di implementazione.

Comu pudete vede, ci sò assai benefici per u metudu GitOps. In l'annu passatu, dui approcci anu guadagnatu una popularità particulare. Unu hè basatu in push, l'altru hè basatu in pull. Prima di guardà elli, guardemu prima ciò chì sò tipici implementazioni Kubernetes.

I metudi di implementazione

In l'ultimi anni, Kubernetes hà stabilitu diversi metudi è arnesi per implementazioni:

1. Basatu nantu à mudelli nativi Kubernetes/Kustomize. Questu hè u modu più faciule per implementà applicazioni in Kubernetes. U sviluppatore crea i schedarii basi YAML è li applica. Per sbarazzà di riscrive constantemente i stessi mudelli, Kustomize hè statu sviluppatu (trasforma mudelli Kubernetes in moduli). Nota. transl.: Kustomize hè stata integrata in kubectl cù liberazione di Kubernetes 1.14.
2. Charts Helm. I charts Helm permettenu di creà setti di mudelli, cuntenituri init, sidecars, etc., chì sò usati per implementà applicazioni cù opzioni di persunalizazione più flexible chì in un approcciu basatu in mudelli. Stu metudu hè basatu annantu à i schedarii YAML di mudellu. Helm li riempie cù diversi parametri è poi li manda à Tiller, un cumpunente di cluster chì li implementa à u cluster è permette l'aghjurnamenti è i rollbacks. L'impurtante hè chì Helm essenzialmente inserisce solu i valori desiderati in i mudelli è poi li applica in u listessu modu cum'è in l'approcciu tradiziunale. (leghjite più nantu à cumu funziona tuttu è cumu pudete aduprà in u nostru articulu di Helm - ca. trad.). Ci hè una larga varietà di charts Helm pronti chì coprenu una larga gamma di compiti.
3. Strumenti alternativu. Ci sò parechje strumenti alternativu. Ciò chì tutti anu in cumunu hè chì trasformanu certi schedarii di mudelli in fugliali YAML leggibili da Kubernetes è poi l'utilizanu.

In u nostru travagliu, usemu constantemente i grafici Helm per arnesi impurtanti (poi ch'elli anu assai cose già pronte, chì rende a vita assai più faciule) è i fugliali "puri" di Kubernetes YAML per implementà e nostre applicazioni.

Pull & Push

In unu di i mo recenti blog posts, aghju introduttu l'uttellu Weave Flux, chì vi permette di cummettà mudelli à u repositoriu Git è aghjurnà a implementazione dopu ogni cummissione o spinta di u cuntinuu. A mo spirienza mostra chì stu strumentu hè unu di i principali in a prumuzione di l'approcciu di pull, cusì spessu riferite à questu. Se vulete sapè più nantu à cumu aduprà, quì ligame à l'articulu.

NB! Tutti i benefici di l'usu di GitOps restanu listessi per i dui approcci.

Approccio basatu in pull

L'approcciu di pull hè basatu annantu à u fattu chì tutti i cambiamenti sò applicati da u cluster. Ci hè un operatore in u cluster chì verifica regularmente i repositori Git è Docker Registry associati. Se ci sò cambiamenti in elli, u statu di u cluster hè aghjurnatu internamente. Stu prucessu hè generalmente cunsideratu assai sicuru, postu chì nisun cliente esternu hà accessu à i diritti di l'amministratore di u cluster.

Pros:

1. Nisun clientu esternu ùn hà u dirittu di fà cambiamenti à u cluster; tutte l'aghjurnamenti sò lanciati da l'internu.
2. Certi arnesi permettenu ancu di sincronizà l'aghjurnamenti di e carte Helm è ligami cù u cluster.
3. Docker Registry pò esse scansatu per novi versioni. Se una nova maghjina hè dispunibule, u repository Git è a implementazione sò aghjurnati à a nova versione.
4. Pull tools ponu esse distribuiti in diversi spazii di nomi cù diversi repositori Git è permessi. Grazie à questu, un mudellu multitenant pò esse usatu. Per esempiu, a squadra A puderia usà u spaziu di nome A, a squadra B puderia usà u spaziu di nome B, è a squadra di l'infrastruttura puderia utilizà u spaziu globale.
5. Comu regula, l'arnesi sò assai ligeri.
6. Cumminatu cù arnesi cum'è operatore Bitnami Sealed Secrets, i sicreti ponu esse guardati criptati in un repository Git è recuperati in u cluster.
7. Ùn ci hè micca una cunnessione cù i pipeline di CD postu chì i dispiegamenti sò in u cluster.

Минусы:

1. A gestione di i sicreti di implementazione da i charts Helm hè più difficiuli di quelli rigulari, postu chì prima deve esse generati in forma di, per dì, sicreti sigillati, poi decriptati da un operatore internu, è solu dopu sò dispunibuli per l'uttellu di pull. Allora pudete eseguisce a liberazione in Helm cù i valori in i sicreti digià implementati. A manera più faciule hè di creà un sicretu cù tutti i valori Helm utilizati per a implementazione, decifrallu è impegnà in Git.
2. Quandu pigliate un avvicinamentu di pull, diventate ligatu à l'arnesi di tira. Questu limita a capacità di persunalizà u prucessu di implementazione in un cluster. Per esempiu, Kustomize hè cumplicatu da u fattu chì deve esse currettu prima chì i mudelli finali sò impegnati in Git. Ùn dicu micca chì ùn pudete micca aduprà strumenti standalone, ma sò più difficiuli di integrà in u vostru prucessu di implementazione.

Approccio basatu à spinta

In l'approcciu push, un sistema esternu (principalmente CD pipeline) lancia implementazioni à u cluster dopu un impegnu à u repository Git o se u pipeline CI precedente hè successu. In questu approcciu, u sistema hà accessu à u cluster.

Плюсы:

1. A sicurezza hè determinata da u repository Git è a pipeline di custruisce.
2. Implementà i grafici Helm hè più faciule è supporta i plugins Helm.
3. I sicreti sò più faciuli di gestisce perchè i sicreti ponu esse utilizati in pipelines è ponu ancu esse almacenati criptati in Git (secondu e preferenze di l'utilizatori).
4. Ùn ci hè micca una cunnessione cù un strumentu specificu, postu chì ogni tipu pò esse usatu.
5. L'aghjurnamenti di a versione di u containeru ponu esse iniziati da u pipeline di creazione.

Минусы:

1. I dati d'accessu à u cluster sò in u sistema di creazione.
2. L'aghjurnamentu di i cuntenituri di implementazione hè sempre più faciule cun un prucessu di pull.
3. A dependenza pesante di u sistema di CD, postu chì e pipeline chì avemu bisognu pò esse scritte in uriginale per Gitlab Runners, è dopu a squadra decide di passà à Azure DevOps o Jenkins ... è duverà migrà un gran numaru di pipelines di custruisce.

Risultati: Push or Pull?

Comu hè di solitu u casu, ogni approcciu hà i so vantaghji è i so contra. Certi travaglii sò più faciuli di rializà cun unu è più difficili cù un altru. À u principiu, aghju fattu implementazioni manualmente, ma dopu avè scontru uni pochi articuli nantu à Weave Flux, aghju decisu di implementà i prucessi GitOps per tutti i prughjetti. Per i mudelli basi, questu era faciule, ma dopu aghju cuminciatu à correre in difficultà cù i charts Helm. À l'epica, Weave Flux offriva solu una versione rudimentale di l'operatore Helm Chart, ma ancu avà certi travaglii sò più difficiuli per a necessità di creà sicreti manualmente è applicà. Puderete argumentà chì l'approcciu di pull hè assai più sicuru perchè e credenziali di u cluster ùn sò micca accessibili fora di u cluster, facendu cusì più sicuru chì vale a pena u sforzu extra.

Dopu qualchì pensamentu, aghju ghjuntu à a cunclusione inespettata chì questu ùn hè micca cusì. Se parlemu di cumpunenti chì necessitanu a massima prutezzione, sta lista includerà u almacenamentu secretu, i sistemi CI / CD è i repositori Git. L'infurmazioni in elli sò assai vulnerabili è necessitanu a massima prutezzione. Inoltre, se qualchissia entra in u vostru repository Git è pò spinghje u codice quì, ponu implementà ciò chì vulete (sia pull o push) è infiltrate i sistemi di u cluster. Cusì, i cumpunenti più impurtanti chì deve esse prutetti sò u repository Git è i sistemi CI / CD, micca i credenziali di cluster. Se tenete pulitiche ben cunfigurate è cuntrolli di sicurezza per questi tipi di sistemi, è e credenziali di cluster sò estratti solu in pipelines cum'è secreti, a sicurità aghjunta di un approcciu di pull ùn pò micca esse preziosa cum'è pensatu urigginariamente.

Allora, se l'approcciu di pull hè più intensivu di travagliu è ùn furnisce micca un benefiziu di sicurità, ùn hè micca logicu aduprà solu l'approcciu push? Ma qualchissia puderia argumentà chì in l'approcciu di spinta hè troppu ligatu à u sistema di CD è, forsi, hè megliu ùn fà micca cusì cusì chì serà più faciule per realizà migrazioni in u futuru.

In u mo parè (cum'è sempre), duvete aduprà ciò chì hè più adattatu per un casu particulari o combina. In modu persunale, aghju utilizatu i dui approcci: Weave Flux per implementazioni basate in pull chì includenu soprattuttu i nostri propri servizii, è un accostu push cù Helm è plugins, chì facilita l'applicà i grafici Helm à u cluster è vi permette di creà secreti senza saldatura. Pensu chì ùn ci sarà mai una solu suluzione adattata per tutti i casi, perchè ci sò sempre assai sfumature è dependenu di l'applicazione specifica. Dittu chistu, vi cunsigliu assai di GitOps - rende a vita assai più faciule è migliurà a sicurità.

Speru chì a mo sperienza nantu à questu tema vi aiuterà à decide quale metudu hè più adattatu per u vostru tipu di implementazione, è mi piacerebbe sente a vostra opinione.

PS Nota da u traduttore

L'inconveniente di u mudellu di pull hè chì hè difficiule di mette i manifesti resi in Git, ma ùn ci hè micca un inconveniente chì u pipeline CD in u mudellu pull vive separatamente da u rollout è essenzialmente diventa un pipeline di categuria. Applicà cuntinuu. Per quessa, ancu più sforzu serà necessariu per cullà u so statutu da tutti i dispiegamenti è in qualchì manera furnisce l'accessu à i logs / status, preferibile cù riferimentu à u sistema CD.

In questu sensu, u mudellu di spinta ci permette di furnisce almenu alcune garanzie di rollout, perchè a vita di u pipeline pò esse uguale à a vita di u rollout.

Avemu pruvatu i dui mudelli è ghjunti à e stesse cunclusioni cum'è l'autore di l'articulu:

1. U mudellu di pull hè adattatu per noi per urganizà l'aghjurnamenti di i cumpunenti di u sistema nantu à un gran numaru di clusters (vede. articulu nantu à l'addon-operator).
2. U mudellu push basatu annantu à GitLab CI hè bè adattatu per lancià l'applicazioni cù i grafici Helm. À u listessu tempu, u rollout di implementazioni in pipelines hè monitoratu cù l'uttellu werf. A propositu, in u cuntestu di u nostru prughjettu, avemu intesu u custanti "GitOps" quandu avemu discututu i prublemi pressanti di l'ingegneri DevOps in u nostru stand à KubeCon Europe'19.

PPS da u traduttore

Leghjite puru nant'à u nostru blog:

• «Cunsiglii è trucchi Kubernetes: trasferimentu di risorse in esecuzione in un cluster à a gestione Helm 2";
• «Presentazione di kubedog, una libreria per seguità e risorse Kubernetes";
• «Espansione è cumplementarii Kubernetes (revisione è video rapportu)";
• «Cunsiglii per creà flussi di travagliu persunalizati in GitLab CI».

Solu l'utilizatori registrati ponu participà à l'indagine. Firmà lu, per piacè.

Aduprate GitOps?

• Iè, tira avvicinamentu

• Iè, spinghja

• Iè, tira + spinghja

• Iè, qualcosa altru

• No

30 utilizatori anu vutatu. 10 utilizatori si sò astenuti.

Source: www.habr.com