Hæ allir! Ég heiti Pavel Agaletsky. Ég vinn sem teymisstjóri í teymi sem þróar Lamoda sendingakerfið. Árið 2018 talaði ég á HighLoad++ ráðstefnunni og í dag langar mig að kynna afrit af skýrslu minni.

Viðfangsefnið mitt er tileinkað reynslu fyrirtækisins okkar í að dreifa kerfum og þjónustu í mismunandi umhverfi. Frá forsögulegum tímum okkar, þegar við settum öll kerfi inn á venjulega sýndarþjóna, endaði með smám saman umskipti frá Nomad til dreifingar í Kubernetes. Ég skal segja þér hvers vegna við gerðum það og hvaða vandamál við áttum í ferlinu.

Að dreifa forritum í VM

Byrjum á því að fyrir 3 árum voru öll kerfi og þjónusta fyrirtækisins sett á venjulega sýndarþjóna. Tæknilega séð var þetta skipulagt þannig að allur kóðinn fyrir kerfin okkar var geymdur og settur saman með sjálfvirkum samsetningarverkfærum, með jenkins. Með því að nota Ansible var það rúllað út úr útgáfustýringarkerfinu okkar yfir á sýndarþjóna. Þar að auki var hvert kerfi sem fyrirtækið okkar hafði sett á að minnsta kosti 2 netþjóna: einn þeirra á hausnum, sá annar á skottinu. Þessi tvö kerfi voru algjörlega eins hvert öðru í öllum stillingum, krafti, uppsetningu osfrv. Eini munurinn á þeim var sá að haus fékk notendaumferð, á meðan tail fékk aldrei notendaumferð.

Hvers vegna var þetta gert?

Þegar við sendum inn nýjar útgáfur af forritinu okkar vildum við tryggja óaðfinnanlega útfærslu, það er án merkjanlegra afleiðinga fyrir notendur. Þetta náðist vegna þess að næsta samsetta útgáfa með Ansible var rúllað út í skottið. Þar gátu þeir sem tóku þátt í dreifingunni athugað og gengið úr skugga um að allt væri í lagi: allar mælingar, hlutar og forrit virkuðu; nauðsynlegar forskriftir eru ræstar. Aðeins eftir að þeir voru sannfærðir um að allt væri í lagi var skipt um umferð. Það byrjaði að fara á netþjóninn sem var áður skott. Og sá sem áður var höfuðið var án notendaumferðar, en var samt með fyrri útgáfuna af forritinu okkar á því.

Þannig að það var óaðfinnanlegt fyrir notendur. Vegna þess að skiptingin er tafarlaus, þar sem það er einfaldlega að skipta um jafnvægisbúnaðinn. Þú getur auðveldlega snúið aftur í fyrri útgáfu með því einfaldlega að skipta jafnvægisbúnaðinum aftur. Við gátum líka staðfest að forritið væri hægt að framleiða jafnvel áður en það fékk notendaumferð, sem var mjög þægilegt.

Hvaða kosti sáum við í þessu öllu?

1. Í fyrsta lagi er nóg það bara virkar. Allir skilja hvernig slíkt dreifingarkerfi virkar, vegna þess að flestir hafa nokkru sinni dreift á venjulega sýndarþjóna.
2. Þetta er nóg áreiðanlega, þar sem dreifingartæknin er einföld, prófuð af þúsundum fyrirtækja. Milljónir netþjóna eru settir á þennan hátt. Það er erfitt að brjóta eitthvað.
3. Og loksins gátum við fengið kjarnorkuuppsetningar. Dreifing sem á sér stað samtímis fyrir notendur, án merkjanlegs stigs að skipta á milli gömlu útgáfunnar og hinnar nýju.

En við sáum líka nokkra annmarka á þessu öllu:

1. Til viðbótar við framleiðsluumhverfið, þróunarumhverfið, eru önnur umhverfi. Til dæmis, qa og preproduction. Á þeim tíma vorum við með marga netþjóna og um 60 þjónustur. Af þessum sökum var nauðsynlegt fyrir hverja þjónustu, viðhaldið nýjustu útgáfunni fyrir hana sýndarvél. Þar að auki, ef þú vilt uppfæra bókasöfn eða setja upp nýjar ósjálfstæði, þarftu að gera þetta í öllum umhverfi. Þú þurftir líka að samstilla tímann þegar þú ætlar að dreifa næstu nýju útgáfu af forritinu þínu við tímann þegar devops framkvæmir nauðsynlegar umhverfisstillingar. Í þessu tilfelli er auðvelt að lenda í aðstæðum þar sem umhverfi okkar verður nokkuð öðruvísi í öllum umhverfi í einu. Til dæmis, í QA umhverfi verða nokkrar útgáfur af bókasöfnum, og í framleiðsluumhverfi verða það mismunandi, sem mun leiða til vandamála.
2. Erfiðleikar við að uppfæra ósjálfstæði umsókn þína. Það fer ekki eftir þér heldur hinu liðinu. Nefnilega frá devops teyminu sem heldur úti netþjónunum. Þú verður að gefa þeim viðeigandi verkefni og lýsingu á því sem þú vilt gera.
3. Á þeim tíma vildum við líka skipta stóru stóru einlitunum sem við áttum í aðskildar litlar þjónustur, þar sem við skildum að þær yrðu fleiri og fleiri. Á þeim tíma vorum við þegar með meira en 100. Fyrir hverja nýja þjónustu var nauðsynlegt að búa til sérstaka nýja sýndarvél, sem einnig þurfti að viðhalda og koma á. Auk þess þarftu ekki einn bíl, heldur að minnsta kosti tvo. Við allt þetta bætist QA umhverfið. Þetta veldur vandamálum og gerir það erfiðara fyrir þig að byggja upp og keyra ný kerfi. flókið, dýrt og langt ferli.

Þess vegna ákváðum við að það væri þægilegra að fara frá því að nota venjulegar sýndarvélar yfir í að dreifa forritunum okkar í hafnargám. Ef þú ert með docker þarftu kerfi sem getur keyrt forritið í klasa, þar sem þú getur ekki bara hækkað ílát. Venjulega vill maður halda utan um hversu mörgum gámum er lyft þannig að þeir lyftist sjálfkrafa. Af þessum sökum þurftum við að velja stjórnkerfi.

Við hugsuðum lengi um hvern við gætum tekið. Staðreyndin er sú að á þeim tíma var þessi dreifingstafla á venjulegum sýndarþjónum nokkuð gamaldags þar sem þeir voru ekki með nýjustu útgáfur af stýrikerfum. Á einhverjum tímapunkti var meira að segja til FreeBSD, sem var ekki mjög þægilegt að styðja. Við skildum að við þyrftum að flytja til Docker eins fljótt og auðið er. Devops okkar skoðuðu núverandi reynslu sína af mismunandi lausnum og völdu kerfi eins og Nomad.

Skiptu yfir í Nomad

Nomad er vara frá HashiCorp. Þeir eru einnig þekktir fyrir aðrar lausnir sínar:

"Ræðismaður" er tæki til að uppgötva þjónustu.

"Terraform" - kerfi til að stjórna netþjónum sem gerir þér kleift að stilla þá í gegnum stillingar, svokallaða innviði-sem-kóða.

"Fráfari" gerir þér kleift að dreifa sýndarvélum á staðnum eða í skýinu í gegnum sérstakar stillingarskrár.

Nomad virtist á þeim tíma vera frekar einföld lausn sem hægt var að skipta yfir í fljótt án þess að breyta öllu innviði. Að auki er það frekar auðvelt að læra. Þess vegna völdum við það sem síunarkerfi fyrir ílátið okkar.

Hvað þarftu til að dreifa kerfinu þínu á Nomad?

1. Fyrst af öllu sem þú þarft Docker mynd umsókn þína. Þú þarft að byggja það og setja það í docker myndageymsluna. Í okkar tilviki er þetta artifactory - kerfi sem gerir þér kleift að troða ýmsum gripum af mismunandi gerðum inn í það. Það getur geymt skjalasafn, bryggjumyndir, PHP-pakka, NPM-pakka og svo framvegis.
2. Einnig þörf stillingarskrá, sem mun segja Nomad hvað, hvar og í hvaða magni þú vilt dreifa.

Þegar við tölum um Nomad notar það HCL tungumálið sem upplýsingaskráarsnið, sem stendur fyrir HashiCorp stillingartungumál. Þetta er ofursett af Yaml sem gerir þér kleift að lýsa þjónustu þinni á Nomad skilmálum.

Það gerir þér kleift að segja hversu marga gáma þú vilt dreifa, úr hvaða myndum á að senda ýmsar breytur til þeirra meðan á dreifingu stendur. Þannig færðu þessa skrá til Nomad og hún setur gáma í framleiðslu samkvæmt henni.

Í okkar tilviki áttuðum við okkur á því að einfaldlega að skrifa alveg eins HCL skrár fyrir hverja þjónustu væri ekki mjög þægilegt, vegna þess að það er mikið af þjónustu og stundum viltu uppfæra þær. Það kemur fyrir að ein þjónusta er ekki notuð í einu tilviki heldur í ýmsum mismunandi. Til dæmis er eitt af kerfunum sem við erum með í framleiðslu með meira en 100 tilvik í framleiðslu. Þær keyra frá sömu myndunum, en eru mismunandi hvað varðar stillingar og stillingarskrár.

Þess vegna ákváðum við að það væri þægilegt fyrir okkur að geyma allar stillingarskrár okkar til uppsetningar í einni sameiginlegri geymslu. Þannig voru þau sýnileg: auðvelt var að viðhalda þeim og við gátum séð hvaða kerfi við höfðum. Ef nauðsyn krefur er líka auðvelt að uppfæra eða breyta einhverju. Það er heldur ekki erfitt að bæta við nýju kerfi - þú þarft bara að búa til stillingarskrá inni í nýju möppunni. Inni í henni eru eftirfarandi skrár: service.hcl, sem inniheldur lýsingu á þjónustu okkar, og nokkrar env skrár sem gera kleift að stilla þessa þjónustu, sem er notuð í framleiðslu.

Hins vegar eru sum kerfin okkar notuð í framleiðslu, ekki í einu eintaki, heldur í nokkrum í einu. Þess vegna ákváðum við að það væri þægilegt fyrir okkur að geyma ekki stillingarnar í hreinu formi, heldur sniðmátformi þeirra. Og við völdum jinja 2. Á þessu sniði geymum við bæði stillingar þjónustunnar sjálfrar og env skrárnar sem þarf til þess.

Að auki höfum við sett í geymsluna dreifingarhandrit sem er sameiginlegt fyrir öll verkefni, sem gerir þér kleift að ræsa og dreifa þjónustunni þinni í framleiðslu, í viðkomandi umhverfi, í viðkomandi markmið. Í tilvikinu þegar við breyttum HCL stillingum okkar í sniðmát, þá fór HCL skráin, sem áður var venjuleg Nomad stillingar, að líta aðeins öðruvísi út.

Það er að segja, við skiptum út nokkrum stillingarstaðsetningarbreytum fyrir innsettar breytur sem eru teknar úr env skrám eða öðrum heimildum. Að auki fengum við tækifæri til að safna HCL skrám á kraftmikinn hátt, það er að segja að við getum ekki aðeins notað venjulegar breytuinnsetningar. Þar sem jinja styður lykkjur og skilyrði geturðu líka búið til stillingarskrár þar sem breytast eftir því hvar nákvæmlega þú setur forritin þín í notkun.

Til dæmis, þú vilt dreifa þjónustunni þinni til forframleiðslu og framleiðslu. Segjum að í forframleiðslu viltu ekki keyra cron forskriftir, heldur viltu bara sjá þjónustuna á sérstöku léni til að vera viss um að hún virki. Fyrir alla sem nota þjónustuna lítur ferlið mjög einfalt og gagnsætt út. Allt sem þú þarft að gera er að keyra deploy.sh skrána, tilgreina hvaða þjónustu þú vilt dreifa og á hvaða miða. Til dæmis, þú vilt senda ákveðið kerfi til Rússlands, Hvíta-Rússlands eða Kasakstan. Til að gera þetta skaltu einfaldlega breyta einni af breytunum og þú munt hafa rétta stillingarskrá.

Þegar Nomad þjónustan er þegar dreifð á klasann þinn lítur hún svona út.

Í fyrsta lagi þarftu einhvers konar jafnvægisbúnað fyrir utan, sem tekur við allri notendaumferð. Það mun vinna saman með Consul og finna út frá því hvar, á hvaða hnút, á hvaða IP-tölu tiltekin þjónusta er staðsett sem samsvarar tilteknu lén. Þjónusta í Consul kemur frá sjálfum Nomad. Þar sem þetta eru vörur frá sama fyrirtæki eru þær frekar skyldar hver annarri. Við getum sagt að Nomad út úr kassanum getur skráð alla þjónustu sem er hleypt af stokkunum í því innan Consul.

Þegar framhlið hleðslujafnarinn þinn veit hvaða þjónustu á að senda umferð á, sendir hann hana áfram í viðeigandi gáma eða marga gáma sem passa við umsókn þína. Auðvitað þarf líka að huga að öryggi. Jafnvel þó að allar þjónustur keyri á sömu sýndarvélum í gámum, þá þarf þetta venjulega að koma í veg fyrir ókeypis aðgang frá hvaða þjónustu sem er að annarri. Við náðum þessu með skiptingu. Hver þjónusta var hleypt af stokkunum í sínu sýndarneti, þar sem settar voru leiðarreglur og reglur um að leyfa/neita aðgangi að öðrum kerfum og þjónustu. Þeir gætu verið staðsettir bæði innan þessa klasa og utan hans. Til dæmis, ef þú vilt koma í veg fyrir að þjónusta tengist tilteknum gagnagrunni, er hægt að gera það með skiptingu netstigs. Það er, jafnvel fyrir mistök, geturðu ekki tengst óvart úr prófunarumhverfinu við framleiðslugagnagrunninn þinn.

Hvað kostaði umskiptin okkur hvað varðar mannauð?

Skipting alls fyrirtækisins yfir í Nomad tók um það bil 5-6 mánuði. Við fluttum þjónustu fyrir þjónustu, en á nokkuð hröðum hraða. Hvert lið þurfti að búa til sína eigin gáma fyrir þjónustuna.

Við höfum tileinkað okkur þá nálgun að hvert teymi ber sjálfstætt ábyrgð á bryggjumyndum af kerfum sínum. DevOps veita almenna innviði sem nauðsynlegur er fyrir uppsetningu, það er stuðningur við klasann sjálfan, stuðning við CI kerfið og svo framvegis. Og á þeim tíma létum við flytja meira en 60 kerfi til Nomad, sem nam um 2 þúsund gámum.

Devops ber ábyrgð á almennum innviðum alls sem tengist dreifingu og netþjónum. Og hvert þróunarteymi ber síðan ábyrgð á að útfæra gáma fyrir sitt sérstaka kerfi, þar sem það er teymið sem veit hvað það þarf almennt í tilteknum gámum.

Ástæður fyrir því að yfirgefa Nomad

Hvaða kosti fengum við með því að skipta yfir í dreifingu með því að nota Nomad og docker, meðal annarra?

1. Við með jöfnum skilyrðum fyrir allt umhverfi. Í þróun, QA umhverfi, forframleiðslu, framleiðslu, eru sömu gámamyndirnar notaðar, með sömu ósjálfstæði. Samkvæmt því hefur þú nánast enga möguleika á því að það sem endar í framleiðslu sé ekki það sem þú hefur áður prófað á staðnum eða í prófunarumhverfi þínu.
2. Við fundum líka að það er nóg auðvelt að bæta við nýrri þjónustu. Frá sjónarhóli dreifingar eru öll ný kerfi sett af stað mjög einfaldlega. Farðu bara í geymsluna sem geymir stillingar, bættu við annarri stillingu fyrir kerfið þitt þar og þú ert tilbúinn. Þú getur sett kerfið þitt í framleiðslu án frekari fyrirhafnar frá devops.
3. Allt stillingarskrár í einni sameiginlegri geymslu reyndist vera í skoðun. Á þeim tíma þegar við settum upp kerfin okkar með sýndarþjónum, notuðum við Ansible, þar sem stillingarnar voru í sömu geymslu. Hins vegar, fyrir flesta þróunaraðila, var þetta aðeins erfiðara að vinna með. Hér er magn stillinga og kóða sem þú þarft að bæta við til að dreifa þjónustunni orðið mun minna. Auk þess er mjög auðvelt fyrir devops að laga eða breyta því. Ef um er að ræða umskipti, til dæmis, yfir í nýja útgáfu af Nomad, geta þeir tekið og magnuppfært allar rekstrarskrárnar sem eru staðsettar á sama stað.

En við lentum líka í nokkrum ókostum:

Það kom í ljós að við gat ekki náð hnökralausri dreifingu í tilviki Nomad. Þegar gámar voru rúllaðir út við mismunandi aðstæður gæti reynst vera í gangi og Nomad skynjaði hann sem gám tilbúinn til að taka á móti umferð. Þetta gerðist áður en forritið inni í því hafði jafnvel tækifæri til að ræsa. Af þessum sökum byrjaði kerfið að framleiða 500 villur í stuttan tíma, vegna þess að umferð fór að fara í gám sem var ekki enn tilbúinn að taka við honum.

Við lentum í nokkrum við mýrarnar. Mikilvægasti gallinn er að Nomad höndlar ekki stóran klasa mjög vel ef þú ert með mörg kerfi og gáma. Þegar þú vilt taka út einn af netþjónunum sem er innifalinn í Nomad þyrpingunni til viðhalds þá eru frekar miklar líkur á því að þyrpingin líði ekki mjög vel og falli í sundur. Sumir gámar geta til dæmis fallið og ekki hækkað - þetta mun kosta þig miklu seinna ef öll framleiðslukerfin þín eru staðsett í klasa sem Nomad stjórnar.

Við ákváðum því að hugsa um hvert við ættum að fara næst. Á þeim tímapunkti urðum við miklu meðvitaðri um hvað við vildum ná. Nefnilega: við viljum áreiðanleika, aðeins fleiri aðgerðir en Nomad býður upp á og þroskaðara, stöðugra kerfi.

Í þessu sambandi féll val okkar á Kubernetes sem vinsælasti vettvangurinn til að koma þyrpingum af stað. Sérstaklega í ljósi þess að stærð og fjöldi gáma okkar var nógu stór. Í slíkum tilgangi virtist Kubernetes vera heppilegasta kerfið sem við gætum skoðað.

Umskipti yfir í Kubernetes

Ég skal segja þér aðeins frá grunnhugtökum Kubernetes og hvernig þau eru frábrugðin Nomad.

Í fyrsta lagi er grunnhugtakið í Kubernetes hugtakið fræbelgur. Pod er hópur eins eða fleiri gáma sem keyra alltaf saman. Og þeir vinna alltaf eins og stranglega á einni sýndarvél. Þau eru aðgengileg hver öðrum í gegnum IP 127.0.0.1 á mismunandi höfnum.

Gerum ráð fyrir að þú sért með PHP forrit sem samanstendur af nginx og php-fpm - klassíska kerfinu. Líklegast viltu halda bæði nginx og php-fpm gámum saman allan tímann. Kubernetes gerir þér kleift að ná þessu með því að lýsa þeim sem einum algengum belg. Þetta er nákvæmlega það sem við gátum ekki fengið með Nomad.

Annað hugtakið er dreifing. Staðreyndin er sú að fræbelgurinn sjálfur er skammvinn hlutur; hann byrjar og hverfur. Viltu drepa alla fyrri gáma þína fyrst og ræsa síðan nýjar útgáfur í einu, eða vilt þú rúlla þeim út smám saman? Þetta er ferlið sem hugmyndin um dreifingu ber ábyrgð á. Það lýsir því hvernig þú dreifir belgunum þínum, í hvaða magni og hvernig á að uppfæra þá.

Þriðja hugtakið er þjónusta. Þjónustan þín er í raun kerfið þitt, sem tekur á móti smá umferð og sendir hana síðan áfram á einn eða fleiri belg sem samsvara þjónustunni þinni. Það er að segja, það gerir þér kleift að segja að öll komandi umferð til slíkrar og slíkrar þjónustu með slíku og slíku nafni verði að senda á þessa tilteknu belg. Og á sama tíma veitir það þér jafnvægi í umferð. Það er, þú getur ræst tvo belg af forritinu þínu og öll komandi umferð verður jafnt á milli belganna sem tengjast þessari þjónustu.

Og fjórða grunnhugtakið er Innstreymi. Þetta er þjónusta sem keyrir á Kubernetes klasa. Það virkar sem ytri álagsjafnari sem tekur við öllum beiðnum. Með því að nota Kubernetes API getur Ingress ákvarðað hvert þessar beiðnir eigi að senda. Þar að auki gerir hann þetta mjög sveigjanlega. Þú getur sagt að allar beiðnir til þessa gestgjafa og svo og svoleiðis vefslóð séu send til þessarar þjónustu. Og þessar beiðnir sem koma til þessa gestgjafa og á aðra vefslóð eru sendar til annarrar þjónustu.

Það flottasta frá sjónarhóli einhvers sem þróar forrit er að þú getur stjórnað því öllu sjálfur. Með því að stilla Ingress config geturðu sent alla umferð sem kemur að svona og svo API í aðskilda gáma sem eru skrifaðir td í Go. En þessi umferð, sem kemur á sama lén, en á aðra slóð, ætti að senda í gáma sem eru skrifuð í PHP, þar sem er mikil rökfræði, en þau eru ekki mjög hröð.

Ef við berum öll þessi hugtök saman við Nomad getum við sagt að fyrstu þrjú hugtökin séu öll saman Þjónusta. Og síðasta hugtakið er fjarverandi í sjálfum Nomad. Við notuðum ytri jafnvægisbúnað sem hann: það gæti verið haproxy, nginx, nginx+, og svo framvegis. Ef um tening er að ræða þarftu ekki að kynna þetta viðbótarhugtak sérstaklega. Hins vegar, ef þú horfir á Ingress innbyrðis, þá er það annað hvort nginx, haproxy eða traefik, en eins konar innbyggt í Kubernetes.

Öll hugtökin sem ég lýsti eru í raun auðlindir sem eru til innan Kubernetes klasa. Til að lýsa þeim í teningnum er notað yaml snið, sem er læsilegra og kunnuglegra en HCL skrár þegar um Nomad er að ræða. En byggingarlega lýsa þeir því sama þegar um til dæmis er að ræða fræbelgur. Þeir segja - ég vil dreifa svona og þvílíkum belgjum þarna, með svona og þvílíkum myndum, í svona og því magni.

Að auki gerðum við okkur grein fyrir því að við vildum ekki búa til hverja einstaka auðlind með höndunum: dreifingu, þjónustu, Ingress o.s.frv. Þess í stað vildum við lýsa hverju kerfi okkar með tilliti til Kubernetes meðan á uppsetningu stendur, svo að við þyrftum ekki að endurskapa handvirkt allar nauðsynlegar auðlindaháðir í réttri röð. Helm var valið sem kerfið sem gerði okkur kleift að gera þetta.

Grunnhugtök í Helm

Helm er pakkastjóri fyrir Kubernetes. Það er mjög svipað því hvernig pakkastjórar í forritunarmálum vinna. Þeir gera þér kleift að geyma þjónustu sem samanstendur af td dreifingu nginx, dreifingu php-fpm, config fyrir Ingress, configmaps (þetta er eining sem gerir þér kleift að stilla env og aðrar breytur fyrir kerfið þitt) í formi svo- kallast kort. Á sama tíma Helm keyrir ofan á Kubernetes. Það er, þetta er ekki einhvers konar kerfi sem stendur til hliðar, heldur bara önnur þjónusta sem er hleypt af stokkunum inni í teningnum. Þú hefur samskipti við það í gegnum API þess í gegnum stjórnborðsskipun. Þægindi þess og fegurð er sú að jafnvel þótt hjálmurinn brotni eða þú fjarlægir hann úr þyrpingunni mun þjónusta þín ekki hverfa, þar sem hjálmurinn þjónar í rauninni aðeins til að ræsa kerfið. Kubernetes ber síðan sjálft ábyrgð á frammistöðu og stöðu þjónustunnar.

Við gerðum okkur líka grein fyrir því sniðmát, sem við vorum áður neydd til að gera sjálf með því að kynna jinja inn í stillingar okkar, er einn af helstu eiginleikum helm. Allar stillingar sem þú býrð til fyrir kerfin þín eru geymdar í stýri í formi sniðmáta, svolítið svipað og jinja, en í raun með því að nota sniðmát Go tungumálsins, þar sem stýrið er skrifað, eins og Kubernetes.

Helm bætir við nokkrum hugmyndum í viðbót fyrir okkur.

Mynd - þetta er lýsing á þjónustu þinni. Í öðrum pakkastjórum væri það kallað pakki, búnt eða eitthvað álíka. Hér er það kallað graf.

Gildi eru breyturnar sem þú vilt nota til að byggja upp stillingarnar þínar úr sniðmátum.

Slepptu. Í hvert sinn sem þjónusta sem er notuð með stýri fær stigvaxandi útgáfu af útgáfunni. Helm man hvað þjónustustillingin var í fyrri útgáfunni, útgáfunni þar á undan og svo framvegis. Þess vegna, ef þú þarft að afturkalla, keyrðu bara skipunina til bakhringingar hjálsins og bendir henni á fyrri útgáfu útgáfunnar. Jafnvel þó að samsvarandi uppsetning í geymslunni þinni sé ekki tiltæk við afturköllun, mun stýrið samt muna hvað það var og mun afturkalla kerfið þitt í það ástand sem það var í í fyrri útgáfu.

Þegar við notum stýri breytast venjulegar stillingar fyrir Kubernetes einnig í sniðmát þar sem hægt er að nota breytur, aðgerðir og beita skilyrtum setningum. Þannig geturðu safnað þjónustustillingum þínum eftir umhverfinu.

Í reynd ákváðum við að gera hlutina aðeins öðruvísi en við gerðum með Nomad. Ef í Nomad voru bæði uppsetningarstillingar og n-breytur sem þurfti til að dreifa þjónustunni okkar geymdar í einni geymslu, hér ákváðum við að skipta þeim í tvær aðskildar geymslur. „Dreifa“ geymslan geymir aðeins n-breytur sem þarf til uppsetningar og „hjálm“ geymslan geymir stillingar eða töflur.

Hvað gaf þetta okkur?

Þrátt fyrir þá staðreynd að við geymum engin raunveruleg viðkvæm gögn í stillingarskránum sjálfum. Til dæmis lykilorð að gagnagrunnum. Þau eru geymd sem leyndarmál í Kubernetes, en engu að síður eru enn ákveðnir hlutir þar sem við viljum ekki veita öllum aðgang að. Þess vegna er aðgangur að „dreifa“ geymslunni takmarkaðri og „helming“ geymslan inniheldur einfaldlega lýsingu á þjónustunni. Af þessum sökum er hægt að nálgast það á öruggan hátt fyrir breiðari hóp fólks.

Þar sem við höfum ekki aðeins framleiðslu, heldur einnig önnur umhverfi, þökk sé þessum aðskilnaði getum við endurnýtt stýrikortin okkar til að dreifa þjónustu ekki aðeins til framleiðslu heldur einnig, til dæmis, í QA umhverfi. Jafnvel að dreifa þeim á staðnum með því að nota Minikube - þetta er hlutur til að keyra Kubernetes á staðnum.

Inni í hverri geymslu skildum við eftir skiptingu í sérstakar möppur fyrir hverja þjónustu. Það er að segja, inni í hverri möppu eru sniðmát sem tengjast samsvarandi töflu og lýsa þeim auðlindum sem þarf að nota til að keyra kerfið okkar. Við skildum aðeins envs eftir í „deploy“ geymslunni. Í þessu tilfelli notuðum við ekki sniðmát með því að nota jinja, vegna þess að hjálmurinn sjálfur veitir sniðmát út úr kassanum - þetta er ein af helstu hlutverkum þess.

Við skildum eftir dreifingarforskrift - deploy.sh, sem einfaldar og staðlar ræsingu fyrir uppsetningu með stýri. Svo, fyrir alla sem vilja dreifa, lítur dreifingarviðmótið nákvæmlega út eins og það gerði þegar það var notað í gegnum Nomad. Sama deploy.sh, nafnið á þjónustunni þinni og hvar þú vilt dreifa henni. Þetta veldur því að stýrið fer í gang innbyrðis. Það aftur á móti safnar stillingum úr sniðmátum, setur nauðsynlegar gildisskrár inn í þær, setur þær síðan í notkun og setur þær í Kubernetes.

Niðurstöður

Kubernetes þjónustan virðist vera flóknari en Nomad.

Hér kemur út umferð til Ingress. Þetta er bara framhliðarstýringin, sem tekur við öllum beiðnum og sendir þær í kjölfarið til þjónustunnar sem samsvarar beiðnigögnunum. Það ákvarðar þær út frá stillingum sem eru hluti af lýsingunni á forritinu þínu í stýrinu og sem forritarar setja á eigin spýtur. Þjónustan sendir beiðnir til belganna sinna, það er tiltekinna gáma, sem jafnar komandi umferð á milli allra gáma sem tilheyra þessari þjónustu. Og auðvitað ættum við ekki að gleyma því að við ættum ekki að fara neitt frá öryggi á netstigi. Þess vegna virkar skipting í Kubernetes klasa, sem byggir á merkingu. Allar þjónustur eru með ákveðin merki sem aðgangsréttur þjónustunnar að ákveðnum ytri/innri auðlindum innan eða utan klasans er tengdur við.

Þegar við gerðum umskiptin sáum við að Kubernetes hafði alla möguleika Nomad, sem við höfðum áður notað, og bætti líka við fullt af nýjum hlutum. Það er hægt að stækka það með viðbætur og í raun með sérsniðnum auðlindategundum. Það er, þú hefur tækifæri til að nota ekki bara eitthvað sem fylgir Kubernetes úr kassanum, heldur til að búa til þína eigin auðlind og þjónustu sem mun lesa auðlindina þína. Þetta gefur þér fleiri möguleika til að stækka kerfið þitt án þess að þurfa að setja upp Kubernetes aftur og án þess að þurfa breytingar.

Dæmi um slíka notkun er Prometheus, sem keyrir inni í Kubernetes þyrpingunni okkar. Til þess að það geti byrjað að safna mæligildum frá tiltekinni þjónustu þurfum við að bæta við viðbótartegund af tilföngum, svokölluðum þjónustueftirliti, við þjónustulýsinguna. Prometheus, vegna þess að það getur lesið sérsniðna tilföngstegund þegar það er hleypt af stokkunum í Kubernetes, byrjar sjálfkrafa að safna mælingum úr nýja kerfinu. Það er frekar þægilegt.

Fyrsta dreifingin sem við gerðum til Kubernetes var í mars 2018. Og á þessum tíma áttum við aldrei í neinum vandræðum með það. Það virkar nokkuð stöðugt án teljandi galla. Að auki getum við stækkað það enn frekar. Í dag höfum við nóg af þeim getu sem það hefur og okkur líkar mjög við þróunarhraða Kubernetes. Eins og er eru meira en 3000 gámar í Kubernetes. Þyrpingin tekur nokkra hnúta. Á sama tíma er það nothæft, stöðugt og mjög stjórnanlegt.

Heimild: www.habr.com