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

CloudPanel є панеллю, яку встановлюють, коли хочуть, щоб сайт запрацював швидко й ніщо не стояло на заваді. Вона безкоштовна, лягає на свіжий хмарний інстанс за хвилини, і те, що виходить, є простим стеком NGINX і PHP-FPM з Let's Encrypt, базою даних та інтеграцією Cloudflare. Без поштового сервера. Без шарів, яких ви не просили.

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

Довкола чого насправді побудований CloudPanel

Один сервер і сайти на ньому.

Ви створюєте сайт (PHP, статичний, Node.js, Python чи зворотний проксі), і CloudPanel записує vhost NGINX, пул PHP-FPM, Linux-користувача сайту й домашній каталог. Поряд ви створюєте базу даних. Ви вказуєте на нього сертифікат. Це цикл, і він хороший: розробник чи агенція, які тримають двадцять сайтів на одній машині, отримують чистий інтерфейс над рівно тими речами, яких вони торкаються.

Чого в нього немає, так це шару над цим: клієнта, який володіє набором сайтів, з планом, квотою та перемикачем. У CloudPanel є користувачі панелі з ролями (admin, менеджер сайту, користувач), і цих користувачів можна обмежити конкретними сайтами. Але це контроль доступу для людей, які входять, а не комерційний обліковий запис, якому можна виставити рахунок і який можна вимкнути.

Ця відмінність звучить академічно, доки перший клієнт не перестане платити.

Поверхнею керування є один інструмент командного рядка

У CloudPanel немає REST API. Усе, що може автоматизація, вона робить через clpctl, власний інструмент командного рядка панелі, який працює на хості від root. Він як слід скриптується (неінтерактивний, прапорці замість запитів) і охоплює те, що ви й очікували б:

Дві речі в цій таблиці варто помітити, перш ніж щось довкола неї планувати.

Перша полягає в тому, що ідентичністю сайту є його доменне імʼя. Не числовий id, не дескриптор облікового запису, а домен. Усе, що ви будуєте, ключується від нього, і воно має пережити клієнта, який хоче перенести домен між планами.

Друга серйозніша, і саме про неї наступний розділ: у цій таблиці немає дієслова для вимкнення сайту.

Три прогалини, що мають значення, коли ви продаєте

Призупинення немає

У clpctl є site:add:* і є site:delete. Між ними немає нічого. Немає ні site:suspend, ні site:disable, ні перемикача обслуговування, і в інтерфейсі панелі теж немає еквівалента.

Для хостингового бізнесу це не косметична прогалина, бо «рахунок прострочено на тридцять днів» є найпоширенішим, на що вам колись доведеться реагувати, а видалити сайт не є відповіддю. Видалення незворотне й забирає дані клієнта з собою; клієнт, який платить тридцять першого дня, очікує знайти свій вебсайт там, де він його лишив.

Тож усе, що продає хостинг на CloudPanel, має винайти призупинення. Звичайними кандидатами є зупинити пул PHP-FPM сайту або відредагувати vhost так, щоб сайт перестав відповідати. Обидва працюють, і другий кращий за перший: зупинений пул дає 502, що для вашого клієнта має вигляд, ніби ваш сервер зламаний, а не ніби його рахунок прострочено.

Добре відредагувати vhost вимагає коротшого переліку, ніж звучить. Обгорніть те, що вставляєте, у коментарі початку й кінця, щоб відновлення означало видалення рівно тих рядків і нічого іншого. Зробіть це в кожному публічному блоці server, бо у vhost зазвичай є один для порту 80 і один для 443, а сайт, призупинений по HTTP і здоровий по HTTPS, гірший за не призупинений узагалі, бо має вигляд, ніби спрацювало. Виконайте nginx -t перед перезавантаженням, бо це спільний вебсервер, і погана конфігурація кладе кожен сайт на ньому разом із вами. Зробіть ці три речі, і призупинення стає звичайною, миттєвою, цілком зворотною дією. Provibr робить саме це: позначений return 403;, кожен публічний блок, перевірено перед перезавантаженням.

Чого жодне рішення не виправляє, так це того, що панель не знає. У CloudPanel немає поняття призупиненого сайту, тож він перелічуватиме призупинений як звичайний, і будь-хто з доступом до панелі чи хоста може відкрити файл і прибрати рядок, зокрема клієнт, якого ви щойно призупинили. Ви можете зробити стан читабельним (позначка на відстані одного grep, і саме так Provibr помічає ручне редагування), але ви не можете зробити так, щоб ним володів CloudPanel.

Вирішіть, що означає «вимкнено», до першого клієнта, а не після першого неплатника.

Пакетів немає

У CloudPanel немає ні планів, ні квот, ні лімітів на рівні сайту. Ні квоти диска, ні обмеження трафіку, ні «цей сайт може мати три бази даних». Найближчим до пакета є шаблон vhost, який є конфігурацією NGINX. Корисно, але це не ліміт, і він не спинить нікого від використання 400 ГБ.

Це означає, що ваш каталог продуктів не може жити в панелі. Хоч би що відділяло ваш план за €5 від плану за €15, це має бути визначено, застосовано й виміряно десь над CloudPanel. Якщо воно ніде не застосовується, це не план. Це пропозиція.

Списку сайтів немає

Є user:list для входів панелі. Немає site:list. Самі сайти живуть у власній базі даних SQLite панелі на хості.

Це важить більше, ніж звучить, бо саме зі списку зроблено звіряння. Без нього ви не можете відповісти «чи те, за що я беру плату, ще існує?», не можете виявити сайт, який хтось видалив вручну, і не можете взагалі імпортувати наявний сервер у будь-що.

Вихід полягає в тому, щоб читати цю базу даних напряму: /home/clp/htdocs/app/data/db.sq3, один select за таблицею site, і у вас є кожен домен з його користувачем, шаблоном і версією PHP. Це те, що робить Provibr, і те, що зрештою робитиме будь-що серйозне. Просто знайте, що ви читаєте внутрішню схему, а не інтерфейс: вона може змінитися в релізі без того, щоб це було порушеною обіцянкою, тож вона потрапляє до переліку речей, які треба перевірити наново після оновлення панелі.

І одне дизайнерське обмеження під усім цим

clpctl працює від root на хості. Це не деталь реалізації, яку можна обійти: він записує конфігурацію NGINX, створює Linux-користувачів і керує системними службами, а тим потрібні привілеї, які їм потрібні.

Наслідок у тому, що автоматизація CloudPanel є питанням привілеїв раніше, ніж питанням інтеграції. Усе, що керує clpctl (ваш власний скрипт, cron-завдання, інструмент розгортання), працює від root на робочому вебсервері, де є чужі сайти. Хоч би що ви будували, будуйте це, знаючи, що задіяний обліковий доступ не є обмеженим API-токеном; це адміністративний доступ до машини. Тримайте його вузьким, тримайте його придатним для аудиту й тримайте його якнайдалі від усього, до чого може дістатися клієнт.

Що має існувати над панеллю

Заберіть специфічну для панелі деталь, і перелік той самий для будь-якої панелі керування, що і є корисним: він не змінюється, якщо ви пізніше переключите панелі:

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

Ніщо з цього не постачається з CloudPanel, і ніщо з цього не є тим, чим CloudPanel намагається бути.

Де Provibr пасує

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

Чого інтеграція не може, так це стерти прогалини вище, бо це властивості самої панелі. Призупинення є вигаданою частиною: позначене правило NGINX, яке повертає 403, вставлене в кожен публічний блок server і перевірене перед перезавантаженням; відновлення прибирає його, і сайт повертається байт у байт. Шаблон vhost фіксується щойно сайт існує, тож зміни тарифу немає: перехід на інший шаблон чи іншу версію PHP означає створити сайт заново, і Provibr так і каже, замість удавати, що щось змінилося. Немає також ні консолі, ні графіка споживання, бо CloudPanel не вимірює ні того, ні іншого.

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

Варто сказати зараз, а не пізніше: керування обліковими записами не означає керування панеллю. Встановлення CloudPanel, його оновлення, зміна налаштувань сервера, тюнінг NGINX і догляд за базами даних і сертифікатами, які створюють ваші клієнти: усе це лишається на вашому боці, у панелі, де йому й місце.

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