Hallo! Wij zijn "Hosting Technologies" en zijn 5 jaar geleden gelanceerd — de eerste vds-hosting die speciaal voor ontwikkelaars is gemaakt. We streven ernaar om het gemakkelijk te maken, zoals DigitalOcean, maar met Russische ondersteuning, betalingsmethoden en servers in Rusland. Maar DigitalOcean is niet alleen betrouwbaarheid en prijs, het is ook een service.
Software van ISPsystem bleek een touw te zijn dat onze handen bond op weg naar een coole dienst. Drie jaar geleden maakten we gebruik van Billmanager billing en het VMmanager server control panel en realiseerden we ons al snel dat het bijna onmogelijk was om een goede service te verlenen zonder ons eigen control panel.
Hoe ISPsystem gemak doodde
Insecten
We konden de bug niet zelf oplossen - elke keer moesten we naar de ondersteuning van iemand anders schrijven en wachten. De oplossing voor elk probleem vereiste de reactie van een extern bedrijf.
ISP-systeemondersteuning reageerde normaal, maar reparaties kwamen pas na een paar releases, en dan niet altijd en niet allemaal. Soms werden kritieke bugs enkele weken gecorrigeerd. We moesten klanten geruststellen, onze excuses aanbieden en wachten tot ISPsystem de bug had opgelost.
Downtime-dreiging
Updates kunnen onvoorspelbare uitvaltijden veroorzaken die nieuwe fouten veroorzaken.
Elke update was een loterij: ik moest de facturering verdoezelen en offers brengen aan de goden van updates - een paar keer veroorzaakte de update een downtime van 10-15 minuten. Onze beheerders zaten op dit moment met hun ogen te kijken - we wisten nooit hoe lang de downtime zou duren en konden niet voorspellen wanneer ISPsystem zou besluiten een nieuwe update uit te brengen.
Op de vijfde generatie werd Billmanager beter, maar om toegang te krijgen tot de noodzakelijke functies, moest ik een bèta installeren, die al elke week werd bijgewerkt. Als er iets kapot ging, moest ik andere ontwikkelaars toegang geven zodat ze iets konden repareren.
Onhandige paneelinterface
Alles werd opgedeeld in verschillende panelen en bestuurd vanuit verschillende plaatsen. Klanten betaalden bijvoorbeeld via Billmanager en moesten VDS opnieuw opstarten of opnieuw installeren in VMManager. Onze medewerkers moesten ook schakelen tussen vensters om een klant te helpen, de belasting van zijn server te controleren of te zien welk besturingssysteem hij gebruikte.
Zo'n interface kost tijd - zowel die van ons als die van onze klanten. Van enig gemak, zoals dat van DigitalOcean, is in zo'n situatie geen sprake.
Korte levenscycli met frequente API-updates
We schreven onze eigen plug-ins - bijvoorbeeld een plug-in met extra betaalmethoden die niet in VMManager zitten.
In de afgelopen jaren had VMManager een relatief korte levenscyclus en in nieuwe versies konden de namen van variabelen of functies in de API willekeurig veranderen - dit brak onze plug-ins. Ondersteuning voor oudere versies werd snel afgebouwd en moest worden bijgewerkt.
Kan niet worden gewijzigd
Meer precies, het is mogelijk, maar uiterst inefficiënt. Licentiebeperkingen staan u niet toe om wijzigingen aan te brengen in de broncode, u kunt alleen plug-ins schrijven. Maximale plug-ins - enkele menu-items, een stapsgewijze wizard. ISPsystem is ontworpen voor veelzijdigheid, maar we hadden gespecialiseerde oplossingen nodig.
De beslissing was dus rijp om mijn eigen panel te schrijven. We hebben doelen gesteld:
- Reageer snel op fouten, bugs en los ze zelf op zonder de klant te laten wachten.
- Pas de interface vrij aan voor workflows en klantbehoeften.
- Vergroot de bruikbaarheid met een schoon en begrijpelijk ontwerp.
En we zijn begonnen met ontwikkelen.
Nieuwe paneelarchitectuur
We hebben een zelfvoorzienend ontwikkelteam, dus we hebben het panel zelf geschreven.
Het belangrijkste werk werd gedaan door drie ingenieurs - technisch directeur Sergey bedacht de architectuur en schreef de serveragent, Alexey deed de facturering en de front-end werd samengesteld door onze front-ender Artysh.
Stap 1: Serveragent
De serveragent is een python-webserver die de bibliotheek beheert , die op haar beurt regeert .
De agent beheert alle services op de server: het maken, stoppen, verwijderen van vd's, het installeren van besturingssystemen, het wijzigen van parameters, enzovoort via de libvirt-bibliotheek. Op het moment van publicatie van het artikel zijn dit meer dan veertig verschillende functies, die we aanvullen naargelang de opdracht en de noden van de opdrachtgever.
In theorie zou libvirt rechtstreeks vanuit de facturering kunnen worden beheerd, maar dit vereiste te veel extra code en we besloten om deze functies te scheiden tussen de agent en facturering - facturering doet eenvoudigweg verzoeken aan de agent via de JSON API.
De agent is het eerste dat we deden, omdat er geen interface voor nodig was en het mogelijk was om het rechtstreeks vanaf de serverconsole te testen.
Wat de serveragent ons gaf: er is een laag verschenen die het leven voor iedereen vereenvoudigt - facturering hoeft niet een hele reeks commando's te verzenden, maar alleen een verzoek te doen. En de agent zal alles doen wat nodig is: hij zal bijvoorbeeld schijfruimte en RAM toewijzen.
Stap 2. Facturering
Voor onze ontwikkelaar Alex was dit niet het eerste configuratiescherm - Alex werkt al heel lang in hosting, dus hij begreep over het algemeen wat de klant nodig had en wat de hoster nodig had.
We noemen onderling factureren een "controlepaneel": het bevat niet alleen geld en diensten, maar ook hun beheer, klantenondersteuning en nog veel meer.
Om over te stappen van ISPSystem-software was het nodig om de vorige functionaliteit voor klanten volledig te behouden, alle financiële acties van gebruikers over te dragen van de oude facturering naar de nieuwe, evenals alle diensten en verbindingen daartussen. We bestudeerden wat er in het huidige product zit, daarna de oplossingen van concurrenten, voornamelijk DO en Vultr. We hebben de nadelen en voordelen bekeken, feedback verzameld van mensen die met oude producten van ISPsystem werkten.
De nieuwe facturering gebruikte twee stapels: klassieke PHP, MySQL (en in de toekomst is het de bedoeling om over te schakelen naar PostgreSQL), Yii2 als een framework op de backend en VueJS op de voorkant. Stacks werken onafhankelijk van elkaar, worden door verschillende mensen ontwikkeld en communiceren via de JSON API. Voor ontwikkeling toen en nu gebruiken we и van JetBrains en hou zielsveel van ze (hey guys!)
Het paneel is modulair opgebouwd: betaalsysteemmodules, domeinregistratiemodule of bijvoorbeeld een SSL-certificaatmodule. U kunt eenvoudig een nieuwe functie toevoegen of een oude verwijderen. De basis voor de uitbreiding wordt architectonisch gelegd, ook in de tegenovergestelde richting, "naar de hardware".
Wat hebben we gekregen: een bedieningspaneel waar we volledige controle over hebben. Nu worden bugs in uren opgelost in plaats van weken, en nieuwe functies worden geïmplementeerd op verzoek van klanten, en niet op verzoek van ISPSystem.
Stap 3 Interface
De interface is het geesteskind van ons team.
Eerst hebben we gekeken wat er zou gebeuren als we een add-on zouden maken via de ISPsystem API zonder iets fundamenteels in de interface te veranderen. Het bleek zo-zo en we besloten om alles vanaf nul te doen.
We waren van mening dat het belangrijkste is om de interface logisch te maken, met een strak en minimalistisch ontwerp, en dan krijgen we een mooi paneel. De locatie van de elementen werd besproken in Megaplan en de interface die gebruikers nu in het controlepaneel zien, zal stilaan geboren worden.
Het ontwerp van de facturatiepagina kwam als eerste naar voren, omdat we al betalingsplugins voor ISPsystem hebben gemaakt.
Voorkant
Ze besloten om van het paneel een SPA-toepassing te maken - niet veeleisend voor bronnen en met snel laden van gegevens. Onze front-ender Artysh besloot het op Vue te schrijven - op dat moment was Vue net verschenen. We gingen ervan uit dat het framework zich dynamisch zou ontwikkelen, net als React, na enige tijd zou de Vue-gemeenschap groeien en zou er een zee van bibliotheken verschijnen. We wedden op Vue en hebben er geen spijt van gehad - nu kost het weinig tijd om nieuwe functies aan de voorkant toe te voegen die al op de backend zijn geprogrammeerd. In een apart artikel vertellen we je meer over het front-end panel.
De frontend verbinden met de backend
De frontend was via push notificaties verbonden met de backend. Ik moest hard werken en mijn eigen handler schrijven, maar nu wordt de informatie op de pagina bijna onmiddellijk bijgewerkt.
Wat is er gebeurd: De paneelinterface is eenvoudiger geworden. We hebben het adaptief gemaakt, en door snel te laden kun je het zelfs vanaf mobiele telefoons gebruiken in de laatste minuten voor het opstijgen, zonder een aparte applicatie te installeren om met het paneel te werken.
Stap 4. Test- en migratieschema
Toen alles op gang kwam en de eerste tests waren geslaagd, rees de kwestie van de migratie. Allereerst hebben we facturering geïnstalleerd en zijn we begonnen met het testen van de werking ervan met de serveragent.
Vervolgens schreven we een eenvoudig script dat de database overzet van de oude facturatie naar de nieuwe.
Ik moest letterlijk alles testen en opnieuw controleren, aangezien de gegevens werden samengevoegd tot één nieuwe database van drie oude: Billmanager, VMmanager en de IPmanager van de manager. Misschien zijn de testmigraties het moeilijkste dat we tegenkwamen tijdens het ontwikkelen van een nieuw paneel.
Na hercontrole hebben we de oude facturering afgesloten. De laatste datamigratie was een heel moeilijk moment, maar godzijdank werd deze binnen enkele minuten en zonder merkbare problemen voltooid. Er waren kleine bugs die we in de loop van de week hebben verholpen. De meeste tijd werd besteed aan het testen van wat er gebeurde.
Vervolgens stuurden we brieven naar klanten met het adres van het nieuwe paneel en de facturering en maakten we een omleiding.
In het kort: HET LEEFT!
Gelukkig einde
Vanaf de eerste werkuren van onze software voelden we alle geneugten van de overgang. De code was volledig van ons en met een handige architectuur, en de interface was schoon en logisch.
Eerste review na de lancering van het nieuwe panel
We hebben het overgangsproces in december gelanceerd, aan de vooravond van nieuwjaar 2017, toen de belasting het minst was, om de overgang gemakkelijker te maken voor klanten - bijna niemand werkt aan de vooravond van de feestdagen.
Het belangrijkste dat we kregen toen we overstapten op ons systeem (afgezien van algemene betrouwbaarheid en gemak) is de mogelijkheid om snel functionaliteit toe te voegen voor belangrijke klanten - om hun gezicht te zijn, niet hun kont.
Wat is het volgende?
We groeien, de hoeveelheid data, klanten, klantdata groeit. Ik moest een Memcached-server en twee wachtrijbeheerders met verschillende taken toevoegen aan de backend. De frontend heeft caching en zijn eigen wachtrijen.
Natuurlijk beleefden we nog steeds avonturen naarmate het product zich ontwikkelde en complexer werd, bijvoorbeeld toen we HighLoad toevoegden.
In het volgende artikel zullen we u vertellen hoe het Hi-CPU-tarief is gelanceerd: over hardware, software, welke taken we hebben opgelost en wat we hebben gedaan.
Bron: www.habr.com