Automazione della fatturazione per Pelican Panel

Pelican ha un flag suspended su ogni server. Nulla in Pelican lo imposta mai. Questa singola frase è l’intera ragione per cui questa pagina esiste: il pannello è in grado di fermare il server di un cliente, ma non ha idea se il cliente abbia pagato.

Questa pagina descrive che aspetto ha un’automazione che funziona: il percorso dell’ordine, il percorso dei solleciti, e le parti che sono davvero più difficili di quanto sembrino.

Due livelli di fatturazione, e non sono la stessa cosa

Prima di ogni altra cosa, separarli. Vengono confusi di continuo, e poi si discute del problema sbagliato.

Ciò che addebita ai suoi clienti, e come, resta interamente all’interno del suo sistema di fatturazione. Provibr non vede mai una fattura di un cliente, non fissa mai un prezzo al suo posto e non parla mai con i suoi clienti; le fattura la capacità riservata per tipo di risorsa, a un prezzo unitario che cala a fasce man mano che il numero cresce.

Questa separazione è ciò che rende l’automazione trattabile. Il suo sistema di fatturazione detiene la decisione; il livello di provisioning detiene l’esecuzione.

Il ciclo di vita, in corrispondenza

Ecco la corrispondenza di cui ha bisogno ogni automazione di game hosting, qualunque strumento si utilizzi:

Pelican qui è a suo agio, e vale la pena dirlo chiaramente, perché non tutti i pannelli di gioco lo sono. Pelican ha una vera primitiva di sospensione. Un server sospeso è sospeso nel pannello: chi ha accesso diretto a Pelican non può semplicemente riavviarlo. Quando l’applicazione della regola conta (e per i solleciti conta), questa è la differenza tra una politica e un desiderio.

(Per contrasto: PufferPanel non ha una sospensione propria, quindi lì una sospensione è un concetto di piattaforma che il pannello non applica.)

La regola che dà forma a tutto: nulla è istantaneo

Questa è la parte che si sbaglia quando si collega un’API da sé.

Il suo pannello vive nella sua rete, e una piattaforma sensata lo raggiunge tramite un agente che si connette verso l’esterno: nessuna porta in entrata, nessun buco nel firewall. La conseguenza è inevitabile: un endpoint che modifica una macchina non può rispondere con il risultato. Risponde che l’ordine è stato accettato, e consegna qualcosa da seguire:

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

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

Si ottiene 202 Accepted, non 200. Poi si legge quel comando finché il suo stato non è definitivo: done, failed, timed_out o cancelled. Un comando fallito porta il codice di errore dell’agente stesso, con i suoi argomenti.

La lettura non funziona mai così: un inventario, un indirizzo o una fattura risponde immediatamente, perché quella risposta viene da un database e non dal suo host.

Progetti i suoi hook di fatturazione attorno a questo. Un hook che interpreta «l’API ha risposto» come «il lavoro è fatto» segnalerà come riuscita una sospensione che non è mai avvenuta, esattamente il giorno in cui contava.

Ripetere una richiesta senza rischi

Tutto ciò che crea qualcosa accetta un’intestazione Idempotency-Key di propria composizione. Ripetere la stessa richiesta con lo stesso valore e si ottiene il primo esito, anziché un secondo server, un secondo comando o un secondo addebito.

Per i solleciti questo non è un lusso. Un cron ogni quindici minuti, un webhook rinviato, un amministratore che clicca due volte. Tutti e tre sono normali e tutti e tre dovrebbero essere innocui. Indicizzare la richiesta su qualcosa di stabile dal proprio lato: l’ID della fattura, l’ID del servizio, la fase di sollecito. Riutilizzare quel valore per una richiesta diversa viene rifiutato di proposito: una chiave che significa due cose non significa nulla.

I verbi, e quando sono consentiti

Un server di gioco accetta sei azioni tramite l’API:

start · stop · restart · kill · suspend · resume

Sono protette dallo stato corrente del server, che è più rigido di quanto possa sembrare:

La riga suspend è quella interessante, ed è una scelta deliberata: si può sospendere un server già fermo. Se la sospensione funzionasse solo sui server in esecuzione, un cliente potrebbe fermare il proprio server, smettere di pagare e diventare immune: il pannello rifiuterebbe la sospensione perché non c’era nulla in esecuzione. Un’applicazione della regola che si può aggirare premendo «stop» non è tale.

Anche suspend da installing conta: una cancellazione che arriva a metà installazione non dovrebbe aspettare che l’installazione finisca.

Farlo da un pannello di fatturazione anziché in codice

Se si utilizza già WHMCS, non serve scrivere nulla di quanto sopra. Provibr fornisce un modulo di provisioning per WHMCS come un semplice zip che si installa da sé: un prodotto WHMCS punta a un piano Provibr, e il normale flusso d’ordine di WHMCS si occupa di creare, sospendere, riattivare e risolvere.

Due decisioni di progettazione in quel modulo vale la pena copiarle anche se si scrive il proprio bridge:

Una consegna ancora in corso conta come successo. Se il budget di attesa si esaurisce mentre l’installer sta ancora lavorando, il modulo segnala un successo. L’ordine è stato accettato: la riga server esiste, l’indirizzo è assegnato, il comando è presso l’agente. E WHMCS non ha uno stato «in installazione» (Pending lì significa non è ancora accaduto nulla, cosa dimostrabilmente falsa). Un comando che fallisce davvero è un’altra cosa: il servizio resta Pending, l’amministratore vede perché, e un clic ripetuto è innocuo grazie alla chiave di idempotenza.

Un server che non c’è più è una risoluzione riuscita. Un 404 alla cancellazione significa quattro cose in una volta: ID sconosciuto, un’altra organizzazione, non assegnato a questo membro, o già eliminato. E per un hook di risoluzione l’azione corretta è identica in tutti e quattro i casi: non c’è più nulla da ripulire. Trattarlo come un errore lascia un servizio bloccato in «terminating» per sempre.

Cosa non viene deliberatamente automatizzato

Confini onesti, perché queste sono le domande che arrivano dopo che si è già venduto qualcosa:

• Nessuna fatturazione basata sull’utilizzo. Le metriche per server vengono raccolte e mostrate nel pannello, ma non ancora esposte tramite l’API. Senza un endpoint non c’è fatturazione a consumo. Se il suo prodotto è «paga la RAM che hai usato», oggi questo non lo fa.
• Nessun cambio di piano in una sola chiamata. Cambiare piano non è nemmeno una singola chiamata API a livello di Pelican: è una reinstallazione o un cambio di risorse, con conseguenze diverse per i dati del cliente.
• Nessun reset della password tramite l’API. Le credenziali viaggiano in modo transitorio e non vengono mai memorizzate, quindi non c’è nulla da rinviare.
• Nessun single sign-on dal suo pannello di fatturazione al pannello Provibr.
• Nessun ciclo di riconciliazione dell’inventario: un rifiuto, non un vuoto. La sincronizzazione _ListAccounts di WHMCS risolve qualsiasi servizio assente dalla risposta, e «assente» ha cause innocenti: un ambito API più stretto, un membro limitato a una parte dell’inventario, un rate limit, una pagina corta il cui cursore non è stato seguito. Ognuna eliminerebbe macchine dei clienti. Al suo posto, l’area cliente legge lo stato in tempo reale a ogni visualizzazione di pagina, cosa che non è una sincronizzazione e non pretende di esserlo.

Il conteggio della capacità, e come incontra i solleciti

La fatturazione della piattaforma conta la capacità, non l’utilizzo, con una regola che coglie tutti nel primo mese: ogni server conta, in esecuzione o no. Solo un server sospeso non conta, e nemmeno uno eliminato. Fermare una macchina non libera un posto.

Questo si allinea perfettamente con i solleciti. Un cliente che si sospende per mancato pagamento smette di contare nella propria capacità finché è sospeso, e conta di nuovo nel momento in cui paga e si riattiva, così non si paga la capacità di piattaforma per un cliente che non paga.

Superare il proprio limite non viene bloccato nel momento in cui accade. Viene rilevato, si viene informati, e si ha un’intera giornata lavorativa. Se quel periodo di grazia scade, i server più recenti oltre il limite vengono sospesi, i più recenti per primi, così che ciò che è stato costruito per primo sopravviva.

Pelican accanto a tutto il resto

Un provider di game hosting che cresce raramente resta su un solo pannello. Provibr copre i suoi pannelli di controllo, i suoi hypervisor e i suoi pannelli di gioco in un’unica dashboard, con un’unica API e un unico numero di capacità per tutti.

POST /v1/servers/{id}/actions/suspend fa la stessa cosa che sotto ci sia un server Pelican, un server Pterodactyl o un account di hosting DirectAdmin. Le differenze vivono nel provider, non nel suo codice di integrazione.