Kompania «URUS» provoi Kubernetes në forma të ndryshme: vendosje të pavarur në bare metal, në Google Cloud, dhe më pas transferoi platformën e saj në cloud të Mail.ru Cloud Solutions (MCS). Si u zgjodh ofruesi i ri i cloud dhe si arritëm të migrojmë te ai për një rekord dy orë rrëfen Igor Shishkin (), administrator i lartë i sistemeve në «URUS».
ĂfarĂ« bĂ«n «URUS»
Ka shumĂ« mĂ«nyra pĂ«r tĂ« pĂ«rmirĂ«suar cilĂ«sinĂ« e ambientit urban, dhe njĂ« nga to Ă«shtĂ« ta bĂ«sh atĂ« ekologjikisht tĂ« sigurt. PikĂ«risht nĂ« kĂ«tĂ« punojnĂ« nĂ« kompaninĂ« «URUS â ShĂ«rbime digjitale inteligjente». KĂ«tu implementohen zgjidhje qĂ« ndihmojnĂ« bizneset tĂ« kontrollojnĂ« treguesit e rĂ«ndĂ«sishĂ«m ekologjikĂ« dhe tĂ« reduktojnĂ« ndikimin negativ nĂ« mjedis. SensorĂ«t mblidhni tĂ« dhĂ«na mbi pĂ«rbĂ«rjen e ajrit, nivelin e zhurmĂ«s dhe parametra tĂ« tjerĂ«, dhe pastaj i dĂ«rgojnĂ« ato nĂ« platformĂ«n e pĂ«rbashkĂ«t «URUS â Ekomon» pĂ«r analizĂ« dhe hartimin e rekomandimeve.
Si funksionon brenda «URUS»
Klienti tipik i «URUS» janë kompani që ndodhen në një zonë banimi ose afër saj. Kjo mund të jetë një fabrikë, port, depo hekurudhor ose ndonjë objekt tjetër. Nëse klienti ynë ka marrë tashmë një paralajmërim, është dënuar për ndotje të ambientit, ose dëshiron vetë të prodhojë më pak zhurmë dhe të reduktojë sasinë e emetimeve të dëmshme, ai vihet në kontakt me ne, dhe ne i ofrojmë një zgjidhje të gatshme për monitorimin ekologjik.
Në grafikun e monitorimit të koncentracionit të H2S, duket qartë emetimi i rregullt natën nga një kompani afër.
Pajisjet që përdorim në «URUS» përmbajnë disa sensore që mbledhin informacion mbi përmbajtjen e gazrave të caktuar, nivelin e zhurmës dhe të dhëna të tjera për vlerësimin e situatës ekologjike. Numri i saktë i sensorëve përcaktohet gjithmonë nga detyra specifike.
NĂ« varĂ«si tĂ« specifikave tĂ« matjeve, pajisjet me sensorĂ« mund tĂ« vendosen nĂ« muret e ndĂ«rtesave, shtyllat dhe nĂ« vende tĂ« tjera tĂ« rastit. Ădo pajisje e tillĂ« mbledh informacione, i agregon ato dhe i dĂ«rgon nĂ« portĂ«n e pranimit tĂ« tĂ« dhĂ«nave. Atje ne ruajmĂ« tĂ« dhĂ«nat pĂ«r ruajtje afatgjatĂ« dhe i pĂ«rpunojmĂ« ato pĂ«r analiza tĂ« mĂ«vonshme. NjĂ« shembull i thjeshtĂ« i asaj qĂ« ne marrim si rezultat pas analizĂ«s Ă«shtĂ« indeksi i cilĂ«sisĂ« sĂ« ajrit, i njohur ndryshe si AQI.
Paralelisht, në platformën tonë funksionojnë shumë shërbime të tjera, por kryesisht ato kanë karakter shërbimi. Për shembull, shërbimi i notifikimeve u dërgon klientëve njoftime nëse ndonjë nga parametrat e monitoruar (p.sh., përmbajtja e CO2) ka tejkaluar vlerën e lejuar.
Si i ruajmë të dhënat. Historia me Kubernetes në bare metal
NĂ« projektin e monitorimit tĂ« ekosistemĂ«ve «URUS» ekzistojnĂ« disa depo tĂ« dhĂ«nash. NĂ« njĂ« prej tyre mbajmĂ« tĂ« dhĂ«nat «e papĂ«rpunuara» â ato qĂ« kemi marrĂ« drejtpĂ«rdrejt nga pajisjet. Kjo depo pĂ«rbĂ«n njĂ« «tĂ« dhĂ«na magnetike», siç ishin kasetat e vjetra, me historikun e tĂ« gjithĂ« treguesve. Lloji i dytĂ« i depove pĂ«rdoret pĂ«r tĂ« dhĂ«na tĂ« pĂ«rpunuara paraprakisht â tĂ« dhĂ«na nga pajisjet, tĂ« pasuruara me metadata rreth lidhjeve tĂ« sensorĂ«ve dhe leximeve tĂ« vetĂ« pajisjeve, pĂ«rkatĂ«sisĂ« ndaj organizatave, vendeve tĂ« pozicionimit etj. KĂ«to informacione lejojnĂ« tĂ« vlerĂ«sojmĂ« nĂ« dinamikĂ« se si ka ndryshuar njĂ« tregues i caktuar pĂ«r njĂ« periudhĂ« tĂ« caktuar kohe. Depoja e tĂ« dhĂ«nave «tĂ« papĂ«rpunuara» pĂ«rdoret gjithashtu si njĂ« kopje rezervĂ« dhe pĂ«r rikuperimin e tĂ« dhĂ«nave tĂ« pĂ«rpunuara paraprakisht, nĂ« rast se do tĂ« lindĂ« njĂ« nevojĂ« e tillĂ«.
Kur disa vjet më parë, kur po kërkonim një zgjidhje për problemin e ruajtjes, bëmë zgjedhjen midis dy platformave: Kubernetes dhe OpenStack. Duke e parë se OpenStack duket mjaft i madh (mjafton të shikoni arkitekturën e tij për ta kuptuar), vendosëm të zgjidhnim Kubernetes. Një tjetër argument për të ishte menaxhimi i thjeshtë programor dhe mundësia për të ndarë edhe nodet fizike në mënyrë më fleksibël sipas burimeve.
PĂ«rveç mĂ«simit tĂ« Kubernetes, ne studiuam edhe metodat e ruajtjes sĂ« tĂ« dhĂ«nave. NdĂ«rsa mbajtĂ«m tĂ« gjitha magazinat tona nĂ« Kubernetes nĂ« harduerin tonĂ«, fituam njĂ« ekspertizĂ« tĂ« shkĂ«lqyer. Ădo gjĂ« qĂ« kishim atĂ«herĂ«, ishte pikĂ«risht nĂ« Kubernetes: magazinimi me gjendje, sistemi i monitoringut, CI/CD. Kubernetes u bĂ« pĂ«r ne njĂ« platformĂ« all-in-one.
Por ne dojmë si të punojmë me Kubernetes si një shërbim, jo të angazhohemi në mbështetje dhe zhvillim të tij. Për më tepër, nuk na pëlqente kostot që na shkaktonte në bare metal, ndërsa zhvillimi kërkohej vazhdimisht! Për shembull, një nga detyrat e para ishte të integroheshin kontrolluesit Ingress të Kubernetes në infrastrukturën tonë rrjetore. Kjo është një detyrë e ngarkuar, veçanërisht kur e mendon që në atë kohë nuk kishte asgjë të gatshme për menaxhimin programatik të burimeve si regjistrat DNS apo ndarjen IP-adresave. Më vonë, filluam të eksperimentojmë me ruajtjen e të dhënave të jashtme. Nuk arritëm kurrë të implementonim kontrolluesin PVC, por atëherë u bë e qartë se ishte një volum i madh pune, për të cilin duhej të angazhonim specialistë të veçantë.
Kalimi në Google Cloud Platform është një zgjidhje e përkohshme
Kuptuam se nuk mund të vazhdojmë kështu më tej, dhe transferuam të dhënat tona nga bare metal në Google Cloud Platform. Në të vërtetë, atëherë për një kompani ruse nuk kishte shumë mundësi interesante: përveç Google Cloud Platform, një shërbim të ngjashëm ofronte vetëm Amazon, por megjithatë ne zgjodhëm zgjidhjen nga Google. Atëherë na dukej se ishte më ekonomikisht e favorshme, më afër Upstream, pa përmendur se Google vetë është një lloj PoC Kubernetes në Prodhuese.
Problemi i parĂ« serioz u shfaq nĂ« horizont paralelisht me rritjen e bazĂ«s sonĂ« tĂ« klientĂ«ve. Kur na u shfaq nevoja pĂ«r tĂ« ruajtur tĂ« dhĂ«nat personale, u gjendĂ«m pĂ«rballĂ« njĂ« zgjedhjeje: ose punojmĂ« me Google dhe shkelim ligjet ruse, ose kĂ«rkojmĂ« njĂ« alternativĂ« brenda RF. Zgjedhja, nĂ« pĂ«rgjithĂ«si, ishte parashikueshme. đ
Si e shihnim shërbimin ideal në cloud
NĂ« fillim tĂ« kĂ«rkimeve ne tashmĂ« e dinim se çfarĂ« ishim duke kĂ«rkuar nga ofruesi i ardhshĂ«m tĂ« cloud. ĂfarĂ« shĂ«rbimi po kĂ«rkonim:
- Të shpejtë dhe fleksibël. Një që na lejon të shtojmë një nod të ri ose të zhvillojmë diçka në çdo moment.
- Të përballueshëm. Ne shqetësoheshim shumë për çështjen financiare, pasi ishim të kufizuar në burime. Tani e dinim që donim të punonim me Kubernetes, dhe tani sfida ishte minimalizimi i kostos së tij, për të rritur ose të paktën për të ruajtur efikasitetin e përdorimit të kësaj zgjidhjeje.
- Të automatizuar. Ne planifikonim të punonim me shërbimin përmes API, pa menaxherë dhe telefonata, apo situata ku na nevojitej të ngremë duar më shumë se njëzet nód në një mënyrë emergjente. Duke qenë se shumica e proceseve tona janë të automatizuara, këtë prisnim nga shërbimi në re.
- Me serverët në RF. Natyrisht, planifikonim të respektonim legjislacionin rus dhe ligjin 152-FZ.
NĂ« atĂ« kohĂ« kishte pak ofrues Kubernetes nĂ« modelin aaS nĂ« Rusi, dhe duke zgjedhur ofruesin, ishte e rĂ«ndĂ«sishme pĂ«r ne tĂ« mos merrnim kompromis me prioritetet tona. Ekipi i Mail.ru Cloud Solutions, me tĂ« cilin filluam tĂ« punonim dhe bashkĂ«punojmĂ« ende, na ofroi njĂ« shĂ«rbim tĂ« plotĂ« tĂ« automatizuar, me mbĂ«shtetje API dhe njĂ« panel tĂ« lehtĂ« menaxhimi, ku kishte Horizon â me tĂ« ne mund tĂ« ngrinim shpejt njĂ« numĂ«r tĂ« rastĂ«sishĂ«m nĂłd.
Si arritëm të migrojmë në MCS për dy orë
Gjatë këtyre migrimeve, shumë kompani përballen me vështirësi dhe dështime, por në rastin tonë nuk kishte asnjë. Patëm fat: pasi që përpara fillimit të migrimit, ne ishim duke punuar me Kubernetes, thjesht modifikuam tri skedarë dhe filluam shërbimet tona në platformën e re cloud, në MCS. Duke rikujtuar, deri atëherë kishim dalë plotësisht nga bare metal dhe ishim në Google Cloud Platform. Kështu, migrimi vetë zgjati jo më shumë se dy orë, plus pak kohë (rreth një orë) kaloi në kopjimin e të dhënave nga pajisjet tona. Atëherë ne ishim duke përdorur Spinnaker (shërbimi multi-cloud CD për të siguruar Continuos Delivery). E shtuam atë gjithashtu shpejt në klusterin e ri dhe vazhduam të punojmë në mënyrë të zakonshme.
FalĂ« automatizimit tĂ« proceseve tĂ« zhvillimit dhe CI/CD me Kubernetes, nĂ« âURUSâ merret njĂ« specialist (dhe ky jam unĂ«). NĂ« njĂ« fazĂ«, punoja me njĂ« administrator tjetĂ«r sistemesh, por mĂ« vonĂ« doli se tĂ« gjitha rutinat kryesore i kishim automatizuar dhe nga ana e produktit tonĂ« kryesor, detyrat po rriteshin, duke bĂ«rĂ« tĂ« arsyeshme tĂ« fokusohemi nĂ« ato.
Marrëdhënia jonë me ofruesin e shërbimeve në re është ashtu siç e prisnim, sepse filluam bashkëpunimin pa iluzione. Nëse kanë ndodhur ndonjë incident, ato ishin kryesisht teknike dhe të lehta për t'u shpjeguar për shkak të rinisë së shërbimit. E rëndësishme është që ekipi i MCS korrigjon shpejt gabimet dhe reagon shpejt në pyetje në mesazherë.
NĂ«se e krahasojmĂ« pĂ«rvojĂ«n me Google Cloud Platform, atje nuk dija as ku ndodhej butoni i reagimit, sepse thjesht nuk kishte nevojĂ« pĂ«r tĂ«. Dhe nĂ«se ndodhnin ndonjĂ« problem, Google vetĂ« dĂ«rgonte njoftime njĂ«anshĂ«m. Por nĂ« rastin e MCS, njĂ« pĂ«rfitim i madh Ă«shtĂ« qĂ« ata janĂ« sa mĂ« afĂ«r klientĂ«ve rusĂ« â dhe nĂ« aspektin territorial dhe mendor.
Si e shohim punën me re në të ardhmen
Tani do tĂ« bĂ«nim punĂ«n tonĂ« ngushtĂ« me Kubernetes, dhe ai plotĂ«sisht na kĂ«naq nĂ« aspektin e detyrave infrastrukturore. Prandaj, ne nuk planifikojmĂ« tĂ« migrojmĂ« ndonjĂ«herĂ« nga ai, megjithatĂ«, vazhdojmĂ« tĂ« vendosim praktika dhe shĂ«rbime tĂ« reja pĂ«r thjeshtimin e detyrave rutinĂ« dhe automatizimin e atyre tĂ« reja, duke rritur qĂ«ndrueshmĂ«rinĂ« dhe besueshmĂ«rinĂ« e shĂ«rbimeve... Tani ne po Đ·Đ°ĐżŃŃĐșĐ°mĂ« shĂ«rbimin Chaos Monkey (saktĂ«sisht, ne pĂ«rdorim chaoskube, por koncepti nuk ndryshon :), i cili fillimisht Ă«shtĂ« krijuar nĂ« Netflix. Chaos Monkey bĂ«n njĂ« gjĂ« tĂ« thjeshtĂ«: nĂ« çdo kohĂ« tĂ« rastit, heq njĂ« pod tĂ« rastĂ«sishĂ«m nĂ« Kubernetes. Kjo Ă«shtĂ« e nevojshme qĂ« shĂ«rbimi ynĂ« tĂ« funksionojĂ« normalisht me njĂ« numĂ«r instancash nâ1, kĂ«shtu qĂ« ne e trajnojmĂ« veten pĂ«r t'u pĂ«rgatitur pĂ«r çdo problem.
Tani do e shoh pĂ«rdorimin e zgjidhjeve tĂ« jashtme â si platforma tĂ« ndryshme cloud â si mĂ«nyra e vetme e saktĂ« pĂ«r kompanitĂ« e reja. Zakonisht, nĂ« fillim tĂ« rrugĂ«timit, ato janĂ« tĂ« kufizuara nĂ« burime, si njerĂ«zore ashtu edhe financiare, dhe ndĂ«rtimi dhe mirĂ«mbajtja e njĂ« cloud-i ose data center-i Ă«shtĂ« shumĂ« e shtrenjtĂ« dhe kĂ«rkon shumĂ« punĂ«. Ofruesit e cloud-it lejojnĂ« minimizimin e kĂ«tyre kostove, ata ofrojnĂ« burimet e nevojshme pĂ«r operimin e shĂ«rbimeve menjĂ«herĂ«, dhe paguhen pĂ«r kĂ«to burime sipas nevojĂ«s. Sa i pĂ«rket kompanisĂ« 'URUS', ne do tĂ« qĂ«ndrojmĂ« besnikĂ« Kubernetes nĂ« cloud pĂ«r momentin. Por kush e di, ndoshta do tĂ« na duhet tĂ« zgjeroheni gjeografikisht, ose tĂ« implementojmĂ« zgjidhje bazuar nĂ« pajisje tĂ« caktuara. Apo ndoshta sasia e burimeve tĂ« konsumuar do tĂ« justifikojĂ« njĂ« Kubernetes tĂ« vetĂ«-mbajtur nĂ« bare-metal, ashtu si nĂ« kohĂ«t e vjetra. đ
ĂfarĂ« nxorrĂ«m nga eksperienca me shĂ«rbimet cloud
Filluam pĂ«rdorimin e Kubernetes nĂ« bare metal, dhe madje atje ai ishte i shkĂ«lqyer nĂ« mĂ«nyrĂ«n e vet. Por pikat e tij tĂ« forta u zbuluan pikĂ«risht si njĂ« komponent aaS nĂ« cloud. NĂ«se vendosni njĂ« qĂ«llim dhe automatizoni çdo gjĂ«, do tĂ« evitoni vendor lock-in dhe kalimi midis ofruesve tĂ« cloud do tĂ« zgjasĂ« disa orĂ«, ndĂ«rsa qelizat nervore do tĂ« mbeten me ne. TĂ« tjerĂ«ve, mund t'u rekomandojmĂ«: nĂ«se dĂ«shironi tĂ« filloni shĂ«rbimin tuaj (cloud) me burime tĂ« kufizuara dhe me maksimalin e shpejtĂ«sisĂ« pĂ«r zhvillim â filloni tani me qira tĂ« burimeve cloud, dhe ndĂ«rtoni qendrĂ«n tuaj tĂ« tĂ« dhĂ«nave pasi Forbes tĂ« shkruajĂ« pĂ«r ju.
Burimi: habr.com
