Helo pawb! Fy enw i yw Pavel Agaletsky. Rwy'n gweithio fel arweinydd tîm mewn tîm sy'n datblygu system gyflenwi Lamoda. Yn 2018, siaradais yng nghynhadledd HighLoad ++, a heddiw rwyf am gyflwyno trawsgrifiad o fy adroddiad.

Mae fy mhwnc yn ymroddedig i brofiad ein cwmni wrth ddefnyddio systemau a gwasanaethau i wahanol amgylcheddau. Gan ddechrau o'n cyfnod cynhanesyddol, pan wnaethom ddefnyddio pob system i weinyddion rhithwir cyffredin, gan orffen gyda thrawsnewid graddol o Nomad i Kubernetes. Dywedaf wrthych pam y gwnaethom hynny a pha broblemau a gawsom yn y broses.

Defnyddio ceisiadau i VM

Gadewch i ni ddechrau gyda'r ffaith bod holl systemau a gwasanaethau'r cwmni wedi'u defnyddio ar weinyddion rhithwir cyffredin 3 blynedd yn ôl. Yn dechnegol, fe'i trefnwyd yn y fath fodd fel bod holl god ein systemau yn gorwedd ac fe'i cydosodwyd gan ddefnyddio offer cydosod awtomatig, gan ddefnyddio jenkins. Gyda chymorth Ansible, fe'i cyflwynwyd eisoes o'n system rheoli fersiynau i weinyddion rhithwir. Ar yr un pryd, defnyddiwyd pob system a oedd yn ein cwmni i o leiaf 2 weinydd: un ohonynt - ar y pen, yr ail - ar y gynffon. Roedd y ddwy system hyn yn union yr un fath â'i gilydd yn eu holl osodiadau, pŵer, cyfluniad ac yn y blaen. Yr unig wahaniaeth rhyngddynt oedd bod y pennaeth yn derbyn traffig defnyddwyr, tra nad oedd y gynffon byth yn derbyn traffig defnyddiwr iddi'i hun.

Beth oedd ei ddiben?

Pan wnaethom ddefnyddio datganiadau newydd o'n cais, roeddem am sicrhau'r posibilrwydd o ddefnydd di-dor, hynny yw, heb ganlyniadau amlwg i ddefnyddwyr. Cyflawnwyd hyn oherwydd bod y datganiad cryno nesaf gan ddefnyddio Ansible wedi'i gyflwyno i'r gynffon. Yno, gallai'r bobl a fu'n ymwneud â'r lleoli wirio a gwneud yn siŵr bod popeth yn iawn: mae pob metrig, adran a chymhwysiad yn gweithio; y sgriptiau angenrheidiol yn cael eu lansio. Dim ond ar ôl iddynt fod yn argyhoeddedig bod popeth yn iawn, y newidiodd y traffig. Dechreuodd fynd at y gweinydd a oedd yn gynffon o'r blaen. Ac arhosodd yr un a oedd yn ben yn flaenorol heb draffig defnyddiwr, tra bod fersiwn flaenorol ein cais ar gael arno.

Felly roedd yn ddi-dor i ddefnyddwyr. Oherwydd bod y newid yn syth, gan mai dim ond newid cydbwysedd ydyw. Mae'n hawdd iawn rholio'n ôl i'r fersiwn flaenorol trwy newid y balancer yn ôl. Gallem hefyd sicrhau bod y cais yn barod i'w gynhyrchu hyd yn oed cyn i draffig y defnyddiwr fynd iddo, a oedd yn eithaf cyfleus.

Pa rinweddau a welwn yn hyn oll?

1. Yn gyntaf oll, mae'n ddigon dim ond yn gweithio. Mae pawb yn deall sut mae cynllun lleoli o'r fath yn gweithio, oherwydd mae'r rhan fwyaf o bobl erioed wedi defnyddio gweinyddwyr rhithwir cyffredin.
2. Mae hyn yn ddigon yn ddibynadwy, gan fod y dechnoleg lleoli yn syml, wedi'i phrofi gan filoedd o gwmnïau. Mae miliynau o weinyddion yn cael eu defnyddio fel hyn. Mae'n anodd torri rhywbeth.
3. Ac yn olaf gallem gael gosodiadau atomig. Defnyddiau sy'n digwydd ar yr un pryd i ddefnyddwyr, heb gyfnod amlwg o newid rhwng yr hen fersiwn a'r un newydd.

Ond gwelsom hefyd nifer o ddiffygion yn hyn oll:

1. Yn ychwanegol at yr amgylchedd cynhyrchu, yr amgylchedd datblygu, mae yna amgylcheddau eraill. Er enghraifft, qa a rhaggynhyrchu. Bryd hynny, roedd gennym lawer o weinyddion a thua 60 o wasanaethau. Am y rheswm hwn roedd yn rhaid ar gyfer pob gwasanaeth, cadwch y fersiwn diweddaraf ar ei gyfer peiriant rhithwir. Ar ben hynny, os ydych chi am ddiweddaru llyfrgelloedd neu osod dibyniaethau newydd, mae angen i chi wneud hyn ym mhob amgylchedd. Roedd hefyd yn angenrheidiol cydamseru'r amser pan fyddwch chi'n mynd i ddefnyddio'r fersiwn newydd nesaf o'ch cais gyda'r amser pan fydd devops yn perfformio'r gosodiadau amgylchedd angenrheidiol. Yn yr achos hwn, mae'n hawdd mynd i sefyllfa lle bydd ein hamgylchedd ychydig yn wahanol ar unwaith ym mhob amgylchedd yn olynol. Er enghraifft, mewn amgylchedd SA bydd rhai fersiynau o lyfrgelloedd, ac wrth gynhyrchu - eraill, a fydd yn arwain at broblemau.
2. Anhawster diweddaru dibyniaethau eich cais. Nid yw'n dibynnu arnoch chi, ond ar y tîm arall. Sef, gan y tîm devops sy'n cynnal y gweinyddion. Dylech roi tasg briodol iddynt a disgrifio'r hyn yr ydych am ei wneud.
3. Bryd hynny, yr oeddem hefyd am rannu’r monolithau mawr mawr a oedd gennym yn wasanaethau bach ar wahân, gan inni ddeall y byddai mwy a mwy ohonynt. Bryd hynny, roedd gennym ni fwy na 100 ohonyn nhw'n barod Roedd angen creu peiriant rhithwir newydd ar wahân ar gyfer pob gwasanaeth newydd, a oedd hefyd angen ei wasanaethu a'i ddefnyddio. Yn ogystal, nid oes angen un car arnoch, ond o leiaf dau. At hyn i gyd ychwanegir amgylchedd SA. Mae hyn yn achosi problemau ac yn ei gwneud yn anoddach i chi adeiladu a rhedeg systemau newydd. broses gymhleth, costus a hir.

Felly, penderfynasom y byddai'n fwy cyfleus symud o ddefnyddio peiriannau rhithwir cyffredin i ddefnyddio ein cymwysiadau mewn cynhwysydd docwr. Os oes gennych dociwr, mae angen system arnoch a all redeg y cymhwysiad mewn clwstwr, gan na allwch godi cynhwysydd yn union fel hynny. Fel arfer, rydych chi am gadw golwg ar faint o gynwysyddion sy'n cael eu codi fel eu bod yn cael eu codi'n awtomatig. Am y rheswm hwn, roedd yn rhaid i ni ddewis system reoli.

Buom yn meddwl yn hir ac yn galed am ba un i'w gymryd. Y ffaith yw bod y pentwr lleoli hwn i weinyddion rhithwir cyffredin ar y pryd braidd yn hen ffasiwn, gan nad oedd y fersiynau diweddaraf o systemau gweithredu. Ar ryw adeg, roedd hyd yn oed FreeBSD yno, nad oedd yn gyfleus iawn i'w gynnal. Roeddem yn deall bod angen i ni fudo i'r docwr cyn gynted â phosibl. Edrychodd ein devops ar eu profiad gyda gwahanol atebion a dewis system fel Nomad.

Newid i Nomad

Mae Nomad yn gynnyrch HashiCorp. Maent hefyd yn adnabyddus am eu datrysiadau eraill:

Conswl yn offeryn ar gyfer darganfod gwasanaeth.

"Trasfform" - system ar gyfer rheoli gweinyddwyr sy'n eich galluogi i'w ffurfweddu trwy gyfluniad, yr hyn a elwir yn seilwaith-yn-god.

Crwydrol yn eich galluogi i ddefnyddio peiriannau rhithwir yn lleol neu yn y cwmwl trwy ffeiliau cyfluniad penodol.

Roedd Nomad bryd hynny yn ymddangos fel ateb eithaf syml y gallwch chi newid iddo'n gyflym heb newid y seilwaith cyfan. Hefyd, mae'n weddol hawdd i ddysgu. Felly, fe wnaethom ei ddewis fel y system hidlo ar gyfer ein cynhwysydd.

Beth sydd ei angen arnoch chi i ddefnyddio'ch system yn Nomad mewn gwirionedd?

1. Yn gyntaf oll, mae angen ichi delwedd docwr eich cais. Mae angen i chi ei adeiladu a'i roi yn y storfa ddelwedd docwr. Yn ein hachos ni, mae hyn yn artiffisial - system sy'n eich galluogi i wthio arteffactau amrywiol o wahanol fathau i mewn iddo. Gall storio archifau, delweddau docwyr, pecynnau cyfansoddwr PHP, pecynnau NPM, ac ati.
2. Angen hefyd ffeil ffurfweddu, a fydd yn dweud wrth Nomad beth, ble a faint rydych chi am ei ddefnyddio.

Pan fyddwn yn siarad am Nomad, mae'n defnyddio'r iaith HCL fel fformat ffeil gwybodaeth, sy'n sefyll am Iaith Ffurfweddu HashiCorp. Mae hwn yn uwch-set o Yaml sy'n eich galluogi i ddisgrifio'ch gwasanaeth yn nhermau Nomad.

Mae'n caniatáu ichi ddweud faint o gynwysyddion rydych chi am eu defnyddio, o ba ddelweddau i drosglwyddo paramedrau amrywiol iddynt wrth eu defnyddio. Felly rydych chi'n bwydo'r ffeil hon i Nomad, ac mae'n lansio cynwysyddion i gynhyrchu yn unol ag ef.

Yn ein hachos ni, sylweddolon ni na fyddai dim ond ysgrifennu'r un ffeiliau HCL union yr un fath ar gyfer pob gwasanaeth yn gyfleus iawn, oherwydd mae yna lawer o wasanaethau ac weithiau rydych chi am eu diweddaru. Mae'n digwydd bod un gwasanaeth yn cael ei ddefnyddio nid mewn un achos, ond mewn amrywiaeth o rai gwahanol. Er enghraifft, mae gan un o'r systemau cynhyrchu sydd gennym dros 100 o achosion mewn cynhyrchu. Maent yn rhedeg o'r un delweddau, ond maent yn wahanol mewn gosodiadau cyfluniad a ffeiliau cyfluniad.

Felly, penderfynasom y byddai'n gyfleus i ni storio ein holl ffeiliau ffurfweddu i'w defnyddio mewn un storfa gyffredin. Yn y modd hwn, daethant yn weladwy: roeddent yn hawdd eu cynnal a gallech weld pa fath o systemau sydd gennym. Os oes angen, mae hefyd yn hawdd diweddaru neu newid rhywbeth. Nid yw ychwanegu system newydd hefyd yn anodd - dim ond ychwanegu ffeil ffurfweddu y tu mewn i'r cyfeiriadur newydd. Y tu mewn iddo mae ffeiliau: service.hcl, sy'n cynnwys disgrifiad o'n gwasanaeth, a rhai ffeiliau env sy'n caniatáu i'r union wasanaeth hwn, sy'n cael ei ddefnyddio wrth gynhyrchu, gael ei ffurfweddu.

Fodd bynnag, mae rhai o'n systemau'n cael eu defnyddio wrth gynhyrchu nid mewn un copi, ond mewn sawl un ar unwaith. Felly, penderfynasom y byddai'n gyfleus i ni storio nid ffurfweddiadau yn eu ffurf bur, ond eu ffurf dempled. Ac fel yr iaith demliadol rydyn ni wedi'i dewis jînja 2. Yn y fformat hwn, rydym yn storio cyfluniadau'r gwasanaeth ei hun a'r ffeiliau env sydd eu hangen ar ei gyfer.

Yn ogystal, rydym wedi gosod yn y storfa sgript defnyddio sy'n gyffredin ar gyfer pob prosiect, sy'n eich galluogi i lansio a defnyddio'ch gwasanaeth wrth gynhyrchu, yn yr amgylchedd cywir, yn y targed cywir. Yn yr achos pan wnaethom droi ein ffurfwedd HCL yn dempled, yna dechreuodd y ffeil HCL, sef y ffurfwedd Nomad arferol cyn hynny, yn yr achos hwn edrych ychydig yn wahanol.

Hynny yw, rydym wedi disodli rhai newidynnau config place gyda mewnosodiadau amrywiol sy'n cael eu cymryd o ffeiliau env neu o ffynonellau eraill. Yn ogystal, cawsom y gallu i adeiladu ffeiliau HCL yn ddeinamig, hynny yw, gallwn ddefnyddio nid yn unig y mewnosodiadau newidyn arferol. Gan fod jinja yn cefnogi cylchoedd ac amodau, gallwch hefyd roi ffeiliau ffurfweddu yno, sy'n newid yn dibynnu ar ble yn union rydych chi'n defnyddio'ch cymwysiadau.

Er enghraifft, rydych chi am ddefnyddio'ch gwasanaeth i gyn-gynhyrchu a chynhyrchu. Gadewch i ni ddweud nad ydych chi am redeg sgriptiau cron mewn cyn-gynhyrchu, ond dim ond eisiau gweld y gwasanaeth ar barth ar wahân i sicrhau ei fod yn rhedeg. I unrhyw un sy'n defnyddio gwasanaeth, mae'r broses yn syml ac yn dryloyw iawn. Mae'n ddigon i weithredu'r ffeil deploy.sh, nodwch pa wasanaeth rydych chi am ei ddefnyddio ac i ba darged. Er enghraifft, rydych chi am ddefnyddio rhywfaint o system i Rwsia, Belarus neu Kazakhstan. I wneud hyn, yn syml, newidiwch un o'r paramedrau, a bydd gennych y ffeil ffurfweddu gywir.

Pan fydd gwasanaeth Nomad eisoes yn cael ei ddefnyddio yn eich clwstwr, mae'n edrych fel hyn.

I ddechrau, mae angen rhywfaint o gydbwysedd llwyth arnoch o'r tu allan, a fydd yn cymryd yr holl draffig defnyddwyr i mewn iddo'i hun. Bydd yn gweithio gyda'r Conswl ac yn dysgu ohono ble, ar ba nod, ym mha gyfeiriad IP y mae gwasanaeth penodol wedi'i leoli, sy'n cyfateb i enw parth penodol. Daw gwasanaethau Conswl gan Nomad ei hun. Gan fod y rhain yn gynhyrchion yr un cwmni, maent wedi'u cysylltu'n dda. Gallwn ddweud bod Nomad allan o'r bocs yn gallu cofrestru'r holl wasanaethau a lansiwyd ynddo y tu mewn i Gonswl.

Ar ôl i'ch balans allanol wybod pa wasanaeth i anfon traffig iddo, mae'n ei ailgyfeirio i'r cynhwysydd priodol neu gynwysyddion lluosog sy'n cyd-fynd â'ch cais. Yn naturiol, mae angen meddwl am ddiogelwch hefyd. Er bod pob gwasanaeth yn rhedeg ar yr un peiriannau rhithwir mewn cynwysyddion, mae hyn fel arfer yn ei gwneud yn ofynnol i chi wrthod mynediad am ddim o unrhyw wasanaeth i unrhyw wasanaeth arall. Cyflawnwyd hyn drwy segmentu. Lansiwyd pob gwasanaeth yn ei rwydwaith rhithwir ei hun, lle ysgrifennwyd rheolau llwybro a rheolau ar gyfer caniatáu / gwadu mynediad i systemau a gwasanaethau eraill. Gallent fod y tu mewn i'r clwstwr hwn a'r tu allan iddo. Er enghraifft, os ydych chi am atal gwasanaeth rhag cysylltu â chronfa ddata benodol, gellir gwneud hyn trwy segmentu ar lefel y rhwydwaith. Hynny yw, hyd yn oed trwy gamgymeriad, ni allwch gysylltu yn ddamweiniol o'r amgylchedd prawf i'ch sylfaen gynhyrchu.

Faint gostiodd y cyfnod pontio inni o ran adnoddau dynol?

Cymerodd tua 5-6 mis y trawsnewidiad o'r cwmni cyfan i Nomad. Symudasom wasanaeth-wrth-wasanaeth, ond ar gyflymder eithaf cyflym. Roedd yn rhaid i bob tîm greu eu cynwysyddion gwasanaeth eu hunain.

Rydym wedi mabwysiadu dull gweithredu o'r fath fel bod pob tîm yn gyfrifol am ddelweddau docwyr eu systemau yn annibynnol. Mae Devops, ar y llaw arall, yn darparu'r seilwaith cyffredinol sydd ei angen ar gyfer ei ddefnyddio, hynny yw, cefnogaeth i'r clwstwr ei hun, cefnogaeth i'r system CI, ac ati. Ac ar y pryd, symudwyd mwy na 60 o systemau i Nomad, a oedd tua 2 fil o gynwysyddion.

DevOps sy'n gyfrifol am seilwaith cyffredinol popeth sy'n ymwneud â defnyddio, gyda gweinyddwyr. Ac mae pob tîm datblygu, yn ei dro, yn gyfrifol am weithredu cynwysyddion ar gyfer eu system benodol, gan mai'r tîm sy'n gwybod beth sydd ei angen yn gyffredinol mewn cynhwysydd penodol.

Rhesymau dros adael Nomad

Pa fanteision gawson ni o newid i leoliad gan ddefnyddio Nomad a docker hefyd?

1. Rydym yn darparu'r un amodau ar gyfer pob amgylchedd. Mewn datblygiad, QA-amgylchedd, cyn-gynhyrchu, cynhyrchu, defnyddir yr un delweddau cynhwysydd, gyda'r un dibyniaethau. Yn unol â hynny, bron nad oes gennych unrhyw siawns y bydd rhywbeth gwahanol i'r hyn y gwnaethoch chi ei brofi'n lleol yn flaenorol neu ar amgylchedd prawf yn troi allan wrth gynhyrchu.
2. Gwelsom hefyd ei fod yn ddigon hawdd ychwanegu gwasanaeth newydd. Mae unrhyw systemau newydd o ran defnyddio yn cael eu lansio yn syml iawn. Mae'n ddigon i fynd i'r ystorfa sy'n storio'r configs, ychwanegwch y config nesaf ar gyfer eich system yno, ac rydych chi i gyd yn barod. Gallwch chi ddefnyddio'ch system i gynhyrchu heb unrhyw ymdrech ychwanegol gan devops.
3. Mae pob ffeiliau ffurfweddu mewn un ystorfa a rennir troi allan i gael ei anwybyddu. Ar hyn o bryd pan wnaethom ddefnyddio ein systemau gan ddefnyddio gweinyddwyr rhithwir, gwnaethom ddefnyddio Ansible, lle'r oedd y cyfluniadau yn yr un gadwrfa. Fodd bynnag, i'r rhan fwyaf o ddatblygwyr, roedd hyn ychydig yn anoddach gweithio ag ef. Yma mae nifer y cyfluniadau a'r cod y mae angen i chi eu hychwanegu i ddefnyddio'r gwasanaeth wedi dod yn llawer llai. Hefyd ar gyfer devops mae'n hawdd iawn ei drwsio neu ei newid. Yn achos trawsnewidiadau, er enghraifft, i fersiwn newydd o Nomad, gallant gymryd a diweddaru'n aruthrol yr holl ffeiliau gweithredu sy'n gorwedd yn yr un lle.

Ond daethom ar draws nifer o anfanteision hefyd:

Mae'n troi allan ein bod ni methu â chyflawni gosodiadau di-dor yn achos Nomad. Wrth gyflwyno cynwysyddion o wahanol amodau, gallai ddigwydd ei fod yn rhedeg allan, ac roedd Nomad yn ei weld fel cynhwysydd a oedd yn barod i dderbyn traffig. Digwyddodd hyn hyd yn oed cyn i'r cais y tu mewn iddo gael amser i ddechrau. Am y rheswm hwn, dechreuodd y system gyhoeddi 500 o wallau am gyfnod byr, oherwydd dechreuodd y traffig fynd i'r cynhwysydd, nad oedd yn barod i'w dderbyn eto.

Rydym wedi dod ar draws rhai chwilod. Y byg mwyaf arwyddocaol yw nad yw Nomad yn trin clwstwr mawr yn dda iawn os oes gennych lawer o systemau a chynwysyddion. Pan fyddwch chi eisiau mynd ag un o'r gweinyddwyr sydd wedi'i gynnwys yng nghlwstwr Nomad i wasanaeth, mae tebygolrwydd eithaf uchel na fydd y clwstwr yn teimlo'n dda iawn ac yn disgyn ar wahân. Efallai y bydd rhai cynwysyddion, er enghraifft, yn disgyn ac nid yn codi - bydd hyn yn costio llawer yn ddiweddarach i chi os yw'ch holl systemau cynhyrchu wedi'u lleoli mewn clwstwr a reolir gan Nomad.

Felly fe benderfynon ni feddwl ble dylen ni fynd nesaf. Bryd hynny, daethom yn llawer mwy ymwybodol o’r hyn yr ydym am ei gyflawni. Sef: rydym eisiau dibynadwyedd, ychydig mwy o nodweddion nag y mae Nomad yn eu rhoi, a system fwy aeddfed, mwy sefydlog.

Yn hyn o beth, disgynnodd ein dewis ar Kubernetes fel y llwyfan mwyaf poblogaidd ar gyfer rhedeg clystyrau. Yn enwedig o ystyried bod maint a nifer ein cynwysyddion yn ddigon mawr. At ddibenion o'r fath, roedd yn ymddangos mai Kubernetes oedd y system fwyaf addas o'r rhai y gallem edrych arnynt.

Symud i Kubernetes

Byddaf yn siarad ychydig am beth yw cysyniadau sylfaenol Kubernetes a sut maen nhw'n wahanol i Nomad.

Yn gyntaf oll, y cysyniad mwyaf sylfaenol yn Kubernetes yw'r cysyniad o goden. Pod yn grŵp o un neu fwy o gynwysyddion sydd bob amser yn dechrau gyda'i gilydd. Ac maen nhw'n gweithio fel pe bai bob amser yn llym ar yr un peiriant rhithwir. Maent ar gael i'w gilydd trwy gyfeiriad IP 127.0.0.1 ar wahanol borthladdoedd.

Gadewch i ni ddweud bod gennych chi gymhwysiad PHP sy'n cynnwys nginx a php-fpm - y patrwm clasurol. Yn fwyaf tebygol, byddwch chi eisiau i gynwysyddion nginx a php-fpm fod gyda'i gilydd bob amser. Mae Kubernetes yn caniatáu ichi gyflawni hyn trwy eu disgrifio fel un pod cyffredin. Dyma'n union beth na allem ei gael gyda Nomad.

Yr ail gysyniad yw defnyddio. Y pwynt yw bod y pod ei hun yn beth byrhoedlog, mae'n dechrau ac yn diflannu. P'un a ydych am ladd eich holl gynwysyddion blaenorol yn gyntaf, ac yna lansio fersiynau newydd ar unwaith, neu a ydych am eu cyflwyno'n raddol - dyma'r union gysyniad o leoli sy'n gyfrifol am y broses hon. Mae'n disgrifio sut rydych chi'n defnyddio'ch codennau, faint, a sut i'w diweddaru.

Y trydydd cysyniad yw gwasanaeth. Eich system mewn gwirionedd yw eich gwasanaeth, sy'n cymryd rhywfaint o draffig, ac yna'n ei gyfeirio at un neu fwy o godau sy'n cyfateb i'ch gwasanaeth. Hynny yw, mae'n caniatáu ichi ddweud bod yn rhaid anfon yr holl draffig sy'n dod i mewn i'r fath a gwasanaeth o'r fath ag enw o'r fath i'r codennau penodol hyn. Ac ar yr un pryd, mae'n rhoi cydbwysedd traffig i chi. Hynny yw, gallwch chi redeg dau god o'ch cais, a bydd yr holl draffig sy'n dod i mewn yn cael ei gydbwyso'n gyfartal rhwng y codennau sy'n gysylltiedig â'r gwasanaeth hwn.

A'r pedwerydd cysyniad sylfaenol - Mynd i mewn. Mae hwn yn wasanaeth sy'n rhedeg ar glwstwr Kubernetes. Mae'n gweithredu fel cydbwysedd llwyth allanol sy'n cymryd drosodd pob cais. Trwy API Kubernetes, gall Ingress benderfynu i ble y dylid anfon y ceisiadau hyn. Ac mae'n ei wneud yn hyblyg iawn. Gallwch ddweud bod pob cais am y gwesteiwr hwn ac o'r fath ac URL o'r fath yn cael eu hanfon at y gwasanaeth hwn. Ac mae'r ceisiadau hyn sy'n dod i'r gwesteiwr hwn ac i URL arall yn cael eu hanfon at wasanaeth arall.

Y peth cŵl o safbwynt rhywun sy'n datblygu cymhwysiad yw eich bod chi'n gallu rheoli'r cyfan eich hun. Trwy osod y ffurfwedd Ingress, gallwch anfon yr holl draffig sy'n dod i API o'r fath ac o'r fath i gynwysyddion ar wahân, wedi'u cofrestru, er enghraifft, yn Go. Ond mae'r traffig hwn sy'n dod i'r un parth, ond i URL gwahanol, yn cael ei anfon at gynwysyddion a ysgrifennwyd yn PHP, lle mae llawer o resymeg, ond nid ydynt yn gyflym iawn.

Os byddwn yn cymharu'r holl gysyniadau hyn â Nomad, yna gallwn ddweud bod y tri chysyniad cyntaf i gyd gyda'i gilydd Gwasanaeth. Ac mae'r cysyniad olaf yn absennol yn Nomad ei hun. Fe wnaethon ni ddefnyddio balancer allanol fel y mae: gall fod yn haproxy, nginx, nginx + ac yn y blaen. Yn achos ciwb, nid oes angen i chi gyflwyno'r cysyniad ychwanegol hwn ar wahân. Fodd bynnag, os edrychwch ar Ingress y tu mewn, yna mae'n naill ai nginx, neu haproxy, neu traefik, ond, fel petai, wedi'i ymgorffori yn Kubernetes.

Mae'r holl gysyniadau a ddisgrifiais, mewn gwirionedd, yn adnoddau sy'n bodoli y tu mewn i glwstwr Kubernetes. I'w disgrifio yn y ciwb, defnyddir y fformat yaml, sy'n fwy darllenadwy a chyfarwydd na ffeiliau HCL yn achos Nomad. Ond yn strwythurol, maent yn disgrifio'r un peth yn achos, er enghraifft, pod. Maen nhw'n dweud - rydw i eisiau defnyddio codennau o'r fath yno, gyda delweddau o'r fath, yn y fath nifer.

Yn ogystal, gwnaethom sylweddoli nad oeddem am greu pob adnodd unigol â llaw: defnydd, gwasanaethau, Ingress, ac ati. Yn lle hynny, roeddem am ddisgrifio ein system pob un yn nhermau Kubernetes yn ystod y defnydd, fel nad oedd yn rhaid i ni ail-greu'r holl ddibyniaethau adnoddau angenrheidiol â llaw yn y drefn gywir. Dewiswyd Helm fel system o'r fath a oedd yn caniatáu i ni wneud hyn.

Cysyniadau sylfaenol yn Helm

Llyw yw rheolwr pecyn ar gyfer Kubernetes. Mae'n debyg iawn i sut mae rheolwyr pecyn yn gweithio mewn ieithoedd rhaglennu. Maent yn caniatáu ichi storio gwasanaeth sy'n cynnwys, er enghraifft, lleoli nginx, lleoli php-fpm, config ar gyfer Ingress, configmaps (dyma endid sy'n eich galluogi i osod amlen a pharamedrau eraill ar gyfer eich system) ar ffurf felly- a elwir yn siartiau. Ar yr un pryd, Helm yn rhedeg ar ben Kubernetes. Hynny yw, nid rhyw fath o system yn sefyll o'r neilltu yw hwn, ond dim ond gwasanaeth arall sy'n rhedeg y tu mewn i'r ciwb. Rydych chi'n rhyngweithio ag ef trwy ei API trwy orchymyn consol. Ei hwylustod a'i swyn yw hyd yn oed os bydd helm yn torri neu os byddwch yn ei dynnu o'r clwstwr, ni fydd eich gwasanaethau'n diflannu, gan mai dim ond cychwyn y system y mae llyw yn ei hanfod. Mae Kubernetes ei hun yn gyfrifol ymhellach am iechyd a chyflwr gwasanaethau.

Sylweddolon ni hynny hefyd templad, yr oedd yn rhaid i ni hyd hyny ei wneud ar ein pen ein hunain trwy gyflwyno jinja i'n cyfluniadau, yn un o brif nodweddion helm. Mae'r holl gyfluniadau rydych chi'n eu creu ar gyfer eich systemau yn cael eu storio mewn llyw fel templedi, yn debyg i jinja, ond mewn gwirionedd gan ddefnyddio templedi'r iaith Go lle mae helm wedi'i ysgrifennu, yn union fel Kubernetes.

Mae Helm yn ychwanegu ychydig mwy o gysyniadau ychwanegol atom.

Siart yn ddisgrifiad o'ch gwasanaeth. Mewn rheolwyr pecynnau eraill, byddai'n cael ei alw'n bwndel, yn fwndel, neu'n rhywbeth tebyg. Yma fe'i gelwir yn siart.

Gwerthoedd yw'r newidynnau rydych chi am eu defnyddio i adeiladu eich cyfluniadau o dempledi.

Rhyddhau. Bob tro mae gwasanaeth sy'n defnyddio gyda llyw yn cael fersiwn cynyddrannol o'r datganiad. Mae Helm yn cofio beth oedd ffurfwedd y gwasanaeth ar gyfer y datganiad blaenorol, y flwyddyn cyn diwethaf, ac ati. Felly, os oes angen i chi rolio'n ôl, rhedwch y gorchymyn galw'n ôl helm, gan ei gyfeirio at fersiwn flaenorol y datganiad. Hyd yn oed os nad yw'r cyfluniad cyfatebol yn eich ystorfa ar gael ar adeg y dychweliad, bydd y llyw yn dal i gofio beth ydoedd ac yn dychwelyd eich system i'r cyflwr yr oedd yn y datganiad blaenorol.

Yn yr achos pan fyddwn yn defnyddio helm, mae'r cyfluniadau arferol ar gyfer Kubernetes hefyd yn troi'n dempledi lle mae'n bosibl defnyddio newidynnau, swyddogaethau, a chymhwyso datganiadau amodol. Felly, gallwch chi gasglu ffurfwedd eich gwasanaeth yn dibynnu ar yr amgylchedd.

Yn ymarferol, fe benderfynon ni wneud pethau ychydig yn wahanol nag a wnaethom gyda Nomad. Pe bai Nomad yn storio cyfluniadau defnyddio ac n-newidynnau sydd eu hangen i ddefnyddio ein gwasanaeth mewn un gadwrfa, yna dyma benderfynu eu rhannu'n ddwy gadwrfa ar wahân. Mae'r ystorfa "defnyddio" yn storio'r n-newidynnau sydd eu hangen ar gyfer eu defnyddio yn unig, tra bod ystorfa "helm" yn storio cyfluniadau neu siartiau.

Beth roddodd i ni?

Er gwaethaf y ffaith nad ydym yn storio unrhyw ddata sensitif iawn yn y ffeiliau ffurfweddu eu hunain. Er enghraifft, cyfrineiriau cronfa ddata. Maent yn cael eu storio fel cyfrinachau yn Kubernetes, ond serch hynny, mae pethau ar wahân o hyd nad ydym am roi mynediad i bawb yn olynol. Felly, mae mynediad i'r ystorfa "defnyddio" yn fwy cyfyngedig, ac mae'r ystorfa "helm" yn cynnwys disgrifiad yn unig o'r gwasanaeth. Am y rheswm hwn, gellir rhoi mynediad diogel iddo i gylch mwy o bobl.

Gan fod gennym nid yn unig gynhyrchu, ond hefyd amgylcheddau eraill, diolch i'r gwahaniad hwn, gallwn ailddefnyddio ein siartiau helm i ddefnyddio gwasanaethau nid yn unig i gynhyrchu, ond hefyd, er enghraifft, i amgylchedd SA. Hyd yn oed i'w defnyddio'n lleol gan ddefnyddio Miniciwb - mae hyn yn beth o'r fath ar gyfer rhedeg Kubernetes yn lleol.

Y tu mewn i bob ystorfa, gadawsom yr is-adran yn gyfeiriaduron ar wahân ar gyfer pob gwasanaeth. Hynny yw, y tu mewn i bob cyfeiriadur mae templedi sy'n gysylltiedig â'r siart cyfatebol ac yn disgrifio'r adnoddau y mae angen eu defnyddio i lansio ein system. Yn ystorfa "deploy", ni adawsom ond eiddigedd. Yn yr achos hwn, ni wnaethom ddefnyddio templedi jinja oherwydd bod helm yn darparu templedi allan o'r bocs - dyna un o'i brif nodweddion.

Gadawsom y sgript defnyddio - deploy.sh, sy'n symleiddio ac yn safoni'r lansiad i'w ddefnyddio gan ddefnyddio helm. Felly, i unrhyw un sydd am ddefnyddio, mae'r rhyngwyneb lleoli yn edrych yn union yr un fath ag yr oedd yn achos lleoli trwy Nomad. Yr un deploy.sh, enw eich gwasanaeth, a lle rydych chi am ei ddefnyddio. Mae hyn yn achosi helm i redeg yn fewnol. Mae ef, yn ei dro, yn casglu cyfluniadau o dempledi, yn amnewid y ffeiliau gwerthoedd angenrheidiol ynddynt, yna'n eu defnyddio, gan eu lansio i Kubernetes.

Canfyddiadau

Mae'n ymddangos bod gwasanaeth Kubernetes yn fwy cymhleth na Nomad.

Dyma lle mae traffig sy'n mynd allan yn dod yn Ingress. Dim ond y rheolydd blaen yw hwn, sy'n cymryd drosodd yr holl geisiadau ac yna'n eu hanfon at y gwasanaethau sy'n cyfateb i ddata'r cais. Mae'n eu pennu yn seiliedig ar gyfluniadau sy'n rhan o'r disgrifiad o'ch cais wrth y llyw ac y mae datblygwyr yn eu gosod iddyn nhw eu hunain. Mae'r gwasanaeth, ar y llaw arall, yn anfon ceisiadau i'w codennau, hynny yw, cynwysyddion penodol, gan gydbwyso traffig sy'n dod i mewn rhwng yr holl gynwysyddion sy'n perthyn i'r gwasanaeth hwn. Ac, wrth gwrs, ni ddylem anghofio na ddylem fynd i unrhyw le o ddiogelwch ar lefel rhwydwaith. Felly, mae segmentu yn gweithio yng nghlwstwr Kubernetes, sy'n seiliedig ar dagio. Mae gan bob gwasanaeth dagiau penodol, ac mae hawliau mynediad gwasanaethau i rai adnoddau allanol / mewnol y tu mewn neu'r tu allan i'r clwstwr ynghlwm wrthynt.

Wrth i ni drawsnewid, gwelsom fod gan Kubernetes holl nodweddion y Nomad rydyn ni wedi bod yn eu defnyddio hyd yn hyn, ac mae'n ychwanegu llawer o bethau newydd hefyd. Gellir ei ymestyn trwy ategion, ac mewn gwirionedd trwy fathau o adnoddau arferol. Hynny yw, mae gennych gyfle nid yn unig i ddefnyddio rhywbeth sy'n dod gyda Kubernetes allan o'r bocs, ond i greu eich adnodd a'ch gwasanaeth eich hun a fydd yn darllen eich adnodd. Mae hyn yn rhoi mwy o opsiynau i chi ehangu'ch system heb orfod ailosod Kubernetes a heb orfod gwneud newidiadau.

Enghraifft o ddefnydd o'r fath yw Prometheus, yr ydym yn ei redeg y tu mewn i glwstwr Kubernetes. Er mwyn iddo ddechrau casglu metrigau o wasanaeth penodol, mae angen inni ychwanegu math ychwanegol o adnodd at y disgrifiad o'r gwasanaeth, sef y gwasanaeth monitro fel y'i gelwir. Mae Prometheus, oherwydd y gall ddarllen, sy'n cael ei lansio yn Kubernetes, math o adnodd arferol, yn dechrau casglu metrigau o'r system newydd yn awtomatig. Mae'n ddigon cyfleus.

Roedd y defnydd cyntaf a wnaethom yn Kubernetes ym mis Mawrth 2018. Ac yn ystod y cyfnod hwn ni chawsom unrhyw broblemau ag ef. Mae'n gweithio'n eithaf sefydlog heb fygiau sylweddol. Yn ogystal, gallwn ei ehangu ymhellach. Hyd yn hyn, mae gennym ddigon o'r galluoedd sydd ganddo, ac rydym yn hoff iawn o gyflymder datblygiad Kubernetes. Ar hyn o bryd, mae mwy na 3000 o gynwysyddion yn Kubernetes. Mae'r clwstwr yn meddiannu sawl Node. Ar yr un pryd, mae'n ddefnyddiol, yn sefydlog ac yn rheoladwy iawn.

Ffynhonnell: hab.com