🥇Príbeh vzniku cloudovej služby s nádychom kyberpunku

S rastom skúseností v IT začínaš vnímať, že systémy majú svoj charakter. Môžu byť poddajné, tiché, výstredné, prísne. Môžu ťa prilákať alebo odradiť. Tak či onak, treba sa s nimi "dohodnúť", manévrovať medzi "nebezpečnými miestami" a vybudovať reťazce ich interakcií.

Tak nám bola zverená česť vybudovať cloudovú platformu, a na to bolo potrebné "presvedčiť" pár pod systémov, aby s nami spolupracovali. Našťastie máme "jazyk API", zručné ruky a kopu nadšenia.

V tomto článku nebude technický hardcore, ale bude popis problémov, s ktorými sme sa stretli pri budovaní cloudu. Rozhodol som sa popísať našu cestu formou ľahkej technickej fantázie o tom, ako sme hľadali spoločný jazyk so systémami a čo z toho vzišlo.

Vitajte pod článkom.

Začiatok cesty

Pred časom bola pred naším tímom stanovená úloha - spustiť cloudovú platformu pre našich klientov. Mali sme podporu vedenia, zdroje, hardvérový stack a slobodu pri výbere technológií na realizáciu softvérovej časti služby.

Taktiež existoval rad požiadaviek:

službe je potrebný pohodlný osobný účet;
platforma musí byť integrovaná do existujúceho systému fakturácie;
softvérovo-hardvérová časť: OpenStack + Tungsten Fabric (Open Contrail), ktoré naši inžinieri naučili dostatočne dobre "pripravovať".

O tom, ako sa tím zhromaždil, vyvíjal rozhranie osobného účtu a prijímal dizajnérske rozhodnutia, sa zmienime inokedy, ak bude záujem zo strany komunity Habr.
Nástroje, ktoré sme sa rozhodli použiť:

Python + Flask + Swagger + SQLAlchemy - celkom štandardná sada Pythonu;
Vue.js pre front-end;
interakciu medzi komponentami a službami sme sa rozhodli realizovať pomocou Celery nad AMQP.

Predvídam otázky o výbere Pythonu, vysvetlím. Jazyk si našiel svoje miesto v našej spoločnosti a okolo neho sa vytvorila malá, ale predsa len kultúra. Preto sa rozhodlo začať budovať službu práve na ňom. O to viac, že rýchlosť vývoja v takýchto úlohách často rozhoduje.

Tak začneme naše zoznámenie.

Tichý Bill - fakturácia

S týmto chlapcom sme sa poznali už dávno. Vždy sedel vedľa a niečo potichu počítal. Niekedy nám posielal požiadavky používateľov, vystavoval faktúry a spravoval služby. Bežný pracovitý chlapec. Pravda, mali sme problémy. Bol tichý, niekedy zamyslený a často mal svoje vlastné myšlienky.

Billing je prvý systém, s ktorým sme sa snažili skamarátiť. A prvá ťažkosť sa nám objavila pri spracovaní služieb.

Napríklad, keď sa vytvára alebo odstraňuje úloha, dostane sa do interného frontu billing systému. Takto je realizovaný systém asynchrónnej práce so službami. Na spracovanie našich typov služieb sme museli „pridávať“ naše úlohy do tohto frontu. Tu sme sa stretli s problémom: nedostatok dokumentácie.

Súdząc podľa popisu programového API, túto úlohu je predsa možné vyriešiť, ale nemali sme čas na reverzné inžinierstvo, preto sme vyviedli logiku von a zorganizovali front úloh nad RabbitMQ. Operácia nad službou je iniciovaná klientom z osobného účtu, zabalí sa do „úlohy“ Celery na backend a vykonáva sa na strane billing systému a OpenStacku. Celery umožňuje celkom pohodlne spravovať úlohy, organizovať opakovania a sledovať stav. O „celery“ si môžete prečítať napríklad tu.

Takisto billing nezastavil projekt, ktorému došli peniaze. Komunikujúc s vývojármi, sme zistili, že pri počítaní podľa štatistiky (a nám je potrebné implementovať presne takú logiku) existuje zložitá súvislosť pravidiel zastavenia. Ale tieto modely sa zle prispôsobujú našim realitám. Takisto sme to realizovali prostredníctvom úloh na Celery, preberajúc logiku správy služieb na backend.

Obe vyššie uvedené problémy viedli k tomu, že kód sa trochu nafúkol a v budúcnosti budeme musieť vykonať refaktoring, aby sme vyviedli logiku práce s úlohami do samostatnej služby. Taktiež musíme uchovávať časť informácií o používateľoch a ich službách vo vlastných tabuľkách, aby sme túto logiku podporovali.

Ešte jeden problém — mlčanlivosť.

Na niektoré požiadavky na API Billing mlčky reaguje „Ok“. Tak to bolo napríklad, keď sme robili pripísania sľubovaných platieb počas testu (o ňom neskôr). Požiadavky boli správne vykonané a nevideli sme žiadne chyby.

Musel som študovať logy, zatiaľ čo som pracoval so systémom cez UI. Ukázalo sa, že samotný billing vykonáva podobné dotazy, mení scope na konkrétneho užívateľa, napríklad admina, odovzdával ho v parametre su.

Celkovo, aj napriek medzerám v dokumentácii a drobným nedostatkom API, všetko prebehlo dosť dobre. Logy sa dajú čítať aj pri vysokom zaťažení, ak pochopíte, ako sú usporiadané a čo treba hľadať. Štruktúra databázy je zložitá, ale celkom logická a v niečom dokonca atraktívna.

Takže, sčítajúc, hlavné problémy, ktoré sme mali počas interakcie, súvisia s osobitosťami implementácie konkrétneho systému:

nedokumentované „funkcie“, ktoré nás viac či menej ovplyvnili;
uzavreté zdrojové kódy (billing je napísaný v C++), čo znamená, že nemôžeme problém 1 vyriešiť nijako inak, len „metódou pokusov a omylov“.

Našťastie, produkt má dosť široký API a integrovali sme do svojho osobného kabinetu nasledujúce podsystémy:

modul technickej podpory – požiadavky z osobného kabinetu sú „proxyované“ do billingu transparentne pre klientov služby;
finančný modul – umožňuje vystavovať faktúry súčasným klientom, vykonávať odpočty a generovať platobné dokumenty;
modul správy služieb – pre neho sme museli implementovať vlastný spracovateľ. Rozšíriteľnosť systému nám pomohla a „naučili“ sme Billy nový typ služieb.
Musel som si s tým poriadne pohrať, ale myslím, že s Billy sa dohodneme.

Prechádzky po wolframových poliach – Tungsten Fabric

Wolframové polia posiate stovkami drôtov, cez ktoré prechádzajú tisíce bitov informácií. Informácie sa zhromažďujú do „balíkov“, rozoberajú sa a vytvárajú zložitú trasu, akoby mávnutím čarovného prútika.

Toto je ríša druhého systému, s ktorým sme sa museli zblížiť – Tungsten Fabric (TF), bývalý OpenContrail. Jej úlohou je spravovať sieťové vybavenie, poskytujúc nám, ako užívateľom, programovú abstrakciu. TF – SDN, zapúzdruje zložitú logiku práce so sieťovým vybavením. O samotnej technológii existuje dobrý článok, napríklad, tu.

Systém je integrovaný s OpenStack (o ňom bude reč nižšie) cez plugin Neutron.

Interakcia služieb OpenStack.

S touto systémou nás zoznámili chlapci z prevádzkového oddelenia. Používame API systému na správu sieťovej infraštruktúry našich služieb. Zatiaľ nám nespôsobila vážne problémy alebo nepríjemnosti (o chlapcoch z PO sa neodvážim hovoriť), aj keď sme sa s niektorými kuriozitami pri interakcii stretli.

Prvá situácia vyzerala takto: príkazy, ktoré si vyžadovali výstup veľkého množstva dát na konzolu inštancie pri pripojení cez SSH, jednoducho „zablokovali“ pripojenie, zatiaľ čo cez VNC všetko fungovalo korektne.

Pre tých, ktorí nie sú oboznámení s problémom, to vyzerá dosť komicky: ls /root funguje správne, zatiaľ čo, napríklad, top sa úplne „zasekne“. Našťastie, už sme sa s podobnými problémami stretli. Riešením bol tuning MTU na trase od compute-nódov k smerovačom. Mimochodom, to nie je problém TF.

Ďalší problém čakal za rohom. V jednom „krásnom“ okamžiku zmizla mágia smerovania, tak jednoducho. TF prestalo spravovať smerovanie na zariadení.

Pracovali sme s OpenStack z úrovne admina a potom sme prechádzali na úroveň požadovaného používateľa. SDN sa zdá, že „prehmatáva“ rozsah používateľa, s ktorým sa vykonávajú akcie. Problém je, že tento istý administrátorský účet sa používa na komunikáciu TF a OpenStack. Na kroku prepínania na používateľa zmizla „mágia“. Riešením bolo založiť samostatný účet na prácu so systémom. To umožnilo fungovať bez narušenia integračnej funkčnosti.

Kyslíkovo-uhličité formy života — OpenStack

Kyslíkovo-uhličitá bytostná kreatúra zvláštneho tvaru žije neďaleko wolframových polí. Najviac pripomína prešľachtené dieťa, ktoré jedným mávnutím môže rozdrviť nás, ale z jeho strany nevychádza jasná agresia. Nevyvoláva strach, ale jeho rozmery vzbudzujú obavy. Rovnako ako zložitosti toho, čo sa okolo deje.

OpenStack je jadrom našej platformy.

OpenStack má niekoľko podsystémov, z ktorých zatiaľ najaktívnejšie používame Nova, Glance a Cinder. Každý z nich má svoje API. Nova zodpovedá za compute zdroje a vytváranie instance, Cinder spravuje volume a ich snímky, Glance je servis obrázkov, ktorý spravuje šablóny OS a metainformácie o nich.

Každá služba sa spúšťa v kontajneri, pričom „biely králik“ — RabbitMQ slúži ako broker správ.

Tento systém nám spôsobil najviac neočakávaných problémov.

A first problem arose when we tried to connect an additional volume to the server. The Cinder API flatly refused to carry out this task. More accurately, according to OpenStack, the connection is established, but within the virtual server, the disk device is absent.

We decided to take a workaround and requested the same action from the Nova API. The result — the device connects correctly and is available inside the server. It seems that the problem occurs when block-storage doesn’t respond to Cinder.

Another complexity awaited us when working with disks. The system volume could not be detached from the server.

Once again, OpenStack ‘swears’ that it destroyed the connection and now we can work with the volume separately. However, the API categorically refused to perform operations on the disk.

Here we decided not to fight too much but to change our perspective on the service's logic. Since there is an instance, there must be a system volume. Therefore, the user cannot delete or detach the system 'disk' without deleting the 'server'.

OpenStack is a rather complex system with its own interaction logic and convoluted API. We are helped by quite detailed documentation and, of course, the method of trial and error (where would we be without it).

Test launch

We conducted the test launch in December last year. The main goal was to check our project from a technical perspective and UX in a real-world scenario. The audience was selected, and the testing was closed. However, we also left the possibility to request access to testing on our website.

Of course, the test did not go without comical moments, as this is just the beginning of our adventures.

Firstly, we somewhat misjudged the interest in the project and had to quickly add compute nodes during the test. A common case for a cluster, but there were nuances here as well. The documentation for the specific version of TF indicated a specific kernel version on which the functionality with vRouter was tested. We decided to launch nodes with more recent kernels. As a result — TF did not receive routes from the nodes. The kernels had to be urgently rolled back.

Another comical moment is related to the functionality of the ‘change password’ button in the personal account.

Rozhodli sme sa použiť JWT na sprístupnenie používateľského rozhrania, aby sme sa nemuseli zaoberať reláciami. Keďže systémy sú rôzne a široko rozptýlené, spravujeme svoj token, do ktorého „obalíme“ relácie z fakturácie a token z OpenStacku. Pri zmene hesla sa token samozrejme „prepadne“, pretože údaje používateľa sú už neplatné a je potrebné ho znovu vydať.

Tento moment nám unikol, a nebolo prostriedkov na rýchle dopísanie tejto časti. Museli sme pred samotným spustením testu odstrániť funkčnosť.
V súčasnosti vykonávame odhlásenie používateľa, ak bolo heslo zmenené.

Napriek týmto nuansám, testovanie prebehlo dobre. Za pár týždňov sa k nám dostalo približne 300 ľudí. Podarilo sa nám pozrieť na produkt očami používateľov, otestovať ho v praxi a získať kvalitnú spätnú väzbu.

Pokračovanie nabudúce

Pre mnohých z nás je to prvý projekt tohto rozsahu. Získali sme cenné lekcie o tom, ako pracovať v tíme, prijímať architektonické a dizajnové rozhodnutia. Ako integrovať zložité systémy s obmedzenými prostriedkami a uvádzať ich do prevádzky.

Samozrejme je nad čím pracovať, ako v oblasti kódu, tak aj na spojeniach systémov. Projekt je dosť mladý, ale sme plní ambícií vybudovať z neho spoľahlivú a pohodlnú službu.

Systémy sme už dokázali presvedčiť. Bill poslušne počíta, vystavuje faktúry a spracováva požiadavky používateľov vo svojej miestnosti. „Kúzlo“ wolframových polí nám zabezpečuje stabilné pripojenie. Iba OpenStack občas zlobí, kričí niečo ako „’WSREP has not yet prepared node for application use“. Ale to je už celkom iný príbeh...

Prednedávnom sme spustili službu.
Všetky podrobnosti si môžete overiť na našej webe.

tím vývoja CLO