Come vendere hosting di server di gioco con PufferPanel

PufferPanel è un pannello per server di gioco leggero e self-hosted. Si installa in pochi minuti, gestisce molti giochi ed è piacevolmente privo della complessità di Pterodactyl. Gli mancano però anche diverse cose che un’attività di hosting dà per scontate.

Questa pagina parla di vendere su PufferPanel a occhi aperti: cosa si automatizza in modo pulito, cosa no e dove passa il confine onesto. Tutto ciò che segue è stato misurato su PufferPanel 3.0.9.

PufferPanel non è un fork di Pterodactyl

Vale la pena dirlo subito, perché la supposizione costa giorni di lavoro. Pelican è un fork di Pterodactyl e ne condivide gran parte della forma dell’API. PufferPanel è un progetto indipendente, e nulla si trasferisce:

• L’autenticazione avviene tramite OAuth2 client credentials, non tramite una chiave API.
• I server si costruiscono da template della community per nome, non da egg numerati.
• Non esiste alcuna gerarchia nest/egg da percorrere.
• Gli identificatori dei server sono scelti da sé, di otto caratteri, e si scelgono al momento della creazione invece di riceverne uno.

Se ha un’integrazione Pterodactyl e spera di puntarla su PufferPanel con una modifica di configurazione, sta scrivendo una nuova integrazione.

Collegamento: OAuth2 e un secret che si vede una sola volta

Crei un client OAuth2 nel pannello, sotto il suo account. Ottiene un client ID e un client secret; entrambi vanno nella sua automazione insieme all’URL del pannello.

Copi subito il client secret. PufferPanel lo mostra una sola volta, alla creazione. Un secret copiato a metà restituisce un semplice errore di autenticazione invece di segnalare che è incompleto: un’ora molto ordinaria della sua vita, passata a controllare le cose sbagliate.

Ciò che il client può fare dipende dall’account a cui appartiene. Non esiste un selettore di ambito. Se si vuole che crei ed elimini server, deve appartenere a un account amministratore. È una nota di sicurezza che conta: un client OAuth2 su un account amministratore è una credenziale di amministratore, e come tale va trattato.

La porta non si indovina

Un PufferPanel appena installato parla semplice HTTP sulla porta 8080. Dietro un reverse proxy sarà sulla 443. Non esiste una porta che un’automazione possa aggiungere al posto suo senza indovinare, quindi le fornisca l’URL completo: http://panel.example.com:8080 oppure https://panel.example.com.

E sia onesto con sé stesso riguardo al trasporto. Un pannello su semplice http funziona, ma il client secret (una credenziale di amministratore) e tutto ciò che fa l’integrazione viaggiano allora non cifrati sulla sua rete. Se il pannello è dietro TLS con un certificato autofirmato, ne fissi l’impronta anziché disattivare la verifica. Un’impronta accanto a un indirizzo http viene rifiutata, perché non c’è nulla da fissare.

Template, non egg

PufferPanel costruisce un server da un template della community (minecraft, factorio e così via) anziché da un egg numerato definito da sé. Il nome del template è la sua identità.

Due conseguenze che determinano il modo in cui si vende:

La definizione completa del template va inviata inline alla creazione. PufferPanel non consente di dire «creami un server dal template X» per riferimento; l’intera definizione, con le sue variabili, entra nella richiesta. Ecco perché ordinare su PufferPanel è realisticamente guidato solo da un piano: serve un catalogo che contenga il template e i suoi valori, perché un modulo d’ordine a testo libero chiederebbe un documento al cliente.

I template della community usano di default un ambiente host. Quell’ambiente richiede binari che un host di pannello appena installato non ha: Java, le dipendenze di un gioco, ciò che il template presuppone. Lasciato così, il server non riesce a costruirsi con un errore di binario mancante che si legge come un bug della sua piattaforma. La soluzione è passare alla variante docker del template, che li porta con sé nella propria image. Provibr lo fa automaticamente; se costruisce il proprio ponte, lo faccia da sé, perché la modalità di errore è un ticket di assistenza ogni singola volta.

Il posizionamento tra i nodi, e perché è grossolano

PufferPanel espone i suoi nodi. Non espone la loro memoria, il loro disco o la loro CPU.

Non è cosa da poco. Un motore di posizionamento non ha nulla su cui ordinare: non può chiedere quale nodo abbia spazio, perché il pannello non risponde a questa domanda. Provibr segnala comunque il nodo (un pannello di gioco senza alcun nodo non è ordinabile), ma con capacità sconosciuta, e un pannello con più nodi viene scelto in ordine di nome anziché per spazio libero.

In pratica: se gestisce più di un nodo PufferPanel, il pianificatore della capacità è lei. Nulla nella catena le impedirà di riempire troppo un nodo, perché nulla nella catena può vederlo riempirsi.

Ciclo di vita: cosa funziona

Creare, avviare, fermare, riavviare, terminare, reinstallare ed eliminare funzionano tutti.

Un dettaglio misurato: l’eliminazione ferma prima il server, perché il daemon rifiuta di rimuovere un container in esecuzione. Un’eliminazione lanciata contro un server in esecuzione restituisce un 500 se si salta quel passaggio, esattamente il tipo di bug che emerge la prima volta che un cliente disdice un server Minecraft molto attivo un venerdì sera.

Tre cose che PufferPanel non ha

Questa è la sezione da leggere prima di puntare su PufferPanel come piattaforma di vendita.

Nessuna sospensione

PufferPanel non ha una sospensione propria. Nessuna colonna, nessun endpoint; lo stato del server conosce solo running e installing.

Quindi quando una piattaforma «sospende» un server di gioco PufferPanel per mancato pagamento, ciò che accade davvero è: il container viene fermato e l’accesso a esso viene bloccato nel pannello della piattaforma. È una cosa reale e utile, ma non è imposta da PufferPanel stesso, il che significa che chiunque abbia accesso diretto all’installazione di PufferPanel può riavviare il server.

Se i suoi clienti non hanno accesso al pannello sottostante, va bene. Se ce l’hanno, il suo sistema di solleciti ha un buco, e nessuna quantità di automazione lo chiude. È una proprietà del pannello, non di alcuno strumento che vi si metta davanti. Si confronti con Pelican, che ha un vero flag suspended.

Nessuna console live

PufferPanel ha una console, ma è basata su polling: GET /console restituisce log in base64 con un cursore epoch, e POST /console invia un comando. Un handshake WebSocket conforme alla specifica su /console restituisce 200 JSON invece di 101, provato sia con un token bearer sia con un cookie di sessione.

Il relay della console di Provibr è un tunnel (trasporta WebSocket NDJSON di Wings e VNC), e un modello a polling non vi rientra senza costruire una seconda forma di relay. Quindi la console è disattivata per PufferPanel, deliberatamente, anziché offrire un pulsante della console che porta a una scheda che ripiega sulla panoramica.

Per un server di gioco, la console è probabilmente il prodotto. Venda di conseguenza: i suoi clienti la ottengono in PufferPanel stesso, non nella sua dashboard.

Quasi nessun dato di utilizzo

L’endpoint delle statistiche di PufferPanel segnala la percentuale di CPU e la memoria in byte. Niente disco, niente rete, niente uptime.

Il set standard di grafici per un server di gioco è CPU, memoria, disco e rete. Due di questi quattro resterebbero vuoti in permanenza. Un grafico bloccato a zero per sempre è peggio di nessun grafico, quindi anche i grafici di utilizzo sono disattivati per PufferPanel.

Quindi quando PufferPanel è la scelta giusta?

È un pannello davvero buono, e i confini indicati sopra non lo squalificano: sono solo specifici. PufferPanel fa al caso suo se:

• I suoi clienti non ottengono accesso diretto all’host del pannello, quindi la mancata applicazione della sospensione è irrilevante.
• Vende piani fissi anziché risorse misurate.
• Gestisce un solo nodo, o non ha problemi a essere il pianificatore della propria capacità.
• Preferisce un pannello piccolo, rapido e con poche dipendenze alla profondità delle funzionalità.

Fa meno al caso suo se vende a un pubblico tecnico con accesso al pannello, o se i grafici di utilizzo per singolo server fanno parte di ciò per cui fa pagare.

Non si è obbligati a scegliere un solo pannello

La risposta realistica per la maggior parte degli host di giochi è entrambi. PufferPanel per la fascia leggera, Pelican o Pterodactyl dove la console e l’applicazione delle regole contano, e probabilmente web hosting o VPS accanto a tutto questo.

Provibr gestisce i suoi pannelli di controllo, i suoi hypervisor e i suoi pannelli di gioco fianco a fianco in un’unica dashboard, con una sola API e un solo numero di capacità per tutti. Dove un provider non sa fare qualcosa, la piattaforma rifiuta con una motivazione che nomina la funzione mancante, anziché fingere il contrario.

La pagina successiva descrive in dettaglio il percorso dall’ordine al server e quello della fattura non pagata: automatizzare la fatturazione con PufferPanel.