Блог ·
Автоматизація білінгу WISP
WISP застосовує призупинення й не має уявлення, чи хтось заплатив. Зіставлення життєвого циклу, пастка двох ключів і форми, що ламають першу інтеграцію.
Автор: Provibr
WISP призупинить для вас сервер, і це призупинення триматиметься: клієнт, який досі має облікові дані панелі, не може натиснути «запустити». Чого WISP не має і ніколи не стверджує, що має, так це будь-якого уявлення про те, чи цей клієнт вам заплатив.
Ця сторінка про шар, що лежить посередині. Вона також охоплює те єдине, що відрізняє WISP від кожної іншої ігрової панелі тут і що не має жодного стосунку до його API: панель не ваша.
Панель розміщена в них, вузол ваш
WISP продається як розміщена послуга. Панель запускає wisp.gg; вузол, який несе ваші ігрові сервери, працює на вашому власному залізі. Агент усередині вашої мережі говорить назовні з панеллю через її API і з демоном вашого вузла заради консолі, тож нічого не треба відкривати в інтернет.
Для інтеграції білінгу цей поділ має один справжній наслідок: вам нічого оновлювати й нічого закріплювати. WISP може змінити свій API без випуску, який контролюєте ви. Provibr перевірено проти 3.7.5, і він читає запущену версію з самої панелі, тож розходження виринає в перевірці зʼєднання, а не в невдалому замовленні о другій ночі.
Одна повʼязана деталь, яку варто знати, перш ніж винуватити власний код. Парадні двері панелі стоять за викликом Cloudflare; кожен шлях /api/… проходить наскрізь. Це виміряно трьома різними user agents, і всі три відповіли 200. Це налаштування на боці wisp.gg, не на вашому й не на нашому, тож якщо WISP колись поставить той самий виклик на API, кожна інтеграція з WISP спиниться одночасно, і локально виправляти буде нічого. Збій має впізнаваний вигляд (403, заголовок Cf-Mitigated: challenge і HTML замість JSON) і заслуговує на власне повідомлення, щоб панель казала вона нас не пускає, а не неправильний ключ.
Життєвий цикл, зіставлений
| Подія білінгу | Що має статися | Ефект на боці WISP |
|---|---|---|
| Замовлення оплачено | Створити сервер з egg із лімітами тарифу | Сервер створено, виділення призначено, запускається інсталятор egg |
| Рахунок прострочено | Призупинити | suspended встановлено, і панель тримає його там |
| Платіж отримано | Відновити | suspended знято |
| Скасування | Видалити | Сервер видалено, виділення звільнено |
| Перевстановлення | Знову запустити інсталяційний скрипт egg | container.installed перемикається на false, потім на true |
Пʼять дій, і всі пʼять відповідають порожнім 204. У тілі буквально нічого немає, тож домашнє правило діє без винятків: жодна мутація не довіряє власній відповіді. Прочитайте сервер назад після цього.
Призупинення справжнє, і воно ідемпотентне
Це поєднання серед ігрових панелей трапляється рідше, ніж мало б, і саме воно є цілою причиною, чому прогін нагадувань на WISP нудний у хорошому сенсі.
Друге призупинення вже призупиненого сервера знову відповідає 204. Нічого не треба обробляти окремо, нічого не треба вважати «уже в цьому стані», немає помилки, яку треба ковтати. Порівняйте це з панелями керування, де призупинити двічі означає помилку автентифікації, і стане видно, скільки інтеграції білінгу зазвичай іде на вибачення за панель.
Видалення працює й на призупиненому сервері, а це важить для скасування, яке приходить через місяць після призупинення. Друге видалення відповідає 404, і це правильний результат для гачка припинення: прибирати вже нічого.
Правила станів на боці Provibr суворіші за панельні, і це навмисно:
| Дія | Дозволено зі стану |
|---|---|
| start | stopped, error, unknown |
| stop / restart / kill | running, error, unknown |
| suspend | running, stopped, installing, error, unknown |
| resume | suspended |
| reinstall | running, stopped, error |
Прочитайте рядок suspend двічі. Ви можете призупинити сервер, який уже зупинено, і той, що ще встановлюється. Якби призупинення працювало лише на запущених серверах, клієнт міг би зупинити власний сервер, перестати платити й бути невразливим. Застосування, якого можна уникнути натисканням «зупинити», застосуванням не є, а скасування, яке припадає на середину встановлення, не повинно чекати, доки встановлення завершиться.
Два ключі, без префікса, і помилка, що з цього випливає
WISP зберігає властивий Pterodactyl поділ на дві поверхні API, і жоден окремий ключ не покриває обидві. Ключ застосунку створює, призупиняє, перевстановлює й вилучає; клієнтський ключ відповідає за живлення, живу статистику та консоль. Обидва створюються на обліковому записі адміністратора.
Ось пастка. Ключі WISP не несуть префікса, на відміну від ptla_ у Pterodactyl чи papp_ у Pelican: це 48 символів без упізнаваної голови, тож ніщо не скаже вам, що ви вставили їх навпаки. Ні ми, ні панель, бо WISP відповідає на неправильний ключ 403 і порожнім повідомленням. 403 зазвичай означає цьому ключу це не дозволено, тож клієнт, який поміняв два ключі місцями, іде в панель і починає ставити галочки на дозволах, які ніколи не були проблемою. Якщо перевірка зʼєднання не проходить, поміняйте два ключі місцями, перш ніж змінювати будь-що інше.
Друга половина цих облікових даних заслуговує на речення у вашому власному довіднику: ключ застосунку це не лише керування серверами. Той самий перелік вузлів, який читає інтеграція, несе також ліцензійний ключ вашого вузла й токен демона. Ставтеся до нього як до облікових даних усієї панелі й відкликайте його у WISP, якщо колись відʼєднаєте інтеграцію.
Ніщо не миттєве, і 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. Читання так не працює ніколи, бо інвентар чи рахунок надходять із бази даних, а не з вашого хоста.
Усе, що щось створює, приймає Idempotency-Key вашого власного виготовлення. Привʼяжіть його до чогось стабільного з вашого боку, наприклад до ID рахунку плюс стадії нагадування, і пʼятнадцятихвилинний cron, повторений вебхук та адміністратор, який клікає двічі, усі стають нешкідливими.
Дві форми, що ламали цю інтеграцію ще до вашої зустрічі з нею
Обидві варто прочитати, навіть якщо ви ніколи не торкнетеся WISP, бо обидві є тим видом збою, що звітує про успіх.
Кожна ідентичність є рядком із префіксом, а не числом. Сервер WISP це server_01m0n8m94afcj2kk5mzt9z379q; вузли, egg і виділення мають такий самий вигляд. На платформі стояла перевірка, що зовнішній ID ігрового сервера складається з літер і цифр, і це правда для кожної іншої ігрової панелі й неправда тут. Результатом було не повідомлення про помилку: клієнтів WISP понад лімітом повідомляли воркеру застосування, а тоді пропускали, кожного разу, назавжди. Їх позначали й ніколи не призупиняли. Тепер одна спільна перевірка ідентичності покриває обидві форми.
Вага диска нуль відхиляється. WISP вимагає limits.io і наполягає на значенні між 10 і 1000. Поле тарифу на платформі за замовчуванням дорівнює нулю, тож кожне замовлення WISP закінчувалося б 422 про поле, про яке більшість людей ніколи не чула. Тепер там дві огорожі: форма тарифу відхиляє нуль і каже чому, а агент піднімає нуль до типової ваги перед надсиланням. Дві огорожі на одну помилку це навмисно, бо одна з них на тому боці, який ви бачите.
Чого ви не бачите і чого не варто вдавати
Це чесна частина, і вона коротка.
- У сервера WISP немає поля статусу. У Pterodactyl воно є, з
installingтаinstall_failedусередині. У WISP єsuspendedіcontainer.installed, обидва булеві. Тому невдале встановлення має точнісінько такий самий вигляд, як запущене:installedлишається false в обох випадках. Будується і зламане на цій поверхні є однією картинкою, і продукт, який стверджує інше, вгадує. - Вузол не повідомляє про власну зайнятість. Поле, яким для цього користуються інші панелі, відсутнє, зокрема й тоді, коли просити його явно. Натомість зайнятість підсумовується із серверів, що працює й коштує на один виклик більше.
- У живій статистиці немає часу роботи. Контейнер, який перезапустився між двома опитуваннями, неможливо розпізнати напевно. Проти цього стоїть те, що WISP не кешує ту статистику двадцять секунд, як це робить Pterodactyl, тож графіки не вигадують провалу, якого не було. У підсумку краще, з одним гострим краєм.
Потужність і як вона зустрічається з нагадуваннями
Provibr виставляє вам рахунок за потужність, а не за ваших клієнтів. Те, що ви берете за ігровий сервер, лишається цілком усередині вашої власної системи білінгу; ми ніколи не бачимо рахунку клієнта й ніколи не спілкуємося з вашими клієнтами.
Правило, що ловить усіх у перший місяць: кожен сервер рахується, працює він чи ні. Призупинений не рахується, і видалений теж. Зупинка машини не звільняє нічого.
Це доволі акуратно збігається з нагадуваннями. Призупиніть клієнта за несплату, і тієї ж миті він перестане враховуватися у вашу потужність; відновіть його, коли він заплатить, і він рахується знову. Ви не платите за потужність платформи для того, хто не платить вам.
Що навмисно не автоматизовано
Provibr керує серверами, а не панеллю. Він не встановлює WISP, не торкається демона вашого вузла поза консоллю й не керує резервними копіями, правилами фаєрвола чи призначенням IP у цього провайдера: ці можливості вимкнено в реєстрі, а не наполовину реалізовано. Вимірюваного білінгу за використання WISP немає, бо статистика на кожен сервер показується в панелі й не виставлена через API, а проти кінцевої точки, якої не існує, рахунка не виставиш.
Якщо ви ще обираєте, порівнянням, яке варто прочитати першим, є Вибір ігрової панелі за її API, що міряє шість панелей рівно за одним питанням: чи призупинення щось робить. Саме зʼєднання, два ключі й поле відбитка описані на сторінці інтеграції WISP.
Поширені запитання
Чи має WISP власний білінг?
Ні. WISP розміщує ігрові сервери й керує ними; у нього немає замовлень, немає рахунків, немає нагадувань і немає жодного уявлення, який клієнт стоїть за яким сервером. Комерційний шар ви додаєте самі.
Чи справді призупинення сервера у WISP зупиняє клієнта?
Так. У WISP є справжній примітив призупинення в його API застосунку, і клієнт з обліковими даними панелі не може запустити призупинений сервер. Це правда не про кожну ігрову панель: у PufferPanel призупинення немає взагалі, а в GameAP є прапорець, який, як виміряно, не змінює нічого.
Чи безпечно прогону нагадувань призупиняти той самий сервер двічі?
Так. Друге призупинення відповідає 204 точнісінько як перше. Немає помилки «уже призупинено», яку треба ловити, і немає стану, який треба спершу перевіряти, і саме це робить нічне завдання нагадувань на WISP простим.
Чому два ключі API WISP так часто плутають?
Бо вони не несуть префікса. Pterodactyl і Pelican підписують свої ключі; у WISP це 48 символів без упізнаваної голови. Переставлена пара дає 403 з порожнім повідомленням, що читається як проблема з дозволами, а не як помилка вставляння, якою вона є.
Чи можу я виставляти клієнтам WISP рахунок за те, що вони використали?
Не через API. Використання на кожен сервер видно в панелі, але воно не виставлене як кінцева точка, тож вимірюваному білінгу нема чого читати. Сьогодні працює ціноутворення за потужністю на кожен сервер.