Хабрахабр

ISPsystem, прости и прощай! Почему и как мы написали свою панель управления серверами

image

Мы «Хостинг технологии» и 5 лет назад запустили VDSina — первый vds хостинг, созданный специально для разработчиков. Привет! Но DigitalOcean это не только надежность и цена, это еще и сервис. Мы стремимся сделать его удобным, как DigitalOcean, но с русской поддержкой, способами оплаты и серверами в России.

Три года назад мы использовали биллинг Billmanager и панель управления серверами VMmanager и быстро поняли, что оказывать хороший сервис без своей панели практически нереально.
Софт от ISPsystem оказался веревкой, которая связывала нам руки на пути к крутому сервису.

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

Баги

Решение любой проблемы требовало реакции сторонней компании. Мы не могли сами пофиксить баг — каждый раз приходилось писать в чужую поддержку и ждать.

Иногда критические баги правились несколько недель. Поддержка ISPsystem нормально отвечала, но фиксы приходили только через несколько релизов, и то не всегда и не все. Нам приходилось успокаивать клиентов, извиняться и ждать, пока ISPsystem починят баг.

Угроза даунтаймов

Обновления могли порождать непрогнозируемые даунтаймы, которые провоцировали новые ошибки.

Наши админы в это время седели на глазах — мы никогда не знали, сколько продлится даунтайм и не могли спрогнозировать, когда ISPsystem решит выпустить новый апдейт. Каждый апдейт был лотереей: приходилось прикрывать биллинг и приносить жертвы богам обновлений — пару раз апдейт вызывал даунтайм на минут 10-15.

Если что-то ломалось, приходилось давать доступ чужим разработчикам, чтобы они что-то поправили. На пятом поколении Billmanager стало получше, но чтобы получить доступ к необходимым фичам пришлось ставить бету, которая уже обновлялась каждую неделю.

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

Например, клиенты платили через Billmanager, а перезагружать или переустанавливать VDS им приходилось в VMManager. Всё было разделено на разные панели и управлялось из разных мест. Нашим сотрудникам тоже приходилось переключаться между окнами, чтобы помочь клиенту, проверить нагрузку на его сервере или посмотреть, какую ОС он использует.

Ни о каком удобстве, как у DigitalOcean, в такой ситуации речи не идёт. Такой интерфейс отнимает время — и наше, и клиентов.

Короткие лайфциклы с частым обновлением API

Мы писали собственные плагины — например, плагин с дополнительными способами оплаты, которых нет в VMManager.

Поддержку старых версий быстро сворачивали и приходилось обновляться. В последние годы у VMManager был относительно короткий жизненный цикл, причем в новых версиях могли произвольно меняться названия переменных или функций в API — это ломало наши плагины.

Нельзя дорабатывать

Лицензионные ограничения не дают вносить изменения в исходники, можно только писать плагины. Точнее можно, но крайне неэффективно. ISPsystem заточены на универсальность, а нам нужны были специализированные решения. Максимум плагинов — какие-то элементы меню, пошаговый мастер.

Мы поставили цели: Так созрело решение написать свою панель.

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

И начали разработку.

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

У нас есть самодостаточная команда разработки, так что панель мы написали сами.
Основную работу проделали три инженера — технический директор Сергей придумал архитектуру и написал серверный агент, Алексей сделал биллинг, а фронтенд собрал наш фронтендер Артыш.

Шаг 1. Серверный агент

Серверный агент — это веб-сервер на питоне, который управляет библиотекой libvirt, которая, в свою очередь, управляет гипервизором Qemu-kvm.

На момент выхода статьи это больше сорока разных функций, которые мы дополняем в зависимости от задачи и потребностей клиента. Агент управляет всеми услугами на сервере: создание, остановка, удаление vds, установка операционных систем, изменение параметров и так далее через библиотеку libvirt.

По идее libvirt можно было управлять прямо из биллинга, но это требовало слишком много дополнительного кода и мы решили разнести эти функции между агентом и биллингом — биллинг просто делает запросы агенту через JSON API.

Агент — первое, что мы сделали, поскольку он не требовал никакого интерфейса и тестировать его можно было прямо из консоли сервера.

А агент сделает все, что нужно: например, выделит место на диске и оперативную память. Что дал нам серверный агент: появилась прослойка, которая упрощает жизнь всем — биллингу не нужно передавать целую кучу команд, а только сделать запрос.

Шаг 2. Биллинг

Для нашего разработчика Алекса это была уже не первая панель управления — Алекс в хостинге давно, поэтому он в целом понимал, что нужно клиенту и что нужно хостеру.

Биллинг мы и называем между собой «панелью управления»: в нем не только деньги и услуги, но и управление ими, поддержка клиентов и многое другое.

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

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

Можно легко добавить новую функцию или убрать старую. Панель спроектирована по модульному принципу: модули платёжных систем, модуль регистраторов доменов или, например, модуль SSL-сертификатов. Теперь баги правятся за часы, а не недели, а новые функции реализовываются по просьбе клиентов, а не по желанию ISPSystem. Задел на расширение заложен архитектурно, в том числе и в обратную сторону, «к железу».
image
Что мы получили: панель управления, над которой у нас полный контроль.

Шаг 3. Интерфейс

image
Интерфейс — наше командное детище.

Вышло так себе и мы решили всё сделать с нуля. Сначала мы посмотрели, что будет, если сделать надстройку над API ISPsystem, ничего кардинально не меняя в интерфейсе.

Расположение элементов обсуждали в Мегаплане и постепенно родится тот интерфейс, который пользователи видят в панели управления сейчас. Мы верили, что главное — сделать интерфейс логичным, с чистым и минималистичным дизайном и тогда получим красивую панель.

Первой появился дизайн странички биллинга, ведь мы уже делали плагины оплаты для ISPsystem.

Фронтенд

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

Связь фронтенда с бекендом

Пришлось попотеть и написать собственный обработчик, но теперь обновление информации на странице происходят почти моментально. Фронтенд связали с бекендом через пуши.

Мы сделали ее адаптивной, а быстрая прогрузка позволяет пользоваться ей даже с мобильников в последние минуты перед взлетом, не устанавливая отдельное приложение для работы с панелью. Что получилось: интерфейс панели стал проще.

Шаг 4. Тестирование и схема миграции

Когда все завелось и прошли первые тесты, встал вопрос миграции. Первым делом мы поставили биллинг и начали тестировать его работу с серверным агентом.

Потом написали простой скрипт, который переносит базу данных из старого биллинга в новый.

Пожалуй, тестовые миграции — самое сложное, с чем мы столкнулись в процессе разработки новой панели. Приходилось тестировать и перепроверять буквально все, так как данные сливали в одну новую базу из трёх старых: Billmanager, VMmanager и IPmanager менеджера.

Финальная миграция данных была очень тревожным моментом, но, слава Богу, выполнилась за несколько минут и без заметных проблем. После перепроверок, мы прикрыли старый биллинг. Основное время заняло тестирование того, что получилось. Были мелкие баги, которые мы чинили в течение недели.

Затем мы разослали письма клиентам с адресом новой панели и биллинга и сделали редирект.

В итоге: IT’S ALIVE!

Хэппиэнд

С первых часов работы своего софта мы почувствовали все прелести перехода. Код был полностью наш и с удобной архитектурой, а интерфейс — чистым и логичным.
image
Первый отзыв после запуска новой панели

Мы запустили процесс перехода в декабре, накануне Нового 2017 года, когда нагрузки было меньше всего, чтобы сделать переход проще для клиентов — почти никто не работает накануне праздников.

Главное, что мы получили при переходе на свою систему (кроме общей надежности и удобства) — возможность быстро добавлять функционал под ключевых клиентов — быть к ним лицом, а не задницей.

Что дальше?

Мы растём, растёт количество данных, клиентов, данных клиентов. На бекенд пришлось добавить Memcached-сервер и два менеджера очередей с разными задачами. На фронтенде есть кэширование и свои очереди.

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

В следующей статье расскажем, как запускали Hi-CPU тариф: про железо, ПО, какие задачи мы решали и что у нас получилось.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть