Hej! Vi er "Hosting Technologies" og blev lanceret for 5 år siden — den første vds-hosting skabt specielt til udviklere. Vi bestræber os på at gøre det bekvemt, ligesom DigitalOcean, men med russisk support, betalingsmetoder og servere i Rusland. Men DigitalOcean er ikke kun pålidelighed og pris, det er også en service.
Software fra ISPsystem viste sig at være et reb, der bandt vores hænder på vej til en fed service. For tre år siden brugte vi Billmanager billing og VMmanager serverkontrolpanelet og indså hurtigt, at det næsten var umuligt at levere en god service uden vores eget kontrolpanel.
Hvordan ISPsystem dræbte bekvemmelighed
Bugs
Vi kunne ikke selv rette fejlen - hver gang måtte vi skrive til en andens support og vente. Løsningen på ethvert problem krævede svar fra en tredjepartsvirksomhed.
ISPsystem-support reagerede normalt, men rettelser kom først efter nogle få udgivelser, og så ikke altid og ikke alle. Nogle gange blev kritiske fejl rettet i flere uger. Vi var nødt til at berolige kunderne, undskylde og vente på, at ISPsystem fikser fejlen.
Nedetidstrussel
Opdateringer kunne generere uforudsigelige nedetider, der fremkaldte nye fejl.
Hver opdatering var et lotteri: Jeg var nødt til at dække over fakturering og ofre for opdateringernes guder - et par gange forårsagede opdateringen nedetid i 10-15 minutter. Vores administratorer på dette tidspunkt sad på deres øjne - vi vidste aldrig, hvor længe nedetiden ville vare og kunne ikke forudsige, hvornår ISPsystem ville beslutte at frigive en ny opdatering.
På femte generation blev Billmanager bedre, men for at få adgang til de nødvendige funktioner var jeg nødt til at installere en beta, som allerede blev opdateret hver uge. Hvis noget gik i stykker, var jeg nødt til at give adgang til andre udviklere, så de kunne rette noget.
Upraktisk panelgrænseflade
Alt var opdelt i forskellige paneler og styret fra forskellige steder. For eksempel betalte kunder gennem Billmanager, og de skulle genstarte eller geninstallere VDS i VMManager. Vores personale skulle også skifte mellem vinduer for at hjælpe en klient, tjekke belastningen på hans server eller se, hvilket OS han brugte.
Sådan en grænseflade tager tid - både vores og vores kunders. Der er ikke tale om nogen bekvemmelighed, som DigitalOcean, i en sådan situation.
Korte livscyklusser med hyppige API-opdateringer
Vi skrev vores egne plugins – for eksempel et plugin med yderligere betalingsmetoder, som ikke er i VMManager.
I de senere år har VMManager haft en relativt kort livscyklus, og i nye versioner kunne navnene på variabler eller funktioner i API'et ændre sig vilkårligt – det knækkede vores plugins. Support til ældre versioner blev hurtigt udfaset og skulle opdateres.
Kan ikke ændres
Mere præcist er det muligt, men ekstremt ineffektivt. Licensrestriktioner tillader ikke, at du foretager ændringer i kildekoden, du kan kun skrive plugins. Maksimalt antal plugins - nogle menupunkter, en trin-for-trin guide. ISP-systemer er designet til alsidighed, men vi havde brug for specialiserede løsninger.
Så beslutningen var moden til at skrive mit eget panel. Vi har sat mål:
- Reager hurtigt på fejl, fejl og vær i stand til selv at rette dem uden at få klienten til at vente.
- Rediger grænsefladen frit til arbejdsgange og klientbehov.
- Øg brugervenligheden med et rent og forståeligt design.
Og vi startede udviklingen.
Ny panelarkitektur
Vi har et selvforsynende udviklingsteam, så vi har selv skrevet panelet.
Hovedarbejdet blev udført af tre ingeniører - teknisk direktør Sergey kom med arkitekturen og skrev serveragenten, Alexey stod for faktureringen, og frontenden blev samlet af vores front-ender Artysh.
Trin 1: Serveragent
Serveragenten er en python-webserver, der administrerer biblioteket , som igen styrer .
Agenten administrerer alle tjenester på serveren: oprettelse, stop, sletning af vd'er, installation af operativsystemer, ændring af parametre og så videre gennem libvirt-biblioteket. På tidspunktet for udgivelsen af artiklen er der tale om mere end fyrre forskellige funktioner, som vi supplerer alt efter opgaven og kundens behov.
I teorien kunne libvirt styres direkte fra fakturering, men dette krævede for meget ekstra kode, og vi besluttede at adskille disse funktioner mellem agenten og fakturering - fakturering sender simpelthen anmodninger til agenten via JSON API.
Agenten er det første vi gjorde, da det ikke krævede nogen grænseflade, og det var muligt at teste det direkte fra serverkonsollen.
Hvad serveragenten gav os: der er dukket et lag op, der forenkler livet for alle - fakturering behøver ikke at sende en hel masse kommandoer, men kun lave en anmodning. Og agenten vil gøre alt, hvad der er nødvendigt: for eksempel vil den tildele diskplads og RAM.
Trin 2. Fakturering
For vores udvikler Alex var dette ikke det første kontrolpanel - Alex har været i hosting i lang tid, så han forstod generelt, hvad klienten havde brug for, og hvad hosteren havde brug for.
Vi kalder indbyrdes fakturering et "kontrolpanel": det indeholder ikke kun penge og tjenester, men også deres administration, kundesupport og meget mere.
For at skifte fra ISPSystem-software var det nødvendigt fuldt ud at bevare den tidligere funktionalitet for kunderne, overføre alle økonomiske handlinger fra brugere fra den gamle fakturering til den nye samt alle tjenester og forbindelser mellem dem. Vi studerede, hvad der er i det nuværende produkt, derefter konkurrenternes løsninger, primært DO og Vultr. Vi så på ulemperne og fordelene, indsamlede feedback fra folk, der arbejdede med gamle produkter fra ISPsystem.
Den nye fakturering brugte to stakke: klassisk PHP, MySQL (og i fremtiden er det planlagt at skifte til PostgreSQL), Yii2 som ramme på backend og VueJS på fronten. Stakke arbejder uafhængigt af hinanden, udvikles af forskellige mennesker og kommunikerer ved hjælp af JSON API. Til udvikling før og nu bruger vi и fra JetBrains og elsker dem højt (hey guys!)
Panelet er designet på modulbasis: betalingssystemmoduler, domæneregistratormodul eller for eksempel et SSL-certifikatmodul. Du kan nemt tilføje en ny funktion eller fjerne en gammel. Grundlaget for udvidelsen er lagt arkitektonisk, herunder i den modsatte retning, "mod hardwaren".
Hvad fik vi: et kontrolpanel, som vi har fuld kontrol over. Nu er fejl rettet i timer, ikke uger, og nye funktioner implementeres på anmodning fra kunder og ikke på anmodning fra ISPSystem.
Trin 3 Interface
Interfacet er vores teams idékind.
Først så vi på, hvad der ville ske, hvis vi lavede en tilføjelse over ISPsystem API uden at ændre noget i grænsefladen fundamentalt. Det blev så som så, og vi besluttede at gøre alt fra bunden.
Vi troede på, at det vigtigste er at gøre grænsefladen logisk med et rent og minimalistisk design, og så får vi et smukt panel. Placeringen af elementerne blev diskuteret i Megaplan, og den grænseflade, som brugerne ser i kontrolpanelet nu, vil gradvist blive født.
Designet af faktureringssiden var det første, der dukkede op, fordi vi allerede har lavet betalingsplugins til ISPsystem.
Frontend
De besluttede at gøre panelet til en SPA-applikation - krævende for ressourcer og med hurtig dataindlæsning. Vores front-ender Artysh besluttede at skrive det på Vue - på det tidspunkt var Vue netop dukket op. Vi antog, at rammen ville udvikle sig dynamisk, ligesom React, efter nogen tid ville Vue-fællesskabet vokse, og et hav af biblioteker ville dukke op. Vi satsede på Vue og fortrød det ikke - nu tager det lidt tid at tilføje nye funktioner til fronten, som allerede er programmeret på bagenden. Vi vil fortælle dig mere om front-end panelet i en separat artikel.
Forbindelse af frontend til backend
Frontenden var forbundet til backend via push-meddelelser. Jeg skulle arbejde hårdt og skrive min egen handler, men nu bliver informationen på siden opdateret næsten øjeblikkeligt.
Hvad skete der: Panelgrænsefladen er blevet enklere. Vi har gjort den adaptiv, og hurtig indlæsning giver dig mulighed for at bruge den selv fra mobiltelefoner i de sidste minutter før takeoff, uden at installere en separat applikation til at arbejde med panelet.
Trin 4. Test- og migreringsordning
Da alt startede og de første test bestod, opstod spørgsmålet om migration. Først og fremmest installerede vi fakturering og begyndte at teste dens drift med serveragenten.
Så skrev vi et simpelt script, der overfører databasen fra den gamle fakturering til den nye.
Jeg var nødt til at teste og gentjekke bogstaveligt talt alt, da dataene blev slået sammen til én ny database fra tre gamle: Billmanager, VMmanager og lederens IPmanager. Måske er testmigreringerne det sværeste, vi stødte på i processen med at udvikle et nyt panel.
Efter genkontrol lukkede vi den gamle fakturering. Den endelige datamigrering var et meget bekymrende øjeblik, men gudskelov blev det gennemført på få minutter og uden mærkbare problemer. Der var mindre fejl, som vi rettede i løbet af ugen. Det meste af tiden gik med at teste, hvad der skete.
Så sendte vi breve til kunder med adressen på det nye panel og fakturering og lavede en omdirigering.
Sammenfattende: DEN LEVER!
Lykkelig slutning
Fra de første timers arbejde med vores software, mærkede vi alle glæderne ved overgangen. Koden var helt vores og med en praktisk arkitektur, og grænsefladen var ren og logisk.
Første anmeldelse efter lanceringen af det nye panel
Vi lancerede overgangsprocessen i december, nytårsaften 2017, hvor belastningen var mindst, for at gøre overgangen nemmere for kunderne – næsten ingen arbejder på ferieaftenen.
Det vigtigste, vi fik, da vi skiftede til vores system (bortset fra generel pålidelighed og bekvemmelighed) er evnen til hurtigt at tilføje funktionalitet for nøglekunder - at være deres ansigt, ikke deres røv.
Hvad er det næste?
Vi vokser, mængden af data, kunder, kundedata vokser. Jeg var nødt til at tilføje en Memcached-server og to køadministratorer med forskellige opgaver til backend. Frontenden har caching og sine egne køer.
Selvfølgelig havde vi stadig eventyr, da produktet udviklede sig og blev mere komplekst, for eksempel da vi tilføjede HighLoad.
I den næste artikel vil vi fortælle dig, hvordan Hi-CPU-taksten blev lanceret: om hardware, software, hvilke opgaver vi løste, og hvad vi gjorde.
Kilde: www.habr.com