Hallo! Wij zijn «Hosting Technologie» en vijf jaar geleden hebben we de eerste VDS-hosting gelanceerd, speciaal ontwikkeld voor ontwikkelaars. We streven ernaar het zo gebruiksvriendelijk te maken als DigitalOcean, maar met Russische ondersteuning, betalingsmogelijkheden en servers in Rusland. Maar DigitalOcean staat niet alleen voor betrouwbaarheid en prijs, het is ook de service.
De software van ISPsystem bleek een touw te zijn dat ons de handen bond op de weg naar een geweldige service. Drie jaar geleden gebruikten we de billing Billmanager en het serverbeheer paneel VMmanager, en we realiseerden ons snel dat het bijna onmogelijk was om goede service te bieden zonder ons eigen paneel.
Hoe ISPsystem het gebruiksgemak ondermijnde
Bugs
We konden zelf geen bugs oplossen - elke keer moesten we contact opnemen met een externe ondersteuning en wachten. Het oplossen van elk probleem vereiste een reactie van een extern bedrijf.
De ondersteuning van ISPsystem reageerde redelijk, maar fixes kwamen pas na enkele releases, en niet altijd en niet allemaal. Soms werden kritieke bugs wekenlang niet opgelost. We moesten klanten geruststellen, ons verontschuldigen en wachten tot ISPsystem de bug zou verhelpen.
De dreiging van downtime
Updates konden onvoorspelbare downtime veroorzaken, wat nieuwe fouten uitlokte.
Elke update was een loterij: we moesten de billing sluiten en offers brengen aan de goden van updates - een paar keer veroorzaakte een update downtime van 10-15 minuten. Onze beheerders zaten intussen te zwoegen - we wisten nooit hoe lang de downtime zou duren en konden niet voorspellen wanneer ISPsystem besloot een nieuwe update uit te brengen.
Met de vijfde generatie Billmanager werd het beter, maar om toegang te krijgen tot de benodigde functies moesten we de beta installeren, die al elke week werd bijgewerkt. Als er iets kapot ging, moesten we toegang verlenen aan externe ontwikkelaars om het te repareren.
Ongemakkelijke interface van het paneel
Alles was verdeeld over verschillende panelen en werd vanuit verschillende plaatsen beheerd. Klanten betaalden bijvoorbeeld via Billmanager, maar om VDS te herstarten of opnieuw te installeren, moesten ze dat in VMManager doen. Onze medewerkers moesten ook tussen vensters schakelen om klanten te helpen, de belasting op hun server te controleren of te kijken welk besturingssysteem ze gebruikten.
Zo'n interface kost tijd - zowel onze als die van de klanten. Van gebruiksgemak zoals dat van DigitalOcean is in zo'n situatie geen sprake.
Korte levenscycli met frequente API-updates
We wrote our own plugins — for example, a plugin with additional payment methods that are not available in VMManager.
In recent years, VMManager had a relatively short lifecycle, with variable or function names in the API changing arbitrarily in new versions — this broke our plugins. Support for older versions was quickly phased out, leading to the need for updates.
Cannot be modified
More precisely, it can be, but it is extremely inefficient. Licensing restrictions prevent changes to the source code; only plugins can be written. The maximum number of plugins is limited to certain menu elements or a step-by-step wizard. ISPsystem is tailored for versatility, but we needed specialized solutions.
This led to the decision to write our own panel. We set the following goals:
- Quickly respond to errors and bugs, and have the ability to resolve them independently without making the client wait.
- Freely modify the interface to fit the workflows and needs of the client.
- Enhance usability with a clean and clear design.
And we began development.
The architecture of the new panel
We have a self-sufficient development team, so we wrote the panel ourselves.
The main work was done by three engineers — the technical director Sergey devised the architecture and wrote the server agent, Alexey handled billing, and our frontend developer Artysh built the frontend.
Step 1. Server agent
The server agent is a web server written in Python that manages the library , which in turn manages .
The agent manages all services on the server: creating, stopping, deleting VDS, installing operating systems, changing parameters, and so on through the libvirt library. At the time of the article's release, there are over forty different functions that we supplement based on tasks and client needs.
In theory, libvirt could be managed directly from billing, but this required too much additional code and we decided to separate these functions between the agent and billing — billing simply makes requests to the agent via the JSON API.
The agent was the first thing we developed since it did not require any interface, and it could be tested directly from the server console.
What the server agent provided us: Er is een laag ontstaan die het leven voor iedereen vergemakkelijkt — de facturering hoeft niet een heleboel commando's door te geven, maar alleen een verzoek te doen. De agent doet alles wat nodig is: bijvoorbeeld, het toewijzen van schijfruimte en geheugen.
Stap 2. Facturering
Voor onze ontwikkelaar Alex was dit niet zijn eerste controlepaneel — Alex is al lange tijd in de hosting, dus hij begreep in het algemeen wat de klant nodig heeft en wat de hoster nodig heeft.
Facturering noemen we tussen ons 'het controlepaneel': daarin zitten niet alleen de financiën en diensten, maar ook het beheer ervan, klantenondersteuning en veel meer.
Voor de overgang van de software ISPSystem moest de eerdere functionaliteit voor klanten volledig behouden blijven, alle financiële handelingen van gebruikers uit de oude facturering naar de nieuwe worden overgebracht, evenals alle diensten en de relaties tussen hen. We bestudeerden wat er in het huidige product zat, daarna de oplossingen van concurrenten, voornamelijk DO en Vultr. We keken naar de tekortkomingen en voordelen, en verzamelden feedback van mensen die met de oude producten van ISPsystem werkten.
In de nieuwe facturering zijn twee stacks gebruikt: klassieke PHP, MySQL (en in de toekomst is een overgang naar PostgreSQL gepland), Yii2 als framework aan de backend en VueJS aan de frontend. De stacks werken onafhankelijk van elkaar, zijn ontwikkeld door verschillende mensen en communiceren via een JSON API. Voor de ontwikkeling toen en nu gebruiken we en van JetBrains en we houden echt van hen (hallo jongens!)
Het paneel is ontworpen volgens het modulaire principe: modules voor betalingssysteem, module voor domeinregistrars of bijvoorbeeld een module voor SSL-certificaten. Het is eenvoudig om een nieuwe functie toe te voegen of een oude te verwijderen. De architectuur is ontworpen voor uitbreiding, ook in de tegenovergestelde richting, 'naar de hardware'.
Wat we hebben verkregen: het controlepaneel, waar wij volledige controle over hebben. Nu worden bugs binnen uren opgelost en niet weken, en nieuwe functies worden op verzoek van klanten geïmplementeerd in plaats van naar de wens van ISPSystem.
Stap 3. Interface
De interface is ons teamproject.
Eerst keken we wat er zou gebeuren als we een uitbreiding bovenop de ISPsystem API maakten, zonder het interface radicaal te veranderen. Het resultaat was niet goed en we besloten alles vanaf nul te doen.
Wij geloofden dat het belangrijkste was om de interface logisch te maken, met een schoon en minimalistisch design, en zo een mooie panel te creëren. De plaatsing van de elementen werd besproken in Megaplan en geleidelijk ontstond de interface die gebruikers nu in het controlepaneel zien.
Als eerste kwamen we met het ontwerp van de factureringspagina, aangezien we al betaalplugins voor ISPsystem hadden gemaakt.
Frontend
We besloten de panel als een SPA-applicatie te maken - lichtgewicht en met snelle gegevenslading. Onze frontend-ontwikkelaar Artysh besloot het te schrijven in Vue - op dat moment was Vue net verschenen. We vermoeden dat het framework dynamisch zou groeien, net als React, en dat de Vue-gemeenschap zou uitbreiden met een overvloed aan bibliotheken. We hebben voor Vue gekozen en hebben daar geen spijt van gehad - het kost nu weinig tijd om nieuwe functies toe te voegen aan de frontend die we al op de backend hebben geprogrammeerd. Meer over de frontend van het panel zullen we in een apart artikel vertellen.
Verbinding tussen frontend en backend
We hebben de frontend verbonden met de backend via push-notificaties. We moesten flink wat werk verzetten en een eigen handler schrijven, maar nu gebeurt de informatie-updating op de pagina bijna onmiddellijk.
Het resultaat: de interface van de panel is eenvoudiger geworden. We hebben het responsief gemaakt, en de snelle laadtijd maakt het mogelijk om het zelfs met mobiele telefoons te gebruiken in de laatste minuten voor de take-off, zonder een aparte applicatie voor de panel te installeren.
Stap 4. Testen en migratie schema
Toen alles werkte en de eerste tests waren doorlopen, kwam de vraag van migratie aan de orde. Als eerste hebben we de facturering opgezet en begonnen we met het testen van de samenwerking met de server-agent.
Vervolgens hebben we een eenvoudig script geschreven dat de database uit de oude facturering naar de nieuwe verplaatst.
We moesten letterlijk alles testen en controleren, omdat de gegevens in één nieuwe database van drie oude werden samengevoegd: Billmanager, VMmanager en IPmanager. Misschien zijn testmigraties het moeilijkste waar we mee te maken kregen tijdens de ontwikkeling van het nieuwe panel.
Na de controles hebben we de oude facturering afgesloten. De finale datamigratie was een erg zenuwslopend moment, maar gelukkig werd deze binnen enkele minuten en zonder merkbare problemen uitgevoerd. Er waren kleine bugs die we gedurende een week hebben opgelost. De meeste tijd ging naar het testen van het uiteindelijke resultaat.
Daarna verstuurden we e-mails naar klanten met het adres van het nieuwe paneel en de facturering en maakten we een omleiding.
Uiteindelijk: HET IS LEVEND!
Gelukkig einde
Vanaf de eerste uren dat we onze software operationeel hadden, ervaarden we de voordelen van de overstap. De code was helemaal van ons en had een handige architectuur, terwijl de interface schoon en logisch was.
De eerste beoordeling na de lancering van het nieuwe paneel
We startten het overstapproces in december, vlak voor het Nieuwe Jaar 2017, toen de belasting het laagst was, om de overgang voor klanten gemakkelijker te maken — bijna niemand werkt vlak voor de feestdagen.
Het belangrijkste dat we hebben gekregen bij de overstap naar ons systeem (naast algemene betrouwbaarheid en gebruiksgemak) — is de mogelijkheid om snel functionaliteit toe te voegen voor sleutelklanten — ze als het ware voorop te stellen in plaats van achteraan.
Wat nu?
We groeien, het aantal gegevens, klanten en klantgegevens groeit. We moesten een Memcached-server en twee queue-managers met verschillende taken aan de backend toevoegen. Aan de frontend zijn er caching en eigen queues.
Natuurlijk hadden we ook nog avonturen tijdens de ontwikkeling en complicatie van het product, bijvoorbeeld toen we HighLoad toevoegden.
In het volgende artikel zullen we vertellen hoe we het Hi-CPU tarief hebben gelanceerd: over de hardware, software, welke taken we oplosten en wat we hebben bereikt.
Bron: habr.com
