Sut i fudo i'r cwmwl mewn dwy awr diolch i Kubernetes ac awtomeiddio

Sut i fudo i'r cwmwl mewn dwy awr diolch i Kubernetes ac awtomeiddio

Ceisiodd cwmni URUS Kubernetes mewn gwahanol ffurfiau: defnydd annibynnol ar fetel noeth, yn Google Cloud, ac yna trosglwyddo ei lwyfan i gwmwl Mail.ru Cloud Solutions (MCS). Mae Igor Shishkin yn dweud sut y gwnaethon nhw ddewis darparwr cwmwl newydd a sut y gwnaethon nhw lwyddo i fudo iddo mewn dwy awr erioed (t3ran), uwch weinyddwr system yn URUS.

Beth mae URUS yn ei wneud?

Mae yna lawer o ffyrdd i wella ansawdd yr amgylchedd trefol, ac un ohonynt yw ei wneud yn gyfeillgar i'r amgylchedd. Dyma'n union beth mae cwmni URUS - Smart Digital Services yn gweithio arno. Yma maent yn gweithredu atebion sy'n helpu mentrau i fonitro dangosyddion amgylcheddol pwysig a lleihau eu heffaith negyddol ar yr amgylchedd. Mae synwyryddion yn casglu data ar gyfansoddiad aer, lefel sŵn a pharamedrau eraill, ac yna'n eu hanfon at y platfform URUS-Ekomon unedig i'w dadansoddi a gwneud argymhellion.

Sut mae URUS yn gweithio o'r tu mewn

Mae cleient nodweddiadol o URUS yn gwmni sydd wedi'i leoli mewn ardal breswyl neu'n agos ati. Gallai hyn fod yn ffatri, porthladd, depo rheilffordd neu unrhyw gyfleuster arall. Os yw ein cleient eisoes wedi derbyn rhybudd, wedi cael dirwy am lygredd amgylcheddol, neu eisiau gwneud llai o sŵn, lleihau faint o allyriadau niweidiol, mae'n dod atom ni, ac rydym eisoes yn cynnig ateb parod iddo ar gyfer monitro amgylcheddol.

Sut i fudo i'r cwmwl mewn dwy awr diolch i Kubernetes ac awtomeiddio
Mae'r graff monitro crynodiad H2S yn dangos allyriadau rheolaidd yn ystod y nos o weithfeydd cyfagos

Mae'r dyfeisiau a ddefnyddiwn yn URUS yn cynnwys sawl synhwyrydd sy'n casglu gwybodaeth am gynnwys rhai nwyon, lefelau sŵn a data arall i asesu'r sefyllfa amgylcheddol. Mae union nifer y synwyryddion bob amser yn cael ei bennu gan y dasg benodol.

Sut i fudo i'r cwmwl mewn dwy awr diolch i Kubernetes ac awtomeiddio
Yn dibynnu ar fanylion y mesuriadau, gellir lleoli dyfeisiau gyda synwyryddion ar waliau adeiladau, polion a lleoedd mympwyol eraill. Mae pob dyfais o'r fath yn casglu gwybodaeth, yn ei hagregu ac yn ei hanfon i'r porth derbyn data. Yno rydym yn arbed y data ar gyfer storio hirdymor ac yn ei rag-brosesu ar gyfer dadansoddiad dilynol. Yr enghraifft symlaf o'r hyn a gawn o ganlyniad i ddadansoddiad yw'r mynegai ansawdd aer, a elwir hefyd yn AQI.

Ar yr un pryd, mae llawer o wasanaethau eraill yn gweithredu ar ein platfform, ond maent yn bennaf o natur gwasanaeth. Er enghraifft, mae'r gwasanaeth hysbysu yn anfon hysbysiadau at gleientiaid os yw unrhyw un o'r paramedrau a fonitrir (er enghraifft, cynnwys CO2) yn fwy na'r gwerth a ganiateir.

Sut rydym yn storio data. Stori Kubernetes ar fetel noeth

Mae gan brosiect monitro amgylcheddol URUS sawl warws data. Mewn un rydym yn cadw data “amrwd” - yr hyn a gawsom yn uniongyrchol o'r dyfeisiau eu hunain. Mae'r storfa hon yn dâp “magnetig”, fel ar hen dapiau casét, gyda hanes yr holl ddangosyddion. Defnyddir yr ail fath o storfa ar gyfer data wedi'i brosesu ymlaen llaw - data o ddyfeisiau, wedi'i gyfoethogi â metadata am gysylltiadau rhwng synwyryddion a darlleniadau'r dyfeisiau eu hunain, cysylltiad â sefydliadau, lleoliadau, ac ati. Mae'r wybodaeth hon yn caniatáu ichi asesu'n ddeinamig sut mae dangosydd penodol wedi newid dros gyfnod penodol o amser. Rydym yn defnyddio'r storfa data "amrwd", ymhlith pethau eraill, fel copi wrth gefn ac ar gyfer adfer data wedi'i brosesu ymlaen llaw, os bydd angen o'r fath yn codi.

Pan oeddem yn edrych i ddatrys ein problem storio sawl blwyddyn yn ôl, roedd gennym ddau ddewis platfform: Kubernetes ac OpenStack. Ond gan fod yr olaf yn edrych yn eithaf gwrthun (dim ond edrych ar ei bensaernïaeth i fod yn argyhoeddedig o hyn), rydym yn setlo ar Kubernetes. Dadl arall o'i blaid oedd y rheolaeth feddalwedd gymharol syml, y gallu i dorri nodau caledwedd hyd yn oed yn fwy hyblyg yn ôl adnoddau.

Ochr yn ochr â meistroli Kubernetes ei hun, fe wnaethom hefyd astudio ffyrdd o storio data, tra ein bod yn cadw ein holl storfa yn Kubernetes ar ein caledwedd ein hunain, cawsom arbenigedd rhagorol. Roedd popeth yr oeddem wedi'i fyw ar Kubernetes bryd hynny: storfa gyflwr, system fonitro, CI/CD. Mae Kubernetes wedi dod yn blatfform popeth-mewn-un i ni.

Ond roeddem am weithio gyda Kubernetes fel gwasanaeth, a pheidio ag ymgysylltu â'i gefnogaeth a'i ddatblygiad. Hefyd, nid oeddem yn hoffi faint yr oedd yn ei gostio i ni ei gynnal ar fetel noeth, ac roedd angen ei ddatblygu'n gyson! Er enghraifft, un o'r tasgau cyntaf oedd integreiddio rheolwyr Kubernetes Ingress i seilwaith rhwydwaith ein sefydliad. Mae hon yn dasg feichus, yn enwedig o ystyried nad oedd unrhyw beth yn barod ar y pryd ar gyfer rheoli adnoddau rhaglennu fel cofnodion DNS neu ddyrannu cyfeiriadau IP. Yn ddiweddarach dechreuon ni arbrofi gyda storio data allanol. Nid ydym byth yn mynd o gwmpas i weithredu'r rheolydd PVC, ond hyd yn oed wedyn daeth yn amlwg bod hwn yn faes gwaith mawr a oedd yn gofyn am arbenigwyr ymroddedig.

Mae newid i Google Cloud Platform yn ddatrysiad dros dro

Fe wnaethom sylweddoli na allai hyn barhau, a symud ein data o fetel noeth i Google Cloud Platform. Mewn gwirionedd, ar yr adeg honno nid oedd llawer o opsiynau diddorol ar gyfer cwmni Rwsiaidd: ar wahân i Google Cloud Platform, dim ond Amazon a gynigiodd wasanaeth tebyg, ond rydym yn dal i setlo ar yr ateb gan Google. Yna roedd yn ymddangos i ni yn fwy proffidiol yn economaidd, yn agosach at Upstream, heb sôn am y ffaith bod Google ei hun yn fath o PoC Kubernetes mewn Cynhyrchu.

Ymddangosodd y broblem fawr gyntaf ar y gorwel wrth i'n sylfaen cwsmeriaid dyfu. Pan oedd angen i ni storio data personol, roeddem yn wynebu dewis: naill ai rydym yn gweithio gyda Google ac yn torri cyfreithiau Rwsia, neu rydym yn chwilio am ddewis arall yn Ffederasiwn Rwsia. Roedd y dewis, ar y cyfan, yn rhagweladwy. 🙂

Sut y gwelsom y gwasanaeth cwmwl delfrydol

Erbyn dechrau'r chwiliad, roeddem eisoes yn gwybod beth yr oeddem am ei gael gan ddarparwr y cwmwl yn y dyfodol. Pa wasanaeth yr oeddem yn chwilio amdano:

  • Cyflym a hyblyg. Fel y gallwn ychwanegu nod newydd yn gyflym neu ddefnyddio rhywbeth ar unrhyw adeg.
  • Yn rhad. Yr oeddem yn bryderus iawn am y mater ariannol, gan ein bod yn gyfyngedig o ran adnoddau. Roeddem eisoes yn gwybod ein bod am weithio gyda Kubernetes, a nawr y dasg oedd lleihau ei gost er mwyn cynyddu neu o leiaf gynnal effeithlonrwydd defnyddio'r datrysiad hwn.
  • awtomataidd. Roeddem yn bwriadu gweithio gyda'r gwasanaeth trwy'r API, heb reolwyr a galwadau ffôn neu sefyllfaoedd lle mae angen i ni godi sawl dwsin o nodau â llaw yn y modd brys. Gan fod y rhan fwyaf o'n prosesau yn awtomataidd, roeddem yn disgwyl yr un peth gan y gwasanaeth cwmwl.
  • Gyda gweinyddion yn Ffederasiwn Rwsia. Wrth gwrs, roeddem yn bwriadu cydymffurfio â deddfwriaeth Rwsia a'r un 152-FZ.

Bryd hynny, ychydig o ddarparwyr Kubernetes aaS oedd yn Rwsia, ac wrth ddewis darparwr, roedd yn bwysig inni beidio â pheryglu ein blaenoriaethau. Darparodd tîm Cloud Solutions Mail.ru, y gwnaethom ddechrau gweithio ag ef ac sy'n dal i gydweithio, wasanaeth cwbl awtomataidd i ni, gyda chefnogaeth API a phanel rheoli cyfleus sy'n cynnwys Horizon - gydag ef gallem godi nifer fympwyol o nodau yn gyflym.

Sut y llwyddasom i ymfudo i MCS mewn dwy awr

Mewn symudiadau o'r fath, mae llawer o gwmnïau'n wynebu anawsterau ac anfanteision, ond yn ein hachos ni nid oedd yr un. Roeddem yn ffodus: gan ein bod eisoes yn gweithio ar Kubernetes cyn i'r mudo ddechrau, fe wnaethom gywiro tair ffeil a lansio ein gwasanaethau ar y platfform cwmwl newydd, MCS. Gadewch i mi eich atgoffa ein bod erbyn hynny wedi gadael metel noeth o'r diwedd ac yn byw ar y Google Cloud Platform. Felly, ni chymerodd y symudiad ei hun fwy na dwy awr, a threuliwyd ychydig mwy o amser (tua awr) yn copïo data o'n dyfeisiau. Bryd hynny roeddem eisoes yn defnyddio Spinnaker (gwasanaeth CD aml-gwmwl i ddarparu Continous Delivery). Fe wnaethom hefyd ei ychwanegu'n gyflym at y clwstwr newydd a pharhau i weithio fel arfer.

Diolch i awtomeiddio prosesau datblygu a CI / CD, mae Kubernetes yn URUS yn cael ei drin gan un arbenigwr (a dyna fi). Ar ryw adeg, bu gweinyddwr system arall yn gweithio gyda mi, ond yna daeth i'r amlwg ein bod eisoes wedi awtomeiddio'r holl brif drefn ac roedd mwy a mwy o dasgau ar ran ein prif gynnyrch ac roedd yn gwneud synnwyr i gyfeirio adnoddau at hyn.

Cawsom yr hyn yr oeddem yn ei ddisgwyl gan ddarparwr y cwmwl, ers i ni ddechrau cydweithredu heb rithiau. Os oedd unrhyw ddigwyddiadau, roeddent yn dechnegol yn bennaf ac yn rhai y gellid eu hesbonio'n hawdd gan ffresni cymharol y gwasanaeth. Y prif beth yw bod tîm MCS yn dileu diffygion yn gyflym ac yn ymateb yn gyflym i gwestiynau mewn negeswyr.

Os ydw i'n cymharu fy mhrofiad â Google Cloud Platform, yn eu hachos nhw, doeddwn i ddim hyd yn oed yn gwybod ble roedd y botwm adborth, gan nad oedd ei angen yn syml. Ac os digwyddodd unrhyw broblemau, anfonodd Google ei hun hysbysiadau yn unochrog. Ond yn achos MCS, rwy'n meddwl mai'r fantais fawr yw eu bod mor agos â phosibl at gleientiaid Rwsiaidd - yn ddaearyddol ac yn feddyliol.

Sut rydyn ni'n gweld gweithio gyda chymylau yn y dyfodol

Nawr mae ein gwaith yn gysylltiedig yn agos â Kubernetes, ac mae'n gwbl addas i ni o safbwynt tasgau seilwaith. Felly, nid ydym yn bwriadu mudo ohono i unrhyw le, er ein bod yn cyflwyno arferion a gwasanaethau newydd yn gyson i symleiddio tasgau arferol ac awtomeiddio rhai newydd, cynyddu sefydlogrwydd a dibynadwyedd gwasanaethau... Rydym bellach yn lansio gwasanaeth Chaos Monkey (yn benodol , rydym yn defnyddio anhrefn, ond nid yw hyn yn newid y cysyniad: ), a grëwyd yn wreiddiol gan Netflix. Mae Chaos Monkey yn gwneud un peth syml: mae'n dileu pod Kubernetes ar hap ar hap. Mae hyn yn angenrheidiol er mwyn i'n gwasanaeth fyw'n normal gyda nifer yr achosion n–1, felly rydym yn hyfforddi ein hunain i fod yn barod am unrhyw broblemau.

Nawr rwy'n gweld y defnydd o atebion trydydd parti - yr un llwyfannau cwmwl - fel yr unig beth iawn i gwmnïau ifanc. Fel arfer, ar ddechrau eu taith, maent yn gyfyngedig o ran adnoddau, yn ddynol ac ariannol, ac mae adeiladu a chynnal eu cwmwl neu ganolfan ddata eu hunain yn rhy ddrud ac yn llafurddwys. Mae darparwyr cwmwl yn caniatáu ichi leihau'r costau hyn; gallwch gael yr adnoddau sydd eu hangen arnynt yn gyflym ar gyfer gweithredu gwasanaethau yn y fan a'r lle, a thalu am yr adnoddau hyn ar ôl y ffaith. O ran cwmni URUS, byddwn yn aros yn ffyddlon i Kubernetes yn y cwmwl am y tro. Ond pwy a wyr, efallai y bydd yn rhaid i ni ehangu'n ddaearyddol, neu weithredu atebion yn seiliedig ar rai offer penodol. Neu efallai y bydd faint o adnoddau a ddefnyddir yn cyfiawnhau bod yn berchen ar Kubernetes ar fetel noeth, fel yn yr hen ddyddiau da. 🙂

Beth ddysgon ni o weithio gyda gwasanaethau cwmwl

Dechreuon ni ddefnyddio Kubernetes ar fetel noeth, a hyd yn oed yno roedd yn dda yn ei ffordd ei hun. Ond datgelwyd ei gryfderau yn union fel cydran aaS yn y cwmwl. Os byddwch chi'n gosod nod ac yn awtomeiddio popeth cymaint â phosib, byddwch chi'n gallu osgoi cloi i mewn i'r gwerthwr a bydd symud rhwng darparwyr cwmwl yn cymryd cwpl o oriau, a bydd y celloedd nerfol yn aros gyda ni. Gallwn gynghori cwmnïau eraill: os ydych chi am lansio'ch gwasanaeth (cwmwl) eich hun, gydag adnoddau cyfyngedig a chyflymder uchaf ar gyfer datblygu, dechreuwch ar hyn o bryd trwy rentu adnoddau cwmwl, ac adeiladwch eich canolfan ddata ar ôl i Forbes ysgrifennu amdanoch chi.

Ffynhonnell: hab.com

Ychwanegu sylw