Märge. tõlge: Kubernetese kogukonnas kogub ilmset populaarsust trend nimega GitOps, nagu oleme isiklikult näinud, KubeCon Europe 2019. See termin oli suhteliselt värske Weaveworksi juhi Alexis Richardsoni poolt ja tähendab arendajatele tuttavate tööriistade (peamiselt Git, sellest ka nimi) kasutamist tööprobleemide lahendamiseks. Eelkõige räägime Kubernetese toimimisest, salvestades selle konfiguratsioonid Giti ja käivitades automaatselt klastri muudatused. Matthias Jg räägib selles artiklis selle levitamise kahest lähenemisviisist.
Möödunud aastal (tegelikult juhtus see ametlikult augustis 2017 – umbes tõlge) Kubernetesis on rakenduste juurutamisel uus lähenemisviis. Seda nimetatakse GitOpsiks ja see põhineb põhiideel, et juurutusversioone jälgitakse Giti hoidla turvalises keskkonnas.
Selle lähenemisviisi peamised eelised on järgmised::
- Juurutamise versioonide koostamine ja muudatuste ajalugu. Kogu klastri olek salvestatakse Git-hoidlasse ja juurutusi värskendatakse ainult kohustuste kaudu. Lisaks saab kõiki muudatusi jälgida sissekannete ajaloo abil.
- Tagasivõtmine tuttavate Giti käskude abil... Tavaline
git resetvõimaldab lähtestada juurutuste muudatusi; minevikuseisud on alati saadaval. - Valmis juurdepääsu kontroll. Tavaliselt sisaldab Git-süsteem palju tundlikke andmeid, nii et enamik ettevõtteid pöörab nende kaitsmisele erilist tähelepanu. Sellest tulenevalt kehtib see kaitse ka kasutuselevõtuga operatsioonide puhul.
- Juurutamise eeskirjad. Enamik Giti süsteeme toetab algselt harupõhiseid eeskirju – näiteks saavad peamist värskendada ainult tõmbamispäringud ning muudatused peab üle vaatama ja heaks kiitma mõni teine meeskonnaliige. Nagu juurdepääsukontrolli puhul, kehtivad juurutamise värskendustele samad reeglid.
Nagu näete, on GitOpsi meetodil palju eeliseid. Viimase aasta jooksul on erilise populaarsuse saavutanud kaks lähenemist. Üks on tõukepõhine, teine tõmbepõhine. Enne kui neid vaatame, vaatame esmalt, millised näevad välja tüüpilised Kubernetese juurutused.
Kasutusmeetodid
Viimastel aastatel on Kubernetesis juurutamiseks välja kujunenud erinevad meetodid ja tööriistad:
- Põhineb natiivsetel Kubernetes/Kustomize'i mallidel. See on lihtsaim viis rakenduste juurutamiseks Kubernetesis. Arendaja loob põhilised YAML-failid ja rakendab need. Et vabaneda samade mallide pidevast ümberkirjutamisest, töötati välja Kustomize (see muudab Kubernetese mallid mooduliteks). Märge. tõlge: Kustomize on integreeritud kubectli koos .
- Helmi graafikud. Helidiagrammid võimaldavad teil luua mallide komplekte, algkonteinereid, külgkorvi jne, mida kasutatakse paindlikumate kohandamisvalikutega rakenduste juurutamiseks kui mallipõhise lähenemisviisi puhul. See meetod põhineb malliga YAML-failidel. Helm täidab need erinevate parameetritega ja saadab need seejärel Tillerile, klastrikomponendile, mis juurutab need klastris ning võimaldab värskendusi ja tagasipööramisi. Oluline on see, et Helm sisuliselt lihtsalt sisestab soovitud väärtused mallidesse ja seejärel rakendab neid samamoodi nagu traditsioonilises lähenemises (lugege lähemalt selle kohta, kuidas see kõik töötab ja kuidas saate seda kasutada meie lehelt - u. tõlge.). Valmis Helmi graafikuid on lai valik, mis katavad mitmesuguseid ülesandeid.
- Alternatiivsed tööriistad. Alternatiivseid tööriistu on palju. Neil kõigil on ühine see, et nad muudavad mõned mallifailid Kubernetese loetavateks YAML-failideks ja seejärel kasutavad neid.
Oma töös kasutame oluliste tööriistade jaoks pidevalt Helmi diagramme (kuna neil on palju asju juba valmis, mis teeb elu palju lihtsamaks) ja “puhtaid” Kubernetes YAML faile enda rakenduste juurutamiseks.
Tõmba lükka
Ühes oma hiljutises ajaveebi postituses tutvustasin tööriista , mis võimaldab kinnitada malle Giti hoidlasse ja värskendada juurutamist pärast iga konteineri kinnistamist või tõuget. Minu kogemus näitab, et see tööriist on üks peamisi tõmbemeetodi propageerimisel, seega viitan sellele sageli. Kui soovite selle kasutamise kohta rohkem teada saada, siis siin .
NB! Kõik GitOpsi kasutamise eelised jäävad mõlema lähenemisviisi puhul samaks.
Tõmbepõhine lähenemine
Tõmbemeetod põhineb asjaolul, et kõik muudatused rakendatakse klastri seest. Klastris on operaator, kes kontrollib regulaarselt seotud Giti ja Dockeri registrihoidlaid. Kui neis tehakse muudatusi, värskendatakse klastri olekut sisemiselt. Seda protsessi peetakse üldiselt väga turvaliseks, kuna ühelgi välisel kliendil pole juurdepääsu klastri administraatori õigustele.
plussid:
- Ühelgi välisel kliendil pole õigusi klastris muudatusi teha; kõik värskendused käivitatakse seestpoolt.
- Mõned tööriistad võimaldavad teil ka Helmi diagrammi värskendusi sünkroonida ja linkida need klastriga.
- Dockeri registrit saab uute versioonide jaoks skannida. Kui uus pilt on saadaval, värskendatakse Giti hoidla ja juurutus uuele versioonile.
- Tõmbetööriistu saab levitada erinevate nimeruumide vahel, millel on erinevad Giti hoidlad ja õigused. Tänu sellele saab kasutada mitme üürniku mudelit. Näiteks võib meeskond A kasutada nimeruumi A, meeskond B kasutada nimeruumi B ja infrastruktuuri meeskond globaalset ruumi.
- Reeglina on tööriistad väga kerged.
- Kombineeritud selliste tööriistadega nagu operaator , saab saladusi salvestada krüpteeritult Git-hoidlasse ja hankida need klastri sees.
- Puudub ühendus CD torujuhtmetega, kuna juurutamine toimub klastris.
Miinused:
- Juurutussaladuste haldamine Helmi diagrammidel on keerulisem kui tavalistel, kuna need tuleb esmalt genereerida näiteks pitseeritud saladuste kujul, seejärel dekrüpteerida sisemise operaatori poolt ja alles pärast seda muutuvad need tõmbetööriistale kättesaadavaks. Seejärel saate Helmis väljalase käivitada juba juurutatud saladuste väärtustega. Lihtsaim viis on luua kõigi juurutamiseks kasutatud Helmi väärtustega saladus, see dekrüpteerida ja Gitile siduda.
- Kui kasutate tõmbemeetodit, seotakse teid tõmbetööriistade külge. See piirab võimalust kohandada juurutusprotsessi klastris. Näiteks teeb Kustomize keeruliseks asjaolu, et see peab töötama enne, kui lõplikud mallid Gitile pühenduvad. Ma ei ütle, et te ei saa kasutada eraldiseisvaid tööriistu, kuid neid on keerulisem juurutusprotsessi integreerida.
Tõukepõhine lähenemine
Tõukepõhise lähenemisviisi korral käivitab väline süsteem (peamiselt CD-konveierid) juurutusi klastris pärast Giti hoidlasse sidumist või kui eelmine CI-konveier on edukas. Selle lähenemisviisi korral on süsteemil juurdepääs klastrile.
Plusse:
- Turvalisuse määrab Giti hoidla ja ehituse torujuhe.
- Helmi diagrammide juurutamine on lihtsam ja toetab Helmi pistikprogramme.
- Saladusi on lihtsam hallata, kuna saladusi saab kasutada konveierites ja neid saab ka Gitis krüpteeritult salvestada (olenevalt kasutaja eelistustest).
- Konkreetse tööriistaga pole ühendust, kuna kasutada saab mis tahes tüüpi.
- Konteineri versiooni värskendusi saab algatada ehituskonveier.
Miinused:
- Klastri juurdepääsuandmed on ehitussüsteemi sees.
- Juurutuskonteinerite värskendamine on tõmbamisprotsessiga endiselt lihtsam.
- Suur sõltuvus CD-süsteemist, kuna meile vajalikud torujuhtmed võisid olla algselt kirjutatud Gitlab Runnersi jaoks ja seejärel otsustab meeskond kolida Azure DevOpsi või Jenkinsi juurde... ja peab migreerima suure hulga ehitustorusid.
Tulemused: lükka või tõmba?
Nagu tavaliselt, on igal lähenemisviisil oma plussid ja miinused. Mõnda ülesannet on ühega kergem täita ja teisega raskem. Algul tegin juurutusi käsitsi, kuid pärast seda, kui leidsin mõne artikli Weave Fluxi kohta, otsustasin juurutada GitOpsi protsessid kõigi projektide jaoks. Põhimallide puhul oli see lihtne, kuid siis tekkis mul Helmi diagrammidega raskusi. Sel ajal pakkus Weave Flux ainult Helm Chart Operatori algelist versiooni, kuid isegi praegu on mõned ülesanded keerulisemad, kuna on vaja käsitsi luua saladusi ja neid rakendada. Võite väita, et tõmbamisviis on palju turvalisem, kuna klastri mandaadid pole väljaspool klastrit juurdepääsetavad, muutes selle nii palju turvalisemaks, et see on lisapingutust väärt.
Pärast mõningast mõtlemist jõudsin ootamatule järeldusele, et see pole nii. Kui räägime komponentidest, mis nõuavad maksimaalset kaitset, siis sisaldab see loend salajasi salvestusi, CI/CD süsteeme ja Giti hoidlaid. Nende sees olev teave on väga haavatav ja vajab maksimaalset kaitset. Lisaks, kui keegi satub teie Giti hoidlasse ja saab sinna koodi lükata, saab ta juurutada mida iganes (olgu see tõmbamine või lükkamine) ja klastri süsteemidesse tungida. Seega on kõige olulisemad komponendid, mida tuleb kaitsta, Giti hoidla ja CI/CD süsteemid, mitte klastri mandaadid. Kui teil on seda tüüpi süsteemide jaoks hästi konfigureeritud eeskirjad ja turbekontrollid ning klastri mandaadid ekstraheeritakse konveieritesse ainult saladuste kujul, ei pruugi tõmbamismeetodi lisaturvalisus olla nii väärtuslik, kui algselt arvati.
Seega, kui tõmbemeetod on töömahukam ja ei anna turvalisust, kas pole loogiline kasutada ainult tõukemeetodit? Kuid keegi võib väita, et push-lähenemise korral olete CD-süsteemiga liiga seotud ja võib-olla on parem seda mitte teha, et tulevikus oleks migratsioone lihtsam läbi viia.
Minu arvates (nagu alati) tuleks kasutada seda, mis konkreetse juhtumi või kombaini jaoks kõige sobivam on. Isiklikult kasutan mõlemat lähenemisviisi: Weave Fluxi tõmbepõhiste juurutuste jaoks, mis hõlmavad enamasti meie enda teenuseid, ja tõukemeetodit Helmi ja pistikprogrammidega, mis muudab Helmi diagrammide klastris hõlpsaks rakendamise ja võimaldab teil sujuvalt saladusi luua. Ma arvan, et kõikidele juhtumitele sobivat ühest lahendust ei tule kunagi, sest nüansse on alati palju ja need sõltuvad konkreetsest rakendusest. Nagu öeldud, soovitan soojalt GitOpsi – see teeb elu palju lihtsamaks ja parandab turvalisust.
Loodan, et minu kogemus sellel teemal aitab teil otsustada, milline meetod on teie kasutusviisi jaoks sobivam, ja mul on hea meel teie arvamust kuulda.
PS Tõlkija märkus
Tõmbemudeli negatiivne külg on see, et renderdatud manifeste on keeruline Giti panna, kuid pole negatiivset, et tõmbemudeli CD-konveier elab levitamisest eraldi ja muutub sisuliselt kategooriakonveieriks. Pidev rakendamine. Seetõttu tuleb veelgi rohkem pingutada, et koguda nende olek kõigist juurutustest ja võimaldada juurdepääsu logidele/olekutele, eelistatavalt CD-süsteemile viidates.
Selles mõttes võimaldab tõukemudel pakkuda vähemalt mõningaid juurutamise tagatisi, sest torujuhtme eluea saab võrdsustada kasutuselevõtu elueaga.
Proovisime mõlemat mudelit ja jõudsime artikli autoriga samadele järeldustele:
- Tõmbemudel sobib meile süsteemikomponentide värskenduste korraldamiseks suurel hulgal klastritel (vt. ).
- GitLab CI-l põhinev tõukemudel sobib hästi rakenduste levitamiseks Helmi diagrammide abil. Samal ajal jälgitakse tööriista abil kasutuselevõttu torujuhtmetes . Muide, selle meie projekti kontekstis kuulsime pidevat “GitOpsi”, kui arutasime oma stendis KubeCon Europe'19 DevOpsi inseneride pakilisi probleeme.
PPS tõlkijalt
Loe ka meie blogist:
- «";
- «";
- «";
- «'.
Küsitluses saavad osaleda ainult registreerunud kasutajad. palun.
Kas kasutate GitOpsi?
-
Jah, tõmmake lähenemine
-
Jah, suruge
-
Jah, tõmba + lükka
-
Jah, midagi muud
-
ei
30 kasutajat hääletas. 10 kasutajat jäi erapooletuks.
Allikas: www.habr.com