ISPsystem, pardonne et au revoir! Pourquoi et comment nous avons écrit notre panneau de contrôle du serveur

Salut Nous sommes des «technologies d'hébergement» et il y a 5 ans a lancé VDSina - le premier hébergement vds créé spécifiquement pour les développeurs. Nous nous efforçons de le rendre pratique, comme DigitalOcean, mais avec un support russe, des méthodes de paiement et des serveurs en Russie. Mais DigitalOcean n'est pas seulement fiabilité et prix, c'est aussi un service.

Le logiciel d'ISPsystem s'est avéré être une corde qui nous liait les mains sur le chemin d'un service sympa. Il y a trois ans, nous avons utilisé la facturation Billmanager et le panneau de contrôle du serveur VMmanager et nous avons rapidement réalisé qu'il était presque impossible de fournir un bon service sans notre panneau.

Comment ISPsystem a tué la convivialité

Bugs

Nous n'avons pas pu corriger le bogue nous-mêmes - chaque fois que nous devions écrire dans le support de quelqu'un d'autre et attendre. La solution à tout problème nécessitait la réponse d'une société tierce.

La prise en charge d'ISPsystem a répondu normalement, mais les correctifs n'ont été apportés que par quelques versions, et pas toujours et pas toutes. Parfois, des bugs critiques corrigés pendant plusieurs semaines. Nous avons dû rassurer les clients, nous excuser et attendre qu'ISPsystem corrige le bogue.

Menace d'indisponibilité

Les mises à jour pourraient entraîner des temps d'arrêt imprévisibles qui ont provoqué de nouveaux bugs.

Chaque mise à jour était une loterie: il fallait couvrir la facturation et faire des sacrifices aux dieux des mises à jour - à quelques reprises, la mise à jour a causé un temps d'arrêt de 10 à 15 minutes. À cette époque, nos administrateurs devenaient gris sous nos yeux - nous ne savions jamais combien de temps durerait le temps d'arrêt et ne pouvions pas prédire quand ISPsystem a décidé de publier une nouvelle mise à jour.

À la cinquième génération, Billmanager s'est amélioré, mais pour avoir accès aux fonctionnalités nécessaires, j'ai dû installer une version bêta, qui était déjà mise à jour chaque semaine. Si quelque chose se cassait, vous deviez donner accès aux développeurs étrangers afin qu'ils corrigent quelque chose.

Interface de panneau peu pratique

Tout était divisé en différents panneaux et contrôlé à partir de différents endroits. Par exemple, les clients ont payé via Billmanager et ont dû redémarrer ou réinstaller VDS dans VMManager. Nos employés ont également dû basculer entre les fenêtres pour aider le client, vérifier la charge sur son serveur ou voir quel OS il utilise.

Une telle interface prend du temps - à la fois la nôtre et les clients. À propos de toute commodité, comme DigitalOcean, il n'y a aucun doute dans une telle situation.

Cycles de vie courts avec mises à jour fréquentes de l'API

Nous avons écrit nos propres plugins - par exemple, un plugin avec des méthodes de paiement supplémentaires qui ne sont pas dans VMManager.

Ces dernières années, VMManager a eu un cycle de vie relativement court, et dans les nouvelles versions, les noms des variables ou des fonctions dans l'API pouvaient changer arbitrairement - cela a cassé nos plugins. La prise en charge des anciennes versions a été rapidement minimisée et a dû être mise à jour.

Vous ne pouvez pas modifier

Plus précisément, mais extrêmement inefficace. Les restrictions de licence ne vous permettent pas de modifier la source, vous ne pouvez écrire que des plugins. Le maximum de plugins est certains éléments de menu, un assistant étape par étape. ISPsystem est affiné pour la polyvalence, et nous avions besoin de solutions spécialisées.

La décision d'écrire votre panel a donc mûri. Nous nous fixons des objectifs:

• Répondez rapidement aux erreurs, bugs et soyez en mesure de les corriger vous-même, sans faire attendre le client.
• Modifiez librement l'interface en fonction des processus de travail et des besoins des clients.
• Améliorez la convivialité avec une conception claire et compréhensible.

Et ils ont commencé le développement.

Nouvelle architecture de panneau

Nous avons une équipe de développement autonome, nous avons donc écrit le panel nous-mêmes.
Le travail principal a été effectué par trois ingénieurs - le directeur technique Sergey a conçu l'architecture et écrit l'agent du serveur, Alexey a fait la facturation et notre front Artysh a rassemblé le front.

Étape 1. Agent serveur

Un agent serveur est un serveur Web python qui gère la bibliothèque libvirt , qui à son tour gère l' hyperviseur Qemu-kvm .

L'agent gère tous les services sur le serveur: création, arrêt, désinstallation de vds, installation de systèmes d'exploitation, modification des paramètres, etc. via la bibliothèque libvirt. Au moment de la publication, il s'agit de plus de quarante fonctions différentes, que nous complétons en fonction de la tâche et des besoins du client.

En principe, libvirt pouvait être géré directement à partir de la facturation, mais il nécessitait trop de code supplémentaire et nous avons décidé de répartir ces fonctions entre l'agent et la facturation - la facturation fait simplement des demandes à l'agent via l'API JSON.

L'agent est la première chose que nous avons faite, car il ne nécessitait aucune interface et il pouvait être testé directement à partir de la console du serveur.

Ce que l'agent serveur nous a donné: une couche est apparue qui simplifie la vie de tout le monde - la facturation n'a pas besoin d'envoyer tout un tas de commandes, mais seulement de faire une demande. Et l'agent fera tout ce dont vous avez besoin: par exemple, allouer de l'espace disque et de la RAM.

Étape 2. Facturation

Pour notre développeur, Alex, ce n'était pas le premier panneau de contrôle - Alex hébergeait depuis longtemps, donc il comprenait généralement ce dont le client avait besoin et ce dont l'hébergeur avait besoin.

Nous appelons la facturation entre nous un «panneau de contrôle»: elle contient non seulement de l'argent et des services, mais aussi leur gestion, le support client et bien plus encore.

Pour passer du logiciel ISPSystem, il était nécessaire de conserver complètement la fonctionnalité précédente pour les clients, de transférer toutes les actions des utilisateurs financiers de l'ancienne facturation vers la nouvelle, ainsi que tous les services et communications entre eux. Nous avons étudié le contenu du produit actuel, puis les décisions des concurrents, principalement DO et Vultr. Nous avons examiné les inconvénients et les avantages, recueilli les commentaires des personnes qui travaillaient avec d'anciens produits d'ISPsystem.

Dans la nouvelle facturation, deux piles ont été utilisées: PHP classique, MySQL (et à l'avenir, il est prévu de passer à PostgreSQL), Yii2 comme framework sur le backend et VueJS sur le front. Les piles fonctionnent indépendamment les unes des autres, développées par différentes personnes et communiquent à l'aide de l'API JSON. Pour le développement, alors et maintenant nous utilisons PHPStorm et WebStorm de JetBrains et les aimons beaucoup (les gars, bonjour!)

Le panneau est conçu selon le principe modulaire: modules de système de paiement, module d'enregistrement de domaine ou, par exemple, module de certificat SSL. Vous pouvez facilement ajouter une nouvelle fonction ou supprimer l'ancienne. Les bases de l'expansion ont été posées sur le plan architectural, y compris dans le sens opposé, «au fer».

Ce que nous avons obtenu : un panneau de contrôle sur lequel nous avons un contrôle total. Désormais, les bogues sont corrigés en heures et non en semaines, et de nouvelles fonctions sont implémentées à la demande des clients et non à la demande d'ISPSystem.

Étape 3. Interface

L'interface est une idée originale de notre équipe.

Tout d'abord, nous avons examiné ce qui se passerait si nous faisions un module complémentaire sur l'API ISPsystem sans rien changer de façon spectaculaire dans l'interface. Cela s'est avéré moyen et nous avons décidé de tout faire à partir de zéro.

Nous pensions que l'essentiel était de rendre l'interface logique, avec un design épuré et minimaliste, et nous obtiendrions alors un beau panneau. L'arrangement des éléments a été discuté dans Megaplan, et l'interface que les utilisateurs voient maintenant dans le panneau de contrôle va progressivement naître.

La première page de facturation est apparue, car nous avons déjà créé des plugins de paiement pour ISPsystem.

Frontend

Ils ont décidé de faire du panel une application SPA - peu exigeante en ressources et avec un chargement rapide des données. Notre front-end Artysh a décidé de l'écrire sur Vue - à l'époque, Vue venait d'apparaître. Nous avons supposé que le framework se développerait dynamiquement, comme React, après un certain temps, la communauté Vue se développerait et une mer de bibliothèques apparaîtrait. Nous l'avons installé sur Vue et ne l'avons pas regretté - l'ajout de nouvelles fonctionnalités qui ont déjà été programmées sur le backend prend maintenant peu de temps. Nous vous en dirons plus sur les panneaux frontaux dans un article séparé.

Communication du frontend avec le backend

Le frontend a été lié au backend par le biais de pushies. J'ai dû transpirer et écrire mon propre gestionnaire, mais maintenant les informations sur la page sont mises à jour presque instantanément.

Ce qui s'est passé: l'interface du panneau est devenue plus facile. Nous l'avons rendu adaptatif, et un chargement rapide lui permet d'être utilisé même à partir de téléphones portables dans les dernières minutes avant le décollage, sans installer d'application séparée pour travailler avec le panneau.

Étape 4. Schéma de test et de migration

Lorsque tout a commencé et que les premiers tests ont réussi, la question de la migration s'est posée. Tout d'abord, nous avons mis en place la facturation et commencé à tester son travail avec l'agent serveur.

Ensuite, ils ont écrit un script simple qui transfère la base de données de l'ancienne facturation à la nouvelle.

J'ai dû tester et revérifier littéralement tout, car les données ont été versées dans une nouvelle base de données à partir des trois anciennes: Billmanager, VMmanager et IPmanager manager. La migration de test est peut-être la chose la plus difficile que nous ayons rencontrée lors du développement d'un nouveau panel.

Après avoir revérifié, nous avons dissimulé l'ancienne facturation. La migration finale des données a été un moment très inquiétant, mais, Dieu merci, elle s'est achevée en quelques minutes et sans problème notable. Il y a eu des bugs mineurs que nous avons corrigés en une semaine. Le temps principal a été pris en testant ce qui s'est passé.

Ensuite, nous avons envoyé des lettres aux clients avec l'adresse du nouveau panneau et la facturation et fait une redirection.

Conclusion: C'EST VIVANT!

Heureux

Dès les premières heures de notre logiciel, nous avons ressenti tous les délices de la transition. Le code était complètement à nous et avec une architecture pratique, et l'interface était propre et logique.

Le premier examen après le lancement d'un nouveau panel

Nous avons entamé le processus de transition en décembre, à la veille du nouvel an 2017, alors qu'il y avait le moins de charge pour faciliter la transition pour les clients - presque personne ne travaille la veille des vacances.

La principale chose que nous avons obtenue lors de la transition vers notre système (en plus de la fiabilité et de la commodité générales) est la possibilité d'ajouter rapidement des fonctionnalités pour les clients clés - d'être leur visage et non leur cul.

Et ensuite?

Nous grandissons, la quantité de données, les clients, les données clients augmentent. Un serveur memcached et deux gestionnaires de files d'attente avec des tâches différentes ont dû être ajoutés au backend. Il y a une mise en cache et des files d'attente sur le frontal.

Bien sûr, nous avions encore des aventures à mesure que nous développions et compliquions le produit, par exemple, lorsque nous avons ajouté HighLoad.

Dans le prochain article, nous vous expliquerons comment le tarif Hi-CPU a été lancé: sur le matériel, les logiciels, les tâches que nous avons résolues et ce que nous avons fait.

Abonnez-vous à notre développeur Instagram