Săriți la conținut

Blog ·

Automatizarea facturării WISP

WISP impune o suspendare și nu știe dacă cineva a plătit. Corespondența ciclului de viață, capcana celor două chei și formele care strică o primă integrare.

De Provibr

WISP va suspenda un server pentru dumneavoastră și va face ca acea suspendare să țină: un client care încă are datele de autentificare pentru panou nu poate apăsa pornirea. Ceea ce WISP nu are, și nici nu pretinde vreodată că are, este vreo idee dacă acel client v-a plătit.

Această pagină este despre nivelul dintre cele două. Ea acoperă și singurul lucru care deosebește WISP de orice alt panou de joc de aici, lucru care nu are nimic de-a face cu API-ul său: panoul nu este al dumneavoastră.

Panoul este găzduit, nodul este al dumneavoastră

WISP este vândut ca serviciu găzduit. wisp.gg rulează panoul; nodul care poartă serverele dumneavoastră de jocuri rulează pe propriul dumneavoastră hardware. Un agent din interiorul rețelei dumneavoastră vorbește spre exterior cu panoul prin API-ul său și cu demonul nodului dumneavoastră pentru consolă, așa că nimic nu trebuie deschis către internet.

Pentru o integrare de facturare, acea separare are o singură consecință reală: nu aveți nimic de actualizat și nimic de fixat pe o versiune. WISP își poate schimba API-ul fără o versiune pe care să o controlați. Provibr este testat pe v3.7.5 și citește versiunea în funcțiune chiar din panou, așa că o abatere apare în testul de conexiune și nu într-o comandă eșuată la ora două dimineața.

Un detaliu conex merită cunoscut înainte de a vă acuza propriul cod. Ușa de la intrare a panoului se află în spatele unei provocări Cloudflare; orice cale /api/… trece direct. Acest lucru a fost măsurat cu trei agenți de utilizator diferiți și toți trei au răspuns 200. Este o setare la wisp.gg, nu la dumneavoastră și nici la noi, așa că, dacă WISP va pune vreodată aceeași provocare pe API, fiecare integrare WISP se oprește deodată și nu este nimic de reparat local. Eșecul are o formă recognoscibilă (403, un antet Cf-Mitigated: challenge și HTML în loc de JSON) și merită propriul său mesaj, astfel încât panoul să spună nu ne lasă să intrăm în loc de cheie greșită.

Ciclul de viață, în corespondență

Eveniment de facturareCe ar trebui să se întâmpleEfect în WISP
Comandă plătităConstruiți serverul din egg cu limitele planuluiServer creat, alocare atribuită, se rulează instalatorul egg-ului
Factură restantăSuspendaresuspended setat, iar panoul îl menține acolo
Plată primităReluaresuspended șters
AnulareȘtergereServer eliminat, alocare eliberată
ReinstalareRulați din nou scriptul de instalare al egg-uluicontainer.installed trece pe fals, apoi pe adevărat

Cinci acțiuni, și toate cinci răspund cu un 204 gol. Nu este literalmente nimic în corp, așa că regula casei se aplică fără excepție: nicio modificare nu are încredere în propriul răspuns. Citiți serverul înapoi după aceea.

Suspendarea este reală și este idempotentă

Această combinație este mai rară decât ar trebui printre panourile de joc și este întregul motiv pentru care un ciclu de relansare pe WISP este plictisitor într-un mod bun.

O a doua suspendare pe un server deja suspendat răspunde tot cu 204. Nimic de tratat ca un caz special, nimic de considerat drept „era deja așa”, nicio eroare de înghițit. Comparați asta cu panourile de control unde a suspenda de două ori este o eroare de autentificare și veți vedea cât din munca unei integrări de relansare se consumă de obicei cerându-și scuze pentru panou.

Ștergerea funcționează și pe un server suspendat, ceea ce contează pentru anularea care sosește la o lună după suspendare. O a doua ștergere răspunde 404, ceea ce este rezultatul corect pentru un declanșator de reziliere: nu mai este nimic de curățat.

Regulile de stare de partea Provibr sunt mai stricte decât cele ale panoului, în mod intenționat:

AcțiunePermisă din
startstopped, error, unknown
stop / restart / killrunning, error, unknown
suspendrunning, stopped, installing, error, unknown
resumesuspended
reinstallrunning, stopped, error

Citiți rândul suspendării de două ori. Puteți suspenda un server care este deja oprit și unul care este încă în curs de instalare. Dacă suspendarea ar funcționa doar pe servere în funcțiune, un client și-ar putea opri propriul server, ar putea înceta să plătească și ar deveni de neatins. Aplicarea unei reguli pe care o puteți evita apăsând oprirea nu este o aplicare, iar o anulare care sosește în mijlocul unei instalări nu ar trebui să aștepte terminarea acesteia.

Două chei, niciun prefix și greșeala care urmează

WISP păstrează separarea Pterodactyl între două suprafețe de API, iar nicio cheie singură nu le acoperă pe amândouă. Cheia de aplicație construiește, suspendă, reinstalează și elimină; cheia de client se ocupă de alimentare, de statisticile în timp real și de consolă. Amândouă se creează pe un cont de administrator.

Aici este capcana. Cheile WISP nu poartă niciun prefix, spre deosebire de ptla_ la Pterodactyl sau de papp_ la Pelican: sunt 48 de caractere fără un început recognoscibil, așa că nimic nu vă poate spune că le-ați lipit invers. Nici noi, și nici panoul, pentru că WISP răspunde la o cheie greșită cu 403 și un mesaj gol. Un 403 înseamnă în mod normal această cheie nu are voie să facă asta, așa că un client care a inversat două chei intră în panou și începe să bifeze permisiuni care nu au fost niciodată problema. Dacă testul de conexiune eșuează, inversați cele două chei înainte de a schimba orice altceva.

Cealaltă jumătate a acelei acreditări merită o frază în propriul dumneavoastră manual de operare: cheia de aplicație nu înseamnă doar gestionarea serverelor. Aceeași listă de noduri pe care o citește o integrare poartă și cheia de licență a nodului dumneavoastră și jetonul demonului. Tratați-o ca pe o acreditare pentru întregul panou și revocați-o în WISP dacă deconectați vreodată integrarea.

Nimic nu este instantaneu, iar API-ul o spune

Panoul dumneavoastră trăiește în propria dumneavoastră rețea, iar agentul se conectează spre exterior, așa că un punct final care modifică o mașină nu poate răspunde cu rezultatul. El răspunde că ordinul a fost acceptat și vă înmânează ceva de urmărit:

http
POST /v1/servers/{serverId}/actions/suspend
Authorization: Bearer pvk_...
Idempotency-Key: dunning-inv-10482
json
{
  "command": {
    "id": "cmd_...",
    "kind": "game.suspend",
    "status": "pending"
  }
}

Acesta este 202 Accepted, nu 200. Apoi citiți comanda până când starea ei este definitivă: done, failed, timed_out sau cancelled. Citirea nu funcționează niciodată astfel, pentru că un inventar sau o factură vine dintr-o bază de date, nu de la gazda dumneavoastră.

Tot ce creează ceva acceptă un Idempotency-Key de propria dumneavoastră alcătuire. Indexați-l pe ceva stabil din partea dumneavoastră, cum ar fi ID-ul facturii plus etapa de relansare, și un cron la fiecare cincisprezece minute, un webhook reluat și un administrator care dă clic de două ori devin toate inofensive.

Două forme care au stricat această integrare înainte să o cunoașteți

Amândouă merită citite chiar dacă nu atingeți niciodată WISP, pentru că amândouă sunt genul de eșec care raportează succes.

Fiecare identitate este un șir cu prefix, nu un număr. Un server WISP este server_01m0n8m94afcj2kk5mzt9z379q; nodurile, egg-urile și alocările arată la fel. Platforma avea o verificare potrivit căreia ID-ul extern al unui server de jocuri era format din litere și cifre, ceea ce este adevărat pentru orice alt panou de joc și fals aici. Rezultatul nu a fost un mesaj de eroare: clienții WISP aflați peste limită erau raportați lucrătorului de aplicare a regulilor și apoi omiși, la fiecare rundă, pentru totdeauna. Erau semnalați și niciodată suspendați. O singură verificare comună a identității acoperă acum ambele forme.

O pondere de disc egală cu zero este refuzată. WISP cere limits.io și pretinde o valoare între 10 și 1000. Câmpul de plan al platformei are implicit zero, așa că fiecare comandă WISP s-ar fi încheiat cu un 422 despre un câmp de care majoritatea oamenilor nu au auzit niciodată. Există acum două garduri: formularul de plan refuză un zero și spune de ce, iar agentul ridică un zero la ponderea implicită înainte de trimitere. Două garduri pentru o singură greșeală este ceva intenționat, pentru că unul dintre ele se află de partea pe care o puteți vedea.

Ce nu puteți vedea și ce nu ar trebui să pretindeți

Aceasta este partea sinceră și este scurtă.

  • Nu există niciun câmp de stare pe un server WISP. Pterodactyl are unul, cu installing și install_failed în el. WISP are suspended și container.installed, ambele booleene. O instalare eșuată arată prin urmare exact ca una în funcțiune: installed rămâne fals în ambele cazuri. În curs de construire și defect sunt aceeași imagine pe această suprafață, iar un produs care pretinde altceva ghicește.
  • Un nod nu își raportează propriul grad de ocupare. Câmpul pe care alte panouri îl folosesc pentru asta lipsește, inclusiv atunci când îl cereți explicit. Gradul de ocupare este însumat în schimb din servere, ceea ce funcționează și înseamnă un apel în plus.
  • Nu există timp de funcționare în statisticile în timp real. Un container care a repornit între două interogări nu poate fi recunoscut cu certitudine. În schimb, WISP nu ține acele statistici în cache timp de douăzeci de secunde, așa cum face Pterodactyl, așa că graficele nu inventează o scădere care nu s-a întâmplat niciodată. În ansamblu mai bine, cu o singură muchie ascuțită.

Capacitatea și cum se întâlnește cu relansarea

Provibr vă facturează capacitatea, nu clienții dumneavoastră. Ceea ce percepeți pentru un server de jocuri rămâne în întregime în interiorul propriului dumneavoastră sistem de facturare; noi nu vedem niciodată o factură de client și nu vorbim niciodată cu clienții dumneavoastră.

Regula care îi prinde pe toți în prima lună: fiecare server contează, în funcțiune sau nu. Unul suspendat nu contează și nici unul șters. Oprirea unei mașini nu eliberează nimic.

Acest lucru se aliniază destul de bine cu relansarea. Suspendați un client pentru neplată și el încetează să conteze pentru capacitatea dumneavoastră chiar în acel moment; reluați-l când plătește și contează din nou. Nu plătiți capacitate de platformă pentru cineva care nu vă plătește.

Ce nu este automatizat în mod deliberat

Provibr gestionează servere, nu panoul. Nu instalează WISP, nu atinge demonul nodului dumneavoastră dincolo de consolă și nu gestionează copii de siguranță, reguli de firewall sau atribuirea de adrese IP la acest furnizor: acele capabilități sunt oprite în registru, nu implementate pe jumătate. Nu există facturare măsurată pe consumul WISP, pentru că statisticile per server sunt afișate în panou și nu sunt expuse prin API, iar un punct final care nu există nu poate sta la baza unei facturi.

Dacă încă alegeți, comparația care merită citită mai întâi este Alegerea unui panou de joc după API-ul său, care măsoară șase panouri pe exact o singură întrebare: dacă o suspendare face ceva. Conexiunea în sine, cele două chei și câmpul de amprentă sunt acoperite pe pagina de integrare WISP.

Întrebări frecvente

WISP are propria sa facturare?

Nu. WISP găzduiește și controlează servere de jocuri; nu are comenzi, nu are facturi, nu are relansare și nu are idee ce client se află în spatele cărui server. Nivelul comercial este unul pe care îl adăugați dumneavoastră.

Suspendarea unui server în WISP chiar oprește clientul?

Da. WISP are o adevărată primitivă de suspendare pe API-ul său de aplicație, iar un client care are datele de autentificare pentru panou nu poate porni un server suspendat. Acest lucru nu este valabil pentru orice panou de joc: PufferPanel nu are deloc suspendare, iar GameAP are un indicator despre care s-a măsurat că nu schimbă nimic.

Este sigur ca un ciclu de relansare să suspende de două ori același server?

Da. O a doua suspendare răspunde 204 exact ca prima. Nu există nicio eroare „deja suspendat” de prins și nicio stare de verificat în prealabil, iar tocmai asta face ca o sarcină nocturnă de relansare pe WISP să fie simplă.

De ce se confundă atât de des cele două chei de API WISP?

Pentru că nu poartă niciun prefix. Pterodactyl și Pelican își etichetează cheile; cele ale WISP sunt 48 de caractere fără un început recognoscibil. O pereche inversată produce un 403 cu un mesaj gol, care se citește ca o problemă de permisiuni și nu ca eroarea de lipire care este de fapt.

Pot factura clienții WISP pentru ceea ce au consumat?

Nu prin API. Consumul per server este vizibil în panou, dar nu este expus ca punct final, așa că facturarea măsurată nu are ce să citească. Ceea ce funcționează astăzi este stabilirea prețului pe bază de capacitate, per server.

Începeți cu o gazdă și un agent

Creați un cont, instalați agentul cu o singură comandă și conectați primul dumneavoastră host Proxmox. Perioada de probă durează 14 zile și nu cere date de plată.