Soos jy in IT werk, begin jy agterkom dat stelsels hul eie karakter het. Hulle kan buigsaam, stil, eksentriek en streng wees. Hulle kan aantrek of afstoot. Op een of ander manier moet jy met hulle "onderhandel", tussen "slaggate" maneuver en kettings van hul interaksie bou.
Ons het dus die eer gehad om 'n wolkplatform te bou, en hiervoor moes ons 'n paar substelsels "oorreed" om saam met ons te werk. Gelukkig het ons 'n "API-taal", direkte hande en baie entoesiasme.
Hierdie artikel sal nie tegnies hardcore wees nie, maar sal die probleme beskryf wat ons ondervind het tydens die bou van die wolk. Ek het besluit om ons pad te beskryf in die vorm van 'n ligte tegniese fantasie oor hoe ons gesoek het na 'n gemeenskaplike taal met sisteme en wat daaruit gekom het.
Welkom by kat.
Die begin van die pad
'n Tyd gelede is ons span getaak om 'n wolkplatform vir ons kliënte te begin. Ons het bestuursondersteuning, hulpbronne, hardeware-stapel en vryheid gehad in die keuse van tegnologieë om die sagteware-deel van die diens te implementeer.
Daar was ook 'n aantal vereistes:
- die diens benodig 'n gerieflike persoonlike rekening;
- die platform moet by die bestaande faktureringstelsel geïntegreer word;
- sagteware en hardeware: OpenStack + Tungsten Fabric (Open Contrail), wat ons ingenieurs geleer het om redelik goed te "kook".
Ons sal jou 'n ander keer vertel van hoe die span saamgestel is, die persoonlike rekeningkoppelvlak ontwikkel is en ontwerpbesluite geneem is, as die Habra-gemeenskap belangstel.
Die gereedskap wat ons besluit het om te gebruik:
- Python + Flask + Swagger + SQLAlchemy - 'n heeltemal standaard Python-stel;
- Vue.js vir frontend;
- Ons het besluit om die interaksie tussen komponente en dienste te doen deur Selery oor AMQP te gebruik.
Ek sal vrae oor die keuse van Python verwag. Die taal het sy nis in ons maatskappy gevind en 'n klein, maar steeds kultuur, het rondom dit ontwikkel. Daarom is besluit om die diens daarop te begin bou. Boonop is die spoed van ontwikkeling in sulke probleme dikwels deurslaggewend.
So, kom ons begin ons kennismaking.
Silent Bill - faktuur
Ons ken hierdie man al lank. Hy het altyd langs my gesit en stilweg iets getel. Soms het hy gebruikersversoeke aan ons aangestuur, kliëntfakture uitgereik en dienste bestuur. 'n Gewone hardwerkende ou. Daar was weliswaar moeilikhede. Hy is stil, soms bedagsaam en dikwels in sy eie gedagtes.
Fakturering is die eerste stelsel waarmee ons vriende probeer maak het. En die eerste probleem wat ons teëgekom het, was tydens die verwerking van dienste.
Byvoorbeeld, wanneer 'n taak geskep of uitgevee word, gaan dit in die interne faktuurwaglys. Dus word 'n stelsel van asynchroniese werk met dienste geïmplementeer. Om ons dienstipes te verwerk, moes ons ons take in hierdie tou "plaas". En hier het ons 'n probleem teëgekom: 'n gebrek aan dokumentasie.
Te oordeel aan die beskrywing van die sagteware API, is dit steeds moontlik om hierdie probleem op te los, maar ons het nie tyd gehad om omgekeerde ingenieurswese te doen nie, so ons het die logika na buite geneem en 'n taakry bo-op RabbitMQ georganiseer. 'n Operasie op 'n diens word deur die kliënt vanaf sy persoonlike rekening geïnisieer, verander in 'n Selery "taak" op die agterkant en word uitgevoer aan die faktuur en OpenStack kant. Seldery maak dit baie gerieflik om take te bestuur, herhalings te organiseer en status te monitor. Jy kan meer lees oor "seldery", byvoorbeeld, .
Ook het faktuur nie 'n projek gekeer wat sonder geld opgeraak het nie. In kommunikasie met die ontwikkelaars, het ons uitgevind dat wanneer statistieke bereken word (en ons moet presies hierdie soort logika implementeer), is daar 'n komplekse onderlinge verband tussen stopreëls. Maar hierdie modelle pas nie goed by ons realiteite nie. Ons het dit ook geïmplementeer deur take op Seldery, wat die diensbestuurslogika na die agterkant geneem het.
Albei bogenoemde probleme het daartoe gelei dat die kode 'n bietjie opgeblase geraak het en in die toekoms sal ons moet herfaktor om die logika vir die werk met take na 'n aparte diens te skuif. Ons moet ook inligting oor gebruikers en hul dienste in ons tabelle stoor om hierdie logika te ondersteun.
Nog 'n probleem is stilte.
Billy antwoord stilweg "Ok" op sommige API-versoeke. Dit was byvoorbeeld die geval toe ons betalings gemaak het van beloofde betalings tydens die toets (meer daaroor later). Die versoeke is korrek uitgevoer en ons het geen foute gesien nie.
Ek moes die logs bestudeer terwyl ek met die stelsel deur die UI gewerk het. Dit het geblyk dat fakturering self soortgelyke versoeke uitvoer, wat die omvang verander na 'n spesifieke gebruiker, byvoorbeeld admin, wat dit in die su-parameter deurgee.
Oor die algemeen, ondanks die leemtes in die dokumentasie en geringe API-foute, het alles redelik goed gegaan. Logs kan selfs onder swaar vrag gelees word as jy verstaan hoe hulle gestruktureer is en waarna om te kyk. Die struktuur van die databasis is sierlik, maar redelik logies en in sekere opsigte selfs aantreklik.
Dus, om op te som, die hoofprobleme wat ons tydens die interaksiestadium teëgekom het, hou verband met die implementeringskenmerke van 'n spesifieke stelsel:
- ongedokumenteerde “kenmerke” wat ons op een of ander manier geraak het;
- geslote bron (fakturering word in C++ geskryf), as gevolg daarvan - dit is onmoontlik om probleem 1 op enige ander manier as "trial and error" op te los.
Gelukkig het die produk 'n redelik uitgebreide API en ons het die volgende substelsels in ons persoonlike rekening geïntegreer:
- tegniese ondersteuningsmodule - versoeke vanaf jou persoonlike rekening word deursigtig vir dienskliënte "gevolmagtig" tot fakturering;
- finansiële module - laat jou toe om fakture aan huidige kliënte uit te reik, afskrywings te maak en betalingsdokumente te genereer;
- diensbeheermodule - hiervoor moes ons ons eie hanteerder implementeer. Die uitbreidbaarheid van die stelsel het in ons hande gespeel en ons het vir Billy 'n nuwe tipe diens "geleer".
Dit was 'n bietjie van 'n gesukkel, maar een of ander manier, ek dink ek en Billy sal oor die weg kom.
Stap deur wolfram velde – Tungsten Stof
Wolfram-velde besaai met honderde drade, wat duisende stukkies inligting daardeur stuur. Inligting word in "pakkies" versamel, ontleed en komplekse roetes gebou word, asof deur towerkrag.
Dit is die domein van die tweede stelsel waarmee ons vriende moes maak – Tungsten Fabric (TF), voorheen OpenContrail. Sy taak is om netwerktoerusting te bestuur, wat 'n sagteware-abstraksie aan ons as gebruikers verskaf. TF - SDN, omsluit die komplekse logika van werk met netwerktoerusting. Daar is 'n goeie artikel oor die tegnologie self, bv. .
Die stelsel is geïntegreer met OpenStack (hieronder bespreek) via die Neutron-inprop.
Interaksie van OpenStack-dienste.
Die ouens van die operasionele departement het ons aan hierdie stelsel voorgestel. Ons gebruik die stelsel se API om die netwerkstapel van ons dienste te bestuur. Dit het ons nog geen ernstige probleme of ongerief veroorsaak nie (ek kan nie namens die ouens van die OE praat nie), maar daar was 'n paar eienaardighede in interaksie.
Die eerste het so gelyk: opdragte wat vereis het om 'n groot hoeveelheid data na die instansiekonsole uit te voer wanneer u via SSH verbind het, het eenvoudig die verbinding "opgehang", terwyl alles via VNC reg gewerk het.
Vir diegene wat nie met die probleem vertroud is nie, lyk dit nogal snaaks: ls /root werk reg, terwyl, byvoorbeeld, top heeltemal “vries”. Gelukkig het ons al voorheen soortgelyke probleme ondervind. Daar is besluit deur die MTU in te stem op die roete vanaf die rekenaarnodusse na die roeteerders. Terloops, dit is nie 'n TF-probleem nie.
Die volgende probleem was net om die draai. In een “mooi” oomblik het die magie van roetering net so verdwyn. TF het opgehou om roetes op die toerusting te bestuur.
Ons het vanaf die administrasievlak met Openstack gewerk en daarna na die vereiste gebruikersvlak oorgeskuif. Dit lyk asof SDN die omvang van die gebruiker deur wie die aksies uitgevoer word, “kaap”. Die feit is dat dieselfde admin-rekening gebruik word om TF en OpenStack te verbind. By die stap van oorskakeling na die gebruiker het die "magic" verdwyn. Daar is besluit om 'n aparte rekening te skep om met die stelsel te werk. Dit het ons toegelaat om te werk sonder om die integrasiefunksionaliteit te breek.
Silicon Lifeforms - OpenStack
’n Bizar gevormde silikoonwese leef naby wolframvelde. Bowenal lyk dit soos 'n oorgroeide kind wat ons met een swaai kan vermorsel, maar daar kom geen ooglopende aggressie van hom af nie. Dit veroorsaak nie vrees nie, maar die grootte daarvan inspireer vrees. So ook die kompleksiteit van wat rondom gebeur.
OpenStack is die kern van ons platform.
OpenStack het verskeie substelsels, waarvan ons tans Nova, Glance en Cinder die aktiefste gebruik. Elkeen van hulle het sy eie API. Nova is verantwoordelik vir rekenaarhulpbronne en die skep van gevalle, Cinder is verantwoordelik vir die bestuur van volumes en hul foto's, Glance is 'n beelddiens wat OS-sjablone en meta-inligting daaroor bestuur.
Elke diens loop in 'n houer, en die boodskap makelaar is die "wit konyn" - RabbitMQ.
Hierdie stelsel het ons die mees onverwagte moeilikheid gegee.
En die eerste probleem was nie lank om te kom toe ons probeer het om 'n bykomende volume aan die bediener te koppel nie. Die Cinder API het botweg geweier om hierdie taak uit te voer. Meer presies, as jy OpenStack self glo, is die verbinding tot stand gebring, maar daar is geen skyftoestel binne die virtuele bediener nie.
Ons het besluit om 'n ompad te neem en dieselfde optrede van die Nova API versoek. Die resultaat is dat die toestel korrek verbind en binne die bediener toeganklik is. Dit blyk dat die probleem voorkom wanneer blokberging nie op Cinder reageer nie.
Nog 'n probleem het op ons gewag wanneer ons met skywe werk. Die stelselvolume kon nie van die bediener ontkoppel word nie.
Weereens, OpenStack self "sweer" dat dit die verbinding vernietig het en nou kan jy korrek met volume afsonderlik werk. Maar die API wou kategories nie bewerkings op die skyf uitvoer nie.
Hier het ons besluit om nie veral te baklei nie, maar om ons siening van die logika van die diens te verander. As daar 'n instansie is, moet daar ook 'n stelselvolume wees. Daarom kan die gebruiker nog nie die stelsel "skyf" verwyder of deaktiveer sonder om die "bediener" uit te vee nie.
OpenStack is 'n taamlik komplekse stel stelsels met sy eie interaksielogika en versierde API. Ons word gehelp deur redelik gedetailleerde dokumentasie en natuurlik probeer en fout (waar sou ons daarsonder wees).
Toetsloop
Ons het in Desember verlede jaar 'n toetsbekendstelling gedoen. Die hooftaak was om ons projek in gevegsmodus van die tegniese kant en van die UX-kant te toets. Die gehoor is selektief genooi en die toetsing is gesluit. Ons het egter ook die opsie gelaat om toegang tot toetsing op ons webwerf te versoek.
Die toets self was natuurlik nie sonder sy snaakse oomblikke nie, want dit is waar ons avonture net begin.
Eerstens het ons die belangstelling in die projek ietwat verkeerd beoordeel en moes vinnig rekenaarnodusse byvoeg reg tydens die toets. 'n Algemene saak vir 'n cluster, maar hier was ook 'n paar nuanses. Die dokumentasie vir 'n spesifieke weergawe van TF dui die spesifieke weergawe van die kern aan waarop werk met vRouter getoets is. Ons het besluit om nodusse met meer onlangse pitte te begin. As gevolg hiervan het TF nie roetes vanaf die nodusse ontvang nie. Ek moes die pitte dringend terugrol.
Nog 'n nuuskierigheid hou verband met die funksionaliteit van die "verander wagwoord"-knoppie in jou persoonlike rekening.
Ons het besluit om JWT te gebruik om toegang tot ons persoonlike rekening te organiseer om nie met sessies te werk nie. Aangesien die stelsels uiteenlopend en wydverspreid is, bestuur ons ons eie teken, waarin ons sessies van faktuur en 'n teken van OpenStack "omhul". Wanneer die wagwoord verander word, word die teken natuurlik "sleg", aangesien die gebruikerdata nie meer geldig is nie en dit heruitgereik moet word.
Ons het hierdie punt uit die oog verloor, en daar was eenvoudig nie genoeg hulpbronne om hierdie stuk vinnig klaar te maak nie. Ons moes die funksionaliteit uitskakel net voordat ons die toets begin het.
Tans teken ons die gebruiker uit as die wagwoord verander is.
Ten spyte van hierdie nuanses het toetsing goed gegaan. Binne 'n paar weke het sowat 300 mense daar gestop. Ons kon na die produk deur die oë van gebruikers kyk, dit in aksie toets en terugvoer van hoë gehalte insamel.
Voortgesit moet word
Vir baie van ons is dit die eerste projek van hierdie skaal. Ons het 'n aantal waardevolle lesse geleer oor hoe om as 'n span te werk en argitektoniese en ontwerpbesluite te neem. Hoe om komplekse stelsels met min hulpbronne te integreer en in produksie te rol.
Natuurlik is daar iets om aan te werk, beide in terme van kode en by die koppelvlakke van stelselintegrasie. Die projek is nogal jonk, maar ons is vol ambisies om dit te laat groei tot 'n betroubare en gerieflike diens.
Ons kon reeds die stelsels oorreed. Bill hanteer pligsgetrou tel, fakturering en gebruikersversoeke in sy kas. Die "magie" van wolframvelde bied ons stabiele kommunikasie. En net OpenStack raak soms wispelturig en skree iets soos "'WSREP het nog nie node voorberei vir toepassingsgebruik nie." Maar dis 'n heel ander storie...
Ons het onlangs die diens bekendgestel.
Jy kan al die besonderhede op ons uitvind .
CLO Ontwikkelingspan
nuttige skakels
OpenStack
Wolfram stof
Bron: will.com