Informatikan lan egiten duzun heinean, sistemak bere izaera dutela nabaritzen hasten zara. Malguak, isilak, eszentrikoak eta zorrotzak izan daitezke. Erakarri edo uxatu ditzakete. Era batera edo bestera, haiekin "negoziatu", "zuloen" artean maniobratu eta haien elkarrekintzaren kateak eraiki behar dituzu.
Beraz, hodeiko plataforma bat eraikitzeko ohorea izan genuen, eta horretarako azpisistema pare bat "konbentzitu" behar genituen gurekin lan egiteko. Zorionez, βAPI lengoaiaβ dugu, esku zuzenak eta ilusio handia.
Artikulu hau ez da teknikoki gogorra izango, baina hodeia eraikitzean aurkitu ditugun arazoak deskribatuko ditu. Gure bidea deskribatzea erabaki nuen fantasia tekniko arin baten moduan nola bilatzen genuen sistemarekin hizkuntza komuna eta zer ateratzen zen.
Ongi etorri katura.
Bidaia baten hasiera
Duela denbora pixka bat, gure taldea gure bezeroentzako hodeiko plataforma bat abian jartzeaz arduratu zen. Kudeaketarako laguntza, baliabideak, hardware pila eta askatasuna izan genituen zerbitzuaren softwarearen zatia ezartzeko teknologiak aukeratzeko.
Baldintza batzuk ere bazeuden:
- zerbitzuak kontu pertsonal erosoa behar du;
- plataformak dagoen fakturazio sisteman integratu behar du;
- softwarea eta hardwarea: OpenStack + Tungsten Fabric (Open Contrail), gure ingeniariek nahiko ondo "sukaldatzen" ikasi dutena.
Beste behin kontatuko dizugu taldea nola osatu zen, kontu pertsonalaren interfazea garatu zen eta diseinu-erabakiak hartu ziren, Habra komunitateak interesa badu.
Erabiltzea erabaki genuen tresnak:
- Python + Flask + Swagger + SQLAlchemy - Python multzo guztiz estandarra;
- Vue.js frontend-erako;
- Osagaien eta zerbitzuen arteko elkarrekintza AMQPren bidez Celery erabiliz egitea erabaki genuen.
Python aukeratzeari buruzko galderak aurreikusita, azalduko dut. Hizkuntzak gure enpresan aurkitu du bere txokoa eta horren inguruan kultura txikia, baina oraindik ere, garatu da. Horregatik, bertan zerbitzua eraikitzen hastea erabaki zen. Gainera, horrelako arazoen garapen-abiadura erabakigarria izaten da askotan.
Beraz, has gaitezen gure ezagutzen.
Silent Bill - fakturazioa
Aspalditik ezagutzen dugu mutil hau. Beti nire ondoan esertzen zen eta isilik zerbait kontatzen zuen. Batzuetan erabiltzaileen eskaerak helarazten zizkigun, bezeroen fakturak igorri eta zerbitzuak kudeatzen zituen. Tipo langile arrunta. Egia da, zailtasunak zeuden. Isilik dago, batzuetan pentsakor eta askotan bere buruan.
Fakturazioa lagun egiten saiatu ginen lehen sistema da. Eta topatu genuen lehen zailtasuna zerbitzuak prozesatzeko orduan izan zen.
Adibidez, sortu edo ezabatzean, zeregin bat barne fakturazio-ilarara sartzen da. Horrela, zerbitzuekin lan asinkronoko sistema bat ezartzen da. Gure zerbitzu motak prozesatzeko, gure zereginak ilara honetan "jarri" behar genituen. Eta hemen arazo batekin egin genuen topo: dokumentazio falta.
Softwarearen APIaren deskribapena ikusita, oraindik posible da arazo hau konpontzea, baina ez genuen astirik izan alderantzizko ingeniaritza egiteko, beraz, logika kanpora atera genuen eta RabbitMQ-ren gainean zeregin-ilara bat antolatu genuen. Zerbitzu baten eragiketa bat bezeroak bere kontu pertsonaletik hasten du, atzealdean "zeregin" bihurtzen da eta fakturazio eta OpenStack aldean egiten da. Apioa nahiko erosoa da zereginak kudeatzea, errepikapenak antolatzea eta egoera kontrolatzea. "Apioari" buruzko informazio gehiago irakur dezakezu, adibidez, .
Gainera, fakturazioak ez zuen geldiarazi dirurik gabe geratu zen proiektu bat. Garatzaileekin komunikatuta, estatistikak kalkulatzerakoan (eta zehatz-mehatz logika hori ezarri behar dugu), gelditzeko arauen arteko erlazio konplexua dagoela jakin genuen. Baina eredu hauek ez datoz ongi gure errealitatearekin. Apioaren zereginen bidez ere inplementatu dugu, zerbitzuen kudeaketa logika backend-era eramanez.
Aurreko bi arazoek kodea apur bat puztuta egotea ekarri zuten eta etorkizunean birfaktorea egin beharko dugu zereginekin lan egiteko logika zerbitzu berezi batera eramateko. Erabiltzaileei eta haien zerbitzuei buruzko informazio batzuk ere gorde behar ditugu gure tauletan logika hori onartzeko.
Beste arazo bat isiltasuna da.
Billy-k isilik erantzuten die "Ok" API eskaera batzuei. Hori gertatu zen, adibidez, proban zehar agindutako ordainketen ordainketak egin genituenean (hori gehiago geroago). Eskaerak behar bezala exekutatu dira eta ez dugu akatsik ikusi.
Erregistroak aztertu behar izan ditut UI bidez sistemarekin lan egiten nuen bitartean. Fakturazioak berak antzeko eskaerak egiten dituela ikusi zen, erabiltzaile jakin bati esparrua aldatuz, adibidez, admin, su parametroan pasatuz.
Oro har, dokumentazioan hutsuneak eta API akats txikiak izan arren, dena nahiko ondo joan da. Erregistroak karga handian ere irakur daitezke, nola egituratuta dauden eta zer bilatu behar den ulertzen baduzu. Datu-basearen egitura apainduta dago, baina nahiko logikoa eta erakargarria ere bai.
Beraz, laburbilduz, elkarrekintza fasean aurkitu ditugun arazo nagusiak sistema zehatz baten ezarpen-ezaugarriekin lotuta daude:
- era batera edo bestera eragiten ziguten dokumenturik gabeko βezaugarriakβ;
- iturri itxia (fakturazioa C++-n idatzita dago), ondorioz, ezinezkoa da 1. arazoa "saiakuntza eta errorea" ez den beste modu batean konpontzea.
Zorionez, produktuak API nahiko zabala du eta azpisistema hauek sartu ditugu gure kontu pertsonalean:
- laguntza teknikoko modulua - zure kontu pertsonalaren eskaerak zerbitzu-bezeroentzako gardentasunez fakturatzera bideratzen dira;
- finantza-modulua - egungo bezeroei fakturak igortzeko, baliogabetzeak egiteko eta ordainketa dokumentuak sortzeko aukera ematen du;
- zerbitzuaren kontrol modulua - horretarako gure kudeatzailea ezarri behar izan dugu. Sistemaren hedagarritasuna gure esku zegoen eta Billyri zerbitzu mota berri bat "irakatsi" genion.
Zale samarra izan zen, baina modu batera edo bestera, Billy eta biok ondo moldatuko garela uste dut.
Tungsteno zelaietan barrena ibiltzea β Tungsteno ehuna
Ehunka hariz zipriztindutako wolframio-eremuak, milaka informazio-bit pasatzen dituzte haietatik. Informazioa "paketeetan" biltzen da, analizatuta, ibilbide konplexuak eraikiz, magiaz bezala.
Lagunak egin behar izan genituen bigarren sistemaren domeinua da hau - Tungsten Fabric (TF), lehen OpenContrail. Bere zeregina sareko ekipoak kudeatzea da, erabiltzaile gisa software abstrakzio bat eskainiz. TF - SDN, sareko ekipoekin lan egiteko logika konplexua biltzen du. Artikulu on bat dago teknologia berari buruz, adibidez, .
Sistema OpenStack-ekin integratuta dago (behean eztabaidatua) Neutron pluginaren bidez.
OpenStack zerbitzuen elkarrekintza.
Operazio saileko mutilek sistema hau aurkeztu ziguten. Sistemaren APIa erabiltzen dugu gure zerbitzuen sare-pila kudeatzeko. Oraindik ez digu arazo edo eragozpen larririk sortu (Ezin dut OEko mutilen alde hitz egin), baina elkarrekintzan bitxikeria batzuk egon dira.
Lehenengoa honelakoa zen: SSH bidez konektatzean instantzia kontsolara datu kopuru handia atera behar zuten komandoek konexioa "zintzilikatu" zuten, VNC bidez dena behar bezala funtzionatzen zuen bitartean.
Arazoa ezagutzen ez dutenentzat, nahiko dibertigarria dirudi: ls /root-ek behar bezala funtzionatzen du, eta, adibidez, goikoa guztiz "izozten" da. Zorionez, lehenago ere antzeko arazoak topatu ditugu. Konputazio-nodoetatik bideratzaileetara doan ibilbidean MTU sintonizatuz erabaki zen. Bide batez, hau ez da TF arazo bat.
Hurrengo arazoa izkinan zegoen. Momentu "eder" batean, bideratzearen magia desagertu zen, halaxe. TF-k ekipamenduko bideratzea kudeatzeari utzi dio.
Openstack-ekin administratzaile mailatik lan egin genuen eta, ondoren, beharrezko erabiltzaile mailara pasatu ginen. SDN-k ekintzak egiten dituen erabiltzailearen esparrua "bahitu" duela dirudi. Kontua da administratzaile kontu bera erabiltzen dela TF eta OpenStack konektatzeko. Erabiltzailera aldatzeko urratsean, "magia" desagertu egin zen. Sistemarekin lan egiteko aparteko kontu bat sortzea erabaki zen. Horri esker, integrazio-funtzionalitatea hautsi gabe lan egin genuen.
Silicon Lifeforms - OpenStack
Forma bitxiko silikonazko izaki bat wolframio-eremuetatik gertu bizi da. Batez ere, kolunpio batez zapal ditzakeen ume hazi baten itxura du, baina ez da harengandik datorren eraso nabaririk. Ez du beldurrik eragiten, baina bere tamainak beldurra pizten du. Inguruan gertatzen denaren konplexutasuna ere bai.
OpenStack gure plataformaren muina da.
OpenStack-ek hainbat azpisistema ditu, eta horietatik Nova, Glance eta Cinder erabiltzen ditugu modu aktiboenean. Horietako bakoitzak bere APIa du. Nova konputazio-baliabideez eta instantzien sorreraz arduratzen da, Cinder bolumenak eta haien argazkiak kudeatzeaz arduratzen da, Glance sistema eragilearen txantiloiak eta horien metainformazioa kudeatzen dituen irudi-zerbitzua da.
Zerbitzu bakoitza edukiontzi batean exekutatzen da, eta mezu-artekaria "untxi zuria" da - RabbitMQ.
Sistema honek eman zigun ustekabeko arazorik.
Eta lehen arazoa ez zen luze gertatu zerbitzariari bolumen gehigarri bat konektatzen saiatu ginenean. Cinder API-k erabat uko egin zion zeregin hori egiteari. Zehatzago esanda, OpenStack bera sinesten baduzu, konexioa ezarrita dago, baina ez dago disko gailurik zerbitzari birtualean.
Saihesbide bat egitea erabaki genuen eta ekintza bera eskatu genion Nova APIari. Ondorioz, gailua behar bezala konektatzen da eta zerbitzarian eskuragarri dago. Badirudi arazoa bloke-biltegiratzeak Cinder-i erantzuten ez dionean gertatzen dela.
Diskoekin lan egiteko beste zailtasun bat itxaroten zitzaigun. Sistemaren bolumena ezin izan da zerbitzaritik deskonektatu.
Berriz ere, OpenStack-ek berak "zin egiten du" konexioa suntsitu duela eta orain behar bezala lan egin dezakezu bolumenarekin bereizita. Baina APIak kategorikoki ez zuen diskoan eragiketarik egin nahi.
Hemen bereziki ez borrokatzea erabaki genuen, zerbitzuaren logikaren ikuspegia aldatzea baizik. Instantzia bat badago, sistemaren bolumen bat ere egon behar du. Hori dela eta, erabiltzaileak ezin du oraindik sistemaren "diskoa" kendu edo desgaitu "zerbitzaria" ezabatu gabe.
OpenStack sistema multzo konplexu samarra da, bere interakzio-logika eta API apaindua duena. Dokumentazio nahiko zehatza eta, noski, saiakerak (non egongo ginateke hori gabe) laguntzen gaitu.
Proba martxan
Iazko abenduan proba bat abiarazi genuen. Zeregin nagusia gure proiektua borroka moduan probatzea izan zen, alde teknikotik eta UX aldetik. Ikusleak modu selektiboan gonbidatu zituzten eta proba itxi zen. Hala ere, gure webgunean azterketarako sarbidea eskatzeko aukera ere utzi dugu.
Proba bera, noski, ez zen momentu dibertigarririk gabea izan, hementxe hasten baitira gure abenturak.
Lehenik eta behin, zertxobait gaizki baloratu genuen proiektuaren interesa eta azkar gehitu behar izan genituen konputazio-nodoak proban zehar. Kluster baten kasu arrunta, baina hemen ere bazeuden Γ±abardura batzuk. TF-ren bertsio zehatz baterako dokumentazioak vRouter-ekin lana probatu den nukleoaren bertsio zehatza adierazten du. Azken kernelekin nodoak abiaraztea erabaki genuen. Ondorioz, TF-k ez zituen nodoetatik biderik jaso. Premiazkoa atzera bota behar izan nuen nukleoak.
Beste bitxikeria bat zure kontu pertsonaleko "aldatu pasahitza" botoiaren funtzionaltasunari dagokio.
JWT erabiltzea erabaki genuen gure kontu pertsonalerako sarbidea antolatzeko, saioekin ez lan egiteko. Sistemak askotarikoak eta sakabanatuta daudenez, geure tokena kudeatzen dugu, eta saioak fakturaziotik eta OpenStack-eko token bat "biltzen ditugu". Pasahitza aldatzen denean, tokena, noski, "txartu egiten da", erabiltzailearen datuak jada ez dira baliozkoak eta berriro kaleratu behar direlako.
Puntu hau bistatik galdu genuen, eta ez zegoen pieza hau azkar amaitzeko baliabide nahikorik. Proba abiarazi baino lehen funtzionalitatea moztu behar izan dugu.
Momentu honetan erabiltzaileari saioa amaitzen diogu pasahitza aldatu bada.
Γabardura horiek gorabehera, probak ondo joan ziren. Aste pare batean, 300 lagun inguru gelditu ziren. Produktua erabiltzaileen begietatik begiratu, ekintzan probatu eta kalitate handiko iritzia jaso ahal izan dugu.
Jarraitu ahal izateko
Gutako askorentzat hauxe da eskala honetako lehen proiektua. Hainbat ikasgai baliotsu ikasi genituen taldean lan egin eta arkitektura eta diseinuaren erabakiak hartzeari buruz. Baliabide gutxiko sistema konplexuak nola integratu eta ekoizpenera txertatu.
Jakina, badago zerbait lantzeko bai kodeari dagokionez, bai sistema integratzeko interfazeetan. Proiektua nahiko gaztea da, baina zerbitzu fidagarri eta eroso bihurtzeko asmoez beteta gaude.
Dagoeneko sistemak konbentzitzeko gai izan gara. Billek arretaz kudeatzen ditu kontaketak, fakturazioak eta erabiltzaileen eskaerak bere armairuan. Wolframio-eremuen "magiak" komunikazio egonkorra eskaintzen digu. Eta OpenStack bakarrik bihurtzen da batzuetan kapritxosoa, "'WSREP-ek ez du oraindik nodo prestatu aplikazioa erabiltzeko". Baina hori guztiz bestelako istorio bat da...
Duela gutxi jarri dugu martxan zerbitzua.
Xehetasun guztiak gure webgunean aurki ditzakezu .
CLO garapen taldea
Esteka interesgarriak
OpenStack
Tungsteno ehuna
Iturria: www.habr.com