🥇werf - tól okkar fyrir CI/CD í Kubernetes (endurskoðun og myndbandsskýrsla)

27. maí í aðalsal DevOpsConf 2019 ráðstefnunnar, haldin sem hluti af hátíðinni RIT++ 2019, sem hluti af hlutanum „Stöðug afhending“, var gefin skýrsla „werf - tól okkar fyrir CI/CD í Kubernetes“. Það er talað um þá vandamál og áskoranir sem allir standa frammi fyrir þegar þeir dreifa til Kubernetes, sem og um blæbrigði sem eru kannski ekki strax áberandi. Með því að greina mögulegar lausnir sýnum við hvernig þetta er útfært í Open Source tól werf.

Frá kynningu hefur gagnsemi okkar (áður þekkt sem dapp) náð sögulegum áfanga 1000 stjörnur á GitHub — við vonum að vaxandi samfélag notenda þess muni gera lífið auðveldara fyrir marga DevOps verkfræðinga.

Svo við kynnum myndband af skýrslunni (~47 mínútur, mun fróðlegri en greinin) og aðalútdráttur úr henni í textaformi. Farðu!

Afhendir kóða til Kubernetes

Erindið mun ekki lengur snúast um werf, heldur um CI/CD í Kubernetes, sem gefur til kynna að hugbúnaðinum okkar sé pakkað í Docker gáma (Ég talaði um þetta í Skýrsla 2016), og K8s verða notaðir til að keyra það í framleiðslu (meira um þetta í 2017 ári).

Hvernig lítur afhending út í Kubernetes?

Það er Git geymsla með kóðanum og leiðbeiningum um að byggja hann upp. Forritið er innbyggt í Docker mynd og birt í Docker Registry.
Sama geymsla inniheldur einnig leiðbeiningar um hvernig eigi að dreifa og keyra forritið. Á dreifingarstigi eru þessar leiðbeiningar sendar til Kubernetes, sem tekur við myndinni sem óskað er eftir úr skránni og ræsir hana.
Auk þess eru venjulega próf. Sumt af þessu er hægt að gera þegar mynd er birt. Þú getur líka (eftir sömu leiðbeiningum) sett upp afrit af forritinu (í sérstakt K8s nafnrými eða sérstakan klasa) og keyrt próf þar.
Að lokum þarftu CI kerfi sem tekur við atburðum frá Git (eða smelli á hnappa) og kallar á öll tilgreind stig: byggja, birta, dreifa, prófa.

Það eru nokkrar mikilvægar athugasemdir hér:

Vegna þess að við erum með óbreytanlega innviði (óbreytanleg innviði), forritamyndin sem er notuð á öllum stigum (sviðsetning, framleiðslu osfrv.), það hlýtur að vera einn. Ég ræddi þetta nánar og með dæmum. hér.
Vegna þess að við fylgjum innviðum sem kóða nálgun (IaC), forritskóðinn, leiðbeiningar um að setja hann saman og ræsa hann ættu að vera nákvæmlega í einni geymslu. Fyrir frekari upplýsingar um þetta, sjá sömu skýrslu.
Sendingarkeðja (afhending) við sjáum þetta venjulega svona: forritið var sett saman, prófað, gefið út (útgáfustig) og það er það - afhending hefur átt sér stað. En í raun og veru fær notandinn það sem þú settir út, ekki síðan þegar þú afhentir það í framleiðslu, og þegar hann gat farið þangað og þessi framleiðsla virkaði. Svo ég tel að afhendingarkeðjan ljúki aðeins á rekstrarstigi (hlaupa), eða nánar tiltekið, jafnvel á því augnabliki þegar kóðinn var fjarlægður úr framleiðslu (sem skipta honum út fyrir nýjan).

Snúum okkur aftur að ofangreindu afhendingarkerfi í Kubernetes: það var fundið upp ekki aðeins af okkur heldur af bókstaflega öllum sem tókust á við þetta vandamál. Reyndar er þetta mynstur núna kallað GitOps (þú getur lesið meira um hugtakið og hugmyndirnar á bak við það hér). Við skulum líta á stig kerfisins.

Byggja svið

Það virðist sem þú getur talað um að byggja Docker myndir árið 2019, þegar allir vita hvernig á að skrifa Dockerfiles og keyra docker build?.. Hér eru blæbrigðin sem mig langar að gefa gaum:

Þyngd myndar skiptir máli, svo notaðu fjölþrepaað skilja aðeins eftir á myndinni forritið sem er raunverulega nauðsynlegt fyrir aðgerðina.
Fjöldi laga verður að lágmarka með því að sameina keðjur af RUN-skipanir eftir merkingu.
Hins vegar bætir þetta við vandamálum villuleit, vegna þess að þegar samsetningin hrynur þarftu að finna réttu skipunina úr keðjunni sem olli vandamálinu.
Samsetningarhraði mikilvægt vegna þess að við viljum fljótt útfæra breytingar og sjá árangurinn. Til dæmis, þú vilt ekki endurbyggja ósjálfstæði í tungumálasöfnum í hvert skipti sem þú byggir forrit.
Oft frá einni Git geymslu sem þú þarft margar myndir, sem hægt er að leysa með því að setja af Dockerfiles (eða nefndum stigum í einni skrá) og Bash handriti með raðsamsetningu þeirra.

Þetta var bara toppurinn á ísjakanum sem allir standa frammi fyrir. En það eru önnur vandamál, sérstaklega:

Oft á samsetningarstigi þurfum við eitthvað fjall (Til dæmis, skyndiminni niðurstöðu skipunar eins og apt í þriðja aðila skrá).
Við viljum Ansible í stað þess að skrifa í skel.
Við viljum byggja án Docker (af hverju þurfum við auka sýndarvél þar sem við þurfum að stilla allt fyrir þetta, þegar við erum nú þegar með Kubernetes þyrping þar sem við getum keyrt gáma?).
Samhliða samsetning, sem hægt er að skilja á mismunandi vegu: mismunandi skipanir úr Dockerfile (ef fjölþrepa er notuð), nokkrar skuldbindingar sömu geymslu, nokkrar Dockerfiles.
Dreift samkoma: Okkur langar til að safna hlutum í belg sem eru "hverfarir" vegna þess skyndiminni þeirra hverfur, sem þýðir að það þarf að geyma það einhvers staðar sérstaklega.
Að lokum nefndi ég hátind langana sjálfvirkur: Það væri tilvalið að fara í geymsluna, slá inn einhverja skipun og fá tilbúna mynd, setta saman með skilning á því hvernig og hvað á að gera rétt. Hins vegar er ég persónulega ekki viss um að hægt sé að sjá fyrir alla blæbrigðin með þessum hætti.

Og hér eru verkefnin:

moby/buildkit — smiður frá Docker Inc (þegar innbyggður í núverandi útgáfur af Docker), sem er að reyna að leysa öll þessi vandamál;
kaniko — smiður frá Google sem gerir þér kleift að smíða án Docker;
Buildpacks.io — Tilraun CNCF til að búa til sjálfvirka galdur og sérstaklega áhugaverða lausn með rebase fyrir lög;
og fullt af öðrum veitum, svo sem byggja, genuinetools/img...

...og sjáðu hversu margar stjörnur þeir hafa á GitHub. Það er annars vegar docker build er til og getur gert eitthvað, en í raun og veru málið er ekki alveg leyst - sönnun þess er samhliða þróun annarra safnara, sem hver um sig leysir einhvern hluta vandamálanna.

Samkoma í werf

Svo við urðum að werf (fyrr frægur eins og dapp) — Opinn hugbúnaður frá Flant fyrirtækinu, sem við höfum verið að gera í mörg ár. Þetta byrjaði allt fyrir 5 árum með Bash forskriftum sem fínstilltu samsetningu Dockerfiles, og síðustu 3 árin hefur fullgild þróun verið framkvæmd innan ramma eins verkefnis með eigin Git geymslu. (fyrst í Ruby, og síðan endurskrifuð að fara, og um leið endurnefna). Hvaða samsetningarmál eru leyst í werf?

Vandamálin með bláum skugga hafa þegar verið hrint í framkvæmd, samhliða byggingin var unnin innan sama hýsils og stefnt er að því að þeim málum sem eru auðkennd með gulu verði lokið í lok sumars.

Útgáfustig í skránni (birta)

Við hringdum docker push... - hvað gæti verið erfitt við að hlaða upp mynd í skrárinn? Og þá vaknar spurningin: "Hvaða merki ætti ég að setja á myndina?" Það kemur til af þeirri ástæðu sem við höfum Gitflow (eða önnur Git stefnu) og Kubernetes, og iðnaðurinn er að reyna að tryggja að það sem gerist í Kubernetes fylgi því sem gerist í Git. Eftir allt saman, Git er eina uppspretta sannleikans.

Hvað er svona erfitt við þetta? Tryggja endurgerðanleika: frá skuldbindingu í Git, sem er óbreytanleg í eðli sínu (óbreytanleg), í Docker mynd, sem ætti að vera óbreytt.

Það er okkur líka mikilvægt ákvarða uppruna, vegna þess að við viljum skilja úr hvaða commit forritið sem keyrir í Kubernetes var byggt (þá getum við gert diffs og svipaða hluti).

Merkingaraðferðir

Sú fyrri er einföld git tag. Við höfum skrásetning með mynd merkt sem 1.0. Kubernetes hefur leiksvið og framleiðslu, þar sem þessari mynd er hlaðið upp. Í Git gerum við skuldbindingar og á einhverjum tímapunkti merkjum við 2.0. Við söfnum því samkvæmt leiðbeiningunum frá geymslunni og setjum það í skrána með merkinu 2.0. Við rúllum því út á svið og, ef allt er í lagi, þá í framleiðslu.

Vandamálið við þessa nálgun er að við settum fyrst merkið, og aðeins síðan prófað og rúllað því út. Hvers vegna? Í fyrsta lagi er það einfaldlega órökrétt: við erum að gefa út útgáfu af hugbúnaði sem við höfum ekki einu sinni prófað ennþá (við getum ekki annað, því til þess að athuga þurfum við að setja merki). Í öðru lagi er þessi leið ekki samhæf við Gitflow.

Seinni valkosturinn - git commit + tag. Aðalútibúið er með merki 1.0; fyrir það í skránni - mynd sem er send til framleiðslu. Að auki hefur Kubernetes þyrpingin forskoðun og útlínur. Næst fylgjumst við með Gitflow: í aðalgrein fyrir þróun (develop) við gerum nýja eiginleika, sem leiðir til skuldbindingar með auðkenninu #c1. Við söfnum því og birtum það í skránni með því að nota þetta auðkenni (#c1). Með sama auðkenni rúllum við út til að forskoða. Við gerum það sama með skuldbindingar #c2 и #c3.

Þegar við áttuðum okkur á því að það eru nógu margir eiginleikar byrjum við að koma öllu á stöðugleika. Búðu til útibú í Git release_1.1 (á grunninum #c3 á develop). Það er engin þörf á að safna þessari útgáfu, því... þetta var gert í fyrra skrefi. Þess vegna getum við einfaldlega rúllað því út í sviðsetningu. Við lagum villur í #c4 og rúlla á sama hátt út í sviðsetningu. Á sama tíma er þróun í gangi develop, þar sem breytingar eru reglulega teknar frá release_1.1. Á einhverjum tímapunkti fáum við commit saman og hlaðið upp á sviðsetningu, sem við erum ánægð með (#c25).

Síðan sameinum við (með spólu áfram) útgáfugreininni (release_1.1) í meistara. Við setjum merki með nýju útgáfunni á þessa skuldbindingu (1.1). En þessari mynd er nú þegar safnað í skránni, svo til að safna henni ekki aftur, bætum við einfaldlega öðru merki við núverandi mynd (nú hefur hún merki í skránni #c25 и 1.1). Eftir það rúllum við því út í framleiðslu.

Það er galli að aðeins einni mynd er hlaðið upp í sviðsetningu (#c25), og í framleiðslu er það svolítið öðruvísi (1.1), en við vitum að „líkamlega“ er þetta sama myndin úr skránni.

Raunverulegi ókosturinn er sá að það er enginn stuðningur við samrunaskuldbindingar, þú verður að spóla áfram.

Við getum gengið lengra og gert brellur... Við skulum skoða dæmi um einfalda Dockerfile:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

Við skulum byggja skrá úr henni samkvæmt eftirfarandi meginreglu:

SHA256 frá auðkennum myndanna sem notaðar eru (ruby:2.3 и nginx:alpine), sem eru eftirlitssummur á innihaldi þeirra;
öll lið (RUN, CMD og svo framvegis.);
SHA256 úr skrám sem bætt var við.

... og taktu eftirlitssumman (aftur SHA256) úr slíkri skrá. Þetta undirskrift allt sem skilgreinir innihald Docker myndarinnar.

Förum aftur að skýringarmyndinni og í stað þess að skuldbinda okkur munum við nota slíkar undirskriftir, þ.e. merktu myndir með undirskriftum.

Nú, þegar það er nauðsynlegt, til dæmis, að sameina breytingar frá útgáfu í master, getum við gert raunverulega sameiningu commit: það mun hafa annað auðkenni, en sömu undirskrift. Með sama auðkenni munum við rúlla myndinni út í framleiðslu.

Ókosturinn er sá að nú verður ekki hægt að ákvarða hvers konar skuldbindingu var ýtt til framleiðslu - tékksummur virka aðeins í eina átt. Þetta vandamál er leyst með viðbótarlagi með lýsigögnum - ég skal segja þér meira síðar.

Merking í werf

Í werf gengum við enn lengra og erum að undirbúa að gera dreifða byggingu með skyndiminni sem er ekki geymt á einni vél... Svo við erum að byggja tvær tegundir af Docker myndum, við köllum þær stigi и mynd.

werf Git geymslan geymir byggingarsértækar leiðbeiningar sem lýsa mismunandi stigum byggingarinnar (áður en þú setur upp, setja, fyrir uppsetningu, skipulag). Við söfnum fyrstu stigs myndinni með undirskrift sem er skilgreind sem eftirlitssumma fyrstu skrefanna. Síðan bætum við frumkóðann við, fyrir nýju sviðsmyndina reiknum við eftirlitssummu hennar... Þessar aðgerðir eru endurteknar fyrir öll stig, sem leiðir af því að við fáum sett af sviðsmyndum. Síðan gerum við lokamyndina sem inniheldur einnig lýsigögn um uppruna hennar. Og við merkjum þessa mynd á mismunandi vegu (upplýsingar síðar).

Segjum sem svo að eftir þetta birtist ný commit þar sem aðeins umsóknarkóðanum hefur verið breytt. Hvað mun gerast? Fyrir kóðabreytingar verður plástur búinn til og ný sviðsmynd útbúin. Undirskrift þess verður ákvörðuð sem eftirlitssumman á gömlu sviðsmyndinni og nýja plástrinum. Ný endanleg mynd verður til úr þessari mynd. Svipuð hegðun mun eiga sér stað með breytingum á öðrum stigum.

Þannig eru sviðsmyndir skyndiminni sem hægt er að geyma dreift og myndirnar sem þegar eru búnar til úr því eru hlaðið upp í Docker Registry.

Þrif á skránni

Við erum ekki að tala um að eyða lögum sem héldust hangandi eftir eyddum merkjum - þetta er staðalbúnaður í Docker Registry sjálfri. Við erum að tala um aðstæður þar sem mikið af Docker merkjum safnast upp og við skiljum að við þurfum ekki lengur sum þeirra, en þau taka pláss (og/eða við borgum fyrir það).

Hverjar eru hreinsunaraðferðirnar?

Þú getur bara ekkert gert ekki þrífa. Stundum er í raun auðveldara að borga aðeins fyrir auka pláss en að leysa upp risastóran flækju af merkjum. En þetta virkar bara upp að vissu marki.
Full endurstilling. Ef þú eyðir öllum myndum og endurbyggir aðeins þær núverandi í CI kerfinu gæti vandamál komið upp. Ef gámurinn er endurræstur í framleiðslu verður ný mynd hlaðin fyrir hann - sú sem hefur ekki enn verið prófuð af neinum. Þetta drepur hugmyndina um óbreytanlega innviði.
Blágrænt. Ein skrásetning byrjaði að flæða yfir - við sendum inn myndir í aðra. Sama vandamál og í fyrri aðferð: á hvaða tímapunkti geturðu hreinsað skrásetninguna sem er farin að flæða yfir?
Eftir tíma. Eyða öllum myndum eldri en 1 mánaðar? En það verður örugglega þjónusta sem hefur ekki verið uppfærð í mánuð...
Handvirkt ákvarða hvað er nú þegar hægt að eyða.

Það eru tveir raunverulega raunhæfir valkostir: ekki þrífa eða blanda af blágrænu + handvirkt. Í síðara tilvikinu erum við að tala um eftirfarandi: þegar þú skilur að það er kominn tími til að þrífa skrásetninguna, býrðu til nýja og bætir öllum nýjum myndum við hana á til dæmis mánuði. Og eftir mánuð, sjáðu hvaða fræbelgur í Kubernetes eru enn að nota gömlu skrána, og flyttu þá líka yfir í nýju skrána.

Að hverju erum við komin werf? Við söfnum:

Git head: öll merki, allar greinar - að því gefnu að við þurfum allt sem er merkt í Git í myndunum (og ef ekki, þá þurfum við að eyða því í Git sjálfum);
öllum belgjum sem nú er dælt út til Kubernetes;
gamla ReplicaSets (það sem var nýlega gefið út), og við ætlum líka að skanna Helm útgáfur og velja nýjustu myndirnar þar.

... og búðu til hvítalista úr þessu setti - lista yfir myndir sem við munum ekki eyða. Við hreinsum allt annað, eftir það finnum við munaðarlausar sviðsmyndir og eyðum þeim líka.

Dreifingarstig

Áreiðanleg yfirlýsing

Fyrsta atriðið sem ég vil vekja athygli á í dreifingunni er útfærsla uppfærðrar auðlindauppsetningar, lýst yfir með yfirlýsandi hætti. Upprunalega YAML skjalið sem lýsir Kubernetes auðlindum er alltaf mjög frábrugðið niðurstöðunni sem raunverulega er í gangi í þyrpingunni. Vegna þess að Kubernetes bætir við stillingarnar:

auðkenni;
þjónustuupplýsingar;
mörg sjálfgefin gildi;
kafla með núverandi stöðu;
breytingar sem gerðar eru sem hluti af inntökuforritinu;
afrakstur vinnu ýmissa stjórnenda (og tímaáætlunar).

Þess vegna, þegar ný auðlindastilling birtist (ný), við getum ekki bara tekið og skrifað yfir núverandi, „lifandi“ uppsetningu með henni (lifa). Til að gera þetta verðum við að bera saman ný með síðustu uppsetningu (síðast sótt) og rúllið yfir á lifa fékk plástur.

Þessi nálgun er kölluð Tvíhliða sameining. Það er til dæmis notað í Helm.

Það er einnig Tvíhliða sameining, sem er frábrugðin því:

að bera saman síðast sótt и ný, við skoðum hvað var eytt;
að bera saman ný и lifa, við skoðum hvað hefur verið bætt við eða breytt;
samantekinn plástur er settur á lifa.

Við sendum yfir 1000+ forrit með Helm, þannig að við búum í raun við tvíhliða sameiningu. Hins vegar hefur það ýmis vandamál sem við höfum leyst með plástrunum okkar, sem hjálpa Helm að vinna eðlilega.

Raunveruleg útsetningarstaða

Eftir að CI kerfið okkar býr til nýja uppsetningu fyrir Kubernetes byggða á næsta atburði, sendir það hana til notkunar (sækja um) í klasa - með því að nota Helm eða kubectl apply. Næst á sér stað hinn þegar lýsti N-vega sameining, sem Kubernetes API svarar CI kerfinu með samþykki, og það notanda þess.

Hins vegar er stórt vandamál: þegar allt kemur til alls árangursrík umsókn þýðir ekki árangursríka útsetningu. Ef Kubernetes skilur hvaða breytingar þarf að beita og beitir þeim, vitum við enn ekki hver niðurstaðan verður. Til dæmis gæti uppfærsla og endurræsing á pods í framendanum gengið vel, en ekki í bakendanum, og við munum fá mismunandi útgáfur af hlaupandi forritamyndum.

Til að gera allt rétt þarf þetta kerfi aukatengils - sérstakan rekja spor einhvers sem mun taka við stöðuupplýsingum frá Kubernetes API og senda þær til frekari greiningar á raunverulegu ástandi hlutanna. Við bjuggum til Open Source bókasafn í Go - kubbahundur (sjá tilkynningu þess hér), sem leysir þetta vandamál og er innbyggt í werf.

Hegðun þessa rekja spor einhvers á werf stigi er stillt með því að nota athugasemdir sem eru settar á Deployments eða StatefulSets. Aðalskýring - fail-mode - skilur eftirfarandi merkingu:

IgnoreAndContinueDeployProcess — við hunsum vandamálin við að koma þessum hluta í notkun og höldum áfram dreifingunni;
FailWholeDeployProcessImmediately — villa í þessum íhlut stöðvar dreifingarferlið;
HopeUntilEndOfDeployProcess — við vonum að þessi hluti muni virka í lok dreifingarinnar.

Til dæmis þessi samsetning auðlinda og athugasemdagilda fail-mode:

Þegar við sendum inn í fyrsta skipti gæti gagnagrunnurinn (MongoDB) ekki verið tilbúinn ennþá - Dreifing mun mistakast. En þú getur beðið eftir augnablikinu þar til það byrjar og dreifingin mun enn eiga sér stað.

Það eru tvær athugasemdir í viðbót fyrir kubedog í werf:

failures-allowed-per-replica — fjöldi leyfilegra falla fyrir hverja eftirmynd;
show-logs-until — stjórnar því augnabliki þar til werf sýnir (í stdout) annálum frá öllum útrúlluðum belgjum. Sjálfgefið er PodIsReady (til að hunsa skilaboð sem við viljum líklega ekki þegar umferð byrjar að koma að belgnum), en gildin eru líka gild: ControllerIsReady и EndOfDeploy.

Hvað viljum við annað af dreifingu?

Til viðbótar við þau tvö atriði sem þegar hefur verið lýst, viljum við:

að sjá logs - og aðeins nauðsynlegar, og ekki allt í röð;
lag framfarir, vegna þess að ef starfið hangir „hljóðlaust“ í nokkrar mínútur er mikilvægt að skilja hvað er að gerast þar;
hafa sjálfvirkt afturköllun ef eitthvað fór úrskeiðis (og þess vegna er mikilvægt að vita raunverulega stöðu dreifingarinnar). Uppsetningin verður að vera atóm: annaðhvort gengur hún til enda eða allt fer aftur í fyrra ástand.

Niðurstöður

Fyrir okkur sem fyrirtæki, til að innleiða öll lýst blæbrigði á mismunandi afhendingarstigum (smíða, birta, dreifa), er CI kerfi og gagnsemi nóg werf.

Í stað niðurstöðu:

Með hjálp werf höfum við náð góðum árangri í að leysa fjölda vandamála fyrir DevOps verkfræðinga og værum ánægð ef samfélagið í heild sinni prófaði þetta tól í verki. Það verður auðveldara að ná góðum árangri saman.

Myndbönd og glærur

Myndband frá gjörningnum (~47 mínútur):

Kynning á skýrslunni:

PS

Aðrar skýrslur um Kubernetes á blogginu okkar:

«Sjálfvirk stærð og auðlindastjórnun í Kubernetes» (Dmitry Stolyarov; 27. apríl 2019 á „Strike“);
«Að framlengja og bæta við Kubernetes» (Andrey Polovov; 8. apríl 2019 á Saint HighLoad++);
«Gagnasöfn og Kubernetes» (Dmitry Stolyarov; 8. nóvember 2018 á HighLoad++);
«Vöktun og Kubernetes» (Dmitry Stolyarov; 28. maí 2018 á RootConf);
«Bestu starfsvenjur CI/CD með Kubernetes og GitLab» (Dmitry Stolyarov; 7. nóvember 2017 á HighLoad++);
«Reynsla okkar af Kubernetes í litlum verkefnum» (Dmitry Stolyarov; 6. júní 2017 á RootConf).

Heimild: www.habr.com

werf - tól okkar fyrir CI / CD í Kubernetes (yfirlit og myndbandsskýrsla)