ShĂ«n. pĂ«rkth.: NĂ« komunitetin e Kubernetes po fiton popullaritet njĂ« trend i quajtur GitOps, nĂ« tĂ« cilin ne vetĂ« kemi besuar, KubeCon Europe 2019. Ky termin u krijua relativisht kohĂ«t e fundit (nĂ« tĂ« vĂ«rtetĂ«, formalisht kjo ndodhi nĂ« gusht 2017 â shĂ«nim i pĂ«rkthyesit)
Në vitin e kaluar për të përmirësuar mënyrën e shpërndarjes së aplikacioneve në Kubernetes. Ai quhet GitOps, dhe në thelb mbështetet në konceptin themelor që ndjekja e versioneve të deploymenteve bëhet në një mjedis të sigurt Git-repository. Përfitimet kryesore të këtij qasjeje janë si më poshtë
Versionimi i deploymenteve dhe historia e ndryshimeve:
- . Gjendja e të gjithë klasterit ruhet në Git-repository, dhe deploymente përditësohen vetëm përmes komiteve. Për më tepër, të gjitha ndryshimet mund të ndjeken përmes historisë së komiteve.Rikthime me komandat e njohura Git
- . E thjeshtëlejon rikthimin e ndryshimeve në deploymente; gjithmonë janë të disponueshme gjendjet e kaluara.
git riktheKontrolli i gatshëm i aksesit - . Zakonisht, sistemi Git përmban shumë të dhëna të ndjeshme, prandaj shumica e kompanive i kushtojnë vëmendje të veçantë mbrojtjes së tij. Për rrjedhojë, kjo mbrojtje zgjerohet gjithashtu në operacionet me deploymente.Politikat për shpërndarje
- . 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Ă« master, dhe ndryshimet duhet tĂ« kontrollohen dhe tĂ« pranohen nga njĂ« anĂ«tar tjetĂ«r i ekipit. Ashtu si me kontrollin e aksesit, tĂ« njĂ«jtat politika zbatohen pĂ«r pĂ«rditĂ«simet e deploymenteve.Siç e shihni, metoda GitOps ka shumĂ« pĂ«rfitime. GjatĂ« vitit tĂ« kaluar, dy qasje kanĂ« fituar veçanĂ«risht popullaritet. NjĂ«ra Ă«shtĂ« e bazuar nĂ« push, tjetra â nĂ« pull. Para se tâi shqyrtojmĂ« ato, le ta shohim sĂ« pari se si duken deploymente tipike tĂ« Kubernetes.
Metodat e shpërndarjes
Gjatë viteve të fundit, në Kubernetes janë stabilizuar mënyra dhe mjete të ndryshme për shpërndarje:
Të bazuara në shabllone native Kubernetes/Kustomize
- Baza e modeleve native të Kubernetes/Kustomize. Kjo është mënyra më e thjeshtë për të implementuar aplikacione në Kubernetes. Zhvilluesi krijon skedarë bazë YAML dhe i aplikon ata. Për të eliminuar nevojën për të riparuar vazhdimisht të njëjtët shabllone, u zhvillua Kustomize (ai kthen shabllonet e Kubernetes në module). Shën. përkth.: Kustomize është integruar në kubectl me .
- Grafikat Helm. Grafikat Helm lejojnĂ« krijimin e grupeve tĂ« shablloneve, konteinerĂ«ve init, sidecarĂ«ve etj., tĂ« cilat pĂ«rdoren pĂ«r tĂ« zbatuar aplikacione me mundĂ«si mĂ« fleksibĂ«l konfigurimi sesa qasja e bazuar nĂ« shabllone. NĂ« thelb, ky metodĂ« bazohet nĂ« skedarĂ« YAML tĂ« shabllonizuar. Helm i plotĂ«son ato me parametra tĂ« ndryshĂ«m dhe pastaj i dĂ«rgon Tiller-it â komponentit klaster qĂ« i implementon ato nĂ« klaster dhe lejon pĂ«rditĂ«sime dhe rikthime. E rĂ«ndĂ«sishme Ă«shtĂ« se, nĂ« thelb, Helm thjesht fut vlerat e nevojshme nĂ« shabllone dhe pastaj i aplikon ashtu siç bĂ«het nĂ« qasjen tradicionale (mĂ« shumĂ« rreth mĂ«nyrĂ«s se si funksionon kjo dhe si mund tĂ« pĂ«rdoret, lexoni nĂ« artikelin tonĂ« â shĂ«n. pĂ«rkth.). Ekziston njĂ« larmi tĂ« madhe grafike Helm, qĂ« mbulon njĂ« gamĂ« tĂ« gjerĂ« detyrash.
- Mjetet alternative. Ekzistojnë shumë mjete alternative. Të gjitha ato e kanë të përbashkët se ato kthejnë disa skedarë-shabllon në skedarë të kuptueshëm YAML të Kubernetes dhe pastaj i aplikojnë ato.
Në punën tonë përdorim vazhdimisht grafikat Helm për mjete të rëndësishme (sepse shumë nga ato janë të përgatitura, çka e thjeshton ndjeshëm jetën) dhe skedarë 'të pastër' YAML të Kubernetes për të implementuar aplikacionet tona të veta.
Pull & Push
Në një nga publikimet e mia të fundit në blog, prezantova një mjet , që lejon për të komituar shabllonet në repozitorin Git dhe për të përditësuar implementimin pas çdo komitimi ose push-i të konteinerit. Eksperienca ime tregon se ky mjet është një nga thelbësorët në promovimin e qasjes pull, prandaj do t'i referohem shpesh atij. Nëse dëshironi të mësoni më shumë rreth mënyrës se si ta përdorni, këtu është .
NB! Të gjitha përfitimet e përdorimit të GitOps mbeten për të dy qasjet.
Qasja e bazuar në Pull
Qashtja e qasjes pull bazohet në faktin se të gjitha ndryshimet aplikohen nga brenda klasterit. Brenda klasterit ka një operator që rregullisht kontrollon depozitat e lidhura Git dhe Docker Registry. Nëse ndodhin ndonjë ndryshim në to, gjendja e klasterit përditësohet nga brenda. Zakonisht mendohet se një proces i tillë është mjaft 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 përditësimet ushtrohen nga brenda.
- Disa mjete gjithashtu lejojnë sinqronizimin e përditësimeve të Helm-chart dhe lidhjen e tyre me klasterin.
- Docker Registry mund të skanohet për versione të reja. Nëse del një imazh i ri, depozita Git dhe deployment përditësohen në versionin e ri.
- Mjetet pull mund të shpërndahen në hapësira të ndryshme emri me depozita të ndryshme Git dhe të drejta qasjeje. Kështu, mund të aplikohet një model 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ë mjaft të lehta.
- Në kombinim me mjete si operatori , sekrecionet mund të ruhen në formë të enkriptuar në depozitat Git dhe të nxirren brenda klasterit.
- Nuk ka lidhje me CD-pajisjet, pasi shpërndarjet ndodhin brenda klasterit.
Disavantazhet:
- Të menaxhosh sekrecionet e deploymentëve nga Helm-chart është më e vështirë se sa të zakonshmet, pasi fillimisht duhet të gjenerohen në formën, le të themi, sealed secrets, pastaj të çkodohen nga operatori i brendshëm dhe vetëm atëherë bëhen të aksesueshme për mjetin pull. Më pas mund të aktivizohet publikimi në Helm me vlerat në sekrecionet tashmë të shpërndarë. Mënyra më e thjeshtë është të krijosh një sekrecion me të gjitha vlerat Helm që përdoren për deployment, ta çkodosh atë dhe ta komitosh në Git.
- Duke përdorni qasjen pull, jeni të lidhur me mjetet që operojnë me pull. Kjo kufizon mundësinë e konfigurimit të procesit të implementimit të shpërndarjeve në klaster. Për shembull, puna me Kustomize bëhet më e komplikuar sepse duhet të ekzekutohet para se shabllonat përfundimtare të hyjnë në Git. Nuk po thëm se nuk është e mundur të përdoren mjete të veçanta, por është më e vështirë të integrohen në procesin e shpërndarjes.
Qasja e bazuar në Push
Në qasjen push, sistemi i jashtëm (kryesisht pipeline-t e CD) niste implementimet në klaster pas një komitimi në depo Git ose në rastin e një përfundimi të suksesshëm të pipeline-it të mëparshëm CI. Në këtë qasje, sistemi ka akses në klaster.
Pikat pozitive:
- Siguria përcaktohet nga depo Git dhe pipeline-i i ndërtimit.
- Implementimi i grafikeve Helm është më i lehtë, ka mbështetje për plugin-ët Helm.
- Menaxhimi i sekreteve është më i lehtë, pasi sekretet mund të aplikohen në pipeline, si dhe të ruhen në Git në formë të enkriptuar (në varësi të preferencave të përdoruesit).
- Mungesa e lidhjes me një mjet të veçantë, pasi është e mundur të përdoren çdo lloj mjeti.
- Përditësimet e versioneve të konteinerëve mund të nisin nga pipeline-i i ndërtimit.
Disavantazhet:
- Të dhënat për aksesin në klaster ndodhen brenda sistemit të ndërtimit.
- Përditësimi i konteinerëve të shpërndarjeve është akoma më i lehtë për tu kryer me procesin pull.
- Vonesa e fortë ndaj sistemit CD, pasi pipeline-t që na nevojiten, ndoshta janë shkruar fillimisht për Gitlab Runners, dhe më pas ekipi vendos të kalojë në Azure DevOps ose Jenkins... dhe do të duhet të migronim një numër të madh të pipeline-ve të ndërtimit.
PĂ«rmbledhje: Push apo Pull?
Si zakonisht ndodh, çdo qasje ka avantazhe dhe disavantazhe të saj. Disa detyra janë më të lehta për t'u realizuar me njëra dhe më të komplikuara me tjetrën. Në fillim, unë i bëra shpërndarjet manualisht, por pasi lexova disa artikuj mbi Weave Flux, vendosa të implementoj proceset GitOps për të gjithë projektet. Për shabllonat bazë, kjo ishte e lehtë, por pastaj fillova të hasja vështirësi 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ë komplikuara 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, pasi akreditimet e klasterit nuk janë të disponueshme jashtë saj, dhe kjo e rrit sigurinë aq sa ia vlen përpjekjet shtesë.
Pas një reflektimi të vogël, arrita në një përfundim të befasishëm, që nuk është ashtu. Nëse flasim për komponentët që kërkojnë siguri maksimale, një listë e tillë do të përfshijë ruajtësit e sekretëve dhe sistemet CI/CD, si dhe Git repository-t. Informacioni brenda tyre është shumë i prekshëm dhe ka nevojë për mbrojtje maksimale. Për më tepër, nëse dikush arrin të hyj në Git repository tuaj dhe mund të bëjë push aty, ai do të jetë në gjendje të shpërndajë gjithçka që dëshiron (pavarësisht nga qasja e zgjedhur, qoftë ajo pull apo push), dhe të depërtojë në sistemet e klasterit. Pra, komponentët më të rëndësishëm që kërkojnë mbrojtje janë Git repository dhe sistemet CI/CD, jo akreditimet e klasterit. Nëse keni vendosur politika dhe masa sigurie të mira për sistemet e këtij lloji, dhe akreditimet e klasterit nxirren në pipeline vetëm si sekrete, siguria shtesë e qasjes pull mund të mos jetë aq e çmuar sa ishte fillimisht e supozuar.
Pra, nëse qasja pull është më e punësuar dhe nuk ofron përfitime në siguri, a nuk është logjike të përdoret vetëm qasja push? Por dikush mund të thotë se në qasjen push jeni shumë të lidhur me sistemin CD, dhe ndoshta është më mirë të mos e bëni këtë, për të pasur më lehtë migrimet në të ardhmen.
Sipas mendimit tim (ashtu si gjithmonĂ«), duhet tĂ« pĂ«rdorĂ«sh atĂ« qĂ« i pĂ«rshtatet mĂ« shumĂ« rastit tĂ« caktuar ose tĂ« kombinosh. Personalish, pĂ«rdor tĂ« dyja qasjet: Weave Flux pĂ«r shpĂ«rndarjet nĂ« bazĂ« tĂ« pull, tĂ« cilat kryesisht pĂ«rfshijnĂ« shĂ«rbimet tona, dhe qasjen push me Helm dhe pluginet, duke e thjeshtuar aplikimin e chart-eve Helm nĂ« klaster dhe duke lejuar krijimin e sekreteve pa ndonjĂ« problem. Mendoj se nuk do tĂ« ketĂ« njĂ« zgjidhje tĂ« vetme qĂ« i pĂ«rshtatet tĂ« gjithĂ«ve, sepse ka shumĂ« nuanca dhe ato varen nga rasti specifik i pĂ«rdorimit. MegjithatĂ«, rekomandoj fuqishĂ«m GitOps â ai shumĂ« lehtĂ«son jetĂ«n dhe rrit sigurinĂ«.
Shpresoj se përvoja ime në këtë temë do t'ju ndihmojë të vendosni se cilat metodë është më e përshtatshme për llojin tuaj të shpërndarjeve, dhe unë 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ë thotë se është e vështirë të vendosësh manifestet e renditura në Git, megjithatë nuk ka disavantazh se CD pipeline në modelin pull jeton veçmas nga shpërndarja dhe në thelb bëhet një pipeline i kategorisë Continuous Apply. Prandaj do të kërkohen edhe më shumë përpjekje për të mbledhur statusin e të gjitha shpërndarjeve dhe ndonjë mënyrë për të dhënë qasje në log-e/status, më së miri me lidhje me sistemin CD.
Në këtë kuptim, modeli push lejon të japësh ndonjë garanci për shpërndarje, sepse koha e jetës së pipeline mund të bëhet e barabartë me kohën e jetës së shpërndarjes.
Ne kemi provuar të dyja modelet dhe kemi arritur në të njëjtat përfundime si autori i artikullit:
- Modeli pull na përshtatet për organizimin e përditësimeve të komponenteve sistemore në një numër të madh klasteresh (shih. ).
- Modeli push nĂ« bazĂ« tĂ« GitLab CI i pĂ«rshtatet mirĂ« shpĂ«rndarjeve tĂ« aplikacioneve me ndihmĂ«n e chart-eve Helm. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, shpĂ«rndarja e deployment-eve brenda pipeline-ve ndiqet me ndihmĂ«n e mjetit . Nga ana tjetĂ«r, nĂ« kontekstin e kĂ«tij projekti tonĂ«, ne dĂ«gjuam vazhdimisht «GitOps» kur diskutonim problemet e ngutshme tĂ« inxhinierĂ«ve DevOps nĂ« stendĂ«n tonĂ« nĂ« KubeCon Europeâ19.
P.P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutem.
A përdorni GitOps?
Po, qasja pull
Po, push
Po, pull + push
Po, diçka tjetër
Jo
30 përdorues kanë votuar. 10 përdorues janë abstenuar.
Burimi: habr.com
