Hallå! Vi är "Hosting Technologies" och lanserades för 5 år sedan — den första vds-värden skapad specifikt för utvecklare. Vi strävar efter att göra det bekvämt, som DigitalOcean, men med rysk support, betalningsmetoder och servrar i Ryssland. Men DigitalOcean är inte bara tillförlitlighet och pris, det är också en tjänst.
Programvara från ISPsystem visade sig vara ett rep som knöt våra händer på vägen till en cool tjänst. För tre år sedan använde vi Billmanager billing och VMmanager-serverns kontrollpanel och insåg snabbt att det var nästan omöjligt att ge en bra service utan vår egen kontrollpanel.
Hur ISPsystem dödade bekvämlighet
Buggar
Vi kunde inte fixa buggen själva - varje gång var vi tvungna att skriva till någon annans support och vänta. Lösningen på alla problem krävde svar från ett tredjepartsföretag.
ISPsystemsupporten svarade normalt, men korrigeringar kom först efter några få releaser, och då inte alltid och inte alla. Ibland korrigerades kritiska buggar under flera veckor. Vi var tvungna att lugna kunderna, be om ursäkt och vänta på att ISPsystem skulle fixa felet.
Driftstoppshot
Uppdateringar kan generera oförutsägbara driftstopp som framkallade nya fel.
Varje uppdatering var ett lotteri: jag var tvungen att täcka över fakturering och göra uppoffringar till uppdateringarnas gudar - ett par gånger orsakade uppdateringen driftstopp i 10-15 minuter. Våra administratörer satt vid den här tiden på sina ögon - vi visste aldrig hur länge stilleståndet skulle pågå och kunde inte förutse när ISPsystem skulle besluta sig för att släppa en ny uppdatering.
På den femte generationen blev Billmanager bättre, men för att få tillgång till nödvändiga funktioner var jag tvungen att installera en beta, som redan uppdaterades varje vecka. Om något gick sönder var jag tvungen att ge åtkomst till andra utvecklare så att de kunde fixa något.
Obekvämt panelgränssnitt
Allt delades upp i olika paneler och styrdes från olika platser. Till exempel betalade klienter via Billmanager och de var tvungna att starta om eller installera om VDS i VMManager. Vår personal var också tvungen att växla mellan fönster för att hjälpa en klient, kontrollera belastningen på hans server eller se vilket operativsystem han använde.
Ett sådant gränssnitt tar tid – både vårt och våra kunders. Det är inte fråga om någon bekvämlighet, som DigitalOcean, i en sådan situation.
Korta livscykler med frekventa API-uppdateringar
Vi skrev våra egna plugins – till exempel ett plugin med ytterligare betalningsmetoder som inte finns i VMManager.
De senaste åren har VMManager haft en relativt kort livscykel, och i nya versioner kan namnen på variabler eller funktioner i API:t ändras godtyckligt – detta bröt våra plugins. Stödet för äldre versioner fasades snabbt ut och måste uppdateras.
Kan inte ändras
Mer exakt, det är möjligt, men extremt ineffektivt. Licensrestriktioner tillåter inte att du gör ändringar i källkoden, du kan bara skriva plugins. Maximalt antal plugins - vissa menyalternativ, en steg-för-steg-guide. ISP-system är designade för mångsidighet, men vi behövde specialiserade lösningar.
Så beslutet var mogen att skriva min egen panel. Vi har satt upp mål:
- Svara snabbt på fel, buggar och kunna fixa dem själv utan att få kunden att vänta.
- Modifiera gränssnittet fritt för arbetsflöden och klientbehov.
- Öka användbarheten med en ren och begriplig design.
Och vi började utveckla.
Ny panelarkitektur
Vi har ett självförsörjande utvecklingsteam, så vi skrev panelen själva.
Det huvudsakliga arbetet gjordes av tre ingenjörer - tekniska chefen Sergey kom på arkitekturen och skrev serveragenten, Alexey gjorde faktureringen, och fronten sattes ihop av vår front-ender Artysh.
Steg 1: Serveragent
Serveragenten är en python-webbserver som hanterar biblioteket , som i sin tur styr .
Agenten hanterar alla tjänster på servern: skapa, stoppa, ta bort vds, installera operativsystem, ändra parametrar och så vidare genom libvirt-biblioteket. Vid tidpunkten för publicering av artikeln rör det sig om mer än fyrtio olika funktioner, som vi kompletterar beroende på uppdraget och kundens behov.
I teorin kunde libvirt styras direkt från fakturering, men detta krävde för mycket extra kod och vi bestämde oss för att separera dessa funktioner mellan agenten och fakturering - fakturering gör helt enkelt förfrågningar till agenten via JSON API.
Agenten är det första vi gjorde, eftersom det inte krävde något gränssnitt och det var möjligt att testa det direkt från serverkonsolen.
Vad serveragenten gav oss: ett lager har dykt upp som förenklar livet för alla - fakturering behöver inte skicka en hel massa kommandon, utan bara göra en förfrågan. Och agenten kommer att göra allt som behövs: till exempel kommer den att allokera diskutrymme och RAM.
Steg 2. Fakturering
För vår utvecklare Alex var detta inte den första kontrollpanelen - Alex har varit i hosting länge, så han förstod i allmänhet vad klienten behövde och vad hostaren behövde.
Vi kallar fakturering sinsemellan en "kontrollpanel": den innehåller inte bara pengar och tjänster, utan också deras hantering, kundsupport och mycket mer.
För att byta från ISPSystem-programvaran var det nödvändigt att helt bevara den tidigare funktionaliteten för kunderna, överföra alla ekonomiska åtgärder från användare från den gamla faktureringen till den nya, såväl som alla tjänster och anslutningar mellan dem. Vi studerade vad som finns i den aktuella produkten, sedan konkurrenternas lösningar, främst DO och Vultr. Vi tittade på nackdelarna och fördelarna, samlade in feedback från personer som arbetade med gamla produkter från ISPsystem.
Den nya faktureringen använde två stackar: klassisk PHP, MySQL (och i framtiden är det planerat att byta till PostgreSQL), Yii2 som ramverk på backend och VueJS på framsidan. Stackar fungerar oberoende av varandra, utvecklas av olika personer och kommunicerar med JSON API. För utveckling då och nu använder vi и från JetBrains och älskar dem innerligt (hej killar!)
Panelen är designad på modulbasis: betalningssystemmoduler, domänregistrarmodul eller till exempel en SSL-certifikatmodul. Du kan enkelt lägga till en ny funktion eller ta bort en gammal. Grunden för utbyggnaden läggs arkitektoniskt, bland annat i motsatt riktning, "mot hårdvaran".
Vad fick vi: en kontrollpanel som vi har full kontroll över. Nu fixas buggar på timmar, inte veckor, och nya funktioner implementeras på begäran av kunder och inte på begäran av ISPSystem.
Steg 3 Gränssnitt
Gränssnittet är vårt team idéskapande.
Först tittade vi på vad som skulle hända om vi gjorde ett tillägg över ISPsystem API utan att i grunden ändra något i gränssnittet. Det blev så som så och vi bestämde oss för att göra allt från grunden.
Vi trodde att det viktigaste är att göra gränssnittet logiskt, med en ren och minimalistisk design, och då får vi en vacker panel. Platsen för elementen diskuterades i Megaplan och gränssnittet som användarna ser i kontrollpanelen nu kommer gradvis att födas.
Utformningen av faktureringssidan var den första som dök upp, eftersom vi redan har gjort betalningsplugins för ISPsystem.
Frontend
De bestämde sig för att göra panelen till en SPA-applikation - resurskrävande och med snabb dataladdning. Vår front-ender Artysh bestämde sig för att skriva det på Vue - vid den tiden hade Vue precis dykt upp. Vi antog att ramverket skulle utvecklas dynamiskt, som React, efter en tid skulle Vue-communityt växa och ett hav av bibliotek skulle dyka upp. Vi satsade på Vue och ångrade det inte - nu tar det lite tid att lägga till nya funktioner på framsidan som redan har programmerats på baksidan. Vi kommer att berätta mer om frontpanelen i en separat artikel.
Anslut frontend till backend
Frontend var ansluten till backend via push-meddelanden. Jag fick jobba hårt och skriva min egen hanterare, men nu uppdateras informationen på sidan nästan direkt.
Vad hände: Panelgränssnittet har blivit enklare. Vi gjorde den anpassningsbar och snabb laddning gör att du kan använda den även från mobiltelefoner under de sista minuterna före start, utan att installera en separat applikation för att fungera med panelen.
Steg 4. Test- och migreringsschema
När allt kom igång och de första testerna klarade uppstod frågan om migration. Först och främst installerade vi fakturering och började testa dess funktion med serveragenten.
Sedan skrev vi ett enkelt script som överför databasen från den gamla faktureringen till den nya.
Jag var tvungen att testa och kontrollera bokstavligen allt eftersom data slogs samman till en ny databas från tre gamla: Billmanager, VMmanager och chefens IPmanager. Testmigreringarna är kanske det svåraste vi stött på i processen med att utveckla en ny panel.
Efter omkontroll stängde vi den gamla faktureringen. Den slutliga datamigreringen var ett mycket oroande ögonblick, men tack och lov slutfördes den på några minuter och utan märkbara problem. Det fanns mindre buggar som vi fixade under veckan. Den mesta tiden gick åt till att testa vad som hände.
Sedan skickade vi brev till kunder med adressen till den nya panelen och fakturering och gjorde en omdirigering.
Sammanfattningsvis: DET ÄR LEVANDE!
Lyckligt slut
Från de första timmarna av arbetet med vår programvara kände vi alla nöjen med övergången. Koden var helt vår och med en bekväm arkitektur, och gränssnittet var rent och logiskt.
Första recensionen efter lanseringen av den nya panelen
Vi lanserade övergångsprocessen i december, på nyårsafton 2017, då belastningen var som minst, för att göra övergången lättare för kunderna – nästan ingen jobbar på semestern.
Det viktigaste vi fick när vi bytte till vårt system (bortsett från allmän tillförlitlighet och bekvämlighet) är möjligheten att snabbt lägga till funktionalitet för nyckelkunder - att vara deras ansikte, inte deras rumpa.
Vad händer nu?
Vi växer, mängden data, kunder, kunddata växer. Jag var tvungen att lägga till en Memcached-server och två köhanterare med olika uppgifter till backend. Frontend har caching och egna köer.
Naturligtvis hade vi fortfarande äventyr när produkten utvecklades och blev mer komplex, till exempel när vi lade till HighLoad.
I nästa artikel kommer vi att berätta hur Hi-CPU-taxan lanserades: om hårdvara, mjukvara, vilka uppgifter vi löste och vad vi gjorde.
Källa: will.com