Come vendere hosting di server di gioco con Pelican Panel

Pelican gestisce server di gioco. Non accetta ordini, non invia fatture e non decide che un server debba fermarsi perché nessuno l’ha pagato. Di questo divario (tra il pannello funziona e l’attività gira) parla questa pagina.

Pelican è un fork di Pterodactyl e, al momento in cui scriviamo, ancora in beta. Provibr vi si collega come integrazione live ed è testato su Pelican 1.0.0.

Cosa offre Pelican e cosa no

Pelican è un pannello di controllo. Conosce bene tre cose:

Ciò di cui Pelican non ha alcun concetto: un cliente, una fattura, un pagamento, un abbonamento che scade. Su un server esiste un flag suspended, ma nel pannello nulla lo imposta mai al posto suo.

Quindi un’attività di hosting di server di gioco costruita su Pelican è fatta di tre parti, non una:

1. 01Il pannello: Pelican, che gestisce i suoi server.
2. 02Il negozio: dove un cliente sceglie un piano e paga. WHMCS, Blesta, FOSSBilling, o un checkout proprio.
3. 03Il ponte: ciò che trasforma un ordine pagato in un server attivo e uno non pagato in un server fermo.

La maggior parte delle persone costruisce questa terza parte a mano e se ne pente. È lì che vivono i casi limite: un nodo pieno, una variabile di egg lasciata vuota, un cliente che disdice mentre l’installer è ancora in esecuzione.

Collegare Pelican: due chiavi e una trappola

Pelican ha due API con due chiavi diverse, e un ponte di provisioning ha bisogno di entrambe. Provengono da due schermate diverse ed entrambe devono appartenere a un account con diritti di amministratore.

Assegni alla chiave applicazione l’accesso in lettura e scrittura a Server, Node, Allocation, User e Egg. Qualcosa di meno e la creazione fallisce a metà strada, il che è peggio che fallire all’inizio.

Due cose al riguardo costano un pomeriggio:

Copi la chiave client nel momento in cui compare. Pelican la mostra una sola volta. Dopo, la lista conserva solo un identificatore breve. E quell’identificatore viene accettato come chiave, quindi incollarlo restituisce un semplice errore di autenticazione anziché un indizio sul fatto che si è copiata la cosa sbagliata. La chiave applicazione può essere riletta per intero dalla lista; la chiave client no.

Faccia attenzione a quale chiave va in quale campo. Pelican accetta una chiave client anche sull’API di gestione, quindi invertirle non produce alcun errore visibile. Il prefisso è l’unica cosa che le distingue. Provibr verifica questo prefisso su entrambi i lati proprio per questo motivo: l’alternativa è un’integrazione che sembra autenticarsi e poi si comporta in modo strano per una settimana.

Qui non c’è una scorciatoia da riga di comando: Pelican non fornisce alcun comando artisan per le chiavi API, quindi entrambe si creano tramite l’interfaccia web.

Se il pannello presenta un certificato autofirmato, ne fissi l’impronta anziché disattivare la verifica. Un pannello raggiungibile via semplice http funziona, ma allora entrambe le chiavi viaggiano non cifrate sulla sua rete. E un’impronta accanto a un indirizzo http viene rifiutata, perché non c’è alcun certificato da fissare.

Dagli egg a qualcosa che si può vendere

Un egg non è un prodotto. Non ha prezzo, non ha un nome che un cliente riconosca e non ha limiti associati. Un piano è lo strato che trasforma l’uno nell’altro: contiene l’egg, l’immagine Docker, il comando di avvio e i limiti di risorse che un server riceve.

Due dettagli che colgono di sorpresa al momento di impostare i limiti:

• Memoria, disco e CPU accettano 0 per illimitato.
• Il limite di CPU si conta in percentuale di un core. 100 è un core intero, 200 sono due. Un piano venduto come «2 vCPU» vale 200, non 2.
• Il peso di I/O va da 0 a 1000, e 500 è il valore consueto.

La regola delle variabili obbligatorie

Un egg definisce le proprie variabili e ne marca alcune come obbligatorie. Ecco una decisione che vale la pena copiare, che si usi Provibr o meno:

Rifiutare l’ordine quando una variabile obbligatoria è vuota, anche se Pelican stesso l’accetterebbe.

Pelican crea comunque il server. Il container poi va in crash al primo avvio, il cliente vede un server morto e la sua coda di assistenza riceve un ticket con scritto «non funziona». Un campo che diventa rosso al checkout è una risposta di gran lunga migliore di un server che esiste e non funziona.

Provibr legge la lista degli egg dal suo pannello, quindi il modulo d’ordine propone gli egg che si hanno davvero invece di chiedere di digitare un numero.

Dove atterra un server

Pelican segnala quanta memoria e CPU ha ogni nodo e quanta ne è già stata assegnata. Un ponte ragionevole usa entrambe: un nuovo server va su un nodo che ha spazio per lui e viene rifiutato con una motivazione quando nessun nodo ne ha.

⚠️ Le cifre che il pannello segnala sono contabilità, non una misurazione. Sommano i limiti dei server presenti su un nodo, compresi quelli ancora in fase di installazione. Un nodo può quindi sembrare pieno mentre in realtà gira ben poco.

Questo conta sul piano commerciale. Se si pratica l’overselling (e la maggior parte degli host di giochi lo fa, perché un server Minecraft a cui sono assegnati 4 GB ne usa raramente 4), allora i numeri di Pelican la fermeranno molto prima del suo hardware. Calibri i budget dei nodi su ciò che intende vendere, non su ciò che la macchina può fisicamente reggere.

Cosa tocca davvero il cliente

Per un server di gioco, la console è il prodotto. I comandi, gli ingressi dei giocatori e la riga di log che spiega un crash vivono tutti lì. Pelican ha una console vera, e Provibr la inoltra al cliente sulla stessa connessione in uscita di tutto il resto: nessuna porta separata, nessun secondo accesso, nessuna seconda password da reimpostare.

File, backup, database e pianificazioni restano in Pelican. È una scelta deliberata: sono funzioni del pannello, e reimplementarle in una seconda interfaccia dà ai suoi clienti due posti in cui potrebbe trovarsi la verità.

Trasferire un pannello esistente

Se già gestisce Pelican con clienti paganti, non deve ricostruire nulla. I server creati al di fuori del ponte vengono lasciati stare; li importa per farli comparire nella sua dashboard e conteggiare nella sua capacità.

L’import non tocca il server. Si limita a iniziare a conteggiarlo. Finché non lo importa, non è né gestito né fatturato, il che significa che può trasferire un pannello a lotti, al proprio ritmo, invece che durante una finestra di manutenzione.

Cosa non è coperto

È bene avere chiaro il confine prima di venderci contro:

• L’amministrazione del pannello resta in Pelican. Aggiungere nodi, modificare egg, gestire gli utenti del pannello: nulla di tutto ciò si sposta.
• File, backup, database e pianificazioni restano anch’essi in Pelican.
• Pelican è ancora in beta e la sua API cambia da una release all’altra. Il pannello non offre alcun modo per chiedere quale versione stia eseguendo, quindi un aggiornamento che modifica una risposta si manifesta come un errore anziché come un avviso preventivo. Legga le note di rilascio prima di aggiornare un pannello con cui la sua automazione dialoga. Non è una limitazione di Provibr: è una proprietà del pannello, e qualsiasi ponte si costruisca l’avrà.

Non si è obbligati a scegliere un solo pannello

La maggior parte degli host di giochi finisce per gestire più di un pannello: Pelican per il nuovo parco macchine, Pterodactyl per ciò che c’era già, qualcos’altro per un cliente che ci teneva. E la maggior parte vende anche web hosting o VPS accanto a questo.

Provibr gestisce i suoi pannelli di controllo, i suoi hypervisor e i suoi pannelli di gioco fianco a fianco in un’unica dashboard. Un solo numero di capacità, un solo set di chiavi API, un solo posto in cui viene registrata la vita di un server, indipendentemente dal pannello su cui capita di girare.

La pagina successiva copre l’altra metà: cosa succede a un server Pelican quando una fattura resta impagata.