🥇GitOps: krahasimi i metodave Pull dhe Push

Shën. përk.: Në komunitetin Kubernetes, trendi i quajtur GitOps po fiton popullaritet të dukshëm, çfarë e kemi përjetuar personalisht, duke vizituar KubeCon Europe 2019. Ky term u shpik relativisht së fundmi nga kreu i kompanisë Weaveworks — Alexis Richardson — dhe nënkupton përdorimin e mjeteve të njohura për zhvilluesit (sidomos — Git, nga e cila vjen dhe emri) për zgjidhjen e problemeve të operimit. Në veçanti, flitet për operimin e Kubernetes përmes ruajtjes së konfigurimeve të tij në Git dhe automatikisht aplikimin e ndryshimeve në klaster. Rreth dy qasjeve për këtë aplikim flet Matthias Jg në këtë artikull. главой компании Weaveworks — Alexis Richardson — и означает применение привычных для разработчиков инструментов (в первую очередь — Git, откуда и само название) для решения задач эксплуатации. В частности, речь об эксплуатации Kubernetes через хранение его конфигураций в Git и автоматического выката изменений в кластер. О двух подходах к этому выкату и рассказывает Matthias Jg в данной статье.

GitOps: krahasimi i metodave Pull dhe Push

Vitit të kaluar (në të vërtetë, në mënyrë formale kjo ndodhi në gusht 2017 — shën. e përkthyesit) po shfaqet një qasje e re për shpërndarjen e aplikacioneve në Kubernetes. E quajtur GitOps, e bazuar në një koncept të thjeshtë që ndjekja e versioneve të deployment’ave zhvillohet në një mjedis të sigurt të depozitës Git.

Përfitimet kryesore të këtij qasjeje janë si më poshtë:

Versionimi i deployment’ave dhe historia e ndryshimeve. Gjendja e gjithë klasterit ruhet në depot Git, dhe dislokimet përditësohen vetëm përmes komiteteve. Për më tepër, të gjitha ndryshimet mund të ndjekin me anë të historisë së komiteteve.
Rikthime me përdorimin e komandave tradicionale të Git. E thjeshtë git reset lejon rikthimin e ndryshimeve në dislokime; gjithmonë janë në dispozicion gjendjet e kaluara.
Kontrolli i gatshëm i aksesit. Zakonisht, sistemi Git përmban shumë të dhëna të ndjeshme, prandaj shumica e kompanive i kushtojnë veçanërisht vëmendje mbrojtjes së saj. Ndërkohë, kjo mbrojtje shtrihet gjithashtu në operacionet me dislokimet.
Politikat për dislokimet. Shumica e sistemeve Git fillimisht mbështesin politika për degë të ndryshme – për shembull, vetëm kërkesat për tërheqje mund të përditësojnë masterin, dhe ndryshimet duhet të kontrollohen e pranohet nga një anëtar tjetër i ekipit. Si me kontrollin e aksesit, të njëjtat politika zbatohen për përditësimet e dislokimeve.

Siç e shihni, metoda GitOps ka shumë përfitime. Gjatë vitit të fundit, dy qasje kanë fituar veçanërisht popullaritet. Njëra bazohet në push, tjetra në pull. Përpara se t’i shqyrtojmë ato, le të shohim fillimisht se si duken dislokimet tipike të Kubernetes.

Metodat e dislokimit

Në vitet e fundit, janë konsoliduar mënyra dhe mjete të ndryshme për shpërndarjen në Kubernetes:

Në bazë të shablloneve native Kubernetes/Kustomize. Ky është mënyra më e thjeshtë për të shpërndarë aplikacione në Kubernetes. Zhvilluesi krijon skedarë të bazuar në YAML dhe i zbarton ato. Për të shmangur shkruarjen e vazhdueshme të të njëjtave shabllone, u zhvillua Kustomize (ai e kthen shabllonet e Kubernetes në module). Shën. përk.: Kustomize u integrua në kubectl me lëshimin e Kubernetes 1.14.
Chartet Helm. Chartet Helm lejojnë krijimin e grupeve të shablloneve, konteinerëve inicialë, sidecar’ëve, etj., të cilat aplikohen për shpërndarjen e aplikacioneve me mundësi më fleksibël konfigurimi sesa qasja e bazuar në shabllo. Në thelb të kësaj metode qëndrojnë skedarët YAML të shabllonuara. Helm i mbush ata me parametra të ndryshëm dhe pastaj i dërgon Tiller-it — komponentit të grumbullit që i shpërndan ato në grumbull dhe lejon që përditësimet dhe rikthimet të kryhen. E rëndësishme është se, në thelb, Helm thjesht vendos vlerat e nevojshme në shabllone dhe pastaj i zbaton ato ashtu siç bëhet në qasjen tradicionale. (me më shumë detaje rreth mënyrës se si funksionon gjithçka dhe si mund të përdoret, lexoni në artikullin tonë rreth Helm — shënim i përkthyesit.). Ekziston një shumëllojshmëri e madhe e helm-chart-eve të gatshme, që mbulojnë një gamë të gjerë detyrash.
Mjetet alternative. Ka shumë mjete alternative. Të gjitha i bashkon fakti se ato kthejnë disa skedarë-shembuj në skedarë të kuptueshëm YAML të Kubernetes dhe pastaj i aplikojnë ato.

Në punën tonë, ne vazhdimisht përdorim helm-chart-e për mjete të rëndësishme (pasi në to ka shumë përgatitur, që e lehtëson ndjeshëm jetesën) dhe skedarë YAML 'të pastër' të Kubernetes për të zbatuar aplikacionet tona.

Pull & Push

Në një prej publikimeve të mia të fundit në blog, prezantova mjetin Weave Flux, që lejon të komitoni shembuj në një depo Git dhe të përditësoni deployment pas çdo komitimi ose push-i të kontenierit. Eksperienca ime tregon se ky mjet është një nga bazat e avancimit të qasjes pull, për këtë arsye do të citoj shpesh atë. Nëse dëshironi të dini më shumë se si ta përdorni, ja linku për artikullin.

NB! Të gjitha përfitimet e përdorimit të GitOps mbeten të vlefshme për të dyja qasjet.

Qasja e bazuar në Pull

GitOps: krahasimi i metodave Pull dhe Push

Baza e qasjes pull është fakti se të gjitha ndryshimet zbatohen nga brenda klasterit. brenda klasterit ka një operator që rregullisht kontrollon depozitat e lidhura Git dhe Docker Registry. Nëse ka ndonjë ndryshim atje, gjendja e klasterit azhurnohet nga brenda. Në përgjithësi, konsiderohet se një proces i tillë është shumë i sigurt, pasi asnjë klient i jashtëm nuk ka qasje në të drejtat e administratorit të klasterit.

Avantazhet:

Asnjë klient i jashtëm nuk ka të drejta për të bërë ndryshime në klaster, të gjitha azhurnimet bëhen nga brenda.
Disa mjete gjithashtu lejojnë të sinkronizoni azhurnimet e Helm chart-eve dhe t'i lidhni ato me klasterin.
Docker Registry mund të skanohet për versione të reja. Nëse një imazh i ri shfaqet, depozita Git dhe deployment-i azhurnohet në versionin e ri.
Mjetet e tërheqjes mund të shpërndahen në hapësira të ndryshme emrash me depo të ndryshme Git dhe të drejta qasjeje. Kjo lejon aplikimin e modelit të shumëqërëshës (multitenant). Për shembull, ekipi A mund të përdorë hapësirën e emrit A, ekipi B hapësirën e emrit B, ndërsa ekipi që merret me infrastrukturën mund të përdorë hapësirën globale.
Në përgjithësi, mjetet janë shumë të lehta.
Në kombinim me mjete si operatori Bitnami Sealed Secrets, sekretet mund të ruhet në formën e enkriptuar në depo Git dhe të nxirren brenda klasterit.
Nuk ka lidhje me CD-pajisjet, pasi implementimet ndodhin brenda klasterit.

Kundrat:

Të menaxhosh sekretet e disiplina nga Helm charts është më e komplikuar se menaxhimi i zakonshëm, pasi fillimisht ato duhet të gjenerohen siç janë, të themi, sekretet e vulosura, pastaj të dekodohen nga operatori i brendshëm dhe vetëm pas kësaj bëhen të disponueshme për mjetin e tërheqjes. Pas kësaj, mund të fillohet versioni në Helm me vlerat nga sekretet që tashmë janë dispezuar. Mënyra më e thjeshtë është të krijoni një sekret me të gjitha vlerat Helm që përdoren për dispenzimin, ta dekodoni atë dhe ta angazhoni në Git.
Duke aplikuar qasjen e tërheqjes, jeni të lidhur me mjetet që operojnë me tërheqje. Kjo kufizon mundësinë për të konfiguruar procesin e dispenzimit në klaster. Për shembull, puna me Kustomize komplikohet sepse duhet të ekzekutohet para se shabllonet përfundimtare të kalojnë në Git. Nuk po them se nuk mund të përdoren mjete të veçanta, por është më e vështirë t'i integroni ato në procesin e dispenzimit.

Qasja e bazuar në Shtytje

GitOps: krahasimi i metodave Pull dhe Push

Në qasjen push, sistemi i jashtëm (përfaqësisht pipeline-t CD) nis implementime në kllaster pas angazhimit në depotin Git ose në rast të suksesit të përfundimit të pipeline-it të mëparshëm CI. Në këtë qasje, sistemi ka akses në kllaster.

Përfitimet:

Siguria përcaktohet nga depoti Git dhe pipeline-i i ndërtimit.
Implementimi i chart-ëve Helm është më i lehtë, sepse ka mbështetje për plugins Helm.
Menaxhimi i sekreteve është më i lehtë, pasi sekretnet mund të përdoren në pipeline, dhe gjithashtu të ruhen në Git në formë të koduar (në varësi të preferencave të përdoruesit).
Nuk ka lidhje me një mjet specifik, pasi mund të përdoren çdo lloj instrumenti.
Përditësimet e versioneve të konteinerëve mund të iniciohen nga pipeline-i i ndërtimit.

Kundrat:

Të dhënat për qasjen në kllaster janë brenda sistemit të ndërtimit.
Përditësimi i konteinerëve të implementimeve është ende më i lehtë për t'u kryer me procesin pull.
Varësia e fortë nga sistemi CD, pasi ndoshta pipeline-t që na nevojiten, fillimisht janë shkruar për Gitlab Runners, dhe pastaj ekipi vendos të kalojë në Azure DevOps ose Jenkins… dhe do të duhet të bëjmë migrimin e një numri të madh të pipeline-ve të ndërtimit.

Përfundim: Push apo Pull?

Si si ndodh zakonisht, çdo qasje ka avantazhet dhe disavantazhet e saj. Disa detyra janë më të lehta për t'u realizuar me një qasje dhe më të vështira me një tjetër. Në fillim, unë bëja implementime manuale, por pasi takohet me disa artikuj mbi Weave Flux, vendosa të zbatoja proceset GitOps për të gjithë projektet. Për shabllonet bazë kjo ishte e lehtë, por më pas fillova të hasja vështirësi në punën me Helm charts. Në atë kohë, Weave Flux ofronte vetëm një version fillestar të Helm Chart Operator, por edhe tani disa detyra janë më të vështira për shkak të nevojës për të krijuar manualisht sekretet dhe për t'i aplikuar ato. Mund të thoni se qasja pull është shumë më e sigurt, sepse kredencialet e klasterit nuk janë të aksesueshme jashtë tij, duke e rritur kaq shumë sigurinë saqë ia vlen çdo përpjekje shtesë.

Pas pak reflektimi, kam arritur në një përfundim të papritur se kjo nuk është e saktë. Kur flasim për komponentët që kërkojnë mbrojtje maksimale, përfshihen ruajtja e sekreteve dhe sistemet CI/CD, si dhe repository-t Git. Informacioni brenda tyre është mjaft i ndjeshëm dhe ka nevojë për mbrojtje maksimale. Për më tepër, nëse dikush arrin të hyjë në repository-n tuaj Git dhe është në gjendje të shtojë kod atje, ai do të mund të implementojë gjithçka që dëshiron (pavarësisht nga qasja e zgjedhur, nëse do të jetë pull ose push), dhe të depërtojë në sistemet e klasterit. Pra, komponentët më të rëndësishëm që kërkojnë mbrojtje janë repository-në Git dhe sistemet CI/CD, jo kredencialet e klasterit. Nëse ju keni vendosur politika dhe masa sigurie të mira për sistemet e këtij lloji, dhe kredencialet e klasterit nxirren në pipeline vetëm si sekrete, siguria shtesë e qasjes pull mund të mos jetë aq e çmuar sa ishte menduar fillimisht.

Pra mu, nëse qasja pull është më e pun intensive dhe nuk ofron përfitime në siguri, a nuk është logjike të përdorim vetëm qasjen push? Por ndokush mund të argumentojë se në qasjen push jeni shumë të varur nga sistemi CD, dhe ndoshta është më mirë të mos e bëni këtë, në mënyrë që në të ardhmen të jetë më e lehtë të bëni migrime.

Sipas mendimit tim (si gjithmonë), duhet të përdorni atë që i përshtatet më mirë rastit të veçantë ose t'i kombinoni ato. Personalish përdor të dyja qasjet: Weave Flux për deployment të bazuar në pull, të cilat kryesisht përfshijnë shërbimet tona, dhe qasjen push me Helm dhe plugins që lehtësojnë aplikimin e Helm charts në klaster dhe lejojnë krijimin e sekreteve pa asnjë problem. Mendoj se kurrë nuk do të ketë një zgjidhje të vetme që i përshtatet të gjitha rasteve, sepse gjithmonë ka shumë nuanca dhe ato varen nga rasti specifik i përdorimit. Megjithatë, unë këshilloj fuqishëm GitOps — ai ndihmon shumë në lehtësimin e jetës dhe rrit sigurinë.

Shpresoj që përvoja ime në këtë temë të ndihmojë në përcaktimin e metodës që i përshtatet më mirë tipit tuaj të deployment-it, dhe do të isha i lumtur të dëgjoja mendimin tuaj.

P.S. Shënim nga përkthyesi

Në disavantazhet e modelit pull, ka një pikë që flet për vështirësitë e depozitimit të manifestave të renderuara në Git, megjithatë, nuk ka një disavantazh që pipeline-i CD në modelin pull jeton veçmas nga versionimi dhe në thelb bëhet një pipeline i kategorisë. Aplikimi i vazhdueshëm. Prandaj, do të kërkohen edhe më shumë përpjekje për të mbledhur statusin nga të gjitha implementimet dhe për të dhënë qasje në logët/statusin, idealisht me lidhje në sistemin CD.

Në këtë kuptim, modeli push lejon dhënien e disa garancive për versionimin, sepse koha e jetës së pipeline-it mund të bëhet e barabartë me kohën e jetës së versionit.

Ne provuam të dyja modelet dhe arritëm në të njëjtat përfundime si autori i artikullit:

Modeli pull na përshtatet për organizimin e përditësimit të komponenteve sistemore në një numër të madh klasteresh (shih. artikulli mbi addon-operatorin).
Modeli push i bazuar në GitLab CI përshtatet mirë për versionimin e aplikacioneve duke përdorur chart-e Helm. Në të njëjtën kohë, versionimi i implementimeve në kuadër të pipeline-ve ndjeket me anë të mjetit werf. Për ta thënë, në kontekstin e këtij projekti tonë, kemi dëgjuar vazhdimisht ‘GitOps’, kur kemi diskutuar për problemet e urgjente të inxhinierëve DevOps në stendën tonë në KubeCon Europe’19.