Hallo! Ons is "Hosting Technologies" en is 5 jaar gelede bekendgestel - die eerste vds-hosting wat spesifiek vir ontwikkelaars geskep is. Ons streef daarna om dit gerieflik te maak, soos DigitalOcean, maar met Russiese ondersteuning, betaalmetodes en bedieners in Rusland. Maar DigitalOcean is nie net betroubaarheid en prys nie, dit is ook 'n diens.
Sagteware van ISPsystem het geblyk 'n tou te wees wat ons hande vasgebind het op pad na 'n cool diens. Drie jaar gelede het ons Billmanager-fakturering en die VMmanager-bedienerbeheerpaneel gebruik en vinnig besef dat dit byna onmoontlik was om 'n goeie diens te lewer sonder ons eie beheerpaneel.
Hoe ISP-stelsel gemak doodgemaak het
Goggas
Ons kon nie self die fout regmaak nie – elke keer moes ons aan iemand anders se ondersteuning skryf en wag. Die oplossing vir enige probleem het die reaksie van 'n derdepartymaatskappy vereis.
ISP-stelselondersteuning het normaal gereageer, maar regstellings het eers na 'n paar vrystellings gekom, en dan nie altyd nie en nie almal nie. Soms is kritieke foute vir 'n paar weke reggestel. Ons moes kliënte gerusstel, om verskoning vra en wag vir ISPsystem om die fout reg te stel.
Stilstandbedreiging
Opdaterings kan onvoorspelbare stilstand veroorsaak wat nuwe foute uitgelok het.
Elke opdatering was 'n lotery: ek moes rekeninge toesmeer en opofferings maak aan die gode van opdaterings - 'n paar keer het die opdatering stilstand vir 10-15 minute veroorsaak. Ons admins het op hierdie tydstip op hul oë gesit - ons het nooit geweet hoe lank die stilstand sou duur nie en kon nie voorspel wanneer ISPsystem sou besluit om 'n nuwe opdatering vry te stel nie.
Op die vyfde generasie het Billmanager beter geword, maar om toegang tot die nodige kenmerke te kry, moes ek 'n beta installeer, wat reeds elke week opgedateer is. As iets gebreek het, moes ek toegang gee aan ander ontwikkelaars sodat hulle iets kon regmaak.
Ongemaklike paneelkoppelvlak
Alles is in verskillende panele verdeel en vanaf verskillende plekke beheer. Kliënte het byvoorbeeld deur Billmanager betaal, en hulle moes VDS herlaai of herinstalleer in VMManager. Ons personeel moes ook tussen vensters wissel om 'n kliënt te help, die las op sy bediener na te gaan of te sien watter bedryfstelsel hy gebruik.
So 'n koppelvlak neem tyd - beide ons s'n en ons kliënte s'n. Daar is geen sprake van enige gerief, soos dié van DigitalOcean, in so 'n situasie nie.
Kort lewensiklusse met gereelde API-opdaterings
Ons het ons eie inproppe geskryf - byvoorbeeld 'n inprop met bykomende betaalmetodes wat nie in VMManager is nie.
In onlangse jare het VMManager 'n relatief kort lewensiklus gehad, en in nuwe weergawes kan die name van veranderlikes of funksies in die API arbitrêr verander - dit het ons inproppe gebreek. Ondersteuning vir ouer weergawes is vinnig uitgefaseer en moes opgedateer word.
Kan nie gewysig word nie
Meer presies, dit is moontlik, maar uiters ondoeltreffend. Lisensiebeperkings laat jou nie toe om veranderinge aan die bronkode aan te bring nie, jy kan net plugins skryf. Maksimum plugins - sommige menu-items, 'n stap-vir-stap towenaar. ISP-stelsel is ontwerp vir veelsydigheid, maar ons het gespesialiseerde oplossings nodig gehad.
Die besluit was dus ryp om my eie paneel te skryf. Ons het doelwitte gestel:
- Reageer vinnig op foute, foute en kan dit self regmaak sonder om die kliënt te laat wag.
- Verander die koppelvlak vrylik vir werkvloeie en kliëntbehoeftes.
- Verhoog bruikbaarheid met 'n skoon en verstaanbare ontwerp.
En ons het begin ontwikkeling.
Nuwe Paneelargitektuur
Ons het 'n selfversorgende ontwikkelingspan, so ons het self die paneel geskryf.
Die hoofwerk is deur drie ingenieurs gedoen - tegniese direkteur Sergey het met die argitektuur vorendag gekom en die bedieneragent geskryf, Alexey het die fakturering gedoen, en die front-end is saamgestel deur ons front-end Artysh.
Stap 1: Bedieneragent
Die bedieneragent is 'n python-webbediener wat die biblioteek bestuur , wat op sy beurt regeer .
Die agent bestuur alle dienste op die bediener: skep, stop, verwyder vd's, installeer bedryfstelsels, verander parameters, ensovoorts deur die libvirt-biblioteek. Ten tyde van die publikasie van die artikel is dit meer as veertig verskillende funksies, wat ons aanvul na gelang van die taak en die behoeftes van die kliënt.
In teorie kon libvirt direk vanaf fakturering beheer word, maar dit het te veel bykomende kode vereis en ons het besluit om hierdie funksies tussen die agent en fakturering te skei - fakturering rig bloot versoeke aan die agent via die JSON API.
Die agent is die eerste ding wat ons gedoen het, aangesien dit geen koppelvlak benodig het nie en dit moontlik was om dit direk vanaf die bedienerkonsole te toets.
Wat die bedieneragent ons gegee het: 'n laag het verskyn wat die lewe vir almal vergemaklik - faktuur hoef nie 'n hele klomp opdragte te stuur nie, maar net 'n versoek te rig. En die agent sal alles doen wat nodig is: dit sal byvoorbeeld skyfspasie en RAM toewys.
Stap 2. Fakturering
Vir ons ontwikkelaar Alex was dit nie die eerste beheerpaneel nie - Alex is al lank in hosting, so hy het oor die algemeen verstaan wat die kliënt nodig het en wat die gasheer nodig het.
Ons noem fakturering onder mekaar 'n "kontrolepaneel": dit bevat nie net geld en dienste nie, maar ook hul bestuur, kliëntediens en nog baie meer.
Om van ISPSystem-sagteware oor te skakel, was dit nodig om die vorige funksionaliteit vir kliënte ten volle te bewaar, alle finansiële aksies van gebruikers van die ou fakturering na die nuwe een oor te dra, sowel as alle dienste en verbindings tussen hulle. Ons het bestudeer wat in die huidige produk is, dan die oplossings van mededingers, hoofsaaklik DO en Vultr. Ons het na die nadele en voordele gekyk, terugvoer ingesamel van mense wat met ou produkte van ISPsystem gewerk het.
Die nuwe faktuur het twee stapels gebruik: klassieke PHP, MySQL (en in die toekoms word daar beplan om na PostgreSQL oor te skakel), Yii2 as 'n raamwerk op die agterkant en VueJS aan die voorkant. Stapels werk onafhanklik van mekaar, word deur verskillende mense ontwikkel en kommunikeer met behulp van die JSON API. Vir ontwikkeling toe en nou gebruik ons и van JetBrains en is baie lief vir hulle (hey ouens!)
Die paneel is op 'n modulêre basis ontwerp: betaalstelselmodules, domeinregistrateurmodule of byvoorbeeld 'n SSL-sertifikaatmodule. Jy kan maklik 'n nuwe kenmerk byvoeg of 'n ou een verwyder. Die grondslag vir die uitbreiding word argitektonies gelê, insluitend in die teenoorgestelde rigting, "na die hardeware".
Wat het ons gekry: 'n beheerpaneel waaroor ons volle beheer het. Nou word foute in ure reggestel, nie weke nie, en nuwe funksies word geïmplementeer op versoek van kliënte, en nie op versoek van ISPSystem nie.
Stap 3 Interface
Die koppelvlak is ons span breinkind.
Eerstens het ons gekyk na wat sou gebeur as ons 'n byvoeging oor die ISPsystem API maak sonder om iets in die koppelvlak fundamenteel te verander. Dit het so-so uitgedraai en ons het besluit om alles van nuuts af te doen.
Ons het geglo dat die belangrikste ding is om die koppelvlak logies te maak, met 'n skoon en minimalistiese ontwerp, en dan sal ons 'n pragtige paneel kry. Die ligging van die elemente is in Megaplan bespreek en die koppelvlak wat gebruikers nou in die beheerpaneel sien, sal geleidelik gebore word.
Die ontwerp van die faktuurbladsy was die eerste wat verskyn het, want ons het reeds betaling-inproppe vir ISP-stelsel gemaak.
Voorkant
Hulle het besluit om die paneel 'n SPA-toepassing te maak - veeleisend vir hulpbronne en met vinnige data-laai. Ons front-end Artysh het besluit om dit op Vue te skryf - op daardie tydstip het Vue pas verskyn. Ons het aanvaar dat die raamwerk dinamies sou ontwikkel, soos React, na 'n ruk sou die Vue-gemeenskap groei en 'n see van biblioteke sou verskyn. Ons wed op Vue en was nie spyt daaroor nie - nou neem dit min tyd om nuwe funksies aan die voorkant by te voeg wat reeds op die agterkant geprogrammeer is. Ons sal jou meer oor die voorpaneel in 'n aparte artikel vertel.
Koppel die voorkant aan die agterkant
Die voorkant is via stootkennisgewings aan die agterkant gekoppel. Ek moes hard werk en my eie hanteerder skryf, maar nou word die inligting op die bladsy feitlik onmiddellik opgedateer.
Wat het gebeur: Die paneelkoppelvlak het eenvoudiger geword. Ons het dit aanpasbaar gemaak, en vinnig laai laat jou toe om dit selfs vanaf selfone te gebruik in die laaste minute voor opstyg, sonder om 'n aparte toepassing te installeer om met die paneel te werk.
Stap 4. Toets- en migrasieskema
Toe alles begin en die eerste toetse geslaag het, het die kwessie van migrasie ontstaan. Eerstens het ons fakturering geïnstalleer en die werking daarvan met die bedieneragent begin toets.
Toe het ons 'n eenvoudige skrif geskryf wat die databasis van die ou faktuur na die nuwe een oordra.
Ek moes letterlik alles toets en herkontroleer, aangesien die data in een nuwe databasis van drie oues saamgevoeg is: Billmanager, VMmanager en die bestuurder se IPmanager. Miskien is die toetsmigrasies die moeilikste ding wat ons teëgekom het in die proses om 'n nuwe paneel te ontwikkel.
Nadat ons weer nagegaan het, het ons die ou rekening gesluit. Die finale data-migrasie was 'n baie kommerwekkende oomblik, maar, dank God, dit is binne 'n paar minute voltooi en sonder merkbare probleme. Daar was klein foute wat ons gedurende die week reggemaak het. Die meeste van die tyd is spandeer om te toets wat gebeur het.
Toe het ons briewe aan kliënte gestuur met die adres van die nuwe paneel en rekeninge en 'n herleiding gemaak.
Ter opsomming: DIS LEWENDIG!
Gelukkige einde
Vanaf die eerste ure se werk van ons sagteware het ons al die lekkertes van die oorgang gevoel. Die kode was heeltemal ons s'n en met 'n gerieflike argitektuur, en die koppelvlak was skoon en logies.
Eerste hersiening na die bekendstelling van die nuwe paneel
Ons het die oorgangsproses in Desember, op die vooraand van Nuwejaar 2017, toe die las die minste was, van stapel gestuur om die oorgang vir kliënte makliker te maak – byna niemand werk op die vooraand van die vakansie nie.
Die belangrikste ding wat ons gekry het toe ons na ons stelsel oorgeskakel het (behalwe algemene betroubaarheid en gerief) is die vermoë om vinnig funksionaliteit vir sleutelkliënte by te voeg - om hul gesig te wees, nie hul gat nie.
Wat is volgende?
Ons groei, die hoeveelheid data, kliënte, kliëntedata groei. Ek moes 'n Memcached-bediener en twee toubestuurders met verskillende take by die agterkant voeg. Die voorkant het kas en sy eie rye.
Natuurlik het ons steeds avonture beleef namate die produk ontwikkel en meer kompleks geword het, byvoorbeeld toe ons HighLoad bygevoeg het.
In die volgende artikel sal ons jou vertel hoe die Hi-CPU-tarief bekendgestel is: oor hardeware, sagteware, watter take ons opgelos het en wat ons gedoen het.
Bron: will.com