🥇GitOps: compararea metodelor Pull și Push

Nota traducătorului.: În comunitatea Kubernetes, o tendință numită GitOps câștigă o popularitate evidentă, ceea ce am constatat personal, vizitând KubeCon Europe 2019. Acest termen a fost inventat relativ recent, de către CEO-ul companiei Weaveworks — Alexis Richardson — și se referă la aplicarea unor instrumente familiare pentru dezvoltatori (în primul rând — Git, de unde provine și numele) pentru a rezolva sarcini de operare. În special, se vorbește despre operarea Kubernetes prin stocarea configurațiilor sale în Git și implementarea automată a modificărilor în cluster. Despre două abordări ale acestei implementări vorbește Matthias Jg în acest articol.

GitOps: compararea metodelor Pull și Push

Anul trecut, (de fapt, formal a avut loc în august 2017 — n.r.) a apărut o nouă abordare pentru desfășurarea aplicațiilor în Kubernetes. Se numește GitOps, iar la baza sa stă o convingere fundamentală că urmărirea versiunilor desfășurărilor se face într-un mediu sigur de Git-repository.

Principalele avantaje ale acestei abordări sunt următoarele::

Versiunea desfășurărilor și istoricul modificărilor.Starea întregului cluster este stocată în Git-repository, iar desfășurărilor le sunt actualizate doar prin commituri. În plus, toate modificările pot fi urmărite prin istoricul commiturilor.
Răsturnări folosind comenzile familiare Git.Simplu și git reset permite resetarea modificărilor în desfășurări; întotdeauna sunt disponibile stările anterioare.
Controlul accesului complet.De obicei, sistemul Git conține multe date confidențiale, astfel că majoritatea companiilor acordă o atenție deosebită protecției sale. Prin urmare, această protecție se extinde și asupra operațiunilor cu desfășurări.
Politicile pentru desfășurări.Majoritatea sistemelor Git suportă inițial politici pentru diferite ramuri — de exemplu, doar pull request-urile pot actualiza masterul, iar modificările trebuie să fie verificate și acceptate de un alt membru al echipei. La fel ca și cu controlul accesului, aceleași politici se aplică și actualizărilor desfășurărilor.

După cum vedeți, metoda GitOps are numeroase avantaje. În ultima an, două abordări au câștigat popularitate deosebită. Una se bazează pe push, cealaltă — pe pull. Înainte de a le analiza, să vedem mai întâi cum arată desfășurările tipice Kubernetes.

Modalități de desfășurare.

În ultimii ani, au existat diverse modalități și instrumente pentru desfășurări în Kubernetes:

Pe baza șabloanelor native Kubernetes/Kustomize.. Aceasta este cea mai simplă modalitate de desfășurare a aplicațiilor în Kubernetes. Dezvoltatorul creează fișiere YAML de bază și le aplică. Pentru a evita rescrierea constantă a acelorași șabloane, a fost dezvoltat Kustomize (care transformă șabloanele Kubernetes în module). Nota traducătorului.: Kustomize a fost integrat în kubectl cu versiunea Kubernetes 1.14.
Grafice Helm. Graficele Helm permit crearea de seturi de șabloane, containere inițiale, sidecar-uri etc., care sunt utilizate pentru desfășurarea aplicațiilor cu opțiuni de configurare mai flexibile decât în abordarea bazată pe șabloane. La baza acestei metode se află fișiere YAML template. Helm completează aceste fișiere cu diferite parametri și apoi le trimite către Tiller — componenta cluster care le desfășoară în cluster și permite actualizări și reveniri. Este important de menționat că, în esență, Helm pur și simplu introduce valorile necesare în șabloane și apoi le aplică la fel cum se face în abordarea tradițională. (mai multe detalii despre cum funcționează totul și cum poate fi utilizat, puteți citi în articolul nostru despre Helm — nota trad.). Există o mare diversitate de grafice Helm disponibile, acoperind o gamă largă de sarcini.
Instrumente alternative. Există numeroase instrumente alternative. Toate au în comun faptul că transformă fișiere șablon în fișiere YAML Kubernetes ușor de înțeles și apoi le aplică.

În activitatea noastră, folosim constant grafice Helm pentru instrumente importante (deoarece acestea conțin deja multe configurații, ceea ce facilitează semnificativ munca) și fișiere YAML Kubernetes „pure” pentru desfășurarea aplicațiilor noastre.

Pull & Push

În una dintre publicațiile mele recente pe blog, am prezentat un instrument Weave Flux, care permite comiterea șabloanelor în depozitul Git și actualizarea desfășurării după fiecare commit sau push al unui container. Experiența mea arată că acest instrument este unul dintre cele mai importante în promovarea abordării pull, așa că voi face frecvent referire la el. Dacă doriți să aflați mai multe despre cum să-l utilizați, iată linkul către articol.

NB! Toate avantajele utilizării GitOps se păstrează pentru ambele abordări.

Abordare bazată pe Pull

GitOps: compararea metodelor Pull și Push

La baza abordării pull se află faptul că toate modificările sunt aplicate din interiorul cluster-ului. În interiorul cluster-ului există un operator care verifică în mod regulat repositoriile Git și Docker Registry asociate. Dacă există vreo schimbare în ele, starea cluster-ului este actualizată din interior. În general, se consideră că un astfel de proces este destul de sigur, deoarece niciun client extern nu are acces la drepturile de administrator ale cluster-ului.

Pro:

Niciun client extern nu are drepturi de a efectua modificări în cluster, toate actualizările sunt aplicate din interior.
Unele instrumente permit, de asemenea, sincronizarea actualizărilor helm-chart-urilor și legarea lor de cluster.
Docker Registry poate fi scanat pentru a verifica dacă există noi versiuni. Dacă apare o nouă imagine, repositorul Git și desfășurarea sunt actualizate la noua versiune.
Instrumentele pull pot fi distribuite pe diferite spații de nume cu diferite repositorii Git și drepturi de acces. Datorită acestui lucru, se poate aplica un model multi-tenant. De exemplu, echipa A poate folosi spațiul de nume A, echipa B - spațiul de nume B, iar echipa responsabilă cu infrastructura poate folosi spațiul global.
În general, instrumentele sunt destul de ușoare.
Împreună cu instrumente precum operatorul Bitnami Sealed Secrets, secretele pot fi stocate criptate în repositorul Git și extrase din interiorul cluster-ului.
Nu există o legătură cu CD-pipelines deoarece desfășurările au loc în interiorul cluster-ului.

Dezavantaje:

Gestionarea secretelor desfășurărilor din helm-charts este mai complicată decât cu cele obișnuite, deoarece trebuie să fie generate inițial sub formă de sealed secrets, apoi decriptate de către operatorul intern și abia apoi devin disponibile pentru instrumentul pull. Apoi, se poate lansa o versiune în Helm cu valorile deja desfășurate ale secretelor. Cel mai simplu mod este de a crea un secret cu toate valorile Helm utilizate pentru desfășurare, de a-l decripta și de a-l comite în Git.
Aplicând abordarea pull, ești legat de instrumentele care operează cu pull-uri. Aceasta limitează capacitatea de personalizare a procesului de desfășurare a deployment-urilor în cluster. De exemplu, utilizarea Kustomize este complicată deoarece trebuie să fie executată înainte ca șabloanele finale să ajungă în Git. Nu spun că nu poți folosi instrumente separate, dar este mai complicat să le integrezi în procesul de desfășurare.

Abordarea bazată pe Push

GitOps: compararea metodelor Pull și Push

În abordarea push, un sistem extern (în principal pipeline-uri CD) inițiază desfășurările în cluster după un commit în depozitul Git sau în cazul în care pipeline-ul CI anterior s-a finalizat cu succes. În această abordare, sistemul are acces la cluster.

Advantages:

Securitatea este definită de depozitul Git și pipeline-ul de construire.
Desfășurarea chart-urilor Helm este mai simplă, având suport pentru pluginuri Helm.
Gestionarea secretelor este mai ușoară, deoarece se pot aplica în pipeline-uri și se pot stoca în Git într-o formă criptată (în funcție de preferințele utilizatorului).
Lipsa legăturii cu un instrument specific, deoarece se pot utiliza tipuri variate de instrumente.
Actualizările versiunilor containerelor pot fi inițiate de pipeline-ul de construire.

Dezavantaje:

Datele pentru accesul la cluster se află în interiorul sistemului de construire.
Actualizarea containerelor deployment-urilor este în continuare mai simplă de realizat cu un proces pull.
Dependența puternică de sistemul CD, deoarece pipeline-urile necesare probabil au fost inițial scrise pentru Gitlab Runners, iar apoi echipa decizi să treacă la Azure DevOps sau Jenkins… și va fi necesară migrarea unui număr mare de pipeline-uri de construire.

Concluzii: Push sau Pull?

Așa cum se întâmplă de obicei, orice abordare are avantajele și dezavantajele sale. Anumite sarcini sunt mai ușor de realizat cu una și mai dificil cu cealaltă. La început, am efectuat desfășurări manuale, dar după ce am dat peste câteva articole despre Weave Flux, am decis să implementez procesele GitOps pentru toate proiectele. Pentru șabloanele de bază, aceasta s-a dovedit a fi simplu, dar apoi am început să întâmpin dificultăți în utilizarea diagramelor Helm. La acea vreme, Weave Flux oferea doar o versiune incipientă a Helm Chart Operator, dar chiar și acum, anumite sarcini sunt mai dificile din cauza necesității de a crea manual secrete și de a le aplica. Puteți spune că abordarea pull este mult mai sigură, deoarece acreditivele clusterului nu sunt accesibile din afară, ceea ce sporește atât de mult securitatea încât merită eforturi suplimentare.

Reflectând puțin, am ajuns la concluzia neașteptată că nu este așa. Dacă ne gândim la componentele care necesită cea mai mare protecție, această listă va include stocurile de secrete și sistemele CI/CD, precum și repository-urile Git. Informațiile din interiorul lor sunt foarte vulnerabile și necesită o protecție maximă. În plus, dacă cineva pătrunde în repository-ul dvs. Git și poate face push de cod acolo, atunci poate desfășura tot ce își dorește (indiferent de abordarea aleasă, fie că este vorba de pull sau push) și se poate infiltra în sistemele clusterului. Astfel, componentele cele mai importante care necesită protecție sunt repository-ul Git și sistemele CI/CD, nu acreditivele clusterului. Dacă aveți politici și măsuri de securitate bine configurate pentru acest tip de sisteme, iar acreditivele clusterului sunt extrase în pipeline-uri doar sub formă de secrete, suplimentar, securitatea abordării pull poate să nu fie atât de valoroasă pe cât s-a presupus inițial.

Deci, dacă abordarea pull este mai laborioasă și nu aduce beneficii în ceea ce privește securitatea, nu ar fi logic să folosești doar abordarea push? Dar cineva ar putea argumenta că în abordarea push ești prea legat de sistemul CD și, poate, ar fi mai bine să nu procedezi astfel, pentru a facilita migrațiile în viitor.

Din punctul meu de vedere (ca întotdeauna), ar trebui să folosim ceea ce se potrivește cel mai bine unei situații specifice sau să combinăm cele două metode. Personal, folosesc ambele abordări: Weave Flux pentru deployment-uri pe baza de pull, care includ în principal serviciile noastre proprii, și abordarea push cu Helm și plugin-uri, care simplifică aplicarea chart-urilor Helm în cluster și permite crearea de secrete fără probleme. Cred că nu va exista niciodată o soluție unică adecvată pentru toate situațiile, deoarece există întotdeauna foarte multe nuanțe, iar acestea depind de un anumit caz de utilizare. Cu toate acestea, recomand cu tărie GitOps - acesta ușurează foarte mult viața și crește securitatea.

Sper că experiența mea pe acest subiect vă va ajuta să decideți ce metodă se potrivește cel mai bine tipului vostru de deployment-uri, iar eu aș fi bucuros să aflu părerea voastră.

P.S. Notă de la traducător

Un dezavantaj al modelului pull este că este dificil să se pună în Git manifestele renderizate, totuși nu există dezavantajul că pipeline-ul CD în modelul pull trăiește separat de implementare și, în esență, devine un pipeline din categoria Continuous Apply. Prin urmare, va fi nevoie de și mai multe eforturi pentru a colecta statusul din toate deployment-urile și a da acces la loguri/status, de preferință corelat cu sistemul CD.

În acest sens, modelul push permite oferirea unor garanții pentru implementare, deoarece timpul de viață al pipeline-ului poate fi egalat cu timpul de viață al implementării.

Am testat ambele modele și am ajuns la aceleași concluzii ca și autorul articolului:

Modelul Pull se potrivește pentru organizarea actualizării componentelor de sistem pe un număr mare de clustere (vezi articolul despre addon-operator).
Modelul Push bazat pe GitLab CI este potrivit pentru implementarea aplicațiilor folosind chart-uri Helm. În acest caz, implementarea deployment-urilor în cadrul pipeline-urilor este urmărită cu ajutorul instrumentului werf. Apropo, în contextul acestui proiect, am auzit constant „GitOps” atunci când discutam despre problemele curente ale inginerilor DevOps la standul nostru de la KubeCon Europe '19.