Automazione della fatturazione per PufferPanel

La maggior parte delle pagine sull’automazione della fatturazione parte dal percorso felice. Questa parte dal vuoto, perché su PufferPanel è il vuoto a determinare la progettazione.

PufferPanel non ha la sospensione. Nessuna colonna, nessun endpoint. Lo stato del server conosce solo running e installing. Tutto ciò che segue ne deriva.

Misurato su PufferPanel 3.0.9.

Due livelli di fatturazione, e non sono la stessa cosa

Ciò che addebita ai suoi clienti resta interamente all’interno del suo sistema di fatturazione. Provibr non vede mai una fattura di un cliente e non parla mai con i suoi clienti. Il suo sistema di fatturazione detiene la decisione, il livello di provisioning detiene l’esecuzione.

Il ciclo di vita, in corrispondenza

Quattro di queste cinque righe sono ordinarie. La seconda no.

Il vuoto della sospensione, e come progettare attorno a esso

Quando una piattaforma sospende un server di gioco PufferPanel (per far rispettare un limite di licenza, o perché lei l’ha ordinato per mancato pagamento), ferma il container e blocca l’accesso a quel server nel proprio pannello. Il server non gira, e il suo cliente non può avviarlo dalla sua dashboard.

Ma il blocco è un concetto di piattaforma, non di pannello. Chiunque abbia accesso diretto all’installazione di PufferPanel può riavviare il server. PufferPanel non sta applicando nulla, perché non ha nulla con cui applicare.

Vale la pena dirlo chiaramente anziché nasconderlo, perché cambia ciò che si dovrebbe vendere:

Se si trova nella seconda o terza riga e l’applicazione dei solleciti conta, usare un pannello con un vero flag suspended. Pelican ne ha uno, e lì un server sospeso resta sospeso indipendentemente da chi accede.

Una via intermedia, se si vuole tenere PufferPanel: risolvere prima. Dato che una sospensione è morbida, trattarla come una fase di avviso anziché di applicazione, e spostare l’applicazione reale sull’eliminazione, con una politica di conservazione e un backup preso prima, comunicati in anticipo. Questa è una decisione di prodotto, non tecnica.

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

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:

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

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

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 è diversa: un inventario, un indirizzo o una fattura risponde immediatamente, perché viene da un database e non dal suo host.

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

Ripetere 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. Indicizzarla su qualcosa di stabile dal proprio lato (l’ID della fattura, l’ID del servizio, la fase di sollecito), perché i webhook rinviati e i cron ogni quindici minuti sono normali, ed entrambi dovrebbero essere innocui. 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, protette dallo stato corrente del server:

Si può sospendere un server già fermo, ed è una scelta deliberata: un’applicazione della regola che si può aggirare premendo «stop» non è tale. suspend da installing segue la stessa logica: una cancellazione che arriva a metà installazione non dovrebbe aspettare che l’installazione finisca.

Ordinare passa per un piano, e non può essere altrimenti

Su alcuni pannelli si può comporre un ordine a mano. Su PufferPanel di fatto non si può, e la ragione è strutturale: PufferPanel richiede la definizione completa del template inline quando si crea un server. Non esiste un «creane uno dal template X per riferimento», quindi la definizione deve venire da un catalogo. Un piano di gioco porta il nome del template e i limiti di risorse; l’ordine punta al piano. Se si costruisce il proprio bridge, si finirà comunque per costruire questo catalogo.

Due dettagli misurati su cui è facile inciampare:

• I template della community usano di default un ambiente host, che richiede binari che un host di pannello appena installato non ha. Passare alla variante docker del template, altrimenti ogni ordine fallisce con un errore di binario mancante che sembra un bug della piattaforma.
• L’eliminazione ferma prima il server. Il daemon rifiuta di rimuovere un container in esecuzione; un’eliminazione contro un server in esecuzione restituisce un 500.

Cosa non c’è deliberatamente

• Nessuna fatturazione basata sull’utilizzo. L’endpoint delle statistiche di PufferPanel riporta solo la percentuale di CPU e la memoria: niente disco, niente rete, niente uptime. Due dei quattro grafici standard per server di gioco resterebbero sempre vuoti, quindi i grafici di utilizzo sono disattivati per questo provider. La fatturazione a consumo non è possibile su dati che non esistono.
• Nessuna console nella dashboard. La console di PufferPanel è basata su polling anziché essere un terminale in tempo reale; un handshake WebSocket conforme alla specifica su /console restituisce 200 JSON invece di 101. I suoi clienti ottengono la console in PufferPanel stesso.
• Nessun posizionamento consapevole della capacità. PufferPanel espone i suoi nodi ma non la loro memoria, il disco o la CPU, quindi un pannello multi-nodo viene scelto per ordine di nome anziché per spazio libero. Il pianificatore di capacità è lei.
• Nessun cambio di piano in una sola chiamata. Cambiare piano è una reinstallazione, con le conseguenze per i dati del cliente che ciò comporta.
• Nessun ciclo di riconciliazione dell’inventario. 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.

Farlo da WHMCS anziché in codice

Se si utilizza già WHMCS, Provibr fornisce un modulo di provisioning come un semplice zip che si installa da sé. Un prodotto WHMCS punta a un piano Provibr; il normale flusso d’ordine di WHMCS si occupa di creare, sospendere, riattivare e risolvere. Due decisioni al suo interno vale la pena copiarle anche nel proprio bridge:

Una consegna ancora in corso conta come successo. Se il budget di attesa si esaurisce mentre l’installer sta lavorando, il modulo segnala un successo: l’ordine è stato accettato, e WHMCS non ha uno stato «in installazione» (Pending lì significa non è ancora accaduto nulla, cosa falsa). Un comando che fallisce davvero è un’altra cosa: il servizio resta Pending e l’amministratore vede perché.

Un server che non c’è più è una risoluzione riuscita. Un 404 significa diverse cose in una volta: ID sconosciuto, un’altra organizzazione, non visibile a questo membro, già eliminato. E per un hook di risoluzione l’azione corretta è la stessa in tutti i casi: non c’è più nulla da ripulire.

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 bene con i solleciti: un cliente che si sospende smette di contare finché è sospeso, e conta di nuovo quando paga e si riattiva.

PufferPanel accanto a tutto il resto

Non è obbligatorio scegliere 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à.

POST /v1/servers/{id}/actions/suspend fa la stessa cosa che sotto ci sia un server Pelican, un server PufferPanel o un account di hosting DirectAdmin. Le differenze vivono nel provider, non nel suo codice di integrazione. E dove un provider davvero non riesce a fare qualcosa, si ottiene un rifiuto che nomina la capacità mancante anziché un’assenza silenziosa di effetto.