GitOps: annað tískuorð eða bylting í sjálfvirkni?

Flest okkar, sem taka eftir næsta nýju hugtaki í upplýsingatækni bloggheimum eða ráðstefnu, spyrja fyrr eða síðar svipaðrar spurningar: „Hvað er það? Annað tískuorð, „tískuorð“ eða er það virkilega eitthvað sem vert er að fylgjast vel með, rannsaka og lofa nýjum sjóndeildarhring? Það sama gerðist hjá mér með hugtakið gitops fyrir nokkru síðan. Vopnaður mörgum greinum sem fyrir eru, auk þekkingar samstarfsmanna frá fyrirtækinu GitLab, Ég reyndi að komast að því hvers konar dýr það er og hvernig beiting þess gæti litið út í reynd.

Við the vegur, um nýjung hugtaksins gitops segir einnig nýleg könnun okkar: meira en helmingur aðspurðra er ekki enn byrjaður að vinna með meginreglur hennar.

Þannig að vandamálið við innviðastjórnun er ekki nýtt. Margar skýjaveitur hafa verið aðgengilegar almenningi í góðan áratug og, að því er virðist, hefðu þeir átt að gera vinnu innviðateyma einfalda og tilgerðarlausa. Hins vegar, þegar borið er saman við forritaþróunarferlið (þar sem stig sjálfvirkni nær nýjum og nýjum sjóndeildarhring), fela innviðaverkefni samt oft í sér mörg handvirk verkefni og krefjast sérstakrar þekkingar og sérfræðinga, sérstaklega miðað við kröfur nútímans um bilanaþol, sveigjanleika, sveigjanleika og mýkt. .

Skýjaþjónustur náðu mjög góðum árangri í að uppfylla þessar kröfur og það voru þær sem ýttu verulega undir þróun nálgunarinnar. IaC. Það er skiljanlegt. Þegar öllu er á botninn hvolft voru það þeir sem gerðu það mögulegt að stilla algjörlega sýndargagnaver: það eru engir líkamlegir netþjónar, rekki, nethlutir, hægt er að lýsa öllum innviðum með forskriftum og stillingarskrám.

Svo hver er munurinn nákvæmlega gitops frá IaC? Það var með þessari spurningu sem ég hóf rannsókn mína. Eftir að hafa talað við samstarfsmenn tókst mér að þróa eftirfarandi samanburð:

gitops

IaC

Allur kóði er geymdur í git geymslu

Kóðaútgáfa er valfrjáls

Yfirlýsingar kóða lýsing / Idempotency

Bæði yfirlýsingar og nauðsynlegar lýsingar eru leyfðar

Breytingar taka gildi með samrunabeiðni / Pull Request aðferðum

Samhæfing, samþykki og samvinna eru valkvæð

Ferlið við að útfæra uppfærslur er sjálfvirkt

Ferlið við að útfæra uppfærslur er ekki staðlað (sjálfvirkt, handvirkt, afrita skrár, nota skipanalínuna osfrv.)

Með öðrum orðum gitops varð til með beitingu meginreglnanna IaC. Í fyrsta lagi væri nú hægt að geyma innviði og stillingar alveg eins og forrit. Kóðann er auðvelt að geyma, auðvelt að deila, bera saman, nota útgáfueiginleika. Útgáfur, greinar, saga. Og allt þetta á opinberum stað fyrir allt liðið. Þess vegna er notkun útgáfustýringarkerfa orðin nokkuð eðlileg þróun. Sérstaklega, git, sem vinsælast.

Á hinn bóginn varð mögulegt að gera innviðastjórnunarferli sjálfvirkt. Nú er hægt að gera það hraðar, áreiðanlegra og ódýrara. Þar að auki voru meginreglur CI / CD þegar þekktar og vinsælar meðal hugbúnaðarframleiðenda. Það var aðeins nauðsynlegt að yfirfæra og beita þegar þekktri þekkingu og færni á nýtt svæði. Þessi vinnubrögð fóru hins vegar út fyrir staðlaða skilgreiningu á Infrastructure sem kóða, þess vegna hugtakið gitops.

forvitni gitops, auðvitað líka í þeirri staðreynd að þetta er ekki vara, viðbót eða vettvangur sem tengist neinum söluaðila. Þetta er meira hugmyndafræði og sett af meginreglum, svipað og annað hugtak sem við þekkjum: DevOps.

Í fyrirtæki GitLab við höfum þróað tvær skilgreiningar á þessu nýja hugtaki: fræðileg og hagnýt. Byrjum á fræðilegu:

GitOps er aðferðafræði sem tekur bestu DevOps meginreglurnar sem notaðar eru við þróun forrita, eins og útgáfustýringu, samvirkni, afstemmingu, CI/CD, og ​​beitir þeim til að gera sjálfvirkan innviðastjórnunarverkefni.

Öll ferli gitops Ég vinn með núverandi verkfæri. Allur innviðakóði er geymdur í kunnuglegri git geymslu, breytingar fara í gegnum sama innritunarferli og hver annar kóða og útsetningarferlið er sjálfvirkt, sem lágmarkar mannleg mistök, bætir áreiðanleika og endurgerðanleika.

Frá hagnýtu sjónarhorni lýsum við gitops sem hér segir:

Við höfum þegar fjallað um innviði sem kóða sem einn af lykilþáttum þessarar formúlu. Við skulum kynna hina félagana.

Sameinabeiðni (aðra nafn fyrir Pull Request). Hvað ferlið varðar er MR beiðni um að beita kóðabreytingum og sameina síðan útibú. En hvað varðar tólin sem við notum, þá er þetta meira tækifæri til að fá heildarmynd af öllum breytingunum sem verið er að gera: ekki aðeins kóðamun sem safnað er úr ákveðnum fjölda skuldbindinga, heldur einnig samhengi, prófunarniðurstöður og endanlega væntanlegt. niðurstöðu. Ef við erum að tala um innviðakóða, þá höfum við áhuga á því hvernig nákvæmlega innviðirnir munu breytast, hversu mörgum nýjum auðlindum verður bætt við eða fjarlægð, breytt. Helst á einhverju þægilegra og auðveldara sniði. Þegar um skýjaveitur er að ræða væri gaman að vita hver fjárhagsleg áhrif þessarar breytingar yrðu.

En MR er líka leið til samvinnu, samskipta, samskipta. Staðurinn þar sem eftirlitskerfið kemur við sögu. Allt frá einföldum athugasemdum til formlegra samþykkja og yfirlýsingar.

Jæja, síðasti hluti: CI / CD, eins og við vitum nú þegar, gerir það mögulegt að gera sjálfvirkan ferlið við að gera innviðabreytingar, prófanir (frá einfaldri setningafræðiathugun til flóknari kyrrstöðugreiningar). Og einnig í síðari svifskynjun: munur á raunverulegu og æskilegu ástandi kerfisins. Til dæmis vegna óviðkomandi handvirkra breytinga eða kerfisbilunar.

Já, hugtakið gitops kynnir okkur ekki neitt algerlega nýtt, finnur ekki upp hjólið á ný, heldur beitir aðeins þeirri reynslu sem þegar hefur safnast á nýju svæði. En í því liggur styrkur þess.

Og ef þú færð skyndilega áhuga á því hvernig þetta lítur allt út í reynd, þá býð ég þér að skoða okkar meistaraflokkur, þar sem ég fer með þig í gegnum hvernig á að nota GitLab:

• Innleiða grunnreglur GitOps

• Búðu til og gerðu breytingar á skýjainnviði (í dæmi um Yandex Cloud)

• Gerðu sjálfvirkan greiningu á reki kerfisins frá æskilegu ástandi með virku eftirliti

https://bit.ly/34tRpwZ

Heimild: www.habr.com