Як продавати вебхостинг із ISPConfig

Більшість панелей керування керує одним сервером. ISPConfig керує парком: одна інсталяція стоїть перед окремими вебмашинами, поштовими, DNS- та базами даних, із сайтами й поштовими скриньками, розподіленими між ними, і одним інтерфейсом над усім цим. Він робить це дуже давно, він з відкритим кодом, і він нічого не коштує.

Це також панель у цій категорії з найповнішим уявленням про те, що таке клієнт. У ISPConfig клієнти, реселери, ліміти й шаблони є обʼєктами першого класу, що більше, ніж може сказати більшість його конкурентів. Чого в нього немає (і саме тому така сторінка існує), так це будь-якого поняття клієнта, який вам платить.

Що ISPConfig уже вам дає

Три речі, і вони незвично хороші.

Клієнти, а не просто облікові записи. Клієнт ISPConfig є людиною чи компанією, яка володіє чимось: вебсайтами, поштовими скриньками, зонами DNS, базами даних. Це та форма, яку хостинговий продукт насправді має, і вам не треба її винаходити.

Ліміти й шаблони, щоб їх застосовувати. Кожен клієнт несе ліміти: скільки вебдоменів, скільки поштових скриньок, скільки баз даних, скільки місця. Шаблони клієнтів дають змогу визначити набір лімітів один раз і застосувати його до багатьох клієнтів, що і є каталогом продуктів під іншою назвою. Ліміт -1 означає безлімітно, і це варто знати, перш ніж читати шаблон і зробити висновок, що щось зламане.

Реселери. ISPConfig розуміє, що клієнт може сам мати клієнтів. Якщо ви продаєте агенціям, які продають власним клієнтам, ця ієрархія існує в панелі, а не в таблиці, яку ви ведете поряд із нею.

Разом ці три покривають ті частини, що більшість панелей змушує вас будувати самостійно.

Незвична частина: одна панель, кілька машин

Саме це по-справжньому відрізняє ISPConfig від DirectAdmin, cPanel, CloudPanel та решти.

Одна інсталяція ISPConfig може керувати виділеними вебсерверами, окремим поштовим сервером, окремими DNS-серверами та окремим сервером баз даних, налаштованими як багатосерверна конфігурація, з дзеркалюванням для тих частин, яким потрібна надлишковість. Коли ви додаєте вебсайт, ISPConfig записує його на ту машину, яка має його нести.

Для хостера з цього випливають два наслідки. Хороший: зростання означає додати машину за панеллю, а не піднімати другу панель і розділяти клієнтів між двома системами, які не знають одна про одну. Той, що варто спланувати: ваше уявлення про «сервер» і уявлення ISPConfig про «сервер» перестають бути тим самим. Обліковий запис більше не привʼязаний до машини, на яку ви можете вказати (і це нормально), але будь-який інвентар, який ви ведете над ISPConfig, має спокійно ставитися до клієнта, чий вебсайт на одній машині, а поштові скриньки на іншій.

Віддалений API і дві речі, які варто про нього знати

Автоматизація ISPConfig іде через його віддалений API, доступний у варіантах SOAP і JSON. Дві властивості формують усе, що ви на ньому будуєте.

Він на основі сесій, а не токенів. Ви викликаєте login з іменем і паролем віддаленого користувача, отримуєте назад session_id і передаєте його з кожним наступним викликом. Сесія дійсна обмежений час. Це інший життєвий цикл, ніж bearer-токени, які роздає більшість сучасних панелей: ваш клієнт має тримати сесію, помічати, коли вона закінчилася, і входити знову, і не повинен робити це наосліп, бо цикл входу з неправильними обліковими даними і є тим, як ви опиняєтеся заблокованим від чогось.

Дозволи задано по функціях, і вони перевіряються. Ви створюєте віддаленого користувача в панелі (System, потім Add Remote User) і позначаєте категорії викликів, які він може робити. ISPConfig перевіряє цей дозвіл на кожному виклику, який отримує.

Ця друга властивість по-справжньому цінна, і її варто використати як слід. Вона означає, що обліковий доступ у вашій автоматизації не мусить уміти все, що вміє ISPConfig. Дайте йому функції, які ваше провізіювання справді викликає, і нічого більше, і тоді помилка у вашому власному коді не зможе дістатися частин панелі, яких ви ніколи не збиралися торкатися. Дуже мало панелей цього класу взагалі дають вам провести цю межу.

Самі функції читаються так, як ви й сподівалися б. Клієнти створюються через client_add. Вебсайтами опікуються sites_web_domain_add, sites_web_domain_update, sites_web_domain_get і sites_web_domain_delete. І критично для будь-чого комерційного, є sites_web_domain_set_status: справжній, підтримуваний спосіб вмикати й вимикати вебсайт, тобто те єдине дієслово, довкола якого обертається хостинговий білінг і якого кілька конкурентних панелей просто не мають.

Чого він досі не робить

Усе вищезгадане є інфраструктурою. Ніщо з цього не комерція.

ISPConfig не прийме замовлення, не прийме платіж, не випустить рахунок, не наздожене його й не вирішить тридцять першого дня, що цей клієнт перестав платити і його треба вимкнути. У нього є важіль (set_status), але нічого, що вирішує, коли за нього потягнути. Немає каталогу з цінами, немає форми реєстрації, немає розкладу нагадувань і немає перегляду, який каже вам, скільки ваш парк вам коштує проти того, скільки він заробляє.

Це не критика. Панель керування, яка ще й намагалася б бути системою білінгу, була б гіршою в обох. Але це означає, що цікава робота в продажу хостингу на ISPConfig цілком у шарі над ним, і цей шар той самий, який вам знадобився б для будь-якої іншої панелі:

• Форма замовлення й каталог із планами, що лягають на шаблони клієнтів.
• Платіж, що запускає провізіювання за секунди.
• Шлях нагадувань (прострочено, попереджено, призупинено, відновлено), підключений до set_status на потрібному кроці.
• Потужність, яку ви бачите, щоб ви знали, скільки облікових записів несете на всіх тих машинах і скільки вони коштують.
• Аудиторський слід, щоб «хто змінив той ліміт» мало відповідь.
• Модель прав для власного персоналу, щоб підтримка могла діяти, не маючи змоги видалити клієнта.

Де Provibr пасує

Підтримка ISPConfig діє. Агент усередині вашої власної мережі говорить із віддаленим API панелі, тож ніщо на вашій панелі не мусить дивитися в інтернет і жодного порту відкривати не треба. Створення клієнта з сайтом і тарифом, призупинення, поновлення, зміна тарифу та вилучення працюють, облікові записи, які вже були, можна імпортувати, а диск і трафік зʼявляються у графіках. Навколо цього стоїть шар, описаний вище: тарифи й потужність із ціною за одиницю, модель прав для вашої команди, журнал активності, а також REST API та модуль WHMCS, щоб платформа, якою ви вже виставляєте рахунки, могла ним керувати.

Обліковий запис у сховищі агента може бути значно вужчим за адміністратора, бо ISPConfig роздає віддалені права функція за функцією: віддаленого користувача можна звузити рівно до тих викликів, які робить Provibr, і ні до чого понад те. На яку з ваших машин ISPConfig покладе сайт, залишається рішенням ISPConfig, дії над обліковим записом однакові в будь-якому разі, а кожен запис рахується як один вебсервер у вашій потужності, хоч би яка машина зрештою його виконувала.

Чого інтеграція не робить, так це не чіпає облікові записи, створені не через неї: вони залишаються недоторканими, доки ви їх не імпортуєте, і ви самі обираєте які. Одна практична заувага щодо самого зʼєднання: свіжа інсталяція ISPConfig самопідписана, тож її відбиток TLS варто закріпити, коли ви додаєте інтеграцію.

Чого воно не робитиме

Керування обліковими записами не означає керування панеллю. Встановлення ISPConfig, його оновлення, додавання серверів за ним, налаштування маршрутизації пошти й догляд за DNS: усе це лишається у вас, у ISPConfig, де йому й місце. Клієнт, який редагує власну поштову скриньку, робить це без того, щоб щось над панеллю про це знало чи цим переймалося.

Вам не обовʼязково стандартизуватися на одній панелі, щоб мати один огляд. Provibr сьогодні тримає свої панелі керування, гіпервізори та ігрові панелі пліч-о-пліч, під одним інвентарем, однією моделлю прав і одним журналом активності. Багатосерверна відкрита панель для клієнтів, які хочуть пошту й DNS у комплекті, щось інше для тих, хто просить cPanel на імʼя, і одне місце, де ви можете бачити обидва.