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

PufferPanel є легкою, самостійно розміщуваною панеллю ігрових серверів. Вона встановлюється за лічені хвилини, запускає багато ігор і приємно позбавлена складності Pterodactyl. Їй також бракує кількох речей, які бізнес хостингу вважає наявними за замовчуванням.

Ця сторінка розповідає про продаж на PufferPanel з відкритими очима: що автоматизується чисто, що ні, і де проходить чесна межа. Усе тут виміряно на PufferPanel 3.0.9.

PufferPanel не є форком Pterodactyl

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

• Автентифікацію дають облікові дані клієнта OAuth2, а не ключ API.
• Сервери збираються зі спільнотних шаблонів за назвою, а не з нумерованих egg.
• Тут немає ієрархії nest/egg, якою можна пройти.
• Ідентифікатори серверів обираєте ви самі, вісім символів, і ви задаєте їх під час створення, а не отримуєте готовий.

Якщо у вас є інтеграція з Pterodactyl і ви сподіваєтеся спрямувати її на PufferPanel зміною конфігурації, ви пишете нову інтеграцію.

Підключення: OAuth2 і секрет, який ви бачите раз

Створіть клієнт OAuth2 у панелі під своїм обліковим записом. Ви отримуєте ідентифікатор клієнта та секрет клієнта; обидва йдуть у вашу автоматизацію разом з URL панелі.

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

Те, що може робити клієнт, визначається обліковим записом, якому він належить. Тут немає вибору області дії. Якщо ви хочете, щоб він створював і видаляв сервери, він має належати обліковому запису адміністратора. Це важлива примітка з безпеки: клієнт OAuth2 на обліковому записі адміністратора є обліковими даними адміністратора, і поводитися з ним треба відповідно.

Порт не вгадати

Свіжий PufferPanel віддає звичайний HTTP на порту 8080. За зворотним проксі він буде на 443. Немає порту, який автоматизація могла б додати за вас без вгадування, тож дайте їй повний URL: http://panel.example.com:8080 або https://panel.example.com.

І будьте чесні з собою щодо транспорту. Панель на звичайному http працює, але секрет клієнта (облікові дані адміністратора) і все, що робить інтеграція, тоді мандрують вашою мережею незашифрованими. Якщо панель за TLS із самопідписаним сертифікатом, закріпіть його відбиток замість того, щоб вимикати перевірку. Відбиток поруч з адресою http відхиляється, бо закріпляти нема чого.

Шаблони, а не egg

PufferPanel будує сервер зі спільнотного шаблону (minecraft, factorio тощо), а не з нумерованого egg, який ви визначили самі. Назва шаблону і є його ідентичністю.

Два наслідки, що визначають, як ви продаєте:

Повне визначення шаблону треба надіслати вбудованим під час створення. PufferPanel не дає вам сказати «зроби мені сервер із шаблону X» за посиланням; усе визначення разом зі змінними йде в запит. Саме тому замовлення на PufferPanel реалістично лише кероване тарифом: вам потрібен каталог, що містить шаблон і його значення, бо форма замовлення з вільним текстом просила б клієнта надати документ.

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

Розміщення на вузлах і чому воно грубе

PufferPanel показує свої вузли. Він не показує їхньої памʼяті, диска чи CPU.

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

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

Життєвий цикл: що працює

Створення, запуск, зупинення, перезапуск, примусове завершення, перевстановлення та видалення: усе працює.

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

Три речі, яких у PufferPanel немає

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

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

PufferPanel не має власного призупинення. Ні стовпця, ні кінцевої точки; статус сервера знає лише running та installing.

Тож коли платформа «призупиняє» ігровий сервер PufferPanel за несплату, насправді відбувається ось що: контейнер зупиняється, а доступ до нього блокується в панелі платформи. Це справжня й корисна річ, але її не забезпечує сам PufferPanel, а це означає, що будь-хто з прямим доступом до встановлення PufferPanel може запустити сервер знову.

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

Немає живої консолі

PufferPanel має консоль, але вона на основі опитування: GET /console повертає логи в base64 з курсором epoch, а POST /console надсилає команду. Рукостискання WebSocket, що відповідає специфікації, на /console повертає 200 JSON замість 101. Пробували і з bearer-токеном, і з сесійним cookie.

Реле консолі Provibr є тунелем (воно несе Wings NDJSON WebSockets і VNC), і модель опитування в нього не вписується без побудови другої форми реле. Тому консоль для PufferPanel вимкнено, навмисно, замість того щоб постачати кнопку консолі, яка веде на вкладку, що відкочується до огляду.

Для ігрового сервера консоль, можна сказати, і є продуктом. Продавайте відповідно: ваші клієнти отримують її в самому PufferPanel, а не у вашому Огляді.

Майже жодних показників використання

Кінцева точка статистики PufferPanel повідомляє відсоток CPU та памʼять у байтах. Ні диска, ні мережі, ні часу роботи.

Стандартний набір графіків для ігрового сервера охоплює CPU, памʼять, диск і мережу. Два з цих чотирьох були б назавжди порожні. Графік, застряглий на нулі назавжди, гірший за відсутність графіка, тож графіки використання для PufferPanel теж вимкнено.

То коли PufferPanel є правильним вибором?

Це справді хороша панель, і межі вище не дискваліфікують її: вони просто конкретні. PufferPanel вам підходить, якщо:

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

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

Вам не обовʼязково обирати одну панель

Реалістичною відповіддю для більшості ігрових хостерів є обидві. PufferPanel для легкого рівня, Pelican чи Pterodactyl там, де важливі консоль і примус, і, ймовірно, вебхостинг або VPS поруч з усім цим.

Provibr запускає свої панелі керування, гіпервізори та ігрові панелі пліч-о-пліч в одному Огляді, з одним API та однією цифрою потужності на всі. Там, де провайдер чогось не вміє, платформа відмовляє з причиною, яка називає відсутню можливість, а не вдає протилежне.

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