Hola! Som "Tecnologies d'allotjament" i ens vam llançar fa 5 anys — el primer allotjament de vds creat específicament per a desenvolupadors. Ens esforcem perquè sigui convenient, com DigitalOcean, però amb suport rus, mètodes de pagament i servidors a Rússia. Però DigitalOcean no és només fiabilitat i preu, també és un servei.
El programari d'ISPsystem va resultar ser una corda que ens lligava les mans en el camí cap a un servei fantàstic. Fa tres anys, vam utilitzar la facturació de Billmanager i el tauler de control del servidor VMmanager i ràpidament ens vam adonar que era gairebé impossible oferir un bon servei sense el nostre propi tauler de control.
Com el sistema ISP va matar la comoditat
Errors
No vam poder solucionar l'error nosaltres mateixos; cada vegada havíem d'escriure al servei d'assistència d'una altra persona i esperar. La solució a qualsevol problema requeria la resposta d'una empresa aliena.
El suport del sistema ISP va respondre amb normalitat, però les correccions van arribar només després d'uns quants llançaments, i no sempre i no totes. De vegades, els errors crítics es van corregir durant diverses setmanes. Vam haver de tranquil·litzar els clients, demanar disculpes i esperar que ISPsystem solucionés l'error.
Amenaça de temps d'inactivitat
Les actualitzacions podrien generar temps d'inactivitat impredictibles que provocaven nous errors.
Cada actualització era una loteria: vaig haver de cobrir la facturació i fer sacrificis als déus de les actualitzacions: un parell de vegades l'actualització va causar temps d'inactivitat durant 10-15 minuts. Els nostres administradors en aquest moment estaven asseguts als ulls: mai sabíem quant de temps duraria el temps d'inactivitat i no podíem predir quan ISPsystem decidiria llançar una nova actualització.
A la cinquena generació, Billmanager va millorar, però per poder accedir a les funcions necessàries, vaig haver d'instal·lar una versió beta, que ja s'actualitzava cada setmana. Si es trencava alguna cosa, havia de donar accés a altres desenvolupadors perquè poguessin arreglar alguna cosa.
Interfície de panell incòmode
Tot estava dividit en diferents panells i controlat des de diferents llocs. Per exemple, els clients pagaven mitjançant Billmanager i havien de reiniciar o reinstal·lar VDS a VMManager. El nostre personal també va haver de canviar entre les finestres per ajudar un client, comprovar la càrrega del seu servidor o veure quin sistema operatiu estava utilitzant.
Aquesta interfície requereix temps, tant per a nosaltres com per als nostres clients. No es tracta de cap conveniència, com la de DigitalOcean, en una situació així.
Cicles de vida curts amb actualitzacions freqüents de l'API
Hem escrit els nostres propis connectors, per exemple, un connector amb mètodes de pagament addicionals que no es troben a VMManager.
En els darrers anys, VMManager va tenir un cicle de vida relativament curt i, en les noves versions, els noms de les variables o funcions de l'API podien canviar arbitràriament; això va trencar els nostres connectors. El suport per a versions anteriors es va eliminar ràpidament i es va haver d'actualitzar.
No es pot modificar
Més precisament, és possible, però extremadament ineficient. Les restriccions de llicència no us permeten fer canvis al codi font, només podeu escriure connectors. Màxim de connectors: alguns elements del menú, un assistent pas a pas. Els sistemes ISP estan dissenyats per a la versatilitat, però necessitàvem solucions especialitzades.
Així que la decisió era madura d'escriure el meu propi panell. Ens hem marcat objectius:
- Respondre ràpidament als errors, errors i ser capaç de solucionar-los tu mateix sense fer esperar el client.
- Modifiqueu lliurement la interfície per als fluxos de treball i les necessitats del client.
- Augmenta la usabilitat amb un disseny net i entenedor.
I vam començar el desenvolupament.
Nova arquitectura de panells
Tenim un equip de desenvolupament autosuficient, així que vam escriure el panell nosaltres mateixos.
El treball principal va ser realitzat per tres enginyers: el director tècnic Sergey va idear l'arquitectura i va escriure l'agent del servidor, Alexey va fer la facturació i el front-end va ser muntat pel nostre front-ender Artysh.
Pas 1: Agent del servidor
L'agent del servidor és un servidor web Python que gestiona la biblioteca , que al seu torn governa .
L'agent gestiona tots els serveis del servidor: creació, aturada, eliminació de vds, instal·lació de sistemes operatius, canvi de paràmetres, etc. a través de la biblioteca libvirt. En el moment de la publicació de l'article, es tracta de més d'una quarantena de funcions diferents, que complementem en funció de la tasca i les necessitats del client.
En teoria, libvirt es podia controlar directament des de la facturació, però això requeria massa codi addicional i vam decidir separar aquestes funcions entre l'agent i la facturació: la facturació simplement fa sol·licituds a l'agent mitjançant l'API JSON.
L'agent és el primer que vam fer, ja que no necessitava cap interfície i era possible provar-ho directament des de la consola del servidor.
Què ens va donar l'agent del servidor: ha aparegut una capa que simplifica la vida de tothom: la facturació no necessita enviar un munt d'ordres, sinó només fer una sol·licitud. I l'agent farà tot el que sigui necessari: per exemple, assignarà espai al disc i RAM.
Pas 2. Facturació
Per al nostre desenvolupador Alex, aquest no va ser el primer tauler de control: l'Alex ha estat a l'allotjament durant molt de temps, de manera que en general va entendre què necessitava el client i què necessitava l'amfitrió.
Anomenem la facturació entre nosaltres un "tauler de control": conté no només diners i serveis, sinó també la seva gestió, atenció al client i molt més.
Per canviar del programari ISPSystem, calia preservar completament la funcionalitat anterior per als clients, transferir totes les accions financeres dels usuaris de la facturació antiga a la nova, així com tots els serveis i connexions entre ells. Hem estudiat què hi ha al producte actual, després les solucions dels competidors, principalment DO i Vultr. Hem analitzat els inconvenients i els avantatges, hem recollit comentaris de persones que treballaven amb productes antics d'ISPsystem.
La nova facturació utilitzava dues piles: PHP clàssic, MySQL (i en el futur està previst canviar a PostgreSQL), Yii2 com a marc a la part posterior i VueJS a la part frontal. Les piles funcionen de manera independent les unes de les altres, són desenvolupades per diferents persones i es comuniquen mitjançant l'API JSON. Per al desenvolupament llavors i ara fem servir и de JetBrains i els estimem molt (hola nois!)
El panell està dissenyat de manera modular: mòduls de sistemes de pagament, mòdul de registre de dominis o, per exemple, mòdul de certificat SSL. Podeu afegir fàcilment una funció nova o eliminar-ne una d'antiga. Les bases de l'ampliació s'estableixen arquitectònicament, fins i tot en sentit contrari, "cap a la ferreteria".
El que tenim: un panell de control sobre el qual tenim el control total. Ara els errors es solucionen en hores, no en setmanes, i les noves funcions s'implementen a petició dels clients, i no a petició d'ISPSystem.
Pas 3 Interfície
La interfície és una idea del nostre equip.
Primer, vam mirar què passaria si féssim un complement a l'API del sistema ISP sense canviar fonamentalment res a la interfície. Va ser així i vam decidir fer-ho tot des de zero.
Creiem que el més important és fer la interfície lògica, amb un disseny net i minimalista, i després obtindrem un panell preciós. La ubicació dels elements es va parlar a Megaplan i la interfície que ara veuen els usuaris al tauler de control anirà naixent.
El disseny de la pàgina de facturació va ser el primer a aparèixer, perquè ja hem fet connectors de pagament per ISPsystem.
Frontend
Van decidir fer del panell una aplicació SPA: poc exigent per als recursos i amb càrrega ràpida de dades. El nostre front-ender Artysh va decidir escriure-ho a Vue, en aquell moment Vue acabava d'aparèixer. Vam suposar que el marc es desenvoluparia de manera dinàmica, com React, al cap d'un temps la comunitat Vue creixeria i apareixeria un mar de biblioteques. Vam apostar per Vue i no ens vam penedir: ara triga poc temps afegir noves funcions a la part frontal que ja s'han programat a la part posterior. Us explicarem més sobre el panell frontal en un article separat.
Connexió del frontend al backend
El frontend es va connectar al backend mitjançant notificacions push. Vaig haver de treballar molt i escriure el meu propi gestor, però ara la informació de la pàgina s'actualitza gairebé a l'instant.
Què va passar: La interfície del panell s'ha fet més senzilla. El vam fer adaptatiu i la càrrega ràpida us permet utilitzar-lo fins i tot des de telèfons mòbils en els últims minuts abans de l'enlairament, sense instal·lar una aplicació independent per treballar amb el panell.
Pas 4. Esquema de prova i migració
Quan tot va començar i van passar les primeres proves, va sorgir la qüestió de la migració. En primer lloc, vam instal·lar la facturació i vam començar a provar el seu funcionament amb l'agent del servidor.
Després vam escriure un script senzill que transfereix la base de dades de la facturació antiga a la nova.
Vaig haver de provar i tornar a comprovar literalment tot, ja que les dades es van fusionar en una nova base de dades de tres antigues: Billmanager, VMmanager i IPmanager del gestor. Potser les migracions de prova són el més difícil que hem trobat en el procés de desenvolupament d'un nou panell.
Després de tornar a comprovar, vam tancar la facturació antiga. La migració de dades final va ser un moment molt preocupant, però, gràcies a Déu, es va completar en pocs minuts i sense problemes notables. Hi va haver errors menors que vam solucionar durant la setmana. La major part del temps es va passar provant el que va passar.
Després vam enviar cartes als clients amb l'adreça del nou panell i la facturació i vam fer una redirecció.
En resum: ESTÀ VIU!
Final feliç
Des de les primeres hores de treball del nostre programari, vam sentir totes les delícies de la transició. El codi era completament nostre i amb una arquitectura convenient, i la interfície era neta i lògica.
Primera revisió després del llançament del nou panell
Vam posar en marxa el procés de transició al desembre, la vigília de l'Any Nou 2017, quan la càrrega era la menor, per facilitar la transició als clients: gairebé ningú treballa la vigília de les vacances.
El més important que vam aconseguir quan vam canviar al nostre sistema (a part de la fiabilitat i la comoditat generals) és la capacitat d'afegir ràpidament funcionalitats per als clients clau: ser la seva cara, no el cul.
Què serà el següent?
Estem creixent, la quantitat de dades, clients, dades de clients creix. Vaig haver d'afegir un servidor Memcached i dos gestors de cues amb diferents tasques al backend. La interfície té memòria cau i les seves pròpies cues.
Per descomptat, encara teníem aventures a mesura que el producte es desenvolupava i es feia més complex, per exemple quan vam afegir HighLoad.
En el següent article us explicarem com es va llançar la tarifa Hi-CPU: sobre maquinari, programari, quines tasques hem resolt i què hem fet.
Font: www.habr.com