🥇Historia e krijimit të shërbimit cloud, e përgatitur me cyberpunk

Me rritjen e përvojës në IT, fillon të vëresh se sistemet kanë karakterin e tyre. Ato mund të jenë të qeta, të heshtura, të çmendura, të ashpra. Ato mund të tërheqin ose të largojnë. Në një mënyrë apo tjetrën, duhet të "kesh biseda" me to, të manovrosh midis "kërcënimeve" dhe të ndërtojnë lidhjet e tyre të bashkëpunimit.

Kështu që na është dhënë nderi të ndërtojmë një platformë cloud, dhe për këtë na duhej të "bindim" disa nën-sisteme që të punonin me ne. Fatmirësisht, ne kemi "gjuhën API", duar të drejta dhe një mori entuziazmi.

Në këtë artikull nuk do të kemi të bëjmë me ashpërsinë teknike, por do të përshkruajmë problemet me të cilat u përballëm gjatë ndërtimit të cloud-it. Kam vendosur ta përshkruaj rrugën tonë në formën e një fantazie teknike të lehtë mbi mënyrën se si kërkuam gjuhën e përbashkët me sistemet dhe çfarë dolën prej saj.

Mirë se vini nën artikull.

Fillimi i rrugës

Disa kohë më parë, ekipi ynë u ngarkua me detyrën — të nisë një platformë cloud për klientët tanë. Në dispozicion ishim mbështetje nga drejtuesit, burime, një grumbull hardware dhe liri në zgjedhjen e teknologjive për realizimin e pjesës softuerike të shërbimit.

Ishte gjithashtu një sërë kërkesash:

shërbimi iu nevojitet një panel i lehtë për t'u përdorur;
platforma duhet të integrohet në sistemin ekzistues të faturimit;
pjesa software-hardware: OpenStack + Tungsten Fabric (Open Contrail), të cilat inxhinierët tanë mësuan të "gatuajnë" mjaft mirë.

Për mënyrën se si u mblodh ekipi, u zhvillua ndërfaqja e përdoruesit dhe u morën vendime dizajni, do të flasim herën tjetër, nëse komuniteti i Habrës do të ketë interes.
Instrumentet që vendosëm të përdorim:

Python + Flask + Swagger + SQLAlchemy — një grup standard Python;
Vue.js për frontend-in;
ndërveprimin midis komponentëve dhe shërbimeve vendosëm ta bëjmë me Celery mbi AMQP.

Për të parashikuar pyetjet rreth zgjedhjes së Python, shpjegoj. Gjuha ka marrë një pozitë në kompaninë tonë dhe rreth saj është ndërtuar një kulturë e vogël, por megjithatë e rëndësishme. Prandaj, u vendos të fillonim ndërtimin e shërbimit pikërisht në të. Veçanërisht, sepse shpejtësia e zhvillimit në këto detyra shpesh është vendimtare.

Pra, le të fillojmë njohjen tonë.

Bill i heshtur — faturimi

Me këtë djalë ishim njohur prej kohësh. Ai gjithmonë qëndronte afër dhe numëronte diçka në heshtje. Ndonjëherë na dërgonte kërkesat e përdoruesve, lëshonte faturat e klientëve, menaxhonte shërbimet. Një djalë i zakonshëm punëtor. Megjithatë, kishte vështirësi. Ai është i heshtur, ndonjëherë i menduar dhe shpesh — në mendimet e tij.

Faturimi është sistemi i parë me të cilin u përpoqëm të bëjmë miqësi. Dhe vështirësia e parë na u paraqit gjatë përpunimit të shërbimeve.

Për shembull, kur krijohet ose fshihet, detyra shkon në radhën e brendshme të faturimit. Kjo është mënyra se si realizohet sistemi i punës asinkrone me shërbimet. Për të përpunuar tipet tona të shërbimeve, na duhej të "ngjitim" detyrat tona në këtë radhë. Dhe këtu u përballëm me problemin: mungesa e dokumentacionit.

Sipas përshkrimit të API-së software, zgjidhja e këtij problemi është e mundur, por nuk kishim kohë të merremi me inxhinierinë e zëvendësimit, prandaj e nxorrëm logjikën jashtë dhe organizuam një radhë detyrash mbi RabbitMQ. Operacioni mbi shërbimin inicohet nga klienti nga paneli i tij personal, i mbështjellë në një "detyrë" Celery në backend dhe ekzekutohet në anën e faturimit dhe OpenStack-it. Celery lejon menaxhimin mjaft të rehatshëm të detyrave, organizimin e ripërsëritjeve dhe ndjekjen e gjendjes. Më shumë mbi "selarin" mund të lexoni, për shembull, këtu.

Gjithashtu, faturimi nuk e ndalonte projektin, në të cilin kishin mbaruar fondet. Duke biseduar me zhvilluesit, zbuluam se gjatë llogaritjeve të statistikave (dhe na duhet të realizojmë pikërisht një logjikë të tillë) ka një lidhje të komplikuar rregullash ndalimi. Por këto modele nuk përputhen mirë me realitetin tonë. Po ashtu, e realizuam përmes detyrave në Celery, duke marrë në anën e backend-it logjikën e menaxhimit të shërbimeve.

Të dy problemet e mësipërme çuan në atë që kodi u fry më tepër dhe ne në të ardhmen do të na duhet të merremi me rrethin e tij, për të nxjerrë logjikën e punës me detyrat në një shërbim të veçantë. Ne gjithashtu duhet të ruajmë një pjesë të informacionit rreth përdoruesve dhe shërbimeve të tyre në tabelat tona, për të mbështetur këtë logjikë.

Një tjetër problem është heshtja.

Për disa kërkesa në API, Bill heshtur përgjigjet "Ok". Kështu ka ndodhur, kur ne bëmë regjistrimet e pagesave të premtuara gjatë testit (për të cilin do të flasim më vonë). Kërkesat u ekzekutuan saktë dhe ne nuk pamë gabime.

Na duhej të studionim logët, duke punuar me sistemin përmes UI. Doli se faturimi vetë kryen kërkesa të tilla, duke ndryshuar skopin për një përdorues të caktuar, për shembull, admin, duke e kaluar atë në parametrin su.

Në përgjithësi, megjithëse ka disa mungesa në dokumentacion dhe disa gabime të vogla në API, gjithçka ka shkuar mjaft mirë. Loget mund të lexohen edhe nën ngarkesë të madhe, për sa kohë që kupton si janë strukturuar dhe çfarë duhet të kërkosh. Struktura e bazës së të dhënave është e ndërlikuar, por mjaft logjike dhe në disa aspekte mjaft të tërheqëse.

Pra, përmbledhjeve, problemet kryesore që na kanë dalë përpara gjatë fazës së ndërveprimit lidhen me veçoritë e implementimit të sistemit të caktuar:

veçori të pa dokumentuara, të cilat na ndikonin në mënyrë të ndryshme;
kodet e mbyllura (blloku është shkruar në C++), si pasojë — pamundësia për të zgjidhur problemin 1 në asnjë mënyrë tjetër veç 'metodës së provave dhe gabimeve'.

Fatmirësisht, produkti ka një API mjaft të gjerë dhe ne integrojmë në panelin tonë personal sistemet e mëposhtme:

moduli i mbështetjes teknik — kërkesat nga paneli personal ‘prokurohen’ në bllokimin e faturave në mënyrë të dukshme për klientët e shërbimit;
moduli financiar — lejon lëshimin e faturave për klientët aktualë, të bëjë shkarkime dhe të formojë dokumente pagese;
moduli i menaxhimit të shërbimeve — për të, na duhej të implementonim një trajtues të ri. Zgjerueshmëria e sistemit na ndihmoi dhe ne ‘mësuam’ Billie për një lloj të ri shërbimesh.
Na duhej të punonim, por në një farë mënyre, mendoj se me Billie do t’i biem në përputhje.

Shëtitjet në fushat tungsten — Tungsten Fabric

Fushat tungsten, të mbushura me qindra kabuj që kalojnë mijëra bit-e informacioni. Informacioni mbledhët në ‘paketa’, analizohet, duke ndërtuar rrugë të ndërlikuara, si me magji.

Kjo është mbretëria e sistemit të dytë, me të cilin duhej të bashkëpunonim — Tungsten Fabric (TF), i njohur më parë si OpenContrail. Detyra e tij është të menaxhojë pajisjet rrjetërore, duke ofruar një abstraksion softuerik për ne, si përdorues. TF është SDN, inkorporon logjikën e ndërlikuar të punës me pajisjet rrjetërore. Për teknologjinë vetë ka një artikull të mirë, për shembull, këtu.

Sistemi është i integruar me OpenStack (për të do të flasim më poshtë) përmes një plani të Neutron.

Ndërveprimi i shërbimeve OpenStack.

Këtë sistem na e prezantuan djemtë nga departamenti i operacioneve. Ne përdorim API-në e sistemit për të menaxhuar rrjetin tonë të shërbimeve. Nuk kemi pasur probleme të mëdha ose shqetësime këtu (nuk do marr përsipër të flas për djemtë nga OE), megjithatë ka pasur disa situata komike gjatë ndërveprimit.

E para dukej kështu: komandat që kërkonin të nxirrnin një sasi të madhe të dhënash në konsolën e instancës gjatë lidhjes përmes SSH thjesht ‘bllokonin’ lidhjen, ndërkohë që përmes VNC gjithçka funksiononte normalisht.

Për ata që nuk e njohin problemin, kjo duket mjaft qesharake: ls /root funksionon siç duhet, ndonëse, për shembull, top ‘ngrihet’ deri në bllokim. Fatmirësisht, ne kishim hasur në probleme të ngjashme më parë. Kjo u zgjidh me tunimin e MTU-së në rrugën nga nodet e llogaritjes deri te ruterat. Për ta thënë ndryshe, kjo nuk ishte as një problem për TF.

Problemi tjetër na priste pas kthesës. Në një moment ‘të mrekullueshëm’ magia e rrugëzimit kishte zhdukur, aq thjesht. TF ndali menaxhimin e rrugëzimit në pajisjet.

Ne punuam me OpenStack nga niveli admin dhe më pas kaluam në nivelin e përdoruesit të nevojshëm. SDN, duket se ‘kap’ skopin e përdoruesit me të cilin veprohet. Çështja është se ky llogari admini përdoret për lidhjen mes TF dhe OpenStack. Në hapin e kalimit tek përdoruesi ‘magjia’ humbiste. U zgjidh të hapim një llogari të veçantë për punë me sistemin. Kjo lehtësoi punën, pa prishur funksionalitetin e integrimit.

Forma të silikonit — OpenStack

Një krijesë silikoni në formën e çuditshme jeton afër fushave tungsten. Më shumë duket si një fëmijë gjigant që me një gjest mund të na shkatërrojë, por nuk lëshon asnjë agresivitet të dukshëm. Nuk shfaq frikë, por përmasat e tij ngjallin shqetësim. Ashtu si edhe kompleksiteti i asaj që ndodh rreth tij.

OpenStack është thelbi i platformës sonë.

OpenStack ka disa nën-sisteme, nga të cilat ne për momentin përdorim më aktivisht Nova, Glance dhe Cinder. Çdo njëra prej tyre ka API të saj. Nova përgjigjet për burimet e llogaritjes dhe krijimin e instancave, Cinder — për menaxhimin e volumëve dhe imazheve të tyre, Glance — shërbimi i imazheve, i cili menaxhon shabllonet e OS dhe metainformacionin për to.

Çdo shërbim aktivizohet në një kontenier, dhe brokeri i mesazheve është ‘krolja e bardhë’ — RabbitMQ.

Ky sistem na ka sjellë më shumë shqetësime të papritura.

Dhe problemi i parë nuk vonoi të shfaqej, kur përpiqeshim të lidhnim një volum shtesë me serverin. API i Cinder refuzonte kategorikisht të realizonte këtë detyrë. Më saktë, nëse besojmë OpenStack, lidhja vendoset, megjithatë brenda serverit virtual pajisja e diskut mungon.

Ne vendosëm t'i shkojmë një rruge tjetër dhe kërkuam të njëjtin veprim nga Nova API. Rezultati - pajisja lidhet siç duhet dhe është e aksesueshme brenda serverit. Duket se problemi ndodh kur block-storage nuk përgjigjet Cinder-it.

Një sfidë tjetër na priste gjatë punës me diskët. Volume sistemik nuk arrinte të shkëputej nga serveri.

Gjithashtu, vetë OpenStack 'premton' se ka shkatërruar lidhjen dhe tani është e mundur të punosh me volume-n veçmas. Por API refuzonte kategorikisht të kryente operacione mbi diskun.

Këtu vendosëm të mos luftojmë shumë, por të ndryshojmë pikëpamjen mbi logjikën e funksionimit të shërbimit. Nëse ka një instance, duhet të ketë edhe një volume sistemik. Prandaj përdoruesi për momentin nuk mund të fshijë ose të shkëputë disku ‘sistemik’ pa fshirë ‘serverin’.

OpenStack është një kompleks sistemesh mjaft i komplikuar me logjikën e tij të ndërveprimit dhe API të ndërlikuar. Dokumentacioni mjaft i detajuar na ndihmon, dhe sigurisht, metoda e provave dhe gabimeve (ku ta di) është e nevojshme.

Testim fillestar

Testimi fillestar e bëmë në dhjetor të vitit të kaluar. Qëllimi kryesor ishte të kontrollonim në mënyrë operative projektin tonë nga ana teknike dhe nga ana e UX. Audienca u ftuar në mënyrë selektive dhe testimi ishte i mbyllur. Megjithatë, ne gjithashtu lanë mundësinë për të kërkuar akses për testim në faqen tonë.

Testi, natyrisht, nuk kaloi pa momente kurioze, pasi aventura jonë sapo kishte filluar.

Së pari, ne vlerësuam disi pasaktë interesin për projektin dhe na duhej të shtojmë node compute pikërisht në kohë gjatë testit. Një rast normal për klaster, megjithatë kishte edhe këtu nuanca. Në dokumentacionin për versionin specifik të TF, është e caktuar një version i veçantë i kernelit, mbi të cilin ishte testuar funksionimi me vRouter. Ne vendosëm të fillojmë node me kernela më të rinj. Si pasojë - TF nuk mori rrugët nga node. Duhej të rikthenim urgjentisht kernelin.

Një tjetër incident është lidhur me funksionalitetin e butonit ‘ndrysho fjalëkalimin’ në panelin personal.

Vendosëm të përdorim JWT për të organizuar aksesin në panelin personal, për të mos punuar me sesionet. Përderisa sistemet janë shumë të larmishme dhe të shpërndara, ne menaxhojmë token-in tonë, në të cilin ‘ndërtojmë’ sesionet nga faturimi dhe token nga OpenStack. Kur ndryshohet fjalëkalimi, token-i, sigurisht, ‘skadon’, pasi të dhënat e përdoruesit tashmë nuk janë të vlefshme dhe duhet të ri-lëshohet.

E humbëm këtë moment nga vëmendja, dhe nuk kishim burime për të shkruar shpejt këtë pjesë. Na duhej të hiqnim funksionalitetin pikërisht para se të fillonim testin.
Në këtë moment, ne kryejmë logout për përdoruesin, nëse është ndryshuar fjalëkalimi.

Pavarësisht këtyre nuancave, testimi kaloi mirë. Gjatë disa javëve rreth 300 njerëz na vizituan. Na arriti të shihnim produktin nga këndvështrimi i përdoruesve, ta testonim në betejë dhe të mbledhim feedback të dobishëm.

Vazhdon

Për shumicën nga ne, ky është projekti i parë i këtij përmasash. Ne nxorëm disa mësime të vlefshme rreth mënyrës se si të punojmë në ekip, të marrim vendime arkitekturore dhe dizajnuese. Si të integrojmë sisteme të komplikuara me burime të pakta dhe t’i nxjerrim ato në prodhim.

Sigurisht, ka shumë për të punuar në lidhje me kodin dhe në ndërprerjet e integrimit të sistemeve. Projekti është mjaft i ri, por ne jemi plot ambicie për ta rritur atë në një shërbim të besueshëm dhe të përshtatshëm.

Sistemet tashmë i kemi bindur. Billi angazhohet me përllogaritjet, lëshimin e faturave dhe kërkesat e përdoruesve në dhomën e tij. ‘Magjia’ e fushave të tungstenit na ofron një lidhje të qëndrueshme. Dhe vetëm OpenStack ndonjëherë bën kapriçio, duke thënë diçka si ‘WSREP ende nuk e ka përgatitur node për përdorim aplikacioni’. Por kjo është një histori krejt tjetër...

Kohët e fundit filluam shërbimin.
Të gjitha detajet mund të mësoni në të internetit.

Ekipi i zhvillimit CLO