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.

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

Какво ни даде сървърният агент: появила се прослойка, която улеснява живота на всички — на billing не му е нужно да предава цяла купчина команди, а само да направи заявка. А агентът ще свърши всичко необходимо: например, ще резервира място на диска и оперативна памет.

Стъпка 2. Билинг

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

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

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

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

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

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

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

Интерфейсът е наше общо дете.

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

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

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

Фронтенд

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

Връзка между фронтенда и бекенда

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

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

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

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

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

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

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

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

Резултат: ТОЙ Е ЖИВ!

Щастлив край

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

Първото мнение след старта на новата панелна система

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

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

Какво следва?

Растем, увеличават се данните, клиентите и клиентските данни. На бекенда добавихме Memcached-сървър и двама мениджъри на опашки с различни задачи. На фронтенда имаме кеширане и собствени опашки.

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

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

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