Athugið. þýð.: Í Kubernetes samfélaginu er þróun sem kallast GitOps að ná augljósum vinsældum, eins og við höfum persónulega séð, KubeCon Europe 2019. Þetta hugtak var tiltölulega nýlegt eftir yfirmann Weaveworks - Alexis Richardson - og þýðir notkun á verkfærum sem forritarar þekkja (aðallega Git, þar af leiðandi nafnið) til að leysa rekstrarvandamál. Sérstaklega erum við að tala um rekstur Kubernetes með því að geyma stillingar þess í Git og útfæra sjálfkrafa breytingar á klasanum. Matthias Jg talar um tvær aðferðir við þessa útfærslu í þessari grein.
Á síðasta ári, (reyndar gerðist þetta formlega í ágúst 2017 - u.þ.b. þýðing) Það er ný nálgun til að dreifa forritum í Kubernetes. Það heitir GitOps og er byggt á þeirri grundvallarhugmynd að uppsetningarútgáfur séu raktar í öruggu umhverfi Git geymslu.
Helstu kostir þessarar aðferðar eru sem hér segir::
- Útgáfuútgáfa og breytingaferill. Staða alls þyrpingarinnar er geymd í Git geymslu og dreifing er aðeins uppfærð í gegnum skuldbindingar. Að auki er hægt að rekja allar breytingar með því að nota skuldbindingarferilinn.
- Afturköllun með kunnuglegum Git skipunum. Einfalt
git resetgerir þér kleift að endurstilla breytingar á dreifingum; fyrri ríki eru alltaf í boði. - Tilbúin aðgangsstýring. Venjulega inniheldur Git kerfi mikið af viðkvæmum gögnum, svo flest fyrirtæki leggja sérstaka áherslu á að vernda þau. Samkvæmt því gildir þessi vernd einnig um aðgerðir með útrásum.
- Stefna fyrir dreifingar. Flest Git kerfi styðja innbyggt grein-fyrir-grein stefnur - til dæmis geta aðeins dráttarbeiðnir uppfært master og breytingar verða að fara yfir og samþykkja af öðrum liðsmanni. Eins og með aðgangsstýringu gilda sömu reglur um dreifingaruppfærslur.
Eins og þú sérð eru margir kostir við GitOps aðferðina. Undanfarið ár hafa tvær aðferðir notið sérstakrar vinsælda. Annar er ýttur, hinn er byggður á dráttum. Áður en við skoðum þær skulum við fyrst skoða hvernig dæmigerð Kubernetes dreifing lítur út.
Dreifingaraðferðir
Á undanförnum árum hafa ýmsar aðferðir og verkfæri til dreifingar fest sig í sessi í Kubernetes:
- Byggt á innfæddum Kubernetes/Kustomize sniðmátum. Þetta er auðveldasta leiðin til að dreifa forritum á Kubernetes. Framkvæmdaraðilinn býr til grunn YAML skrárnar og beitir þeim. Til að losna við að endurskrifa sömu sniðmátin stöðugt var Kustomize þróað (það breytir Kubernetes sniðmátum í einingar). Athugið. þýð.: Kustomize hefur verið samþætt í kubectl með .
- Hjálmarkort. Hjálmartöflur gera þér kleift að búa til sett af sniðmátum, upphafsgámum, hliðarvagnum o.s.frv., sem eru notuð til að dreifa forritum með sveigjanlegri aðlögunarvalkostum en í sniðmátsbundinni nálgun. Þessi aðferð er byggð á sniðmátum YAML skrám. Helm fyllir þær með ýmsum breytum og sendir þær svo til Tiller, klasahluta sem setur þær í þyrpinguna og leyfir uppfærslur og afturköllun. Það mikilvæga er að Helm setur í rauninni bara þau gildi sem óskað er eftir inn í sniðmátin og beitir þeim síðan á sama hátt og það er gert í hefðbundinni nálgun (lestu meira um hvernig þetta virkar allt og hvernig þú getur notað það í okkar - ca. þýðing.). Það er til mikið úrval af tilbúnum Helm töflum sem ná yfir margs konar verkefni.
- Önnur verkfæri. Það eru mörg önnur tæki. Þeir eiga það allir sameiginlegt að breyta sumum sniðmátsskrám í Kubernetes-lesanlegar YAML skrár og nota þær síðan.
Í vinnu okkar notum við stöðugt Helm töflur fyrir mikilvæg verkfæri (þar sem þeir hafa mikið af hlutum þegar tilbúið, sem gerir lífið miklu auðveldara) og "hreinar" Kubernetes YAML skrár til að dreifa eigin forritum.
Dragðu og ýttu
Í einni af nýlegum bloggfærslum mínum kynnti ég tólið , sem gerir þér kleift að binda sniðmát í Git geymsluna og uppfæra dreifinguna eftir hverja commit eða ýtingu á ílátið. Mín reynsla sýnir að þetta tól er eitt af því helsta í því að efla dráttaraðferðina, svo ég mun oft vísa til þess. Ef þú vilt vita meira um hvernig á að nota það, hér .
ATH! Allir kostir þess að nota GitOps eru þeir sömu fyrir báðar aðferðir.
Pull byggt nálgun
Pullaðferðin byggir á því að öllum breytingum er beitt innan úr klasanum. Það er rekstraraðili inni í klasanum sem skoðar reglulega tilheyrandi Git og Docker Registry geymslur. Ef einhverjar breytingar verða á þeim er staða klasans uppfærð innbyrðis. Þetta ferli er almennt talið mjög öruggt, þar sem enginn utanaðkomandi viðskiptavinur hefur aðgang að klasastjórnandaréttindum.
Kostir:
- Enginn utanaðkomandi viðskiptavinur hefur réttindi til að gera breytingar á klasanum; allar uppfærslur eru settar út innan frá.
- Sum verkfæri gera þér einnig kleift að samstilla Helm töfluuppfærslur og tengja þær við klasann.
- Hægt er að skanna Docker Registry fyrir nýjar útgáfur. Ef ný mynd er tiltæk eru Git geymslan og uppsetningin uppfærð í nýju útgáfuna.
- Hægt er að dreifa dráttarverkfærum um mismunandi nafnrými með mismunandi Git geymslum og heimildum. Þökk sé þessu er hægt að nota multitenant líkan. Til dæmis gæti lið A notað nafnrými A, lið B gæti notað nafnrými B og innviðateymið gæti notað alþjóðlegt rými.
- Að jafnaði eru verkfærin mjög létt.
- Samsett með verkfærum eins og stjórnanda , leyndarmál er hægt að geyma dulkóðuð í Git geymslu og sækja innan klasans.
- Það er engin tenging við CD leiðslur þar sem dreifing á sér stað innan klasans.
Gallar:
- Það er erfiðara að hafa umsjón með dreifingarleyndarmálum frá Helm kortum en venjulegum, þar sem fyrst þarf að búa til þau í formi til dæmis innsigluð leyndarmál, síðan afkóða af innri rekstraraðila, og aðeins eftir það verða þau aðgengileg fyrir dráttarverkfærið. Síðan geturðu keyrt útgáfuna í Helm með gildunum í leyndarmálum sem þegar hafa verið sendar út. Auðveldasta leiðin er að búa til leyndarmál með öllum Helm gildunum sem notuð eru við uppsetningu, afkóða það og skuldbinda það til Git.
- Þegar þú tekur aðdráttarafl verðurðu bundinn við togverkfæri. Þetta takmarkar getu til að sérsníða dreifingarferlið í klasa. Til dæmis er Kustomize flókið vegna þess að það verður að keyra áður en lokasniðmátin eru skuldbundin til Git. Ég er ekki að segja að þú getir ekki notað sjálfstæð verkfæri, en erfiðara er að samþætta þau inn í dreifingarferlið þitt.
Push based nálgun
Í þrýstinálguninni setur utanaðkomandi kerfi (aðallega geisladiskaleiðslur) dreifingu í þyrpinguna eftir að hafa verið sett á Git geymsluna eða ef fyrri CI leiðslan heppnast. Í þessari nálgun hefur kerfið aðgang að klasanum.
Kostir:
- Öryggi er ákvarðað af Git geymslunni og byggingaleiðslum.
- Það er auðveldara að dreifa Helm töflum og styður Helm viðbætur.
- Auðveldara er að stjórna leyndarmálum vegna þess að hægt er að nota leyndarmál í leiðslum og einnig er hægt að geyma þau dulkóðuð í Git (fer eftir óskum notandans).
- Það er engin tenging við ákveðið verkfæri, þar sem hægt er að nota hvaða tegund sem er.
- Hægt er að hefja uppfærslur á gámaútgáfum með byggingarleiðslum.
Gallar:
- Klasaaðgangsgögnin eru inni í byggingarkerfinu.
- Enn er auðveldara að uppfæra dreifingargáma með dráttarferli.
- Mikið háð geisladiskakerfinu, þar sem leiðslur sem við þurfum kunna að hafa verið upphaflega skrifaðar fyrir Gitlab Runners, og þá ákveður teymið að fara yfir í Azure DevOps eða Jenkins... og mun þurfa að flytja fjölda byggingaleiðslna.
Niðurstöður: Ýta eða draga?
Eins og venjulega hefur hver aðferð sína kosti og galla. Sum verkefni er auðveldara að framkvæma með einu og erfiðara með öðru. Í fyrstu var ég að gera dreifingar handvirkt en eftir að ég rakst á nokkrar greinar um Weave Flux ákvað ég að innleiða GitOps ferla fyrir öll verkefni. Fyrir grunnsniðmát var þetta auðvelt, en svo fór ég að lenda í erfiðleikum með Helm töflur. Á þeim tíma bauð Weave Flux aðeins grunnútgáfu af Helm Chart Operator, en jafnvel núna eru sum verkefni erfiðari vegna þess að þurfa að búa til leyndarmál handvirkt og beita þeim. Þú gætir haldið því fram að aðdráttaraðferðin sé miklu öruggari vegna þess að skilríki klasans eru ekki aðgengileg utan klasans, sem gerir hann svo miklu öruggari að það er þess virði að leggja á sig aukalega.
Eftir nokkra umhugsun komst ég að þeirri óvæntu niðurstöðu að svo er ekki. Ef við tölum um íhluti sem krefjast hámarksverndar mun þessi listi innihalda leynilega geymslu, CI/CD kerfi og Git geymslur. Upplýsingarnar í þeim eru mjög viðkvæmar og þarfnast hámarksverndar. Að auki, ef einhver kemst inn í Git geymsluna þína og getur ýtt kóða þangað, þá getur hann sett upp hvað sem þeir vilja (hvort sem það er að draga eða ýta) og síast inn í kerfi klasans. Þannig eru mikilvægustu þættirnir sem þarf að vernda Git geymslan og CI/CD kerfin, ekki klasaskilríkin. Ef þú ert með vel stilltar stefnur og öryggisstýringar fyrir þessar tegundir kerfa, og klasaskilríki eru aðeins dregin út í leiðslur sem leyndarmál, gæti aukið öryggi afdráttaraðferðar ekki verið eins mikils virði og upphaflega var talið.
Svo ef aðdráttaraðferðin er vinnufrekari og veitir ekki öryggisávinning, er þá ekki rökrétt að nota aðeins þrýstiaðferðina? En einhver gæti haldið því fram að í þrýstiaðferðinni sétu of bundinn við geisladiskakerfið og ef til vill er betra að gera þetta ekki svo að það verði auðveldara að framkvæma flutninga í framtíðinni.
Að mínu mati (eins og alltaf) ættir þú að nota það sem hentar best fyrir tiltekið tilvik eða sameina. Persónulega nota ég báðar aðferðirnar: Weave Flux fyrir dreifingu sem byggir á dráttum sem innihalda að mestu leyti okkar eigin þjónustu, og ýta nálgun með Helm og viðbótum, sem gerir það auðvelt að setja Helm töflur á þyrpinguna og gerir þér kleift að búa til leyndarmál óaðfinnanlega. Ég held að það verði aldrei ein lausn sem hæfir öllum tilfellum, því það eru alltaf mörg blæbrigði og þau fara eftir tiltekinni notkun. Sem sagt, ég mæli eindregið með GitOps - það gerir lífið miklu auðveldara og bætir öryggi.
Ég vona að reynsla mín af þessu efni hjálpi þér að ákveða hvaða aðferð hentar betur fyrir þína tegund dreifingar og ég væri feginn að heyra álit þitt.
PS Athugasemd frá þýðanda
Gallinn við pull líkanið er sá að það er erfitt að setja birt birtingarmyndir inn í Git, en það er enginn galli að geisladiskaleiðslan í pull líkaninu lifir aðskilið frá útsetningu og verður í raun að flokkapísla Stöðugt sækja um. Þess vegna þarf enn meira átak til að safna stöðu þeirra frá öllum dreifingum og á einhvern hátt veita aðgang að annálum/stöðu, helst með tilvísun í geisladiskkerfið.
Í þessum skilningi gerir þrýstilíkanið okkur kleift að veita að minnsta kosti nokkrar tryggingar fyrir útsetningu, vegna þess að líftími leiðslunnar getur verið jafn líftími útfærslunnar.
Við prófuðum báðar módelin og komumst að sömu niðurstöðu og höfundur greinarinnar:
- Pulllíkanið hentar okkur til að skipuleggja uppfærslur á kerfisíhlutum á miklum fjölda klasa (sjá. ).
- Þrýstilíkanið sem byggir á GitLab CI hentar vel til að útfæra forrit með því að nota Helm töflur. Á sama tíma er fylgst með útsetningu dreifingar innan leiðslna með því að nota tólið . Við the vegur, í tengslum við þetta verkefni okkar, heyrðum við stöðugt „GitOps“ þegar við ræddum brýn vandamál DevOps verkfræðinga á básnum okkar á KubeCon Europe'19.
PPS frá þýðanda
Lestu líka á blogginu okkar:
- «»;
- «»;
- «»;
- «'.
Aðeins skráðir notendur geta tekið þátt í könnuninni. , takk.
Ertu að nota GitOps?
-
Já, draga nálgun
-
Já, ýttu
-
Já, draga + ýta
-
Já, eitthvað annað
-
No
30 notendur kusu. 10 notendur sátu hjá.
Heimild: www.habr.com