Автоматизація білінгу для Pelican Panel

У Pelican на кожному сервері є прапорець suspended. Ніщо в Pelican його ніколи не встановлює. Це єдине речення і є вся причина, чому існує ця сторінка: панель здатна зупинити сервер клієнта, але не має жодного уявлення, чи клієнт заплатив.

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

Два шари білінгу, і це не одне й те саме

Перш за все, розділіть їх. Люди постійно їх плутають, а потім сперечаються не про ту проблему.

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

Саме це розділення робить автоматизацію керованою. Ваша система білінгу володіє рішенням; шар провізіювання володіє виконанням.

Життєвий цикл, зіставлений

Ось зіставлення, яке потрібне кожній автоматизації ігрового хостингу, хоч би якими інструментами ви користувалися:

Pelican тут почувається комфортно, і це варто сказати прямо, бо не кожна ігрова панель така. У Pelican є справжній примітив призупинення. Призупинений сервер призупинено в панелі: той, хто має прямий доступ до Pelican, не може просто запустити його знову. Коли застосування має значення (а для нагадувань має), саме це відрізняє політику від побажання.

(Для контрасту: PufferPanel не має власного призупинення, тож призупинення там є концепцією платформи, яку панель не застосовує.)

Правило, що формує все: ніщо не миттєве

Це та частина, яку люди роблять неправильно, коли самі підключають API.

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

POST /v1/servers/{serverId}/actions/suspend
Authorization: Bearer pvk_...
Idempotency-Key: dunning-inv-10482

{
  "command": {
    "id": "cmd_...",
    "kind": "game.suspend",
    "status": "pending"
  }
}

Ви отримуєте 202 Accepted, а не 200. Далі ви читаєте цю команду, доки її статус не стане остаточним: done, failed, timed_out чи cancelled. Команда, що зазнала невдачі, несе код помилки самого агента, з його аргументами.

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

Проєктуйте свої гачки білінгу довкола цього. Гачок, який вважає «API повернув відповідь» тим самим, що «роботу виконано», повідомить про успіх призупинення, яке ніколи не сталося, рівно того дня, коли це мало значення.

Як безпечно повторити запит

Усе, що щось створює, приймає заголовок Idempotency-Key вашого власного виготовлення. Повторіть той самий запит із тим самим значенням, і ви отримаєте назад перший результат, а не другий сервер, другу команду чи друге списання.

Для нагадувань це не дрібна зручність. Пʼятнадцятихвилинний cron, повторений вебхук, адміністратор, який клікає двічі: усі три нормальні й усі три мають бути нешкідливими. Привʼязуйте запит до чогось стабільного з вашого боку: ID рахунку, ID послуги, стадія нагадування. Повторне використання того значення для іншого запиту відхиляється навмисно: ключ, що означає дві речі, не означає нічого.

Дієслова та коли вони дозволені

Ігровий сервер приймає шість дій через API:

start · stop · restart · kill · suspend · resume

Їх охороняє поточний стан сервера, і він суворіший, ніж може здатися:

Рядок suspend є найцікавішим, і він навмисний: ви можете призупинити сервер, який уже зупинено. Якби призупинення працювало лише на запущених серверах, клієнт міг би зупинити власний сервер, перестати платити й бути невразливим. Панель відмовила б у призупиненні, бо нічого не було запущено. Застосування, якого можна уникнути натисканням «зупинити», застосуванням не є.

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

Як робити це з панелі білінгу замість коду

Якщо ви вже користуєтеся WHMCS, вам не потрібно писати нічого з наведеного вище. Provibr постачає модуль провізіювання для WHMCS у вигляді звичайного zip, який ви встановлюєте самі: один продукт WHMCS указує на один тариф Provibr, а звичайний потік замовлень WHMCS робить створення, призупинення, відновлення й припинення.

Два дизайнерські рішення в цьому модулі варто перейняти, навіть якщо ви пишете власний міст:

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

Сервер, якого вже немає, означає успішне припинення. 404 на видаленні означає чотири речі одночасно (невідомий ID, інший обліковий запис, не призначено цьому учаснику або вже видалено), і для гачка припинення правильна дія однакова в усіх чотирьох: прибирати вже нічого. Вважати це помилкою означає лишити послугу застряглою в «припиняється» назавжди.

Що навмисно не автоматизовано

Чесні межі, бо це питання, які надходять після того, як ви вже щось продали:

• Немає білінгу за використанням. Метрики на рівні сервера збираються й показуються в панелі, але поки не виставлені через API. Без кінцевої точки немає вимірюваного білінгу. Якщо ваш продукт звучить як «платіть за оперативну памʼять, яку ви використали», сьогодні цього немає.
• Немає зміни плану одним викликом. Заміна тарифу теж не є одним викликом API на рівні Pelican: це перевстановлення або зміна ресурсів, з різними наслідками для даних клієнта.
• Немає скидання пароля через API. Облікові дані подорожують транзитно й ніколи не зберігаються, тож пересилати нема чого.
• Немає єдиного входу з вашої панелі білінгу в панель Provibr.
• Немає циклу звіряння інвентаря. Це відмова, а не прогалина. Синхронізація _ListAccounts у WHMCS припиняє будь-яку послугу, якої немає у відповіді, а «немає» має невинні причини: вужча область дії API, учасник, обмежений частиною інвентаря, обмеження частоти, коротка сторінка, за курсором якої не пішли. Кожна з них видалила б машини клієнтів. Натомість клієнтський розділ читає живий статус при кожному перегляді сторінки, що не є синхронізацією й не вдає її.

Підрахунок потужності та як він зустрічається з нагадуваннями

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

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

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

Запуск Pelican поруч з усім іншим

Ігровий хост, що росте, рідко лишається на одній панелі. Provibr охоплює свої панелі керування, гіпервізори та ігрові панелі в одному Огляді, з одним API та одним числом потужності для всіх них.

POST /v1/servers/{id}/actions/suspend робить те саме, чи то під ним сервер Pelican, сервер Pterodactyl, чи хостинговий обліковий запис DirectAdmin. Відмінності живуть у провайдері, а не у вашому інтеграційному коді.