Automatizarea facturării pentru PufferPanel

Majoritatea paginilor despre automatizarea facturării încep cu calea fericită. Aceasta începe cu golul, pentru că pe PufferPanel golul determină proiectarea.

PufferPanel nu are suspendare. Nici coloană, nici endpoint. Starea serverului cunoaște doar running și installing. Tot ce urmează decurge din asta.

Măsurat față de PufferPanel 3.0.9.

Două straturi de facturare, și nu sunt același lucru

Ceea ce le percepeți dumneavoastră propriilor clienți rămâne în întregime în interiorul sistemului dumneavoastră de facturare. Provibr nu vede niciodată o factură de client și nu vorbește niciodată cu clienții dumneavoastră. Sistemul dumneavoastră de facturare deține decizia, stratul de aprovizionare deține execuția.

Ciclul de viață, cartografiat

Patru dintre acele cinci rânduri sunt obișnuite. Al doilea nu este.

Golul de suspendare și cum să îl ocoliți prin proiectare

Când o platformă suspendă un server de jocuri PufferPanel, pentru a impune o limită de licență sau pentru că i-ați spus s-o facă din cauza neplății, oprește containerul și blochează accesul la acel server în propriul panou al platformei. Serverul nu rulează, iar clientul dumneavoastră nu îl poate porni din tabloul dumneavoastră de bord.

Dar blocarea este un concept al platformei, nu al panoului. Oricine are acces direct la instalarea PufferPanel poate porni serverul din nou. PufferPanel nu impune nimic, pentru că nu are cu ce să impună.

Merită spus limpede, nu îngropat, pentru că schimbă ce ar trebui să vindeți:

Dacă vă aflați în al doilea sau al treilea rând și impunerea somării contează, folosiți un panou cu un indicator real de suspendare. Pelican are unul, iar un server suspendat acolo rămâne suspendat indiferent cine se autentifică.

O cale de mijloc, dacă vreți să păstrați PufferPanel: reziliați mai devreme. Din moment ce o suspendare este slabă, tratați-o ca pe o etapă de avertizare, nu ca pe o etapă de impunere, și mutați impunerea reală la ștergere, cu o politică de retenție și o copie de rezervă făcută în prealabil, comunicate din start. Aceea este o decizie de produs, nu una tehnică.

Regula care modelează totul: nimic nu este instantaneu

Panoul dumneavoastră trăiește în propria rețea, iar o platformă rezonabilă îl atinge printr-un agent care se conectează spre exterior, fără port de intrare, fără gaură în firewall. Consecința este inevitabilă: un endpoint care schimbă o mașină nu poate răspunde cu rezultatul. Răspunde că a fost acceptată comanda:

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

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

202 Accepted, nu 200. Apoi citiți acea comandă până când starea sa este finală: done, failed, timed_out sau cancelled. O comandă eșuată poartă propriul cod de eroare al agentului cu argumentele lui. Citirea este diferită. Un inventar, o adresă sau o factură răspund imediat, pentru că asta vine dintr-o bază de date și nu de pe gazda dumneavoastră.

Proiectați-vă declanșatoarele de somare în jurul acestui lucru. Un declanșator care tratează „API-ul a răspuns” drept „munca este gata” va raporta o suspendare reușită care nu s-a întâmplat niciodată, tocmai în ziua în care conta.

Repetați în siguranță

Orice creează ceva acceptă un antet Idempotency-Key la alegerea dumneavoastră. Repetați aceeași cerere cu aceeași valoare și primiți înapoi primul rezultat, nu un al doilea server. Cheia lui pe ceva stabil de partea dumneavoastră (ID-ul facturii, ID-ul serviciului, etapa de somare), pentru că webhookurile reîncercate și joburile cron de cincisprezece minute sunt normale și ambele ar trebui să fie inofensive. Reutilizarea acelei valori pentru o cerere diferită este refuzată în mod deliberat: o cheie care înseamnă două lucruri nu înseamnă nimic.

Verbele și când sunt permise

Un server de jocuri acceptă șase acțiuni prin API: start · stop · restart · kill · suspend · resume, păzite de starea curentă a serverului:

Puteți suspenda un server care este deja oprit, iar asta este deliberat: o impunere pe care o puteți evita apăsând „stop” nu este o impunere. suspend din installing urmează aceeași logică. O reziliere care aterizează la mijlocul instalării nu ar trebui să aștepte terminarea instalării.

Comanda este condusă de plan, și așa trebuie să fie

Pe unele panouri puteți construi manual o comandă. Pe PufferPanel, în esență, nu puteți, iar motivul este structural: PufferPanel cere definiția completă a șablonului în linie atunci când se creează un server. Nu există un „fă unul din șablonul X prin referință”, așa că definiția trebuie să vină dintr-un catalog. Un plan de joc poartă numele șablonului și limitele de resurse; comanda indică spre plan. Dacă vă construiți propriul pod, veți sfârși oricum construind acest catalog.

Două detalii măsurate, ușor de nimerit greșit:

• Șabloanele comunitare au implicit un mediu de gazdă, care are nevoie de fișiere binare pe care o gazdă de panou proaspătă nu le are. Comutați la varianta docker a șablonului, altfel fiecare comandă eșuează cu o eroare de binar lipsă care se citește ca un defect al platformei.
• Ștergerea oprește mai întâi serverul. Daemonul refuză să elimine un container în funcțiune; o ștergere împotriva unui server în funcțiune returnează un 500.

Ce lipsește în mod deliberat

• Fără facturare bazată pe consum. Endpointul de statistici al PufferPanel raportează doar procentul de CPU și memoria: fără disc, fără rețea, fără uptime. Două dintre cele patru grafice standard de server de jocuri ar fi permanent goale, așa că graficele de consum sunt dezactivate pentru acest furnizor. Facturarea contorizată nu este posibilă pe date care nu există.
• Fără consolă în tabloul de bord. Consola PufferPanel este bazată pe sondare, nu un terminal live; o strângere de mână WebSocket conformă cu specificația pe /console returnează 200 JSON în loc de 101. Clienții dumneavoastră primesc consola în PufferPanel însuși.
• Fără plasare conștientă de capacitate. PufferPanel își expune nodurile, dar nu memoria, discul sau CPU-ul lor, așa că un panou cu mai multe noduri este ales după ordinea numelor, nu după spațiul liber. Dumneavoastră sunteți planificatorul de capacitate.
• Fără schimbare de plan într-un singur apel. Schimbarea unui plan este o reinstalare, cu tot ce implică asta pentru datele clientului.
• Fără buclă de reconciliere a inventarului. Sincronizarea _ListAccounts a WHMCS reziliază orice serviciu lipsă din răspuns, iar „lipsă” are cauze nevinovate: un domeniu de API mai restrâns, un membru limitat la o parte din inventar, o limitare de rată, o pagină scurtă al cărei cursor nu a fost urmat. Fiecare ar șterge mașini ale clienților.

Cum se face din WHMCS în loc de cod

Dacă rulați deja WHMCS, Provibr livrează un modul de aprovizionare ca un simplu fișier zip pe care îl instalați dumneavoastră înșivă. Un produs WHMCS indică spre un plan Provibr; fluxul obișnuit de comandă al WHMCS face crearea, suspendarea, reluarea și rezilierea. Două decizii din el merită copiate chiar și în propriul dumneavoastră pod:

O livrare încă în curs contează drept succes. Dacă bugetul de așteptare expiră în timp ce rulează programul de instalare, modulul raportează succes: comanda a fost acceptată, iar WHMCS nu are o stare de „în curs de instalare” (Pending acolo înseamnă nu s-a întâmplat încă nimic, ceea ce este fals). O comandă care eșuează cu adevărat este diferită: serviciul rămâne Pending, iar administratorul vede de ce.

Un server care a dispărut deja este o reziliere reușită. Un 404 înseamnă mai multe lucruri deodată (ID necunoscut, alt cont, invizibil pentru acest membru, deja șters), iar pentru un declanșator de reziliere acțiunea corectă este aceeași în toate: nu a mai rămas nimic de curățat.

Numărarea capacității și cum se întâlnește cu somarea

Facturarea platformei numără capacitatea, nu consumul, cu o regulă care îi prinde pe toți în prima lună: fiecare server contează, în funcțiune sau nu. Doar un server suspendat nu contează, și nici unul șters; oprirea unei mașini nu eliberează un loc.

Asta se potrivește bine cu somarea: un client pe care îl suspendați încetează să conteze cât timp este suspendat și contează din nou când plătește și îl reluați.

Rularea PufferPanel alături de tot restul

Nu trebuie să alegeți un singur panou. Provibr acoperă panourile sale de control, hipervizoarele și panourile de joc într-un singur tablou de bord, cu un singur API și o singură cifră de capacitate.

POST /v1/servers/{id}/actions/suspend face același lucru fie că dedesubt se află un server Pelican, un server PufferPanel sau un cont de găzduire DirectAdmin. Diferențele trăiesc în furnizor, nu în codul dumneavoastră de integrare, iar acolo unde un furnizor chiar nu poate face ceva, primiți un refuz care numește capabilitatea lipsă, nu o operațiune nulă tăcută.