Wylst jo yn IT wurkje, begjinne jo te merken dat systemen har eigen karakter hawwe. Se kinne fleksibel, stil, eksintrysk en strang wêze. Se kinne oanlûke of ôfwize. Op ien of oare manier moatte jo "ûnderhannelje" mei har, manoeuvre tusken "falfallen" en bouwe keatlingen fan har ynteraksje.
Dat wy hienen de eare om in wolkplatfoarm te bouwen, en dêrfoar moasten wy in pear subsystemen "oerhelje" om mei ús te wurkjen. Gelokkich hawwe wy in "API-taal", direkte hannen en in protte entûsjasme.
Dit artikel sil net technysk hardcore wêze, mar sil de problemen beskriuwe dy't wy tsjinkamen by it bouwen fan 'e wolk. Ik besleat ús paad te beskriuwen yn 'e foarm fan in lichte technyske fantasy oer hoe't wy sochten nei in mienskiplike taal mei systemen en wat der fan kaam.
Wolkom by kat.
Start fan 'e reis
In skoft lyn krige ús team de opdracht om in wolkplatfoarm te lansearjen foar ús kliïnten. Wy hiene managementstipe, boarnen, hardwarestapel en frijheid by it kiezen fan technologyen om it softwarediel fan 'e tsjinst út te fieren.
Der wiene ek in oantal easken:
- de tsjinst hat in handich persoanlik akkount nedich;
- it platfoarm moat yntegreare wurde yn it besteande billingsysteem;
- software en hardware: OpenStack + Tungsten Fabric (Iepen Contrail), dy't ús yngenieurs hawwe leard om "cook" frij goed.
Wy sille jo in oare kear fertelle oer hoe't it team waard gearstald, de persoanlike akkountynterface waard ûntwikkele en ûntwerpbesluten waarden makke, as de Habra-mienskip ynteressearre is.
De ark dy't wy besletten hawwe te brûken:
- Python + Flask + Swagger + SQLAlchemy - in folslein standert Python-set;
- Vue.js foar frontend;
- Wy besletten de ynteraksje te dwaan tusken komponinten en tsjinsten mei Sellery oer AMQP.
Ferwachtsje fragen oer it kiezen fan Python, sil ik útlizze. De taal hat syn niche fûn yn ús bedriuw en der is in lytse, mar dochs kultuer hinne ûntwikkele. Dêrom waard besletten om dêr de tsjinst op te bouwen. Boppedat is de snelheid fan ûntwikkeling yn sokke problemen faak beslissend.
Sa, lit ús begjinne ús kunde.
Silent Bill - billing
Wy kennen dizze man al lang. Hy siet altyd njonken my en telde swijend wat. Soms stjoerde hy brûkersoanfragen nei ús troch, joech klantfakturen út en behearde tsjinsten. In gewoane hurdwurkjende keardel. Wier, der wiene swierrichheden. Hy is stil, soms betochtsum en faaks op eigen tinzen.
Billing is it earste systeem dat wy besochten freonen te meitsjen. En de earste muoite dy't wy tsjinkamen wie by it ferwurkjen fan tsjinsten.
Bygelyks, doe't oanmakke of wiske, in taak giet yn de ynterne fakturearring wachtrige. Sa wurdt in systeem fan asynchrone wurk mei tsjinsten ymplementearre. Om ús tsjinsttypen te ferwurkjen, moasten wy ús taken yn dizze wachtrige "sette". En hjir rûnen wy op in probleem: gebrek oan dokumintaasje.
Beoardielje troch de beskriuwing fan 'e software API, is it noch mooglik om dit probleem op te lossen, mar wy hienen gjin tiid om reverse engineering te dwaan, dus namen wy de logika nei bûten en organisearre in taakwachtrige boppe op RabbitMQ. In operaasje op in tsjinst wurdt inisjearre troch de kliïnt fan syn persoanlike akkount, feroaret yn in Celery "taak" op 'e efterkant en wurdt útfierd oan' e fakturearring en OpenStack side. Selderij makket it frij handich om taken te behearjen, repetysjes te organisearjen en status te kontrolearjen. Jo kinne mear lêze oer "selderij", bygelyks, .
Ek fakturearre net stop in projekt dat rûn út jild. Kommunikaasje mei de ûntwikkelders, wy fûnen út dat by it berekkenjen fan statistyk (en wy moatte útfiere krekt dit soarte fan logika), der is in komplekse ynterrelaasje fan stopping regels. Mar dizze modellen passe net goed mei ús realiteiten. Wy hawwe it ek ymplementearre fia taken op Selery, en namen de logika fan tsjinstbehear nei de efterkant.
Beide boppesteande problemen liede ta dat de koade in bytsje opblaasd waard en yn 'e takomst sille wy moatte refaktorearje om de logika foar wurkjen mei taken yn in aparte tsjinst te ferpleatsen. Wy moatte ek wat ynformaasje oer brûkers en har tsjinsten opslaan yn ús tabellen om dizze logika te stypjen.
In oar probleem is stilte.
Billy antwurdet stil "Ok" op guon API-oanfragen. Dit wie bygelyks it gefal doe't wy by de test betellingen makken fan taseine betellingen (deroer letter mear). De oanfragen waarden korrekt útfierd en wy seagen gjin flaters.
Ik moast studearje de logs wylst wurkjen mei it systeem fia de UI. It die bliken dat de fakturearring sels ferlykbere oanfragen útfiert, it feroarjen fan it berik nei in spesifike brûker, bygelyks admin, trochjaan it yn 'e parameter su.
Yn 't algemien, nettsjinsteande de gatten yn' e dokumintaasje en lytse API-fouten, gie alles frij goed. Logboeken kinne wurde lêzen sels ûnder swiere lading as jo begripe hoe't se binne strukturearre en wat te sykjen. De struktuer fan 'e databank is sierlik, mar frij logysk en op guon manieren sels oantreklik.
Dus, om te gearfetten, binne de wichtichste problemen dy't wy tsjinkamen yn 'e ynteraksjestadium relatearre oan de ymplemintaasjefunksjes fan in spesifyk systeem:
- net dokumintearre "funksjes" dy't ús op ien of oare manier beynfloede;
- sletten boarne (fakturearring is skreaun yn C++), as gefolch - it is ûnmooglik om probleem 1 op in oare manier op te lossen as "probearje en flater".
Gelokkich hat it produkt in frij wiidweidige API en hawwe wy de folgjende subsystemen yntegreare yn ús persoanlike akkount:
- technyske stipe module - oanfragen fan jo persoanlike akkount wurde "proxied" foar transparante fakturearring foar tsjinstkliïnten;
- finansjele module - lit jo faktueren útjaan oan hjoeddeistige kliïnten, ôfskriuwings meitsje en betellingsdokuminten generearje;
- service control module - hjirfoar moasten wy ús eigen handler implementearje. De útwreidzjen fan it systeem spile ús yn hannen en wy "learden" Billy in nij soarte tsjinst.
It wie in bytsje fan in gedoe, mar ien of oare manier, ik tink dat Billy en ik sille tegearre.
Walking troch wolfraam fjilden - Tungsten Fabric
Wolframfjilden bespuige mei hûnderten triedden, dy't tûzenen stikjes ynformaasje troch har passe. Ynformaasje wurdt sammele yn "pakketten", parsed, it bouwen fan komplekse rûtes, as troch magy.
Dit is it domein fan it twadde systeem wêrmei wy freonen meitsje moasten - Tungsten Fabric (TF), earder OpenContrail. De taak is om netwurkapparatuer te behearjen, in softwareabstraksje foar ús as brûkers te leverjen. TF - SDN, encapsulates de komplekse logika fan wurkjen mei netwurk apparatuer. D'r is in goed artikel oer de technology sels, bygelyks, .
It systeem is yntegrearre mei OpenStack (hjirûnder besprutsen) fia it Neutron-plugin.
Ynteraksje fan OpenStack tsjinsten.
De jonges fan de operaasjeôfdieling hawwe ús dit systeem yntrodusearre. Wy brûke de API fan it systeem om de netwurkstapel fan ús tsjinsten te behearjen. It hat ús noch gjin serieuze problemen of ûngemak feroarsake (ik kin net prate foar de jonges fan 'e OE), mar d'r hawwe wat nuverheden west yn ynteraksje.
De earste seach der sa út: kommando's dy't nedich wiene om in grutte hoemannichte gegevens nei de eksimplaarkonsole út te jaan by it ferbinen fia SSH gewoan de ferbining "ophongen", wylst fia VNC alles goed wurke.
Foar dyjingen dy't net bekend binne mei it probleem, sjocht it der aardich grappich út: ls /root wurket goed, wylst, bygelyks, top "befriest" folslein. Gelokkich hawwe wy earder ferlykbere problemen tsjinkaam. It waard besletten troch it ôfstimmen fan de MTU op 'e rûte fan' e komputerknooppunten nei de routers. Trouwens, dit is gjin TF-probleem.
It folgjende probleem wie krekt om 'e hoeke. Yn ien "moai" momint ferdwûn de magy fan routing, krekt sa. TF is stoppe mei it behearen fan routing op 'e apparatuer.
Wy wurken mei Openstack fanôf it adminnivo en ferpleatse dêrnei nei it fereaske brûkersnivo. SDN liket de omfang fan 'e brûker troch wa't de aksjes wurde útfierd "hijack". It feit is dat itselde admin-akkount wurdt brûkt om TF en OpenStack te ferbinen. By de stap fan it wikseljen nei de brûker ferdwûn de "magy". It waard besletten om in apart akkount te meitsjen om mei it systeem te wurkjen. Dit liet ús wurkje sûnder de yntegraasjefunksjonaliteit te brekken.
Silicon Lifeforms - OpenStack
In bizar foarme silikonske skepsel libbet tichtby wolfraamfjilden. Foaral liket it op in oergroeid bern dat ús mei ien swaai ferpletterje kin, mar der komt gjin dúdlike agression fan him. It feroarsaket gjin eangst, mar syn grutte ynspirearret eangst. Lykas de kompleksiteit fan wat der rûnom bart.
OpenStack is de kearn fan ús platfoarm.
OpenStack hat ferskate subsystemen, wêrfan wy no Nova, Glance en Cinder it meast aktyf brûke. Elk fan harren hat syn eigen API. Nova is ferantwurdlik foar berekkeningsboarnen en it meitsjen fan eksimplaren, Cinder is ferantwurdlik foar it behearen fan folumes en har snapshots, Glance is in ôfbyldingstsjinst dy't OS-sjabloanen en meta-ynformaasje derop beheart.
Elke tsjinst rint yn in kontener, en de berjochtmakelaar is de "wite konijn" - RabbitMQ.
Dit systeem joech ús de meast ûnferwachte problemen.
En it earste probleem wie net lang te kommen doe't wy besochten in ekstra folume te ferbinen mei de tsjinner. De Cinder API wegere bot om dizze taak út te fieren. Mear krekt, as jo OpenStack sels leauwe, is de ferbining fêststeld, mar d'r is gjin skiifapparaat yn 'e firtuele tsjinner.
Wy besletten om in omwei te nimmen en fregen deselde aksje fan 'e Nova API. It resultaat is dat it apparaat goed ferbynt en tagonklik is binnen de tsjinner. It docht bliken dat it probleem optreedt as blok-opslach net reagearret op Cinder.
In oare swierrichheid wachte ús by it wurkjen mei skiven. It systeem folume koe net loskeppele wurde fan de tsjinner.
Nochris, OpenStack sels "swiert" dat it de ferbining hat ferneatige en no kinne jo goed apart wurkje mei folume. Mar de API woe kategoarysk gjin operaasjes op 'e skiif útfiere.
Hjir hawwe wy besletten net spesjaal te fjochtsjen, mar om ús sicht op 'e logika fan' e tsjinst te feroarjen. As der in eksimplaar is, moat der ek in systeemfolum wêze. Dêrom kin de brûker it systeem "skiif" noch net fuortsmite of útskeakelje sûnder de "tsjinner" te wiskjen.
OpenStack is in frij komplekse set fan systemen mei in eigen ynteraksje logika en sierlike API. Wy wurde holpen troch frij detaillearre dokumintaasje en, fansels, probearje en flater (wêr soene wy sûnder wêze).
Test run
Wy hawwe yn desimber ferline jier in testlansearring útfierd. De wichtichste taak wie om ús projekt te testen yn fjochtsmodus fan 'e technyske kant en fan' e UX-kant. It publyk waard selektyf útnoege en de test waard ôfsletten. Wy hawwe lykwols ek de opsje ferlitten om tagong te freegjen ta testen op ús webside.
De test sels wie fansels net sûnder grappige mominten, want dit is wêr't ús aventoeren krekt begjinne.
As earste hawwe wy de belangstelling foar it projekt wat ferkeard beoardiele en moasten direkt tidens de test fluch komputerknooppunten tafoegje. In gewoan gefal foar in kluster, mar hjir wiene ek wat nuânses. De dokumintaasje foar in spesifike ferzje fan TF jout de spesifike ferzje fan 'e kearn oan wêrop wurk mei vRouter waard hifke. Wy besletten om knopen te starten mei mear resinte kernels. Dêrtroch krige TF gjin rûtes fan de knopen. Ik moast driuwend de kearnen weromrôlje.
In oare nijsgjirrigens is relatearre oan de funksjonaliteit fan 'e knop "Wachtwurd feroarje" yn jo persoanlike akkount.
Wy besletten om JWT te brûken om tagong te organisearjen ta ús persoanlike akkount om net mei sesjes te wurkjen. Sûnt de systemen binne ferskaat en wiid ferspraat, wy beheare ús eigen token, wêryn wy "wrap" sesjes fan fakturearring en in token fan OpenStack. As it wachtwurd feroare wurdt, giet it token fansels "min", om't de brûkersgegevens net mear jildich binne en it opnij útjûn wurde moat.
Wy ferlearen dit punt út it each, en d'r wiene gewoan net genôch boarnen om dit stik fluch ôf te meitsjen. Wy moasten de funksjonaliteit útskeakelje krekt foardat de test lansearre.
Op it stuit melde wy de brûker út as it wachtwurd feroare is.
Nettsjinsteande dizze nuânses, testen gie goed. Yn in pear wike kamen sa'n 300 minsken langs. Wy koene it produkt troch de eagen fan brûkers besjen, it yn aksje testen en feedback fan hege kwaliteit sammelje.
To continue
Foar in protte fan ús is dit it earste projekt fan dizze skaal. Wy learden in oantal weardefolle lessen oer hoe te wurkjen as in team en meitsje arsjitektoanyske en ûntwerp besluten. Hoe komplekse systemen te yntegrearjen mei lytse boarnen en rôlje se yn produksje.
Fansels is d'r wat om oan te wurkjen sawol yn termen fan koade as by de ynterfaces fan systeemyntegraasje. It projekt is nochal jong, mar wy binne fol ambysjes om it út te groeien ta in betroubere en handige tsjinst.
Wy hawwe de systemen al oertsjûge kinnen. Bill behannelet plichtsgetrouwe rekkenjen, fakturearjen en fersiken fan brûkers yn syn kast. De "magy" fan wolfraamfjilden jout ús stabile kommunikaasje. En allinnich OpenStack wurdt soms grillig, en ropt wat as "'WSREP hat noch gjin knooppunt taret foar gebrûk fan tapassing." Mar dat is in folslein oar ferhaal...
Wy hawwe de tsjinst koartlyn lansearre.
Jo kinne alle details fine op ús .
CLO Development Team
Nuttige keppelings
OpenStack
Wolfram stof
Boarne: www.habr.com