Athugið. þýð.: Eftir nýlega útgáfu um pull and push aðferðir í GitOps, við sáum almennt áhuga á þessu líkani, en það voru mjög fáar útgáfur á rússnesku um þetta efni (það eru einfaldlega engin á Habré). Þess vegna er okkur ánægja að bjóða þér þýðingu á annarri grein - þó fyrir tæpu ári síðan! - frá Weaveworks, yfirmaður sem bjó til hugtakið „GitOps“. Textinn útskýrir kjarna nálgunarinnar og lykilmun frá þeim sem fyrir eru.
Fyrir ári síðan gáfum við út . Á þeim tíma deildum við því hvernig Weaveworks teymið hleypti af stokkunum SaaS sem byggist algjörlega á Kubernetes og þróaði sett af fyrirskipandi bestu starfsvenjum til að dreifa, stjórna og fylgjast með í skýi innbyggt umhverfi.
Greinin reyndist vinsæl. Annað fólk byrjaði að tala um GitOps og byrjaði að gefa út ný verkfæri fyrir , , , , og svo framvegis. Birtist á heimasíðunni okkar útgáfur og GitOps notkunartilvik. En sumir hafa samt spurningar. Hvernig er líkanið frábrugðið því hefðbundna? og stöðug afhending ()? Er nauðsynlegt að nota Kubernetes?
Fljótlega áttuðum við okkur á því að þörf væri á nýrri lýsingu sem býður upp á:
- Mikill fjöldi dæma og sagna;
- Sérstök skilgreining á GitOps;
- Samanburður við hefðbundna samfellda afhendingu.
Í þessari grein höfum við reynt að fjalla um öll þessi efni. Það veitir uppfærða kynningu á GitOps og sjónarhorni þróunaraðila og CI/CD. Við einbeitum okkur fyrst og fremst að Kubernetes, þó hægt sé að alhæfa líkanið.
Kynntu þér GitOps
Ímyndaðu þér Alice. Hún rekur fjölskyldutryggingar, sem býður upp á heilsu-, bifreiða-, heimilis- og ferðatryggingar fyrir fólk sem er of upptekið til að gera sér grein fyrir kostum samninga sjálft. Viðskipti hennar hófust sem aukaverkefni þegar Alice var að vinna í banka sem gagnafræðingur. Dag einn áttaði hún sig á því að hún gæti notað háþróaða tölvualgrím til að greina gögn á skilvirkari hátt og móta tryggingarpakka. Fjárfestar fjármögnuðu verkefnið og nú skilar fyrirtæki hennar meira en 20 milljónum dollara á ári og fer ört vaxandi. Nú starfa um 180 manns í ýmsum störfum. Þetta felur í sér tækniteymi sem þróar, heldur úti vefsíðunni, gagnagrunninum og greinir viðskiptavinahópinn. Hið 60 manna lið er undir forystu Bob, tæknistjóra fyrirtækisins.
Lið Bobs setur upp framleiðslukerfi í skýinu. Kjarnaforrit þeirra keyra á GKE og nýta Kubernetes á Google Cloud. Auk þess nota þeir ýmis gagna- og greiningartæki í starfi sínu.
Fjölskyldutryggingin ætlaði sér ekki að nota gáma heldur lenti í Docker-áhuganum. Fyrirtækið uppgötvaði fljótlega að GKE gerði það auðvelt að dreifa klasa til að prófa nýja eiginleika. Jenkins fyrir CI og Quay var bætt við til að skipuleggja gámaskrána, forskriftir voru skrifaðar fyrir Jenkins sem ýttu nýjum gámum og stillingum til GKE.
Nokkur tími er liðinn. Alice og Bob urðu fyrir vonbrigðum með frammistöðu þeirrar aðferðar sem þeir valdu og áhrif hennar á fyrirtækið. Innleiðing gáma bætti ekki framleiðni eins mikið og liðið hafði vonast til. Stundum brotnaði uppsetning og óljóst var hvort kóðabreytingum væri um að kenna. Það reyndist líka erfitt að rekja stillingarbreytingar. Oft þurfti að búa til nýjan klasa og færa til hans forrit þar sem það var auðveldasta leiðin til að útrýma óreiðu sem kerfið var orðið. Alice var hrædd um að ástandið myndi versna eftir því sem forritið þróaðist (auk þess var nýtt verkefni byggt á vélanámi í uppsiglingu). Bob var búinn að gera sjálfvirkan meirihluta verksins og skildi ekki hvers vegna leiðslan var enn óstöðug, mælikvarði ekki vel og þurfti reglulega íhlutun handvirkt?
Síðan lærðu þeir um GitOps. Þessi ákvörðun reyndist vera nákvæmlega það sem þeir þurftu til að komast áfram.
Alice og Bob hafa heyrt um Git, DevOps og innviði sem kóðaverkflæði í mörg ár. Það sem er einstakt við GitOps er að það kemur með bestu starfsvenjur – bæði endanlega og staðlaðar – til að útfæra þessar hugmyndir í samhengi við Kubernetes. Þetta þema , þar á meðal í .
Fjölskyldutryggingar ákveða að innleiða GitOps. Fyrirtækið hefur nú sjálfvirkt rekstrarlíkan sem er samhæft við Kubernetes og sameina hraði með stöðugleikaaf því að þau:
- komst að því að framleiðni liðsins tvöfaldaðist án þess að nokkur klikkaði;
- hætt að þjóna skriftum. Þess í stað geta þeir nú einbeitt sér að nýjum eiginleikum og bætt verkfræðilegar aðferðir - til dæmis að kynna kanarífuglaútgáfur og bæta prófanir;
- við höfum bætt dreifingarferlið þannig að það bilar sjaldan;
- fékk tækifæri til að endurheimta dreifingu eftir bilanir að hluta án handvirkrar íhlutunar;
- keypt notaðоMeira traust á afhendingarkerfum. Alice og Bob uppgötvuðu að þau gætu skipt liðinu í örþjónustuteymi sem störfuðu samhliða;
- getur gert 30-50 breytingar á verkefninu á hverjum degi með átaki hvers hóps og prófað nýja tækni;
- það er auðvelt að laða að nýja þróunaraðila að verkefninu, sem hafa tækifæri til að setja upp uppfærslur á framleiðslu með því að nota dráttarbeiðnir innan nokkurra klukkustunda;
- standast endurskoðun auðveldlega innan ramma SOC2 (til að uppfylla kröfur þjónustuveitenda um örugga gagnastjórnun; lestu meira, td. - ca. þýðing.).
Hvað gerðist?
GitOps er tvennt:
- Rekstrarlíkan fyrir Kubernetes og skýjamódel. Það veitir safn af bestu starfsvenjum til að dreifa, stjórna og fylgjast með gámaþyrpingum og forritum. Glæsileg skilgreining í formi frá :
- Leiðin að því að búa til forritaramiðað forritastjórnunarumhverfi. Við notum Git verkflæðið bæði í rekstur og þróun. Vinsamlegast athugaðu að þetta snýst ekki bara um Git push, heldur um að skipuleggja allt settið af CI/CD og UI/UX verkfærum.
Nokkur orð um Git
Ef þú þekkir ekki útgáfustýringarkerfi og Git-undirstaða vinnuflæði, mælum við eindregið með því að læra um þau. Að vinna með útibú og togabeiðnir kann að virðast eins og svartagaldur í fyrstu, en ávinningurinn er fyrirhafnarinnar virði. Hérna að byrja.
Hvernig Kubernetes virkar
Í sögunni okkar sneru Alice og Bob sér að GitOps eftir að hafa unnið með Kubernetes um stund. Reyndar er GitOps nátengd Kubernetes - það er rekstrarlíkan fyrir innviði og forrit byggð á Kubernetes.
Hvað gefur Kubernetes notendum?
Hér eru nokkrir helstu eiginleikar:
- Í Kubernetes líkaninu er hægt að lýsa öllu í yfirlýsingarformi.
- Kubernetes API þjónninn tekur þessa yfirlýsingu sem inntak og reynir síðan stöðugt að koma þyrpingunni í það ástand sem lýst er í yfirlýsingunni.
- Yfirlýsingar nægja til að lýsa og stjórna margs konar vinnuálagi — „umsóknir“.
- Þess vegna eiga sér stað breytingar á forritinu og þyrpingunni vegna:
- breytingar á gámamyndum;
- breytingar á yfirlýsandi forskrift;
- villur í umhverfinu - til dæmis gámahrun.
Miklir samleitnihæfileikar Kubernetes
Þegar stjórnandi gerir breytingar á stillingum mun Kubernetes hljómsveitarstjórinn nota þær á klasann svo lengi sem ástand hans er mun ekki koma nálægt nýju uppsetningunni. Þetta líkan virkar fyrir hvaða Kubernetes auðlind sem er og er hægt að stækka með sérsniðnum auðlindaskilgreiningum (CRD). Þess vegna hefur Kubernetes dreifing eftirfarandi frábæra eiginleika:
- Sjálfvirkni: Kubernetes uppfærslur bjóða upp á kerfi til að gera sjálfvirkan ferlið við að beita breytingum á þokkafullan og tímanlegan hátt.
- Samruni: Kubernetes mun halda áfram að reyna uppfærslur þar til það tekst.
- Geðleysi: Endurtekin beiting á samleitni leiðir til sömu niðurstöðu.
- Ákveðni: Þegar tilföng eru næg veltur ástand uppfærða klasans aðeins eftir því ástandi sem óskað er eftir.
Hvernig GitOps virkar
Við höfum lært nóg um Kubernetes til að útskýra hvernig GitOps virkar.
Snúum okkur aftur að örþjónustuteymum Fjölskyldutrygginga. Hvað þurfa þeir venjulega að gera? Skoðaðu listann hér að neðan (ef einhver atriði í honum virðast undarleg eða ókunnug, vinsamlegast haltu áfram að gagnrýna og vertu hjá okkur). Þetta eru bara dæmi um vinnuflæði sem byggir á Jenkins. Það eru mörg önnur ferli þegar unnið er með önnur verkfæri.
Aðalatriðið er að við sjáum að hverri uppfærslu lýkur með breytingum á stillingarskrám og Git geymslum. Þessar breytingar á Git valda því að „GitOps rekstraraðili“ uppfærir þyrpinguna:
1. Vinnuferli: "Jenkins byggja - meistaragrein'.
Verkefnalisti:
- Jenkins ýtir merktum myndum til Quay;
- Jenkins ýtir config og Helm töflum í aðal geymslufötuna;
- Skýjaaðgerðin afritar stillingar og töflur úr aðalgeymslufötunni yfir í aðal Git geymsluna;
- GitOps rekstraraðili uppfærir þyrpinguna.
2. Jenkins smíða - útgáfu eða flýtileiðréttingargrein:
- Jenkins ýtir ómerktum myndum til Quay;
- Jenkins ýtir stillingar- og Helm-kortum að sviðsgeymslufötunni;
- Skýjaaðgerðin afritar stillingar og töflur úr sviðsetningargeymslunni yfir í sviðsetningar Git geymsluna;
- GitOps rekstraraðili uppfærir þyrpinguna.
3. Jenkins byggja - þróa eða lögun útibú:
- Jenkins ýtir ómerktum myndum til Quay;
- Jenkins ýtir stillingar- og Helm-kortum í þróunargeymslufötu;
- Skýjaaðgerðin afritar stillingar og töflur úr þróunargeymslufötunni yfir í þróunar Git geymsluna;
- GitOps rekstraraðili uppfærir þyrpinguna.
4. Bætir nýjum viðskiptavini við:
- Stjórnandinn eða stjórnandinn (LCM/ops) kallar til Gradle til að setja upp og stilla netálagsjafnara (NLBs) í upphafi;
- LCM/ops framkvæmir nýja stillingu til að undirbúa dreifinguna fyrir uppfærslur;
- GitOps rekstraraðili uppfærir þyrpinguna.
Stutt lýsing á GitOps
- Lýstu æskilegu ástandi alls kerfisins með því að nota yfirlýsandi forskriftir fyrir hvert umhverfi (í sögunni okkar skilgreinir teymi Bob alla kerfisuppsetninguna í Git).
- Git geymslan er ein uppspretta sannleikans varðandi æskilegt ástand alls kerfisins.
- Allar breytingar á viðkomandi ástandi eru gerðar í gegnum skuldbindingar í Git.
- Allar æskilegar klasabreytur eru einnig sjáanlegar í klasanum sjálfum. Á þennan hátt getum við ákvarðað hvort þau falli saman (samræmast, renna saman) eða mismunandi (munur, víkja) óskað og athugað ástand.
- Ef æskileg og fylgst ríki eru mismunandi, þá:
- Það er samleitnikerfi sem fyrr eða síðar samstillir sjálfkrafa markmiðið og ástandið sem sést. Inni í klasanum gerir Kubernetes þetta.
- Ferlið hefst strax með viðvörun um „breyting framin“.
- Eftir nokkurn stillanlegan tíma er hægt að senda „diff“ viðvörun ef ástandið er öðruvísi.
- Þannig valda allar skuldbindingar í Git sannanlegum og óþolandi uppfærslum á klasanum.
- Afturköllun er samleitni í áður óskað ástand.
- Samruninn er endanlegur. Tilvik þess er gefið til kynna með:
- Engar mismunandi viðvaranir í ákveðinn tíma.
- „converged“ viðvörun (td webhook, Git-afritunarviðburður).
Hvað er mismunun?
Við skulum endurtaka aftur: allir æskilegar klasaeiginleikar verða að vera sjáanlegir í klasanum sjálfum.
Nokkur dæmi um mismunun:
- Breyting á stillingarskrá vegna sameiningar útibúa í Git.
- Breyting á stillingarskránni vegna Git commit sem GUI viðskiptavinurinn gerði.
- Margar breytingar á æskilegu ástandi vegna PR í Git fylgt eftir með því að byggja upp gámamyndina og stillingarbreytingar.
- Breyting á ástandi klasans vegna villu, auðlindaátaka sem leiðir til „slæmrar hegðunar“ eða einfaldlega tilviljunarkennds fráviks frá upprunalegu ástandi.
Hver er aðferðin við samleitni?
Nokkur dæmi:
- Fyrir ílát og klasa er samleitnibúnaðurinn útvegaður af Kubernetes.
- Sama vélbúnaður er hægt að nota til að stjórna Kubernetes-undirstaða forritum og hönnun (eins og Istio og Kubeflow).
- Vélbúnaður til að stjórna rekstrarsamskiptum milli Kubernetes, myndageymsla og Git býður upp á , sem er hluti .
- Fyrir grunnvélar verður samleitnibúnaðurinn að vera lýsandi og sjálfstæður. Af eigin reynslu getum við sagt það næst þessari skilgreiningu, en krefst samt mannlegrar stjórnunar. Í þessum skilningi víkkar GitOps út hefð innviða sem kóða.
GitOps sameinar Git með frábærri samleitnivél Kubernetes til að bjóða upp á fyrirmynd fyrir hagnýtingu.
GitOps gerir okkur kleift að segja: Aðeins þau kerfi sem hægt er að lýsa og fylgjast með er hægt að gera sjálfvirk og stjórna.
GitOps er ætlað fyrir allan skýjastafla (til dæmis Terraform, osfrv.)
GitOps er ekki bara Kubernetes. Við viljum að allt kerfið sé knúið áfram af yfirlýsingu og noti samleitni. Með öllu kerfinu er átt við safn umhverfi sem vinnur með Kubernetes - til dæmis, "dev cluster 1", "framleiðsla" o.s.frv. Hvert umhverfi inniheldur vélar, klasa, forrit, auk viðmóta fyrir utanaðkomandi þjónustu sem veitir gögn, eftirlit og o.s.frv.
Taktu eftir hversu mikilvægt Terraform er fyrir ræsingarvandamálið í þessu tilfelli. Einhvers staðar þarf að koma Kubernetes í notkun og með því að nota Terraform getum við beitt sömu GitOps verkflæðinum til að búa til stjórnlagið sem liggur undir Kubernetes og forritum. Þetta eru gagnlegar bestu venjur.
Mikil áhersla er lögð á að beita GitOps hugtökum á lög ofan á Kubernetes. Í augnablikinu eru til lausnir af GitOps-gerð fyrir Istio, Helm, Ksonnet, OpenFaaS og Kubeflow, sem og, til dæmis, fyrir Pulumi, sem búa til lag til að þróa forrit fyrir skýjamætt.
Kubernetes CI/CD: að bera saman GitOps við aðrar aðferðir
Eins og fram hefur komið er GitOps tvennt:
- Rekstrarlíkanið fyrir Kubernetes og skýjamódel sem lýst er hér að ofan.
- Leiðin að þróunarmiðuðu forritastjórnunarumhverfi.
Fyrir marga er GitOps fyrst og fremst vinnuflæði byggt á Git ýtum. Okkur líkar við hann líka. En það er ekki allt: við skulum nú líta á CI/CD leiðslur.
GitOps gerir stöðuga dreifingu (CD) kleift fyrir Kubernetes
GitOps býður upp á stöðugt dreifingarkerfi sem útilokar þörfina fyrir aðskilin „dreifingarstjórnunarkerfi“. Kubernetes gerir allt fyrir þig.
- Til að uppfæra forritið þarf að uppfæra í Git. Þetta er viðskiptauppfærsla í æskilegt ástand. „Dreifing“ er síðan gert innan klasans af Kubernetes sjálfum byggt á uppfærðri lýsingu.
- Vegna eðlis þess hvernig Kubernetes virkar eru þessar uppfærslur samræmdar. Þetta veitir kerfi fyrir stöðuga dreifingu þar sem allar uppfærslur eru atómar.
- Ath: býður upp á GitOps rekstraraðila sem samþættir Git og Kubernetes og gerir kleift að framkvæma geisladisk með því að samræma æskilegt og núverandi ástand klasans.
Án kubectl og skrifta
Þú ættir að forðast að nota Kubectl til að uppfæra klasann þinn, og sérstaklega forðast að nota forskriftir til að flokka kubectl skipanir. Í staðinn, með GitOps leiðslunni, getur notandi uppfært Kubernetes þyrpinguna sína í gegnum Git.
Fríðindi fela í sér:
- Rétt. Hægt er að beita hópi uppfærslna, sameinast og að lokum staðfesta, sem færir okkur nær markmiðinu um dreifingu kjarnorkuvopna. Aftur á móti veitir notkun forskrifta enga trygging fyrir samleitni (meira um þetta hér að neðan).
- öryggi. Kelsey Hightower: „Takmarkaðu aðgang að Kubernetes þyrpingunni þinni við sjálfvirkniverkfæri og stjórnendur sem bera ábyrgð á villuleit eða viðhaldi hans. sjá einnig um öryggi og samræmi við tækniforskriftir, svo og með því að stela skilríkjum úr kærulausu handriti Jenkins.
- Reynsla notanda. Kubectl afhjúpar aflfræði Kubernetes hlutlíkansins, sem er nokkuð flókið. Helst ættu notendur að hafa samskipti við kerfið á hærra stigi abstrakt. Hér mun ég aftur vísa til Kelsey og mæla með því að horfa .
Munurinn á CI og CD
GitOps bætir núverandi CI/CD módel.
Nútíma CI netþjónn er hljómsveitarverkfæri. Einkum er það tæki til að skipuleggja CI leiðslur. Þetta felur í sér byggingu, prófun, sameiningu í stofnkerfi osfrv. CI netþjónar gera sjálfvirkan stjórnun á flóknum fjölþrepa leiðslum. Algeng freisting er að skrifa sett af Kubernetes uppfærslum og keyra það sem hluta af leiðslu til að ýta undir breytingar á klasanum. Reyndar, þetta er það sem margir sérfræðingar gera. Hins vegar er þetta ekki ákjósanlegt og hér er ástæðan.
CI ætti að nota til að ýta uppfærslum á skottinu og Kubernetes þyrpingin ætti að breyta sjálfum sér miðað við þessar uppfærslur til að stjórna geisladisknum innbyrðis. Við köllum það , ólíkt CI push líkaninu. CD er hluti runtime hljómsveitarstjórn.
Af hverju CI netþjónar ættu ekki að gera geisladiska með beinum uppfærslum í Kubernetes
Ekki nota CI miðlara til að skipuleggja beinar uppfærslur á Kubernetes sem sett af CI verkum. Þetta er and-mynstrið sem við erum að tala um á blogginu þínu.
Förum aftur til Alice og Bob.
Hvaða vandamál stóðu þeir frammi fyrir? CI þjónn Bob beitir breytingunum á klasann, en ef hann hrynur í ferlinu mun Bob ekki vita í hvaða ástandi klasinn er (eða ætti að vera) eða hvernig á að laga það. Sama er uppi á teningnum ef vel tekst til.
Gerum ráð fyrir að teymi Bobs hafi byggt nýja mynd og síðan lagfært dreifingar sínar til að dreifa myndinni (allt úr CI leiðslum).
Ef myndin byggist eðlilega, en leiðslan mistekst, verður liðið að finna út:
- Er uppfærslan komin út?
- Erum við að hefja nýja byggingu? Mun þetta leiða til óþarfa aukaverkana - með möguleika á að hafa tvær smíðir af sömu óbreytanlegu myndinni?
- Eigum við að bíða eftir næstu uppfærslu áður en við keyrum bygginguna?
- Hvað fór eiginlega úrskeiðis? Hvaða skref þarf að endurtaka (og hvaða skref er óhætt að endurtaka)?
Að koma á Git-undirstaða vinnuflæði tryggir ekki að teymi Bob muni ekki lenda í þessum vandamálum. Þeir geta samt gert mistök með commit push, merkinu eða einhverri annarri færibreytu; þessi nálgun er samt miklu nær skýrri allt-eða-ekkert nálgun.
Til að draga saman, hér er hvers vegna CI netþjónar ættu ekki að takast á við geisladisk:
- Uppfærsluforskriftir eru ekki alltaf ákvarðaðar; Það er auðvelt að gera mistök í þeim.
- CI netþjónar renna ekki saman við yfirlýsingaklasalíkanið.
- Það er erfitt að tryggja getuleysi. Notendur verða að skilja djúpa merkingarfræði kerfisins.
- Það er erfiðara að jafna sig eftir bilun að hluta.
Athugasemd um Helm: Ef þú vilt nota Helm mælum við með því að sameina það með GitOps rekstraraðila eins og . Þetta mun hjálpa til við að tryggja samleitni. Helm sjálfur er hvorki deterministic né atómbundinn.
GitOps sem besta leiðin til að innleiða stöðuga afhendingu fyrir Kubernetes
Lið Alice og Bob innleiðir GitOps og uppgötvar að það er orðið miklu auðveldara að vinna með hugbúnaðarvörur, viðhalda mikilli afköstum og stöðugleika. Við skulum enda þessa grein með mynd sem sýnir hvernig nýja nálgun þeirra lítur út. Hafðu í huga að við erum aðallega að tala um forrit og þjónustu, en GitOps er hægt að nota til að stjórna heilum vettvangi.
Rekstrarmódel fyrir Kubernetes
Horfðu á eftirfarandi skýringarmynd. Það kynnir Git og gámamyndageymsluna sem sameiginleg auðlind fyrir tvo skipulagða lífsferla:
- Stöðug samþættingarleiðsla sem les og skrifar skrár í Git og getur uppfært geymslu gámamynda.
- Runtime GitOps leiðsla sem sameinar uppsetningu með stjórnun og sýnileika. Það les og skrifar skrár í Git og getur hlaðið niður gámamyndum.
Hverjar eru helstu niðurstöður?
- Aðskilnaður áhyggjuefna: Vinsamlegast athugaðu að báðar leiðslur geta aðeins átt samskipti með því að uppfæra Git eða myndageymsluna. Með öðrum orðum, það er eldveggur á milli CI og keyrsluumhverfisins. Við köllum það „óbreytanleg eldvegg“ (óbreytanleg eldveggur), þar sem allar geymsluuppfærslur búa til nýjar útgáfur. Nánari upplýsingar um þetta efni er að finna á glærum 72-87 .
- Þú getur notað hvaða CI og Git netþjón sem er: GitOps virkar með hvaða íhlut sem er. Þú getur haldið áfram að nota uppáhalds CI og Git netþjónana þína, myndageymslur og prófunarsvítur. Næstum öll önnur verkfæri fyrir stöðuga afhendingu á markaðnum þurfa sinn eigin CI/Git netþjón eða myndgeymslu. Þetta gæti orðið takmarkandi þáttur í þróun innfæddra skýja. Með GitOps geturðu notað kunnugleg verkfæri.
- Viðburðir sem samþættingartæki: Um leið og gögn í Git eru uppfærð, lætur Weave Flux (eða Weave Cloud rekstraraðilinn) tilkynningu um keyrslutíma. Alltaf þegar Kubernetes samþykkir breytingasett er Git uppfært. Þetta veitir einfalt samþættingarlíkan til að skipuleggja verkflæði fyrir GitOps, eins og sýnt er hér að neðan.
Ályktun
GitOps veitir sterkar uppfærslutryggingar sem hvers kyns nútíma CI/CD verkfæri krefjast:
- sjálfvirkni;
- samleitni;
- getuleysi;
- ákveðni.
Þetta er mikilvægt vegna þess að það býður upp á rekstrarlíkan fyrir frumbyggja í skýjum.
- Hefðbundin verkfæri til að stjórna og fylgjast með kerfum eru tengd við rekstrarteymi sem starfa innan runbook (safn af venjubundnum aðferðum og aðgerðum - u.þ.b. þýðing), bundin við tiltekna dreifingu.
- Í skýjastjórnun eru athugunartæki besta leiðin til að mæla árangur dreifingar svo þróunarteymið geti brugðist hratt við.
Ímyndaðu þér marga klasa dreifða um mismunandi ský og margar þjónustur með eigin teymi og dreifingaráætlanir. GitOps býður upp á stærðaróbreytilegt líkan til að stjórna öllu þessu gnægð.
PS frá þýðanda
Lestu líka á blogginu okkar:
- «»;
- «»;
- «'.
Aðeins skráðir notendur geta tekið þátt í könnuninni. , takk.
Vissir þú um GitOps áður en þessar tvær þýðingar birtust á Habré?
-
Já, ég vissi allt
-
Aðeins yfirborðslega séð
-
No
35 notendur kusu. 10 notendur sátu hjá.
Heimild: www.habr.com