Блог ·
Як продавати хостинг ігрових серверів на Pelican Panel
Pelican запускає ігрові сервери, але не продає їх. Як зробити з панелі Pelican продукт: два ключі API, egg як тарифи, розміщення на вузлах та імпорт.
Автор: Provibr
Pelican запускає ігрові сервери. Він не приймає замовлень, не надсилає рахунків і не вирішує, що сервер має зупинитися, бо ніхто за нього не заплатив. Саме про цей розрив (між панель працює і бізнес працює) ця сторінка.
Pelican є форком Pterodactyl і, на час написання цих рядків, ще в беті. Provibr підключається до нього як жива інтеграція та протестований на Pelican 1.0.0.
Що Pelican вам дає, а що ні
Pelican є панеллю керування. Три речі вона знає добре:
| Поняття Pelican | Що це |
|---|---|
| Egg | Рецепт, з якого збирається сервер: образ Docker, команда запуску та набір змінних, які egg визначає сам |
| Вузол | Машина, що несе сервер, з бюджетом памʼяті та CPU |
| Виділення | IP та порт, на які відповідає сервер |
Чого Pelican не має у своєму понятті: клієнта, рахунку, платежу, підписки, яка спливає. На сервері є прапорець suspended, але ніщо в панелі ніколи не виставляє його за вас.
Отже, бізнес хостингу ігрових серверів на Pelican складається з трьох частин, а не з однієї:
- Панель: Pelican, що запускає ваші сервери.
- Магазин: де клієнт обирає тариф і платить. WHMCS, Blesta, FOSSBilling, ваша власна каса.
- Міст: те, що перетворює оплачене замовлення на працюючий сервер, а неоплачене на зупинений.
Більшість людей будують цю третю частину вручну й шкодують про це. Саме там живуть крайні випадки: повний вузол, порожня змінна egg, клієнт, який скасовує підписку, поки інсталятор ще працює.
Підключення Pelican: два ключі й одна пастка
Pelican має два API з двома різними ключами, і мосту провізіювання потрібні обидва. Вони походять із двох різних екранів, і обидва мають належати обліковому запису з правами адміністратора.
| Ключ | Де | Префікс | Що він несе |
|---|---|---|---|
| Ключ застосунку | Admin → API Keys | papp_ | Створення, призупинення, перевстановлення, видалення |
| Клієнтський ключ | Profile → API Keys | pacc_ | Команди живлення, показники використання наживо, консоль |
Надайте ключу застосунку права на читання та запис для Server, Node, Allocation, User та Egg. Дайте менше, і створення зірветься на півдорозі, що гірше, ніж зірватися одразу.
Дві речі щодо цього коштують людям половини дня:
Скопіюйте клієнтський ключ тієї ж миті, щойно він зʼявиться. Pelican показує його лише раз. Потім у списку лишається тільки короткий ідентифікатор, і цей ідентифікатор приймається як ключ, тож, вставивши його, ви отримаєте звичайну помилку автентифікації, а не підказку, що ви скопіювали не те. Ключ застосунку можна повністю прочитати зі списку; клієнтський ключ прочитати не можна.
Стежте, який ключ іде в яке поле. Pelican приймає клієнтський ключ і на API керування, тож перестановка їх місцями не дає видимої помилки. Префікс є єдиним, що їх розрізняє. Provibr перевіряє цей префікс з обох боків саме з цієї причини, інакше ви отримаєте інтеграцію, яка ніби автентифікується, а потім тиждень поводиться дивно.
Короткого шляху через командний рядок тут немає: Pelican не постачає жодної команди artisan для ключів API, тож обидва створюються через вебінтерфейс.
Якщо панель віддає самопідписаний сертифікат, закріпіть його відбиток замість того, щоб вимикати перевірку. Панель, доступна через звичайний http, працює, але обидва ключі тоді мандрують вашою мережею незашифрованими, а відбиток поруч з адресою http відхиляється, бо немає сертифіката, який можна закріпити.
Від egg до чогось, що можна продати
Egg не є продуктом. У нього немає ні ціни, ні назви, яку впізнає клієнт, ні прикріплених лімітів. Тариф є шаром, що перетворює одне на інше: він містить egg, образ Docker, команду запуску та ліміти ресурсів, які отримує сервер.
Дві деталі, які збивають людей з пантелику, коли вони задають ліміти:
- Памʼять, диск і CPU приймають 0 для необмеженого.
- Ліміт CPU рахується у відсотках від одного ядра.
100означає одне повне ядро,200означає два. Тариф, який продається як «2 vCPU», дорівнює200, а не2. - Вага введення-виведення йде від 0 до 1000, і 500 є звичайним значенням.
Правило обовʼязкових змінних
Egg визначає власні змінні й позначає деякі з них обовʼязковими. Ось рішення, яке варто перейняти, користуєтесь ви Provibr чи ні:
Відхиляйте замовлення, коли обовʼязкова змінна порожня, навіть якщо сам Pelican його б прийняв.
Pelican однаково створює сервер. Далі контейнер падає при першому запуску, клієнт бачить мертвий сервер, а ваша черга підтримки отримує звернення з текстом «воно не працює». Поле, яке червоніє під час оформлення, є набагато кращою відповіддю, ніж сервер, який існує й не працює.
Provibr читає список egg з вашої панелі, тож форма замовлення пропонує ті egg, які у вас справді є, замість того щоб просити когось увести номер.
Куди потрапляє сервер
Pelican повідомляє, скільки памʼяті та CPU має кожен вузол і скільки з цього вже роздано. Розумний міст використовує обидві цифри: новий сервер іде на вузол, де є місце для нього, і відхиляється з причиною, коли місця немає на жодному вузлі.
⚠️ Цифри, які повідомляє панель, є бухгалтерією, а не вимірюванням. Вони підсумовують ліміти серверів на вузлі, зокрема й тих, що ще встановлюються. Тому вузол може виглядати повним, тоді як насправді працює дуже мало.
Це має комерційне значення. Якщо ви перепродаєте (а більшість ігрових хостерів так і роблять, бо сервер Minecraft, якому виділено 4 ГБ, рідко використовує 4 ГБ), то цифри Pelican спинять вас задовго до вашого заліза. Плануйте бюджети вузлів довкола того, що маєте намір продавати, а не довкола того, що машина фізично здатна витримати.
Чого клієнт торкається насправді
Для ігрового сервера консоль і є продуктом. Команди, приєднання гравців і той рядок журналу, що пояснює збій: усе живе там. Pelican має справжню консоль, і Provibr передає її клієнту тим самим вихідним зʼєднанням, що й усе інше: без окремого порту, без другого входу, без другого пароля для скидання.
Файли, резервні копії, бази даних і розклади лишаються в Pelican. Це навмисно: це функції панелі, і відтворення їх у другому інтерфейсі дає вашим клієнтам два місця, де могла б жити правда.
Перенесення наявної панелі
Якщо ви вже запускаєте Pelican із платними клієнтами, вам не треба нічого перебудовувати. Сервери, створені поза мостом, лишаються недоторканими; ви імпортуєте їх, щоб вони зʼявилися у вашому Огляді й враховувалися у вашій потужності.
Імпорт не зачіпає сервер. Він лише починає його рахувати. Доки ви не імпортуєте його, ним ні керують, ні виставляють рахунок, а отже, ви можете переносити панель партіями, у власному темпі, а не під час вікна обслуговування.
Що сюди не входить
Чітко визначте межу, перш ніж продавати навпроти неї:
- Адміністрування панелі лишається в Pelican. Додавання вузлів, редагування egg, керування користувачами панелі: ніщо з цього не переїжджає.
- Файли, резервні копії, бази даних і розклади теж лишаються в Pelican.
- Pelican сам ще в беті, і його API змінюється від версії до версії. Панель не дає способу запитати, яку версію вона виконує, тож оновлення, яке змінює відповідь, проявляється як помилка, а не як попередження заздалегідь. Читайте примітки до випуску, перш ніж оновлювати панель, з якою розмовляє ваша автоматизація. Це не обмеження Provibr, а властивість панелі, і будь-який міст, який ви збудуєте, її матиме.
Вам не обовʼязково обирати одну панель
Більшість ігрових хостерів зрештою запускають більш ніж одну панель: Pelican для нового парку, Pterodactyl для того, що вже було, щось інше для клієнта, який наполіг. І більшість з них поруч продають ще й вебхостинг або VPS.
Provibr запускає свої панелі керування, гіпервізори та ігрові панелі пліч-о-пліч в одному Огляді. Одна цифра потужності, один набір ключів API, одне місце, де записується життя сервера, незалежно від того, на якій панелі він працює.
Наступна сторінка охоплює другу половину: що стається з сервером Pelican, коли рахунок лишається неоплаченим.
