ISPsystem, lihtsad ja selged lahendused! Miks ja kuidas me kirjutasime oma serverihalduspaneeli

Tere! Me oleme "Hostingu Tehnoloogiad" ja viis aastat tagasi alustasime VDSina — esimest VDS hostimist, mis on loodud spetsiaalselt arendajatele. Meie eesmärk on teha see mugavaks nagu DigitalOcean, kuid vene toega, makseviisidega ja serveritega Venemaal. Kuid DigitalOcean ei ole ainult usaldusväärsus ja hind, see on ka teenus.

ISPsystemi tarkvara muutus köieks, mis sidus meie käed teel suurepärase teenuse pakkumise poole. Kolm aastat tagasi kasutasime Billmanageri arvelduse ja VMmanageri serverihalduspaneeli ning mõistsime kiiresti, et hea teenuse pakkumine ilma oma paneelita on praktiliselt võimatu.

Kuidas ISPsystem lõhkus mugavust

Vead

Me ei saanud vigu ise parandada — iga kord pidime kirjutama kolmandate osapoolte toetusele ja ootama. Iga probleemi lahendamine nõudis kolmanda osapoole reageerimist.

ISPsystemi tugi vastas normaalselt, kuid parandused tulid alles pärast mitmeid väljalaskeid, ja see ei olnud alati ja mitte kõikide puhul. Mõnikord parandati kriitilisi vigu mitu nädalat. Me pidime kliente rahustama, vabandama ja ootama, kuni ISPsystem vea parandab.

Kadalipud

Uuendused võisid tekitada ettenägematuid seisakuid, mis põhjustasid uusi vigu.

Iga uuendus oli loterii: pidime peitma arvelduse ja tooma uuenduste jumalatele ohvreid — paar korda põhjustas uuendus 10-15 minuti seisaku. Meie administraatorid istusid sel ajal silmade all — me ei teadnud kunagi, kui kaua seisak kestab ja ei saanud ennustada, millal ISPsystem otsustab välja anda uue uuenduse.

Viiendal põlvkonnal Billmanageris läks paremaks, kuid vajalikest funktsioonidest ligipääsu saamiseks tuli installida beetaversioon, mis uuendati juba iga nädala tagant. Kui midagi murdus, pidime andma ligipääsu välistele arendajatele, et nad midagi parandaksid.

Ebamugav juhtpaneeli liides

Kõik oli jagatud erinevatesse paneelidesse ja seda haldati erinevatest kohtadest. Näiteks maksid kliendid Billmanageri kaudu, kuid VDS-i taaskäivitamine või uuesti installimine pidi toimuma VMManageris. Meie töötajad pidid samuti akende vahel vahetama, et aidata kliendil, kontrollida tema serveri koormust või vaadata, millist opsüsteemi ta kasutab.

Selline liides võtab aega — nii meie kui ka klientide jaoks. Sellises olukorras ei saa rääkida DigitalOcean'i mugavusest.

Lühikesed elutsüklid sagedaste API värskendustega.

Oleme kirjutanud oma pluginaid — näiteks makseviiside plugin, mida VMManager'is pole.

Viimastel aastatel oli VMManager'il suhteliselt lühike elutsükkel, kusjuures uusversionites võisid API-s muutuda muutujate või funktsioonide nimed — see rikkus meie pluginaid. Vanade versioonide tugi lõpetati kiiresti ja pidi uuendama.

Täitmine ei ole võimalik.

Täpsemalt on see võimalik, kuid äärmiselt ebaefektiivne. Litsentsipiirangud ei luba lähtekoodi muuta, saab ainult pluginaid kirjutada. Maximump pluginaid — mõned menüüelemendid, samm-sammuline viisard. ISPsystem on suunatud universaalsusele, kuid me vajame spetsialiseeritud lahendusi.

Nii sündis otsus kirjutada oma paneel. Seadsime eesmärgid:

• Kiire reageerimine vigadele, tõrgetele ja võimalus iseseisvalt neid kõrvaldada, sundimata klienti ootama.
• Võime vabalt kohandada liidest vastavalt tööprotsessidele ja kliendi vajadustele.
• Tõsta kasutatavust puhta ja arusaadava disaini kaudu.

Ja alustasid arendust.

Uue paneeli arhitektuur

Meil on täiesti iseseisev arendusmeeskond, mistõttu oleme paneeli ise kirjutanud.
Peamist tööd tegid kolm inseneri — tehniline direktor Sergei mõtles välja arhitektuuri ja kirjutas serveri agendi, Aleksei tegi arvelduse ning meie frontendi arendaja Artysh kokku frontendi.

Samm 1. Serveri agent

Serveri agent on veebiserver Pythonis, mis haldab raamatukogu libvirt, mis omakorda haldab hüperviisorit Qemu-kvm.

Agent haldab kõiki teenuseid serveris: VDS-i loomine, peatamine, kustutamine, operatsioonisüsteemide installimine, parameetrite muutmine ja nii edasi libvirt raamatukogu kaudu. Artikli avaldamise ajal on seda üle neljakümne erineva funktsiooni, mida täiustame vastavalt ülesandele ja kliendi vajadustele.

Idee poolest võiks libvirtiga hallata otse arveldusest, kuid see nõudis liiga palju lisakoodi ning otsustasime need funktsioonid agendi ja arveldussüsteemi vahel jagada — arveldus teeb lihtsalt päringud agendile JSON API kaudu.

Agent on esimene, mida me tegime, kuna see ei nõudnud mingit liidest ja selle testimine oli võimalik otse serveri konsoolist.

Mida meie serveri agent tõi: ilmus vahekiht, mis lihtsustab kõigi elu — arveldus ei pea edastama suurt hulka käske, vaid teeb lihtsalt päringu. Agent teeb kõik vajalikud toimingud: näiteks eraldab kettaruumi ja RAM-i.

Samm 2. Arveldamine

Meie arendaja Aleksi jaoks polnud see esimene juhtpaneel — Alesk on juba pikka aega hostingus töötanud, seega mõistis ta, mida klient vajab ja mida hosti pakkuja vajab.

Arveldamist nimetame omavahel «juhtpaneeliks»: seal ei ole mitte ainult raha ja teenuseid, vaid ka nende haldamine, klienditugi ja palju muud.

ISPSystem'i tarkvara vahetamiseks oli vajalik täielikult säilitada eelmine funksionaalsus klientidele, kanda kõik kasutajate finantstehingud vanast arveldussüsteemist uude, samuti kõik teenused ja nendevahelised suhted. Uurisime, mis praeguses tootes on, seejärel konkurentide lahendusi, peamiselt DO ja Vultr. Vaatasime puuduseid ja eeliseid, kogusime tagasisidet inimestelt, kes on töötanud ISPsystemi vanade toodete kallal.

Uues arveldussüsteemis kasutasime kahte steki: klassikaline PHP, MySQL (ja tulevikus plaanime üle minna PostgreSQL'ile), Yii2 raamistik tagaküljel ja VueJS esiküljel. Stekid töötavad üksteisest eraldi, neid arendavad erinevad inimesed ning nad suhtlevad JSON API kaudu. Arenduseks oleme kasutanud PHPStorm ja WebStorm JetBrainsilt ning armastame neid väga (tervitame, poisid!)

Paneel on kavandatud modulaarse põhimõtte järgi: maksesüsteemide moodul, domeeniregistrite moodul või näiteks SSL-sertifikaatide moodul. Uue funktsiooni lisamine või vana eemaldamine on lihtne. Laiendamiseks on arhitektuurses mõttes rajatud alus, sealhulgas ka „rauda“.

Mida me saime: juhtpaneel, mille üle meil on täielik kontroll. Nüüd parandatakse tõrkeid tundide jooksul, mitte nädalate jooksul, ja uusi funktsioone rakendatakse klientide soovi järgi, mitte ISPSystemi tahtmise järgi.

3. samm. Liidese loomine

Liides on meie meeskonna looming.

Alguses mõtlesime, mida saaks teha ISPsystemi API-le põhinedes, mitte liidest drastiliselt muutes. Tulemus oli kesine ja otsustasime luua kõik nullist.

Usume, et peamine on luua loogiline liides, puhta ja minimalistliku disainiga, et saada ilus juhtpaneel. Elementide asukohta arutati Megaplanis ja järk-järgult tekkis see liides, mida kasutajad näevad praegu juhtpaneelil.

Esimesena valmis arvehalduse lehekujundus, kuna olime juba loonud maksepluginad ISPsystemi jaoks.

Frontend

Otsustasime luua paneelist SPA rakenduse, mis on kerge ja kiire andmete laadimisega. Meie frontend arendaja Artur valis selle kirjutamiseks Vue, kuna see ise oli just ilmunud. Me oletame, et raamistik areneb dünaamiliselt, nagu React, ja varsti kasvab Vue kogukond ning ilmub hulk teeke. Me panustasime Vue-le ja pole kahetsenud — nüüd uute funktsioonide lisamine front-endile, mis on juba backendis programmeeritud, võtab vähe aega. Räägime paneeli front-endist eraldi artiklis.

Frontend'i ja backend'i ühendus

Frontend ühendati backend'iga pushite kaudu. Pidi kõvasti vaeva nägema ja kirjutama oma töötleja, kuid nüüd toimub teabe värskendamine lehe peal peaaegu koheselt.

Mida me saavutasime: paneeli liides on saanud lihtsamaks. Me tegime selle responsiivseks, ja kiire laadimine võimaldab seda kasutada ka mobiiltelefonidest just enne starti, ilma et peaks eraldi rakendust installima paneeliga töötamiseks.

Samm 4. Testimine ja migratsiooniskeem

Kui kõik oli käima läinud ja esimesed testid tehtud, tekkis küsimus migratsioonist. Esmalt seadistasime arvelduse ja hakkasime testima selle töötamist serveriagendiga.

Siis kirjutasime lihtsa skripti, mis viib andmebaasi vana arveldamise süsteemist uude.

Pidime testima ja uuesti kontrollima praktiliselt kõike, kuna andmed koondati ühte uude andmebaasi kolmest vanast: Billmanager, VMmanager ja IPmanager. Võib öelda, et testmigratsioonid olid kõige keerulisemad, millega me uue paneeli arendamise käigus silmitsi seisime.

Pärast uuesti kontrollimist sulgesime vana arvelduse. Andmete lõplik migratsioon oli väga ärev hetk, kuid õnneks teostus see mõne minuti jooksul ja ilma nähtavate probleemideta. Esines väikseid vigu, mida me parandasime nädala jooksul. Enamik aega kulus selle testimise peale, mis välja tuli.

Seejärel saatsime klientidele kirjad uue paneeli ja arvelduse aadressiga ning tegime ümbersuunamise.

Kokkuvõttes: SEE ON ELUS!

Õnnelik lõpp

Esimestest tundidest oma tarkvara töös tundsime üle minemise kõiki eeliseid. Kood oli täiesti meie oma, mugava arhitektuuriga, ja liides oli puhas ja loogiline.

Esimene tagasiside uue paneeli käivitamise järel

Me alustasime ülemineku protsessi detsembris, vahetult enne 2017. aasta uut aastat, kui koormus oli kõige väiksem, et muuta üleminek klientidele lihtsamaks — peaaegu keegi ei tööta pühade eel.

Peamine, mida me oma süsteemile ülemisel saime (välja arvatud üldine usaldusväärsus ja mugavus) — võimalus kiiresti lisada funktsioone võtmeklientide vajadustele — olla nende nägu, mitte tagaplane.

Mis edasi?

Me kasvame, kasvab andmete, klientide ja klientide andmete hulk. Tagaküljel pidime lisama Memcached-serveri ja kaks queue manegerit erinevate ülesannete jaoks. Eesliinil on vahemälu ja oma järjekorrad.

Muidugi olid meil veel seiklused toote arendamisel ja keerukuse suurendamisel, näiteks kui lisasime HighLoad'i.

Järgmises artiklis räägime, kuidas käivitasime Hi-CPU plaani: riistvara, tarkvara, milliseid ülesandeid me lahendasime ja mis meil välja tuli.

Allikas: habr.com