Hallo! Vi er "Hosting Technologies" og ble lansert for 5 år siden — den første vds-verten laget spesielt for utviklere. Vi streber etter å gjøre det praktisk, som DigitalOcean, men med russisk støtte, betalingsmetoder og servere i Russland. Men DigitalOcean er ikke bare pålitelighet og pris, det er også en tjeneste.
Programvare fra ISPsystem viste seg å være et tau som bandt hendene våre på vei til en kul tjeneste. For tre år siden brukte vi Billmanager billing og VMmanager serverkontrollpanel og innså raskt at det var nesten umulig å yte en god service uten vårt eget kontrollpanel.
Hvordan ISPsystem drepte bekvemmelighet
Feil
Vi kunne ikke fikse feilen selv - hver gang måtte vi skrive til andres support og vente. Løsningen på ethvert problem krevde respons fra et tredjepartsselskap.
ISP-systemstøtten reagerte normalt, men rettelser kom først etter noen få utgivelser, og da ikke alltid og ikke alle. Noen ganger ble kritiske feil rettet i flere uker. Vi måtte berolige kundene, be om unnskyldning og vente på at ISPsystem fikser feilen.
Nedetidstrussel
Oppdateringer kan generere uforutsigbare nedetider som provoserte nye feil.
Hver oppdatering var et lotteri: Jeg måtte dekke over fakturering og ofre til gudene for oppdateringer – et par ganger forårsaket oppdateringen nedetid i 10-15 minutter. Administratorene våre på dette tidspunktet satt på øynene - vi visste aldri hvor lenge nedetiden ville vare og kunne ikke forutsi når ISPsystem ville bestemme seg for å gi ut en ny oppdatering.
På femte generasjon ble Billmanager bedre, men for å få tilgang til de nødvendige funksjonene måtte jeg installere en beta, som allerede ble oppdatert hver uke. Hvis noe gikk i stykker, måtte jeg gi tilgang til andre utviklere slik at de kunne fikse noe.
Upraktisk panelgrensesnitt
Alt ble delt inn i ulike paneler og styrt fra ulike steder. For eksempel betalte klienter gjennom Billmanager, og de måtte starte på nytt eller installere VDS på nytt i VMManager. Våre ansatte måtte også bytte mellom vinduer for å hjelpe en klient, sjekke belastningen på serveren hans eller se hvilket operativsystem han brukte.
Et slikt grensesnitt tar tid – både vårt og våre kunders. Det er ikke snakk om noen bekvemmelighet, som for DigitalOcean, i en slik situasjon.
Korte livssykluser med hyppige API-oppdateringer
Vi skrev våre egne plugins – for eksempel en plugin med ekstra betalingsmetoder som ikke er i VMManager.
De siste årene har VMManager hatt en relativt kort livssyklus, og i nye versjoner kan navnene på variabler eller funksjoner i API endres vilkårlig – dette brøt pluginene våre. Støtte for eldre versjoner ble raskt faset ut og måtte oppdateres.
Kan ikke endres
Mer presist er det mulig, men ekstremt ineffektivt. Lisensrestriksjoner lar deg ikke gjøre endringer i kildekoden, du kan bare skrive plugins. Maksimal plugins - noen menyelementer, en trinn-for-trinn veiviser. ISP-systemet er designet for allsidighet, men vi trengte spesialiserte løsninger.
Så beslutningen var moden for å skrive mitt eget panel. Vi har satt oss mål:
- Reager raskt på feil, feil og vær i stand til å fikse dem selv uten å få klienten til å vente.
- Modifiser fritt grensesnittet for arbeidsflyter og klientbehov.
- Øk brukervennligheten med en ren og forståelig design.
Og vi startet utviklingen.
Ny panelarkitektur
Vi har et selvforsynt utviklingsteam, så vi skrev panelet selv.
Hovedarbeidet ble utført av tre ingeniører - teknisk direktør Sergey kom opp med arkitekturen og skrev serveragenten, Alexey gjorde faktureringen, og front-end ble satt sammen av vår front-ender Artysh.
Trinn 1: Serveragent
Serveragenten er en python-webserver som administrerer biblioteket , som igjen styrer .
Agenten administrerer alle tjenester på serveren: opprette, stoppe, slette vds, installere operativsystemer, endre parametere og så videre gjennom libvirt-biblioteket. På tidspunktet for publisering av artikkelen er dette mer enn førti forskjellige funksjoner, som vi supplerer avhengig av oppgaven og kundens behov.
I teorien kunne libvirt kontrolleres direkte fra fakturering, men dette krevde for mye tilleggskode, og vi bestemte oss for å skille disse funksjonene mellom agenten og faktureringen – fakturering sender ganske enkelt forespørsler til agenten via JSON API.
Agenten er det første vi gjorde, siden det ikke krevde noe grensesnitt og det var mulig å teste det direkte fra serverkonsollen.
Hva serveragenten ga oss: det har dukket opp et lag som forenkler livet for alle - fakturering trenger ikke å sende en hel haug med kommandoer, men bare gjøre en forespørsel. Og agenten vil gjøre alt som er nødvendig: for eksempel vil den tildele diskplass og RAM.
Trinn 2. Fakturering
For vår utvikler Alex var ikke dette det første kontrollpanelet - Alex har vært i hosting i lang tid, så han forsto generelt hva klienten trengte og hva hosteren trengte.
Vi kaller fakturering mellom oss et "kontrollpanel": det inneholder ikke bare penger og tjenester, men også deres administrasjon, kundestøtte og mye mer.
For å bytte fra ISPSystem-programvare var det nødvendig å fullt ut bevare den tidligere funksjonaliteten for kunder, overføre alle økonomiske handlinger til brukere fra den gamle faktureringen til den nye, samt alle tjenester og forbindelser mellom dem. Vi studerte hva som er i det nåværende produktet, deretter løsningene til konkurrentene, hovedsakelig DO og Vultr. Vi så på ulemper og fordeler, samlet inn tilbakemeldinger fra folk som jobbet med gamle produkter fra ISPsystem.
Den nye faktureringen brukte to stabler: klassisk PHP, MySQL (og i fremtiden er det planlagt å bytte til PostgreSQL), Yii2 som rammeverk på backend og VueJS på fronten. Stabler fungerer uavhengig av hverandre, er utviklet av forskjellige personer og kommuniserer ved hjelp av JSON API. For utvikling da og nå bruker vi и fra JetBrains og elsker dem høyt (hei folkens!)
Panelet er utformet på modulbasis: betalingssystemmoduler, domeneregistrarmodul eller for eksempel en SSL-sertifikatmodul. Du kan enkelt legge til en ny funksjon eller fjerne en gammel. Grunnlaget for utvidelsen er lagt arkitektonisk, inkludert i motsatt retning, «mot maskinvaren».
Det vi fikk: et kontrollpanel som vi har full kontroll over. Nå er feil fikset i timer, ikke uker, og nye funksjoner implementeres på forespørsel fra kunder, og ikke på forespørsel fra ISPSystem.
Trinn 3 Grensesnitt
Grensesnittet er laget vårt hjernebarn.
Først så vi på hva som ville skje hvis vi laget et tillegg over ISPsystem API uten å fundamentalt endre noe i grensesnittet. Det ble så som så og vi bestemte oss for å gjøre alt fra bunnen av.
Vi trodde at hovedsaken er å gjøre grensesnittet logisk, med et rent og minimalistisk design, og så får vi et vakkert panel. Plasseringen av elementene ble diskutert i Megaplan og grensesnittet som brukerne ser i kontrollpanelet nå vil gradvis bli født.
Utformingen av faktureringssiden var den første som dukket opp, fordi vi allerede har laget betalingsplugins for ISPsystem.
Frontend
De bestemte seg for å gjøre panelet til en SPA-applikasjon - lite ressurskrevende og med rask datainnlasting. Vår front-ender Artysh bestemte seg for å skrive det på Vue - på det tidspunktet hadde Vue nettopp dukket opp. Vi antok at rammeverket ville utvikle seg dynamisk, som React, etter en tid ville Vue-fellesskapet vokse og et hav av biblioteker ville dukke opp. Vi satset på Vue og angret ikke – nå tar det kort tid å legge til nye funksjoner foran som allerede er programmert på baksiden. Vi vil fortelle deg mer om frontpanelet i en egen artikkel.
Koble frontend til backend
Frontend ble koblet til backend via push-varsler. Jeg måtte jobbe hardt og skrive min egen handler, men nå oppdateres informasjonen på siden nesten umiddelbart.
Hva skjedde: Panelgrensesnittet er blitt enklere. Vi gjorde den adaptiv, og rask lasting lar deg bruke den selv fra mobiltelefoner de siste minuttene før avgang, uten å installere en egen applikasjon for å jobbe med panelet.
Trinn 4. Test- og migreringsordning
Da alt startet opp og de første testene bestod, dukket spørsmålet om migrasjon opp. Først av alt, installerte vi fakturering og begynte å teste driften med serveragenten.
Så skrev vi et enkelt script som overfører databasen fra den gamle faktureringen til den nye.
Jeg måtte teste og sjekke bokstavelig talt alt på nytt, siden dataene ble slått sammen til én ny database fra tre gamle: Billmanager, VMmanager og lederens IPmanager. Kanskje testmigreringene er det vanskeligste vi har møtt i prosessen med å utvikle et nytt panel.
Etter å ha sjekket på nytt, stengte vi den gamle faktureringen. Den endelige datamigreringen var et veldig urovekkende øyeblikk, men, gudskjelov, fullført på noen få minutter og uten merkbare problemer. Det var mindre feil som vi fikset i løpet av uken. Mesteparten av tiden gikk med til å teste det som skjedde.
Deretter sendte vi brev til kunder med adressen til det nye panelet og fakturering og foretok en omdirigering.
Oppsummert: DEN LEVER!
Lykkelig slutt
Fra de første timene med programvaren vår følte vi alle gledene ved overgangen. Koden var helt vår og med en praktisk arkitektur, og grensesnittet var rent og logisk.
Første gjennomgang etter lanseringen av det nye panelet
Vi lanserte overgangsprosessen i desember, på nyttårsaften 2017, da belastningen var minst, for å gjøre overgangen enklere for kundene – nesten ingen jobber på ferieaften.
Det viktigste vi fikk når vi byttet til systemet vårt (bortsett fra generell pålitelighet og bekvemmelighet) er muligheten til raskt å legge til funksjonalitet for nøkkelkunder - å være deres ansikt, ikke deres rumpa.
Hva blir det neste?
Vi vokser, mengden data, kunder, kundedata vokser. Jeg måtte legge til en Memcached-server og to køadministratorer med forskjellige oppgaver til backend. Frontend har caching og egne køer.
Selvfølgelig hadde vi fortsatt eventyr ettersom produktet utviklet seg og ble mer komplekst, for eksempel da vi la til HighLoad.
I den neste artikkelen vil vi fortelle deg hvordan Hi-CPU-tariffen ble lansert: om maskinvare, programvare, hvilke oppgaver vi løste og hva vi gjorde.
Kilde: www.habr.com