IT-alal töötades hakkate märkama, et süsteemidel on oma iseloom. Need võivad olla paindlikud, vaiksed, ekstsentrilised ja karmid. Nad võivad meelitada või tõrjuda. Ühel või teisel viisil tuleb nendega “läbirääkimisi pidada”, “lõkse” vahel manööverdada ja ehitada nende suhtlusahelaid.
Seega oli meil au luua pilveplatvorm ja selleks oli meil vaja paar alamsüsteemi meiega koostööd teha. Õnneks on meil “API keel”, otsesed käed ja palju entusiasmi.
See artikkel ei ole tehniliselt raske, vaid kirjeldab probleeme, millega pilve loomisel kokku puutusime. Otsustasin kirjeldada meie teed kerge tehnilise fantaasia vormis sellest, kuidas otsisime süsteemidega ühist keelt ja mis sellest välja tuli.
Tere tulemast kassi.
Algus reisi
Mõni aeg tagasi sai meie meeskonna ülesandeks käivitada meie klientide jaoks pilveplatvorm. Meil oli haldustugi, ressursid, riistvarapinn ja vabadus valida tehnoloogiaid teenuse tarkvaraosa juurutamiseks.
Samuti oli mitmeid nõudeid:
- teenus vajab mugavat isiklikku kontot;
- platvorm tuleb integreerida olemasolevasse arveldussüsteemi;
- tarkvara ja riistvara: OpenStack + Tungsten Fabric (Open Contrail), mida meie insenerid on õppinud päris hästi “küpsetama”.
Sellest, kuidas meeskond komplekteeriti, personaalset kontoliidest arendati ja disainiotsuseid langetati, räägime teile teine kord, kui Habra kogukond on huvitatud.
Tööriistad, mida otsustasime kasutada:
- Python + Flask + Swagger + SQLAlchemy – täiesti standardne Pythoni komplekt;
- Vue.js kasutajaliidese jaoks;
- Otsustasime komponentide ja teenuste vahelise suhtluse läbi AMQP Celery abil.
Ennetades Pythoni valimise küsimusi, selgitan. Keel on meie ettevõttes leidnud oma niši ja selle ümber on välja kujunenud väike, kuid siiski kultuur. Seetõttu otsustati hakata teenust sellele üles ehitama. Pealegi on selliste probleemide puhul sageli määrav arengukiirus.
Niisiis, alustame oma tutvust.
Vaikne arve – arveldamine
Oleme seda meest juba pikka aega tundnud. Ta istus alati minu kõrval ja luges vaikides midagi. Mõnikord edastas ta meile kasutajate päringuid, väljastas klientidele arveid ja haldas teenuseid. Tavaline töökas mees. Tõsi, raskusi oli. Ta on vaikne, mõnikord mõtlik ja sageli omapäi.
Arveldamine on esimene süsteem, millega proovisime sõbruneda. Ja esimene raskus, millega me kokku puutusime, oli teenuste töötlemisel.
Näiteks kui ülesanne luuakse või kustutatakse, läheb see sisemisse arveldusjärjekorda. Seega rakendatakse teenustega asünkroonse töö süsteem. Teenusetüüpide töötlemiseks pidime oma ülesanded sellesse järjekorda panema. Ja siin puutusime kokku probleemiga: dokumentide puudumine.
Tarkvara API kirjelduse järgi otsustades on see probleem veel võimalik lahendada, kuid meil polnud aega pöördprojekteerimiseks, nii et võtsime loogika väljastpoolt ja korraldasime RabbitMQ peale ülesannete järjekorra. Teenuse toimingu algatab klient oma isiklikult kontolt, see muutub taustaprogrammis Celery “ülesandeks” ja seda tehakse arvelduse ja OpenStacki poolel. Seller muudab ülesannete haldamise, korduste korraldamise ja oleku jälgimise üsna mugavaks. Selleri kohta saate rohkem lugeda näiteks .
Samuti ei peatanud arvete esitamine projekti, mille raha otsa sai. Arendajatega suheldes saime teada, et statistika arvutamisel (ja just sellist loogikat peame rakendama) on peatamisreeglite vahel keerukas vastastikune seos. Kuid need mudelid ei sobi hästi meie tegelikkusega. Rakendasime selle ka Selery ülesannete kaudu, viies teenusehalduse loogika taustapoolele.
Mõlemad ülaltoodud probleemid viisid selleni, et kood läks veidi ülespuhutud ja edaspidi peame ümber tegema, et ülesannetega töötamise loogika eraldi teenusesse viia. Selle loogika toetamiseks peame oma tabelitesse salvestama ka teavet kasutajate ja nende teenuste kohta.
Teine probleem on vaikus.
Billy vastab mõnele API päringule vaikselt „Ok”. Nii juhtus näiteks siis, kui sooritasime testi ajal lubatud maksete makseid (sellest lähemalt hiljem). Päringud täideti õigesti ja me ei näinud ühtegi viga.
Pidin logisid uurima UI kaudu süsteemiga töötades. Selgus, et arveldamine ise teostab sarnaseid päringuid, muutes ulatuse konkreetsele kasutajale, näiteks admin, edastades selle parameetris su.
Üldiselt läks vaatamata dokumentatsiooni lünkadele ja väikestele API-vigadele kõik üsna hästi. Logisid saab lugeda ka suure koormuse korral, kui mõistate, kuidas need on üles ehitatud ja mida otsida. Andmebaasi ülesehitus on küll ehitud, kuid üsna loogiline ja mõnes mõttes isegi atraktiivne.
Kokkuvõtteks võib öelda, et peamised probleemid, millega suhtlemise etapis kokku puutusime, on seotud konkreetse süsteemi rakendusfunktsioonidega:
- dokumenteerimata "omadused", mis meid ühel või teisel viisil mõjutasid;
- suletud lähtekoodiga (arveldamine on kirjutatud C++ keeles), selle tulemusena - probleemi 1 on võimatu lahendada muul viisil kui katse-eksituse meetodil.
Õnneks on tootel üsna ulatuslik API ja oleme integreerinud oma isiklikule kontole järgmised alamsüsteemid:
- tehnilise toe moodul - teie isikliku konto päringud on teenuseklientide jaoks läbipaistvalt edastatud arveldamiseks;
- finantsmoodul - võimaldab väljastada praegustele klientidele arveid, teha mahakandmisi ja genereerida maksedokumente;
- teenindusjuhtimismoodul - selleks pidime juurutama oma käitleja. Süsteemi laiendatavus mängis meie kätes ja "õpetasime" Billyle uut tüüpi teenust.
See oli natuke tülikas, aga nii või teisiti, ma arvan, et me Billyga saame omavahel läbi.
Kõndimine läbi volframiväljade – Tungsten Fabric
Volframväljad, mis on täis sadu juhtmeid, edastades nende kaudu tuhandeid bitte teavet. Teave kogutakse "pakettidesse", sõelutakse, ehitades keerulisi marsruute, justkui võluväel.
See on teise süsteemi domeen, millega me sõbrunesime – Tungsten Fabric (TF), varem OpenContrail. Selle ülesandeks on hallata võrguseadmeid, pakkudes meile kui kasutajatele tarkvara abstraktsiooni. TF - SDN, kapseldab võrguseadmetega töötamise keerulist loogikat. Tehnoloogia enda kohta on hea artikkel, näiteks .
Süsteem on integreeritud OpenStackiga (seda käsitletakse allpool) Neutroni pistikprogrammi kaudu.
OpenStacki teenuste koostoime.
Operatiivosakonna poisid tutvustasid meile seda süsteemi. Kasutame oma teenuste võrguvirna haldamiseks süsteemi API-d. See ei ole meile veel tõsiseid probleeme ega ebamugavusi tekitanud (ma ei saa rääkida OE kuttide nimel), kuid suhtluses on olnud veidrusi.
Esimene nägi välja selline: käsud, mis nõudsid SSH kaudu ühenduse loomisel suure hulga andmete väljastamist eksemplari konsooli, lihtsalt "riputasid" ühenduse, samas kui VNC kaudu töötas kõik õigesti.
Neile, kes pole probleemiga kursis, tundub see üsna naljakas: ls /root töötab õigesti, samas kui näiteks top "külmub" täielikult. Õnneks oleme sarnaste probleemidega ka varem kokku puutunud. See otsustati MTU häälestamisega marsruudil arvutussõlmedest ruuteriteni. Muide, see pole TF probleem.
Järgmine probleem oli kohe nurga taga. Ühe “ilusa” hetkega kadus marsruutimise võlu, niisama. TF on lõpetanud seadmete marsruutimise haldamise.
Töötasime Openstackiga alates adminni tasemelt ja pärast seda liikusime vajalikule kasutajatasemele. Näib, et SDN "kaaperdab" selle kasutaja ulatuse, kes toiminguid teeb. Fakt on see, et TF-i ja OpenStacki ühendamiseks kasutatakse sama administraatori kontot. Kasutajale ülemineku etapil kadus "maagia". Süsteemiga töötamiseks otsustati luua eraldi konto. See võimaldas meil töötada ilma integratsioonifunktsiooni rikkumata.
Silicon Lifeforms – OpenStack
Volframiväljade läheduses elab veidra kujuga silikoonist olend. Kõige rohkem näeb see välja nagu ülekasvanud laps, kes suudab meid ühe kiiksuga muserdada, kuid temast ei tule ilmselget agressiivsust. See ei tekita hirmu, kuid selle suurus tekitab hirmu. Nagu ka ümberringi toimuva keerukus.
OpenStack on meie platvormi tuum.
OpenStackil on mitu alamsüsteemi, millest praegu kasutame kõige aktiivsemalt Novat, Glance’i ja Cinderit. Igal neist on oma API. Nova vastutab arvutusressursside ja eksemplaride loomise eest, Cinder vastutab mahtude ja nende hetketõmmiste haldamise eest, Glance on pilditeenus, mis haldab OS-i malle ja nende metainfot.
Iga teenus töötab konteineris ja sõnumite vahendajaks on "valge jänes" - RabbitMQ.
See süsteem tekitas meile kõige ootamatuma probleemi.
Ja esimene probleem ei lasknud end kaua oodata, kui proovisime serveriga täiendavat helitugevust ühendada. Cinder API keeldus kindlalt seda ülesannet täitmast. Täpsemalt, kui uskuda OpenStacki ennast, on ühendus loodud, kuid virtuaalserveris pole kettaseadet.
Otsustasime teha ümbersõidu ja taotlesime sama toimingut Nova API-lt. Tulemuseks on see, et seade ühendub õigesti ja on serveris juurdepääsetav. Näib, et probleem ilmneb siis, kui plokk-salvestus ei reageeri Cinderile.
Veel üks raskus ootas meid ketastega töötades. Süsteemi helitugevust ei saanud serveriga lahti ühendada.
Jällegi, OpenStack ise "vannub", et on ühenduse hävitanud ja nüüd saate helitugevusega õigesti töötada. Kuid API ei tahtnud kategooriliselt kettaga toiminguid teha.
Siin otsustasime mitte eriti tülitseda, vaid muuta oma arvamust teenuse loogikast. Kui eksemplar on olemas, peab olema ka süsteemi maht. Seetõttu ei saa kasutaja veel süsteemi "ketast" eemaldada ega keelata ilma "serverit" kustutamata.
OpenStack on üsna keeruline süsteemide komplekt, millel on oma interaktsiooniloogika ja kaunistatud API. Meid aitab üsna detailne dokumentatsioon ja loomulikult katse-eksitus (kus me oleksime ilma selleta).
Proovisõit
Viisime testkäivituse läbi eelmise aasta detsembris. Peamine ülesanne oli testida meie projekti lahingurežiimis tehnilise poole pealt ja UX poolelt. Publik kutsuti kohale valikuliselt ja testimine suleti. Kuid oleme jätnud ka võimaluse taotleda juurdepääsu oma veebisaidil testimisele.
Test ise ei olnud muidugi naljakate hetkedeta, sest siin on meie seiklused alles algamas.
Esiteks hindasime projekti vastu huvi mõnevõrra valesti ja pidime kohe testi ajal kiiresti arvutussõlmed lisama. Tavaline juhtum klastri puhul, kuid ka siin oli mõningaid nüansse. Konkreetse TF-i versiooni dokumentatsioon näitab kerneli konkreetset versiooni, millel testiti vRouteriga töötamist. Otsustasime käivitada sõlmed uuemate tuumadega. Selle tulemusena ei saanud TF sõlmedelt marsruute. Pidin tuumad kiiresti tagasi kerima.
Veel üks uudishimu on seotud teie isikliku konto nupu "Muuda parooli" funktsionaalsusega.
Otsustasime kasutada JWT-d oma isiklikule kontole juurdepääsu korraldamiseks, et mitte seanssidega töötada. Kuna süsteemid on mitmekesised ja laialt hajutatud, haldame oma tokenit ise, millesse "mähime" seansid arveldamisest ja OpenStacki märgi. Parooli muutmisel läheb token loomulikult halvaks, kuna kasutajaandmed ei kehti enam ja need tuleb uuesti väljastada.
Kaotasime selle punkti silmist ja selle tüki kiireks lõpetamiseks lihtsalt ei jätkunud ressursse. Vahetult enne testi käivitamist pidime funktsioonid välja lülitama.
Hetkel logime kasutajast välja, kui parooli on muudetud.
Nendest nüanssidest hoolimata läks testimine hästi. Paari nädala jooksul peatus umbes 300 inimest. Saime toodet vaadata läbi kasutajate silmade, testida seda tegevuses ja koguda kvaliteetset tagasisidet.
Et jätkata
Paljudele meist on see esimene sellises mahus projekt. Saime mitmeid väärtuslikke õppetunde, kuidas töötada meeskonnana ning teha arhitektuuri- ja disainiotsuseid. Kuidas integreerida väheste ressurssidega keerulisi süsteeme ja viia need tootmisse.
Muidugi on, mille kallal töötada nii koodi kui ka süsteemiintegratsiooni liideste osas. Projekt on üsna noor, kuid oleme täis ambitsioone kasvatada see usaldusväärseks ja mugavaks teenuseks.
Oleme juba suutnud süsteeme ümber veenda. Bill käsitleb oma kapis kohusetundlikult loendamist, arveldamist ja kasutajate taotlusi. Volframiväljade "maagia" tagab meile stabiilse suhtluse. Ja ainult OpenStack muutub mõnikord kapriisseks, karjudes midagi sellist nagu "WSREP pole veel sõlme rakenduse kasutamiseks ette valmistanud." Aga see on hoopis teine lugu...
Hiljuti käivitasime teenuse.
Kõik üksikasjad leiate meie lehelt .
CLO arendusmeeskond
Kasulikud lingid
OpenStack
Volfram kangas
Allikas: www.habr.com