Dirbdamas IT srityje pradedi pastebėti, kad sistemos turi savo charakterį. Jie gali būti lankstūs, tylūs, ekscentriški ir griežti. Jie gali pritraukti arba atstumti. Vienaip ar kitaip, jūs turite su jais „derėtis“, laviruoti tarp „spąstų“ ir kurti jų sąveikos grandines.
Taigi mums teko garbė sukurti debesų platformą ir tam reikėjo „įtikinti“ keletą posistemių dirbti su mumis. Laimei, turime „API kalbą“, tiesiogines rankas ir daug entuziazmo.
Šis straipsnis nebus techniškai sudėtingas, bet bus aprašytos problemos, su kuriomis susidūrėme kurdami debesį. Nusprendžiau aprašyti mūsų kelią lengvos techninės fantazijos forma apie tai, kaip ieškojome bendros kalbos su sistemomis ir kas iš to išėjo.
Sveiki atvykę į katę.
Kelionės pradžia
Prieš kurį laiką mūsų komandai buvo pavesta paleisti debesų platformą mūsų klientams. Turėjome valdymo palaikymą, išteklius, aparatinės įrangos krūvą ir laisvę renkantis technologijas, skirtas įdiegti programinę paslaugos dalį.
Taip pat buvo keliami reikalavimai:
- paslaugai reikalinga patogi asmeninė paskyra;
- platforma turi būti integruota į esamą atsiskaitymo sistemą;
- programinė ir techninė įranga: OpenStack + Tungsten Fabric (Open Contrail), kurią mūsų inžinieriai išmoko gana gerai „virti“.
Apie tai, kaip buvo suburta komanda, kuriama asmeninės paskyros sąsaja ir buvo priimti dizaino sprendimai, papasakosime kitą kartą, jei susidomės Habra bendruomenė.
Įrankiai, kuriuos nusprendėme naudoti:
- Python + Flask + Swagger + SQLAlchemy - visiškai standartinis Python rinkinys;
- Vue.js, skirtas priekinei sistemai;
- Nusprendėme sąveikauti tarp komponentų ir paslaugų naudodami Celery per AMQP.
Numatydamas klausimų apie Python pasirinkimą, paaiškinsiu. Kalba mūsų įmonėje rado savo nišą ir aplink ją susiformavo nedidelė, bet vis dar kultūra. Todėl nuspręsta paslaugą pradėti kurti ant jo. Be to, tokių problemų vystymosi greitis dažnai yra lemiamas.
Taigi, pradėkime savo pažintį.
Tylusis Billas – atsiskaitymas
Su šiuo vaikinu mes pažįstami jau seniai. Jis visada sėdėdavo šalia manęs ir tylėdamas kažką skaičiuodavo. Kartais jis mums persiųsdavo vartotojų užklausas, išrašydavo klientų sąskaitas, tvarkydavo paslaugas. Eilinis darbštus vaikinas. Tiesa, buvo sunkumų. Jis tylus, kartais susimąstęs ir dažnai susimąstęs.
Atsiskaitymas yra pirmoji sistema, su kuria bandėme susidraugauti. Ir pirmasis sunkumas, su kuriuo susidūrėme, buvo apdorojant paslaugas.
Pavyzdžiui, kai sukurta arba ištrinta užduotis, ji patenka į vidinę atsiskaitymo eilę. Taigi yra įdiegta asinchroninio darbo su paslaugomis sistema. Norėdami apdoroti savo paslaugų tipus, turėjome „įkelti“ savo užduotis į šią eilę. Ir čia susidūrėme su problema: trūksta dokumentų.
Sprendžiant iš programinės įrangos API aprašymo, šią problemą vis dar įmanoma išspręsti, tačiau neturėjome laiko atlikti atvirkštinės inžinerijos, todėl išėmėme logiką ir suorganizavome užduočių eilę ant RabbitMQ. Paslaugos operaciją inicijuoja klientas iš savo asmeninės paskyros, ji virsta „Selery“ „užduotimi“ užpakalinėje sistemoje ir atliekama atsiskaitymo ir „OpenStack“ pusėje. Salierai leidžia gana patogiai valdyti užduotis, organizuoti pasikartojimus ir stebėti būseną. Galite paskaityti daugiau apie „salierą“, pavyzdžiui, .
Be to, atsiskaitymas nesustabdė projekto, kuriam pritrūko pinigų. Bendraudami su kūrėjais išsiaiškinome, kad skaičiuojant statistiką (o reikia įgyvendinti būtent tokią logiką) yra sudėtingas stabdymo taisyklių tarpusavio ryšys. Tačiau šie modeliai nelabai atitinka mūsų realijas. Mes taip pat tai įdiegėme vykdydami užduotis „Selery“, perkeldami paslaugų valdymo logiką į užpakalinę pusę.
Dėl abiejų aukščiau išvardytų problemų kodas šiek tiek išsipūtė ir ateityje turėsime pertvarkyti, kad darbo su užduotimis logika būtų perkelta į atskirą paslaugą. Taip pat turime saugoti tam tikrą informaciją apie vartotojus ir jų paslaugas savo lentelėse, kad palaikytume šią logiką.
Kita problema – tyla.
Billy tyliai atsako „Gerai“ į kai kurias API užklausas. Pavyzdžiui, tai buvo atvejis, kai testo metu atlikome pažadėtų mokėjimų mokėjimus (apie tai vėliau). Užklausos buvo įvykdytos teisingai ir jokių klaidų nepastebėjome.
Man teko studijuoti žurnalus dirbant su sistema per vartotojo sąsają. Paaiškėjo, kad pats atsiskaitymas atlieka panašias užklausas, pakeisdamas apimtį į konkretų vartotoją, pavyzdžiui, admin, perduodamas su parametre.
Apskritai, nepaisant spragų dokumentacijoje ir nedidelių API trūkumų, viskas klostėsi gana gerai. Žurnalus galima skaityti net esant didelei apkrovai, jei suprantate, kokia jų struktūra ir ko ieškoti. Duomenų bazės struktūra puošni, bet gana logiška ir tam tikra prasme net patraukli.
Taigi, apibendrinant, pagrindinės problemos, su kuriomis susidūrėme sąveikos etape, yra susijusios su konkrečios sistemos diegimo ypatybėmis:
- nedokumentuotos „ypatybės“, kurios vienaip ar kitaip paveikė mus;
- uždaras šaltinis (atsiskaitymas rašomas C++), dėl to 1 problemos neįmanoma išspręsti jokiu būdu, išskyrus „bandymą ir klaidą“.
Laimei, produktas turi gana platų API ir mes integravome šiuos posistemius į savo asmeninę paskyrą:
- techninės pagalbos modulis - užklausos iš jūsų asmeninės paskyros yra skaidriai „perduodamos“ paslaugų klientams atsiskaitant;
- finansinis modulis - leidžia išrašyti sąskaitas faktūras esamiems klientams, atlikti nurašymus ir generuoti mokėjimo dokumentus;
- serviso valdymo modulis – tam turėjome įdiegti savo tvarkyklę. Sistemos išplečiamumas pateko į mūsų rankas ir mes „išmokėme“ Bilį naujo tipo paslaugos.
Buvo šiek tiek vargo, bet vienaip ar kitaip, manau, mes su Billy sutarsime.
Vaikščiojimas per volframo laukus – Tungsten Fabric
Volframo laukai, nusėti šimtais laidų, per juos perduodantys tūkstančius informacijos bitų. Informacija surenkama į „paketus“, analizuojama, tiesiant sudėtingus maršrutus, tarsi burtų keliu.
Tai antrosios sistemos, su kuria mums teko susidraugauti, sritis – „Tungsten Fabric“ (TF), anksčiau buvusi „OpenContrail“. Jos užduotis – valdyti tinklo įrangą, teikti programinės įrangos abstrakciją mums, kaip vartotojams. TF – SDN, apima sudėtingą darbo su tinklo įranga logiką. Yra geras straipsnis apie pačią technologiją, pvz. .
Sistema yra integruota su „OpenStack“ (aptarta toliau) per „Neutron“ įskiepį.
„OpenStack“ paslaugų sąveika.
Vaikinai iš operacijų skyriaus mus supažindino su šia sistema. Mes naudojame sistemos API, kad valdytume savo paslaugų tinklo krūvą. Mums tai dar nesukėlė jokių rimtų problemų ar nepatogumų (negaliu kalbėti už vaikinus iš OE), tačiau sąveikoje buvo tam tikrų keistenybių.
Pirmasis atrodė taip: komandos, reikalaujančios išvesti didelį duomenų kiekį į egzempliorių konsolę jungiantis per SSH, tiesiog „užkabino“ ryšį, o per VNC viskas veikė tinkamai.
Tiems, kurie nėra susipažinę su problema, ji atrodo gana juokinga: ls /root veikia teisingai, o, pavyzdžiui, top visiškai „užšąla“. Laimei, su panašiomis problemomis susidūrėme ir anksčiau. Tai buvo nuspręsta suderinus MTU maršrute nuo skaičiavimo mazgų iki maršrutizatorių. Beje, tai ne TF problema.
Kita problema buvo visai šalia. Vieną „gražią“ akimirką maršruto magija dingo, kaip tik. TF nustojo valdyti įrangos maršrutą.
Su Openstack dirbome nuo administratoriaus lygio ir po to perėjome į reikiamą vartotojo lygį. Atrodo, kad SDN „užgrobia“ vartotojo, kuris atlieka veiksmus, sritį. Faktas yra tas, kad ta pati administratoriaus paskyra naudojama TF ir OpenStack prijungimui. Perėjus prie vartotojo, „stebuklingumas“ išnyko. Buvo nuspręsta sukurti atskirą paskyrą darbui su sistema. Tai leido mums dirbti nepažeidžiant integravimo funkcijų.
Silicon Lifeforms – OpenStack
Netoli volframo laukų gyvena keistos formos silikoninė būtybė. Labiausiai tai atrodo kaip peraugęs vaikas, kuris gali mus sutraiškyti vienu sūpuokliu, tačiau akivaizdžios agresijos iš jo nekyla. Jis nekelia baimės, bet jo dydis įkvepia baimę. Kaip ir dėl to, kas vyksta aplinkui, sudėtingumas.
OpenStack yra mūsų platformos pagrindas.
OpenStack turi keletą posistemių, iš kurių šiuo metu aktyviausiai naudojame Nova, Glance ir Cinder. Kiekvienas iš jų turi savo API. „Nova“ yra atsakinga už skaičiavimo išteklius ir egzempliorių kūrimą, „Cinder“ yra atsakinga už tomų ir jų momentinių nuotraukų tvarkymą, „Glance“ yra vaizdo paslauga, valdanti OS šablonus ir metainformaciją apie juos.
Kiekviena paslauga veikia konteineryje, o pranešimų tarpininkas yra „baltasis triušis“ - RabbitMQ.
Ši sistema mums sukėlė netikėčiausią bėdą.
Ir pirmoji problema netruko laukti, kai bandėme prijungti papildomą tomą prie serverio. Cinder API kategoriškai atsisakė atlikti šią užduotį. Tiksliau, jei tikite pačiu OpenStack, ryšys užmegztas, tačiau virtualiame serveryje nėra disko įrenginio.
Nusprendėme apvažiuoti aplinkkeliu ir paprašėme to paties veiksmo iš „Nova“ API. Rezultatas yra tai, kad įrenginys tinkamai prisijungia ir yra pasiekiamas serveryje. Atrodo, kad problema kyla, kai blokų saugykla nereaguoja į Cinder.
Dar vienas sunkumas mūsų laukė dirbant su diskais. Nepavyko atjungti sistemos tomo nuo serverio.
Vėlgi, pati „OpenStack“ „prisiekia“, kad sunaikino ryšį ir dabar galite teisingai dirbti su garsu atskirai. Tačiau API kategoriškai nenorėjo atlikti operacijų diske.
Čia nusprendėme ne itin kovoti, o pakeisti savo požiūrį į tarnybos logiką. Jei yra egzempliorius, turi būti ir sistemos tomas. Todėl vartotojas dar negali pašalinti arba išjungti sistemos „disko“, neištrindamas „serverio“.
OpenStack yra gana sudėtingas sistemų rinkinys, turintis savo sąveikos logiką ir puošnią API. Mums padeda gana išsami dokumentacija ir, žinoma, bandymai ir klaidos (kur mes be jos).
Bandomasis važiavimas
Bandomąjį paleidimą atlikome praėjusių metų gruodį. Pagrindinė užduotis buvo išbandyti mūsų projektą koviniu režimu iš techninės pusės ir iš UX pusės. Publika buvo pakviesta pasirinktinai, o testavimas buvo uždarytas. Tačiau taip pat palikome galimybę prašyti prieigos prie bandymų mūsų svetainėje.
Pats išbandymas, žinoma, neapsiėjo be smagių akimirkų, nes čia mūsų nuotykiai tik prasideda.
Pirma, mes šiek tiek neteisingai įvertinome susidomėjimą projektu ir testo metu turėjome greitai pridėti skaičiavimo mazgus. Dažnas klasterio atvejis, tačiau čia taip pat buvo keletas niuansų. Konkrečios TF versijos dokumentacijoje nurodoma konkreti branduolio versija, kurioje buvo išbandytas darbas su vRouter. Nusprendėme paleisti mazgus su naujesniais branduoliais. Dėl to TF negavo maršrutų iš mazgų. Turėjau skubiai atsukti branduolius.
Kitas įdomumas yra susijęs su mygtuko „pakeisti slaptažodį“ funkcionalumu jūsų asmeninėje paskyroje.
Nusprendėme naudoti JWT, kad organizuotume prieigą prie savo asmeninės paskyros, kad nedirbtume su seansais. Kadangi sistemos yra įvairios ir plačiai išsibarsčiusios, mes patys valdome savo prieigos raktą, į kurį „apvyniojame“ seansus iš atsiskaitymo ir prieigos raktą iš „OpenStack“. Pakeitus slaptažodį, prieigos raktas, žinoma, „sugenda“, nes vartotojo duomenys nebegalioja ir juos reikia išduoti iš naujo.
Mes praradome šį tašką ir tiesiog nebuvo pakankamai išteklių greitai užbaigti šį kūrinį. Prieš pradėdami testą, turėjome išjungti funkcionalumą.
Šiuo metu mes atsijungiame nuo vartotojo, jei slaptažodis buvo pakeistas.
Nepaisant šių niuansų, bandymai praėjo gerai. Per porą savaičių užsuko apie 300 žmonių. Galėjome pažvelgti į produktą vartotojų akimis, išbandyti jį veikiant ir surinkti aukštos kokybės atsiliepimus.
Turi būti tęsiama
Daugeliui iš mūsų tai pirmasis tokio masto projektas. Gavome daug vertingų pamokų, kaip dirbti komandoje ir priimti architektūrinius bei dizaino sprendimus. Kaip integruoti sudėtingas sistemas naudojant mažai išteklių ir įdiegti jas į gamybą.
Žinoma, yra ką dirbti tiek kalbant apie kodą, tiek ties sistemos integravimo sąsajomis. Projektas gana jaunas, tačiau esame kupini ambicijų išauginti jį į patikimą ir patogią paslaugą.
Mes jau sugebėjome įtikinti sistemas. Bilas savo spintoje pareigingai tvarko skaičiavimą, atsiskaitymus ir vartotojų užklausas. Volframo laukų „magija“ suteikia mums stabilų ryšį. Ir tik „OpenStack“ kartais tampa kaprizingas, šaukdamas kažką panašaus į „WSREP dar neparengė mazgo naudoti programą“. Bet tai visai kita istorija...
Neseniai pradėjome paslaugą.
Visą informaciją galite sužinoti mūsų svetainėje .
CLO plėtros komanda
Naudingos nuorodos
OpenStack
Volframo audinys
Šaltinis: www.habr.com