Ndërsa punoni në IT, filloni të vini re se sistemet kanë karakterin e tyre. Ata mund të jenë fleksibël, të heshtur, të çuditshëm dhe të ashpër. Ata mund të tërheqin ose zmbrapsin. Në një mënyrë apo tjetër, ju duhet të "negocioni" me ta, të manovroni midis "grackave" dhe të ndërtoni zinxhirë të ndërveprimit të tyre.
Pra, ne patëm nderin të ndërtonim një platformë cloud, dhe për këtë na duhej të "bindnim" disa nënsisteme që të punonin me ne. Për fat të mirë, ne kemi një "gjuhë API", duar të drejtpërdrejta dhe shumë entuziazëm.
Ky artikull nuk do të jetë teknikisht i fortë, por do të përshkruajë problemet që kemi hasur gjatë ndërtimit të cloud. Vendosa të përshkruaj rrugën tonë në formën e një fantazie të lehtë teknike se si kërkuam një gjuhë të përbashkët me sistemet dhe çfarë doli prej saj.
Mirë se vini në mace.
Fillimi i një udhëtimi
Pak kohë më parë, ekipi ynë u ngarkua me lançimin e një platforme cloud për klientët tanë. Ne kishim mbështetje menaxheriale, burime, harduer dhe liri në zgjedhjen e teknologjive për të zbatuar pjesën softuerike të shërbimit.
Kishte gjithashtu një sërë kërkesash:
- shërbimi ka nevojë për një llogari personale të përshtatshme;
- platforma duhet të integrohet në sistemin ekzistues të faturimit;
- softueri dhe hardueri: OpenStack + Pëlhurë Tungsteni (Open Contrail), të cilën inxhinierët tanë kanë mësuar ta “gatojnë” mjaft mirë.
Ne do t'ju tregojmë një herë tjetër se si u mblodh ekipi, u zhvillua ndërfaqja e llogarisë personale dhe u morën vendimet e projektimit, nëse komuniteti Habra është i interesuar.
Mjetet që vendosëm të përdorim:
- Python + Flask + Swagger + SQLAlchemy - një grup plotësisht standard Python;
- Vue.js për frontend;
- Ne vendosëm të bëjmë ndërveprimin midis komponentëve dhe shërbimeve duke përdorur Selinon mbi AMQP.
Duke parashikuar pyetje në lidhje me zgjedhjen e Python, unë do të shpjegoj. Gjuha ka gjetur vendin e saj në shoqërinë tonë dhe rreth saj është zhvilluar një kulturë e vogël, por ende. Prandaj, u vendos që të fillojë ndërtimi i shërbimit mbi të. Për më tepër, shpejtësia e zhvillimit në probleme të tilla është shpesh vendimtare.
Pra, le të fillojmë njohjen tonë.
Fatura e heshtur - faturimi
Ne e njohim këtë djalë për një kohë të gjatë. Ai ulej gjithmonë pranë meje dhe numëronte në heshtje diçka. Ndonjëherë ai na përcillte kërkesat e përdoruesve, lëshonte fatura klientësh dhe menaxhonte shërbime. Një djalë i zakonshëm punëtor. Vërtetë, kishte vështirësi. Ai është i heshtur, ndonjëherë i menduar dhe shpesh në mendjen e tij.
Faturimi është sistemi i parë me të cilin u përpoqëm të miqësoheshim. Dhe vështirësia e parë që hasëm ishte gjatë përpunimit të shërbimeve.
Për shembull, kur krijohet ose fshihet, një detyrë shkon në radhën e brendshme të faturimit. Kështu, zbatohet një sistem i punës asinkrone me shërbimet. Për të përpunuar llojet e shërbimeve tona, na duhej të "vendosnim" detyrat tona në këtë radhë. Dhe këtu kemi hasur në një problem: mungesë dokumentacioni.
Duke gjykuar nga përshkrimi i API-së së softuerit, është ende e mundur të zgjidhet ky problem, por ne nuk patëm kohë për të bërë inxhinieri të kundërt, kështu që ne e morëm logjikën jashtë dhe organizuam një radhë detyrash në krye të RabbitMQ. Një operacion në një shërbim inicohet nga klienti nga llogaria e tij personale, kthehet në një "detyrë" Selino në pjesën e pasme dhe kryhet në anën e faturimit dhe OpenStack. Selino e bën mjaft të përshtatshëm menaxhimin e detyrave, organizimin e përsëritjeve dhe monitorimin e statusit. Ju mund të lexoni më shumë rreth "selinos", për shembull, .
Gjithashtu, faturimi nuk ndaloi një projekt që mbeti pa para. Duke komunikuar me zhvilluesit, zbuluam se gjatë llogaritjes së statistikave (dhe ne duhet të zbatojmë pikërisht këtë lloj logjike), ekziston një ndërlidhje komplekse e rregullave të ndalimit. Por këto modele nuk përshtaten mirë me realitetet tona. Ne gjithashtu e zbatuam atë përmes detyrave në Celery, duke e çuar logjikën e menaxhimit të shërbimit në anën e pasme.
Të dyja problemet e mësipërme bënë që kodi të bëhej pak i fryrë dhe në të ardhmen do të na duhet të rifaktorojmë në mënyrë që të zhvendosim logjikën e punës me detyrat në një shërbim të veçantë. Ne gjithashtu duhet të ruajmë disa informacione rreth përdoruesve dhe shërbimeve të tyre në tabelat tona për të mbështetur këtë logjikë.
Një problem tjetër është heshtja.
Billy i përgjigjet në heshtje "Ok" për disa kërkesa për API. Ky ishte rasti, për shembull, kur bëmë pagesat e pagesave të premtuara gjatë testit (më shumë për këtë më vonë). Kërkesat janë ekzekutuar në mënyrë korrekte dhe nuk kemi parë asnjë gabim.
Më duhej të studioja regjistrat gjatë punës me sistemin përmes UI. Doli që vetë faturimi kryen kërkesa të ngjashme, duke ndryshuar fushëveprimin tek një përdorues specifik, për shembull, administratori, duke e kaluar atë në parametrin su.
Në përgjithësi, pavarësisht boshllëqeve në dokumentacion dhe gabimeve të vogla në API, gjithçka shkoi mjaft mirë. Regjistrat mund të lexohen edhe nën ngarkesë të madhe nëse e kuptoni se si janë të strukturuara dhe çfarë të kërkoni. Struktura e bazës së të dhënave është e zbukuruar, por mjaft logjike dhe në një farë mënyre edhe tërheqëse.
Pra, për të përmbledhur, problemet kryesore që kemi hasur në fazën e ndërveprimit lidhen me tiparet e zbatimit të një sistemi specifik:
- “karakteristika” të padokumentuara që na ndikuan në një mënyrë ose në një tjetër;
- burim i mbyllur (faturimi është shkruar në C++), si rezultat - është e pamundur të zgjidhet problemi 1 në asnjë mënyrë tjetër përveç "provës dhe gabimit".
Për fat të mirë, produkti ka një API mjaft të gjerë dhe ne kemi integruar nënsistemet e mëposhtme në llogarinë tonë personale:
- Moduli i mbështetjes teknike - kërkesat nga llogaria juaj personale janë “të përafruara” në faturim transparent për klientët e shërbimit;
- moduli financiar - ju lejon të lëshoni fatura për klientët aktualë, të bëni fshirje dhe të gjeneroni dokumente pagese;
- moduli i kontrollit të shërbimit - për këtë ne duhej të zbatonim mbajtësin tonë. Zgjerimi i sistemit luajti në duart tona dhe ne "i mësuam" Billit një lloj të ri shërbimi.
Ishte pak sherr, por në një mënyrë apo tjetër, mendoj se unë dhe Billi do të shkojmë mirë.
Duke ecur nëpër fusha tungsteni - Pëlhurë Tungsteni
Fushat e tungstenit të mbushura me qindra tela, duke kaluar mijëra pjesë informacioni përmes tyre. Informacioni mblidhet në "pako", analizuar, duke ndërtuar rrugë komplekse, si me magji.
Ky është domeni i sistemit të dytë me të cilin na është dashur të miqësohemi - Pëlhura Tungsteni (TF), dikur OpenContrail. Detyra e tij është të menaxhojë pajisjet e rrjetit, duke ofruar një abstraksion softueri për ne si përdorues. TF - SDN, përmbledh logjikën komplekse të punës me pajisjet e rrjetit. Ekziston një artikull i mirë për vetë teknologjinë, për shembull, .
Sistemi është i integruar me OpenStack (diskutuar më poshtë) nëpërmjet shtojcës Neutron.
Ndërveprimi i shërbimeve OpenStack.
Djemtë nga departamenti i operacioneve na njohën me këtë sistem. Ne përdorim API-në e sistemit për të menaxhuar grupin e rrjetit të shërbimeve tona. Nuk na ka shkaktuar ende ndonjë problem apo shqetësim serioz (nuk mund të flas për djemtë nga OE), por ka pasur disa çudira në ndërveprim.
E para dukej kështu: komandat që kërkonin daljen e një sasie të madhe të të dhënave në tastierën e shembullit kur lidheshin me SSH thjesht "e mbyllnin" lidhjen, ndërsa përmes VNC gjithçka funksiononte si duhet.
Për ata që nuk janë të njohur me problemin, duket mjaft qesharake: ls /root funksionon si duhet, ndërsa, për shembull, pjesa e sipërme "ngrihet" plotësisht. Për fat të mirë, ne kemi hasur probleme të ngjashme edhe më parë. U vendos duke akorduar MTU në rrugën nga nyjet llogaritëse te ruterat. Nga rruga, ky nuk është një problem TF.
Problemi tjetër ishte afër qoshes. Në një moment të “bukur”, magjia e rrugëtimit u zhduk, pikërisht ashtu. TF ka ndaluar menaxhimin e rrugëzimit në pajisje.
Ne kemi punuar me Openstack nga niveli i administratorit dhe më pas kaluam në nivelin e kërkuar të përdoruesit. SDN duket se "rrëmben" hapësirën e përdoruesit nga i cili kryhen veprimet. Fakti është se e njëjta llogari administratori përdoret për të lidhur TF dhe OpenStack. Në hapin e kalimit te përdoruesi, "magjia" u zhduk. U vendos të krijohej një llogari e veçantë për të punuar me sistemin. Kjo na lejoi të punonim pa prishur funksionalitetin e integrimit.
Silicon Lifeforms - OpenStack
Një krijesë silikoni me formë të çuditshme jeton pranë fushave të tungstenit. Mbi të gjitha, duket si një fëmijë i rritur që mund të na shtypë me një lëkundje, por nuk ka asnjë agresion të dukshëm që vjen prej tij. Nuk shkakton frikë, por madhësia e tij ngjall frikë. Ashtu si kompleksiteti i asaj që po ndodh përreth.
OpenStack është thelbi i platformës sonë.
OpenStack ka disa nënsisteme, nga të cilat aktualisht përdorim më aktivisht Nova, Glance dhe Cinder. Secila prej tyre ka API-në e vet. Nova është përgjegjëse për burimet llogaritëse dhe krijimin e rasteve, Cinder është përgjegjëse për menaxhimin e vëllimeve dhe fotografive të tyre, Glance është një shërbim imazhi që menaxhon shabllonet e OS dhe metainformacionet mbi to.
Çdo shërbim funksionon në një kontejner, dhe ndërmjetësi i mesazheve është "lepuri i bardhë" - RabbitMQ.
Ky sistem na dha telashet më të papritura.
Dhe problemi i parë nuk vonoi kur u përpoqëm të lidhnim një vëllim shtesë me serverin. Cinder API refuzoi kategorikisht të kryente këtë detyrë. Më saktësisht, nëse besoni vetë OpenStack, lidhja është krijuar, por nuk ka pajisje disk brenda serverit virtual.
Ne vendosëm të bënim një devijim dhe kërkuam të njëjtin veprim nga Nova API. Rezultati është që pajisja lidhet saktë dhe është e aksesueshme brenda serverit. Duket se problemi ndodh kur ruajtja e bllokut nuk i përgjigjet Cinder.
Një tjetër vështirësi na priste kur punonim me disqe. Vëllimi i sistemit nuk mund të shkëputej nga serveri.
Përsëri, vetë OpenStack "betohet" se ka shkatërruar lidhjen dhe tani mund të punoni saktë me volumin veç e veç. Por API kategorikisht nuk donte të kryente operacione në disk.
Këtu vendosëm të mos luftonim veçanërisht, por të ndryshonim pikëpamjen tonë për logjikën e shërbimit. Nëse ka një shembull, duhet të ketë gjithashtu një vëllim të sistemit. Prandaj, përdoruesi nuk mund të heqë ose çaktivizojë ende "diskun" e sistemit pa fshirë "serverin".
OpenStack është një grup mjaft kompleks sistemesh me logjikën e vet të ndërveprimit dhe API të zbukuruar. Ne ndihmohemi nga dokumentacioni mjaft i detajuar dhe, natyrisht, prova dhe gabimi (ku do të ishim pa të).
Vrapimi testues
Ne kryem një nisje provë në dhjetor të vitit të kaluar. Detyra kryesore ishte të testonim projektin tonë në modalitetin luftarak nga ana teknike dhe nga ana UX. Publiku u ftua në mënyrë selektive dhe testimi u mbyll. Megjithatë, ne kemi lënë gjithashtu opsionin për të kërkuar qasje në testim në faqen tonë të internetit.
Vetë testi, natyrisht, nuk ishte pa momentet e tij qesharake, sepse këtu sapo kanë filluar aventurat tona.
Së pari, ne vlerësuam disi gabimisht interesin për projektin dhe duhej të shtonim shpejt nyjet llogaritëse pikërisht gjatë testit. Një rast i zakonshëm për një grup, por kishte edhe disa nuanca këtu. Dokumentacioni për një version specifik të TF tregon versionin specifik të kernelit në të cilin është testuar puna me vRouter. Ne vendosëm të nisnim nyjet me kernele më të fundit. Si rezultat, TF nuk mori rrugë nga nyjet. Më duhej të ktheja urgjentisht bërthamat.
Një kuriozitet tjetër lidhet me funksionalitetin e butonit “ndrysho fjalëkalimin” në llogarinë tuaj personale.
Ne vendosëm të përdorim JWT për të organizuar qasjen në llogarinë tonë personale në mënyrë që të mos punojmë me sesione. Meqenëse sistemet janë të ndryshme dhe të shpërndara gjerësisht, ne menaxhojmë tokenin tonë, në të cilin "mbështjellim" seancat nga faturimi dhe një token nga OpenStack. Kur ndryshohet fjalëkalimi, token, natyrisht, "shkohet keq", pasi të dhënat e përdoruesit nuk janë më të vlefshme dhe duhet të ribotohen.
Ne e humbëm nga sytë këtë pikë dhe thjesht nuk kishte burime të mjaftueshme për ta përfunduar me shpejtësi këtë pjesë. Na u desh të shkëputnim funksionalitetin pak para nisjes së testit.
Aktualisht ne dalim nga përdoruesi nëse fjalëkalimi është ndryshuar.
Pavarësisht këtyre nuancave, testimi shkoi mirë. Në dy javë, rreth 300 njerëz ndaluan. Ne ishim në gjendje ta shikonim produktin përmes syve të përdoruesve, ta testonim atë në veprim dhe të mblidhnim komente me cilësi të lartë.
Për të vazhduar
Për shumë prej nesh, ky është projekti i parë i kësaj shkalle. Mësuam një sërë mësimesh të vlefshme se si të punojmë si ekip dhe të marrim vendime arkitektonike dhe dizajni. Si të integroni sisteme komplekse me pak burime dhe t'i futni ato në prodhim.
Sigurisht, ka diçka për të punuar si në aspektin e kodit ashtu edhe në ndërfaqet e integrimit të sistemit. 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.
Ne kemi qenë tashmë në gjendje të bindim sistemet. Bill trajton me kujdes numërimin, faturimin dhe kërkesat e përdoruesve në dollapin e tij. "Magjia" e fushave të tungstenit na siguron komunikim të qëndrueshëm. Dhe vetëm OpenStack ndonjëherë bëhet kapriçioz, duke bërtitur diçka si "'WSREP nuk ka përgatitur ende nyjen për përdorim të aplikacionit." Por kjo është një histori krejtësisht tjetër ...
Së fundmi kemi nisur shërbimin.
Të gjitha detajet mund t'i mësoni në faqen tonë .
Ekipi i zhvillimit të CLO
Lidhje të dobishme
OpenStack
Pëlhurë tungsteni
Burimi: www.habr.com