Notă. transl.: În comunitatea Kubernetes, o tendință numită GitOps câștigă o popularitate evidentă, așa cum am văzut personal, KubeCon Europe 2019. Acest termen a fost relativ recent de către șeful Weaveworks - Alexis Richardson - și înseamnă utilizarea unor instrumente familiare dezvoltatorilor (în primul rând Git, de unde și numele) pentru a rezolva probleme operaționale. În special, vorbim despre funcționarea Kubernetes prin stocarea configurațiilor sale în Git și lansarea automată a modificărilor în cluster. Matthias Jg vorbește despre două abordări ale acestei lansări în acest articol.
În ultimul an (de fapt, oficial acest lucru s-a întâmplat în august 2017 - aprox. traducere) Există o nouă abordare a implementării aplicațiilor în Kubernetes. Se numește GitOps și se bazează pe ideea de bază că versiunile de implementare sunt urmărite în mediul securizat al unui depozit Git.
Principalele avantaje ale acestei abordări sunt următoarele::
- Versiunile de implementare și istoricul modificărilor. Starea întregului cluster este stocată într-un depozit Git, iar implementările sunt actualizate numai prin comitări. În plus, toate modificările pot fi urmărite folosind istoricul de comitere.
- Rollbacks folosind comenzi Git familiare... Simplu
git resetvă permite să resetați modificările în implementări; stările trecute sunt întotdeauna disponibile. - Control de acces gata. De obicei, un sistem Git conține o mulțime de date sensibile, așa că majoritatea companiilor acordă o atenție deosebită protejării acestora. În consecință, această protecție se aplică și operațiunilor cu implementări.
- Politici pentru implementări. Majoritatea sistemelor Git acceptă în mod nativ politici ramură cu ramură — de exemplu, numai cererile de extragere pot actualiza master, iar modificările trebuie revizuite și acceptate de un alt membru al echipei. Ca și în cazul controlului accesului, aceleași politici se aplică actualizărilor de implementare.
După cum puteți vedea, metoda GitOps are multe beneficii. În ultimul an, două abordări au câștigat o popularitate deosebită. Unul se bazează pe push, celălalt se bazează pe tragere. Înainte de a le privi, să vedem mai întâi cum arată implementările Kubernetes tipice.
Metode de implementare
În ultimii ani, în Kubernetes s-au stabilit diverse metode și instrumente pentru implementări:
- Bazat pe șabloane native Kubernetes/Kustomize. Acesta este cel mai simplu mod de a implementa aplicații pe Kubernetes. Dezvoltatorul creează fișierele de bază YAML și le aplică. Pentru a scăpa de rescrierea constantă a acelorași șabloane, a fost dezvoltat Kustomize (transformă șabloanele Kubernetes în module). Notă. transl.: Kustomize a fost integrat în kubectl cu .
- Tabele de cârmă. Diagramele Helm vă permit să creați seturi de șabloane, containere init, sidecar-uri etc., care sunt folosite pentru a implementa aplicații cu opțiuni de personalizare mai flexibile decât într-o abordare bazată pe șabloane. Această metodă se bazează pe fișiere YAML șablon. Helm le umple cu diverși parametri și apoi îi trimite către Tiller, o componentă de cluster care le implementează în cluster și permite actualizări și rollback. Important este că, în esență, Helm doar inserează valorile dorite în șabloane și apoi le aplică în același mod în care se face în abordarea tradițională. (citiți mai multe despre cum funcționează totul și despre cum îl puteți utiliza în documentul nostru - aprox. traducere). Există o mare varietate de diagrame Helm gata făcute care acoperă o gamă largă de sarcini.
- Instrumente alternative. Există multe instrumente alternative. Ceea ce au toate în comun este că transformă unele fișiere șablon în fișiere YAML care pot fi citite de Kubernetes și apoi le folosesc.
În munca noastră, folosim în mod constant diagramele Helm pentru instrumente importante (deoarece au o mulțime de lucruri deja pregătite, ceea ce face viața mult mai ușoară) și fișiere YAML Kubernetes „pure” pentru implementarea propriilor aplicații.
Trage împinge
Într-una dintre postările mele recente pe blog, am prezentat instrumentul , care vă permite să trimiteți șabloane în depozitul Git și să actualizați implementarea după fiecare comitere sau împingere a containerului. Experiența mea arată că acest instrument este unul dintre principalele în promovarea abordării pull, așa că mă voi referi adesea la el. Dacă vrei să afli mai multe despre cum să-l folosești, aici .
NB! Toate beneficiile utilizării GitOps rămân aceleași pentru ambele abordări.
Abordare bazată pe tragere
Abordarea pull se bazează pe faptul că toate modificările sunt aplicate din interiorul clusterului. Există un operator în interiorul clusterului care verifică în mod regulat depozitele asociate Git și Docker Registry. Dacă apar modificări la acestea, starea clusterului este actualizată intern. Acest proces este, în general, considerat a fi foarte sigur, deoarece niciun client extern nu are acces la drepturile de administrator de cluster.
Pro-uri:
- Niciun client extern nu are drepturi de a face modificări în cluster; toate actualizările sunt lansate din interior.
- Unele instrumente vă permit, de asemenea, să sincronizați actualizările diagramelor Helm și să le conectați la cluster.
- Docker Registry poate fi scanat pentru versiuni noi. Dacă este disponibilă o nouă imagine, depozitul Git și implementarea sunt actualizate la noua versiune.
- Instrumentele de extragere pot fi distribuite în diferite spații de nume cu diferite depozite Git și permisiuni. Datorită acestui fapt, poate fi utilizat un model multilocator. De exemplu, echipa A ar putea folosi spațiul de nume A, echipa B ar putea folosi spațiul de nume B, iar echipa de infrastructură ar putea folosi spațiul global.
- De regulă, instrumentele sunt foarte ușoare.
- Combinat cu instrumente precum operatorul , secretele pot fi stocate criptate într-un depozit Git și preluate în cluster.
- Nu există nicio conexiune la conductele CD, deoarece implementările au loc în cadrul clusterului.
Contra:
- Gestionarea secretelor de implementare din diagramele Helm este mai dificilă decât cele obișnuite, deoarece acestea trebuie mai întâi generate sub formă, de exemplu, de secrete sigilate, apoi decriptate de un operator intern și abia după aceea devin disponibile instrumentului de extragere. Apoi puteți rula ediția în Helm cu valorile din secretele deja implementate. Cel mai simplu mod este să creați un secret cu toate valorile Helm utilizate pentru implementare, să îl decriptați și să îl trimiteți în Git.
- Când abordezi prin tragere, devii legat de unelte de tragere. Acest lucru limitează capacitatea de a personaliza procesul de implementare într-un cluster. De exemplu, Kustomize este complicat de faptul că trebuie să ruleze înainte ca șabloanele finale să fie trimise în Git. Nu spun că nu poți folosi instrumente independente, dar sunt mai dificil de integrat în procesul tău de implementare.
Abordare bazată pe push
În abordarea push, un sistem extern (în principal conducte CD) lansează implementări în cluster după o comitare în depozitul Git sau dacă conducta CI anterioară are succes. În această abordare, sistemul are acces la cluster.
Pro:
- Securitatea este determinată de depozitul Git și pipeline de construcție.
- Implementarea diagramelor Helm este mai ușoară și acceptă pluginuri Helm.
- Secretele sunt mai ușor de gestionat deoarece secretele pot fi folosite în conducte și pot fi stocate și criptate în Git (în funcție de preferințele utilizatorului).
- Nu există nicio conexiune cu un instrument specific, deoarece poate fi utilizat orice tip.
- Actualizările versiunii containerului pot fi inițiate de canalul de construcție.
Contra:
- Datele de acces la cluster se află în sistemul de compilare.
- Actualizarea containerelor de implementare este încă mai ușoară cu un proces de extragere.
- Dependență puternică de sistemul CD, deoarece conductele de care avem nevoie ar fi putut fi scrise inițial pentru Gitlab Runners, iar apoi echipa decide să se mute la Azure DevOps sau Jenkins... și va trebui să migreze un număr mare de conducte de construcție.
Rezultate: împingeți sau trageți?
Așa cum este de obicei cazul, fiecare abordare are avantajele și dezavantajele sale. Unele sarcini sunt mai ușor de îndeplinit cu una și mai dificil cu alta. La început făceam implementări manual, 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ă, acest lucru a fost ușor, dar apoi am început să întâmpin dificultăți cu diagramele Helm. La acea vreme, Weave Flux oferea doar o versiune rudimentară a Helm Chart Operator, dar și acum unele sarcini sunt mai dificile din cauza necesității de a crea manual secrete și de a le aplica. Ați putea argumenta că abordarea pull este mult mai sigură, deoarece acreditările clusterului nu sunt accesibile în afara clusterului, ceea ce îl face mult mai sigur, încât merită efortul suplimentar.
După câteva gânduri, am ajuns la concluzia neașteptată că nu este așa. Dacă vorbim despre componente care necesită protecție maximă, această listă va include stocare secretă, sisteme CI/CD și depozite Git. Informațiile din interiorul lor sunt foarte vulnerabile și necesită protecție maximă. În plus, dacă cineva intră în depozitul tău Git și poate împinge codul acolo, poate implementa orice dorește (fie că este vorba de pull sau push) și poate infiltra sistemele clusterului. Astfel, cele mai importante componente care trebuie protejate sunt depozitul Git și sistemele CI/CD, nu acreditările clusterului. Dacă aveți politici și controale de securitate bine configurate pentru aceste tipuri de sisteme, iar acreditările de cluster sunt extrase în conducte doar ca secrete, securitatea adăugată a unei abordări pull ar putea să nu fie la fel de valoroasă cum se credea inițial.
Deci, dacă abordarea pull necesită mai multă muncă și nu oferă un beneficiu de securitate, nu este logic să folosim doar abordarea push? Dar cineva ar putea argumenta că în abordarea push ești prea legat de sistemul CD și, poate, este mai bine să nu faci asta, pentru a fi mai ușor să faci migrații în viitor.
În opinia mea (ca întotdeauna), ar trebui să utilizați ceea ce este cel mai potrivit pentru un anumit caz sau combinați. Personal, folosesc ambele abordări: Weave Flux pentru implementări bazate pe pull care includ în cea mai mare parte propriile noastre servicii și o abordare push cu Helm și pluginuri, care facilitează aplicarea diagramelor Helm la cluster și vă permite să creați secrete fără probleme. Cred că nu va exista niciodată o singură soluție potrivită pentru toate cazurile, pentru că întotdeauna există o mulțime de nuanțe și depind de aplicația specifică. Acestea fiind spuse, recomand cu căldură GitOps - face viața mult mai ușoară și îmbunătățește securitatea.
Sper că experiența mea pe acest subiect vă va ajuta să decideți care metodă este mai potrivită pentru tipul dvs. de implementare și m-aș bucura să vă aud părerea.
PS Notă de la traducător
Dezavantajul modelului pull este că este dificil să introduci manifeste redate în Git, dar nu există niciun dezavantaj că conducta CD din modelul pull trăiește separat de lansare și devine, în esență, o conductă de categorie. Aplicare continuă. Prin urmare, va fi necesar și mai mult efort pentru a colecta starea acestora de la toate implementările și pentru a oferi cumva acces la jurnalele/starea, de preferință cu referire la sistemul CD.
În acest sens, modelul push ne permite să oferim cel puțin unele garanții de lansare, deoarece durata de viață a conductei poate fi egalată cu durata de viață a lansării.
Am încercat ambele modele și am ajuns la aceleași concluzii ca și autorul articolului:
- Modelul pull este potrivit pentru ca noi să organizăm actualizări ale componentelor sistemului pe un număr mare de clustere (vezi. ).
- Modelul push bazat pe GitLab CI este potrivit pentru lansarea aplicațiilor folosind diagramele Helm. În același timp, lansarea implementărilor în conducte este monitorizată cu ajutorul instrumentului . Apropo, în contextul acestui proiect al nostru, am auzit constant „GitOps” când am discutat despre problemele stringente ale inginerilor DevOps la standul nostru la KubeCon Europe'19.
PPS de la traducător
Citește și pe blogul nostru:
- «»;
- «»;
- «»;
- «".
Numai utilizatorii înregistrați pot participa la sondaj. , Vă rog.
Folosești GitOps?
-
Da, trageți abordare
-
Da, împinge
-
Da, trage + împinge
-
Da, altceva
-
Nu
Au votat 30 utilizatori. 10 utilizatori s-au abținut.
Sursa: www.habr.com