ISPsystem, прости и сбогом! Защо и как написахме контролния панел на нашия сървър

Здравейте! Ние сме "Хостинг технологии" и стартирахме преди 5 години VDSina — първият vds хостинг, създаден специално за разработчици. Стремим се да го направим удобен, като DigitalOcean, но с руска поддръжка, методи на плащане и сървъри в Русия. Но DigitalOcean не е само надеждност и цена, той е и услуга.

Софтуерът от ISPsystem се оказа въже, което ни върза ръцете по пътя към страхотна услуга. Преди три години използвахме таксуването на Billmanager и контролния панел на сървъра VMmanager и бързо осъзнахме, че е почти невъзможно да предоставим добра услуга без нашия собствен контролен панел.

Как ISPsystem уби удобството

Грешки

Не можахме сами да поправим грешката - всеки път трябваше да пишем на поддръжката на някой друг и да чакаме. Решението на всеки проблем изисква реакцията на трета страна.

Поддръжката на ISPsystem реагира нормално, но поправките идват само след няколко издания, а след това не винаги и не всички. Понякога критичните грешки бяха коригирани за няколко седмици. Трябваше да успокоим клиентите, да се извиним и да изчакаме ISPsystem да поправи грешката.

Заплаха от престой

Актуализациите могат да генерират непредвидими прекъсвания, които провокират нови грешки.

Всяка актуализация беше лотария: трябваше да прикрия таксуването и да направя жертви на боговете на актуализациите - няколко пъти актуализацията причини прекъсване за 10-15 минути. Нашите администратори по това време седяха на очи - никога не знаехме колко дълго ще продължи прекъсването и не можехме да предвидим кога ISPsystem ще реши да пусне нова актуализация.

При петото поколение Billmanager се подобри, но за да получа достъп до необходимите функции, трябваше да инсталирам бета версия, която вече се актуализира всяка седмица. Ако нещо се повреди, трябваше да дам достъп на други разработчици, за да могат да поправят нещо.

Неудобен интерфейс на панела

Всичко беше разделено на различни панели и се управляваше от различни места. Например, клиентите плащаха през Billmanager и трябваше да рестартират или преинсталират VDS във VMManager. Нашият персонал също трябваше да превключва между прозорци, за да помогне на клиент, да провери натоварването на неговия сървър или да види каква операционна система използва.

Подобен интерфейс изисква време – както наше, така и на нашите клиенти. За удобство като това на DigitalOcean в подобна ситуация не може да става дума.

Кратки жизнени цикли с чести актуализации на API

Написахме наши собствени плъгини - например плъгин с допълнителни методи за плащане, които не са във VMManager.

През последните години VMManager имаше сравнително кратък жизнен цикъл и в новите версии имената на променливите или функциите в API можеха да се променят произволно - това счупи нашите плъгини. Поддръжката за по-стари версии бързо беше премахната и трябваше да бъде актуализирана.

Не може да се променя

По-точно възможно е, но изключително неефективно. Ограниченията на лиценза не ви позволяват да правите промени в изходния код, можете да пишете само добавки. Максимум плъгини - някои елементи от менюто, съветник стъпка по стъпка. ISPsystem са проектирани за гъвкавост, но имахме нужда от специализирани решения.

Така че решението беше узряло да напиша собствен панел. Поставили сме си цели:

• Отговаряйте бързо на грешки, бъгове и можете да ги коригирате сами, без да карате клиента да чака.
• Свободно модифицирайте интерфейса за работни процеси и нужди на клиента.
• Увеличете използваемостта с чист и разбираем дизайн.

И започнахме развитие.

Нова панелна архитектура

Имаме самодостатъчен екип за разработка, така че сами написахме панела.
Основната работа беше извършена от трима инженери - техническият директор Сергей измисли архитектурата и написа сървърния агент, Алексей направи таксуването, а фронтендът беше сглобен от нашия фронтенд Артиш.

Стъпка 1: Агент на сървъра

Агентът на сървъра е уеб сървър на Python, който управлява библиотеката libvirt, което от своя страна управлява Qemu-kvm хипервизор.

Агентът управлява всички услуги на сървъра: създаване, спиране, изтриване на vds, инсталиране на операционни системи, промяна на параметри и т.н. чрез библиотеката libvirt. Към момента на публикуване на статията това са повече от четиридесет различни функции, които допълваме в зависимост от задачата и нуждите на клиента.

На теория libvirt може да се контролира директно от таксуването, но това изисква твърде много допълнителен код и ние решихме да разделим тези функции между агента и таксуването - таксуването просто прави заявки към агента чрез JSON API.

Агентът е първото нещо, което направихме, тъй като не изискваше никакъв интерфейс и беше възможно да го тестваме директно от конзолата на сървъра.

Какво ни даде сървърният агент: се появи слой, който опростява живота на всички - фактурирането не трябва да изпраща цял куп команди, а само да прави заявка. И агентът ще направи всичко, което е необходимо: например ще разпредели дисково пространство и RAM.

Стъпка 2. Таксуване

За нашия разработчик Алекс това не беше първият контролен панел - Алекс се занимава с хостинг от дълго време, така че като цяло разбираше от какво се нуждае клиентът и от какво се нуждае хостът.

Ние наричаме фактурирането помежду си „контролен панел“: той съдържа не само пари и услуги, но и тяхното управление, поддръжка на клиенти и много други.

За да преминете от софтуера ISPSystem, беше необходимо да запазите напълно предишната функционалност за клиентите, да прехвърлите всички финансови действия на потребителите от стария билинг към новия, както и всички услуги и връзки между тях. Проучихме какво има в текущия продукт, след това решенията на конкурентите, главно DO и Vultr. Разгледахме недостатъците и предимствата, събрахме отзиви от хора, които са работили със стари продукти на ISPsystem.

Новото таксуване използва два стека: класически PHP, MySQL (а в бъдеще се планира да премине към PostgreSQL), Yii2 като рамка в задната част и VueJS в предната част. Стековете работят независимо един от друг, разработени са от различни хора и комуникират чрез JSON API. За развитие тогава и сега използваме PHPStorm и уеббуря от JetBrains и ги обичам много (хей, момчета!)

Панелът е проектиран на модулен принцип: модули на платежната система, модул за регистрация на домейни или, например, модул за SSL сертификат. Можете лесно да добавите нова функция или да премахнете стара. Основата за експанзията е положена архитектурно, включително и в обратната посока, „към хардуера“.

Какво получихме: контролен панел, върху който имаме пълен контрол. Сега грешките се коригират за часове, а не за седмици, а новите функции се внедряват по желание на клиентите, а не по искане на ISPSystem.

Стъпка 3 Интерфейс

Интерфейсът е идеята на нашия екип.

Първо, разгледахме какво би се случило, ако направим добавка върху API на ISPsystem, без да променим фундаментално нищо в интерфейса. Получи се така-така и решихме да направим всичко от нулата.

Вярвахме, че основното нещо е да направим интерфейса логичен, с изчистен и минималистичен дизайн и тогава ще получим красив панел. Местоположението на елементите беше обсъдено в Megaplan и постепенно ще се роди интерфейсът, който потребителите виждат в контролния панел сега.

Първо се появи дизайнът на страницата за плащане, тъй като вече сме направили плъгини за плащане за ISPsystem.

Frontend

Те решават да направят панела SPA приложение - невзискателно към ресурси и с бързо зареждане на данни. Нашият фронтендър Артиш реши да го напише на Vue — по това време Vue току-що се появи. Предполагахме, че рамката ще се развива динамично, подобно на React, след известно време общността на Vue ще нарасне и ще се появи море от библиотеки. Заложихме на Vue и не съжаляваме - сега отнема малко време за добавяне на нови функции към предната част, които вече са били програмирани в задната част. Ще ви разкажем повече за предния панел в отделна статия.

Свързване на фронтенда с бекенда

Предният интерфейс беше свързан с задния чрез насочени известия. Трябваше да работя усилено и да напиша собствен манипулатор, но сега информацията на страницата се актуализира почти мигновено.

Какво стана: Интерфейсът на панела стана по-прост. Направихме го адаптивен, а бързото зареждане ви позволява да го използвате дори от мобилни телефони в последните минути преди излитане, без да инсталирате отделно приложение за работа с панела.

Стъпка 4. Схема за тестване и миграция

Когато всичко стартира и преминаха първите тестове, възникна въпросът за миграцията. На първо място, инсталирахме таксуване и започнахме да тестваме работата му със сървърния агент.

След това написахме прост скрипт, който прехвърля базата данни от старото таксуване към новото.

Трябваше да тествам и проверявам отново буквално всичко, тъй като данните бяха обединени в една нова база данни от три стари: Billmanager, VMmanager и IPmanager на мениджъра. Може би тестовите миграции са най-трудното нещо, с което се сблъскахме в процеса на разработване на нов панел.

След повторна проверка затворихме старото таксуване. Окончателната миграция на данни беше много тревожен момент, но, слава Богу, беше завършена за няколко минути и без забележими проблеми. Имаше малки грешки, които коригирахме през седмицата. По-голямата част от времето беше прекарано в тестване на случилото се.

След това изпратихме писма до клиентите с адреса на новия панел и таксуването и направихме пренасочване.

В обобщение: ЖИВО Е!

Щастлив край

От първите часове на работа на нашия софтуер усетихме всички прелести на прехода. Кодът беше изцяло наш и с удобна архитектура, а интерфейсът изчистен и логичен.

Първи преглед след пускането на новия панел

Стартирахме прехода през декември, в навечерието на Нова 2017 г., когато натоварването беше най-малко, за да улесним прехода на клиентите - почти никой не работи в навечерието на празниците.

Основното, което получихме при преминаването към нашата система (освен общата надеждност и удобство) е възможността бързо да добавяме функционалност за ключови клиенти - да бъдем тяхното лице, а не задника им.

Каква е следващата?

Ние растем, количеството данни, клиенти, клиентски данни нарастват. Трябваше да добавя Memcached сървър и два мениджъра на опашки с различни задачи към бекенда. Предният интерфейс има кеширане и собствени опашки.

Разбира се, все още имахме приключения, докато продуктът се развиваше и ставаше по-сложен, например когато добавихме HighLoad.

В следващата статия ще ви разкажем как беше пусната тарифата Hi-CPU: за хардуера, софтуера, какви задачи решихме и какво направихме.

Източник: www.habr.com