Vendre de l’hébergement de serveurs de jeu avec PufferPanel

PufferPanel est un panneau de serveurs de jeu léger et auto-hébergé. Il s’installe en quelques minutes, il fait tourner beaucoup de jeux, et il est agréablement dépourvu de la complexité de Pterodactyl. Il lui manque aussi plusieurs choses qu’une activité d’hébergement suppose acquises.

Cette page parle de vendre sur PufferPanel en connaissance de cause : ce qui s’automatise proprement, ce qui ne s’automatise pas, et où passe la frontière honnête. Tout ce qui suit a été mesuré sur PufferPanel 3.0.9.

PufferPanel n’est pas un fork de Pterodactyl

À dire d’emblée, car cette supposition coûte des jours de travail. Pelican est un fork de Pterodactyl et partage l’essentiel de la forme de son API. PufferPanel est un projet indépendant, et rien ne se transpose :

• L’authentification passe par des identifiants client OAuth2, pas par une clé d’API.
• Les serveurs sont construits à partir de modèles communautaires nommés, pas d’eggs numérotés.
• Il n’y a aucune hiérarchie nest/egg à parcourir.
• Les identifiants de serveur sont choisis par vous, sur huit caractères, et vous les choisissez à la création au lieu d’en recevoir un.

Si vous avez une intégration Pterodactyl et espérez la pointer vers PufferPanel avec un changement de configuration, vous écrivez une nouvelle intégration.

Se connecter : OAuth2, et un secret que vous voyez une fois

Créez un client OAuth2 dans le panneau, sous votre compte. Vous obtenez un identifiant de client et un secret de client ; les deux entrent dans votre automatisation avec l’URL du panneau.

Copiez le secret de client immédiatement. PufferPanel l’affiche une seule fois, à la création. Un secret copié à moitié donne une simple erreur d’authentification au lieu d’indiquer qu’il est incomplet : une heure très ordinaire de votre vie, passée à vérifier les mauvaises choses.

Ce que le client peut faire dépend du compte auquel il appartient. Il n’y a pas de sélecteur de portée. Pour qu’il crée et supprime des serveurs, il doit appartenir à un compte administrateur. C’est une note de sécurité qui compte : un client OAuth2 sur un compte administrateur est un identifiant d’administrateur, et doit être traité comme tel.

Le port ne se devine pas

Un PufferPanel neuf parle HTTP en clair sur le port 8080. Derrière un reverse proxy, il écoute sur 443. Il n’existe aucun port qu’une automatisation puisse ajouter à votre place sans deviner : donnez donc l’URL complète, http://panneau.exemple.fr:8080 ou https://panneau.exemple.fr.

Et soyez honnête avec vous-même sur le transport. Un panneau en http simple fonctionne, mais le secret de client (un identifiant d’administrateur) et tout ce que fait l’intégration circulent alors en clair sur votre réseau. Si le panneau est derrière TLS avec un certificat auto-signé, épinglez son empreinte plutôt que de désactiver la vérification. Une empreinte à côté d’une adresse http est refusée, car il n’y a rien à épingler.

Des modèles, pas des eggs

PufferPanel construit un serveur à partir d’un modèle communautaire (minecraft, factorio, etc.) plutôt qu’à partir d’un egg numéroté que vous auriez défini. Le nom du modèle est son identité.

Deux conséquences qui déterminent votre façon de vendre :

La définition complète du modèle doit être envoyée en ligne à la création. PufferPanel ne vous laisse pas dire « fabrique-moi un serveur à partir du modèle X » par référence ; toute la définition, avec ses variables, part dans la requête. C’est pourquoi commander sur PufferPanel est réalistement uniquement piloté par un plan : il vous faut un catalogue qui porte le modèle et ses valeurs, car un formulaire libre demanderait un document à un client.

Les modèles communautaires utilisent par défaut un environnement hôte. Cet environnement exige des binaires qu’un hôte de panneau neuf n’a pas : Java, les dépendances d’un jeu, ce que le modèle suppose. Laissé tel quel, le serveur échoue à se construire avec une erreur de binaire manquant qui se lit comme un bug de votre plateforme. La solution est de basculer sur la variante docker du modèle, qui les embarque dans son image. Provibr le fait automatiquement ; si vous bâtissez votre propre pont, faites-le vous-même, car le mode de défaillance est un ticket de support à chaque fois.

Le placement entre nœuds, et pourquoi il est grossier

PufferPanel expose ses nœuds. Il n’expose pas leur mémoire, leur disque ni leur processeur.

Ce n’est pas anodin. Un moteur de placement n’a rien pour classer : il ne peut pas demander quel nœud a de la place, car le panneau ne répond pas à cette question. Provibr signale le nœud malgré tout (un panneau de jeu sans aucun nœud n’est pas commandable), mais avec une capacité inconnue, et un panneau à plusieurs nœuds est choisi par ordre de nom plutôt que par espace libre.

En pratique : si vous faites tourner plus d’un nœud PufferPanel, c’est vous le planificateur de capacité. Rien dans la chaîne ne vous empêchera de surcharger un nœud, car rien dans la chaîne ne peut le voir se remplir.

Cycle de vie : ce qui fonctionne

Créer, démarrer, arrêter, redémarrer, tuer, réinstaller et supprimer fonctionnent tous.

Un détail mesuré : la suppression arrête d’abord le serveur, car le démon refuse de retirer un conteneur en cours d’exécution. Une suppression lancée contre un serveur en marche renvoie un 500 si vous omettez cette étape, exactement le genre de bug qui apparaît la première fois qu’un client résilie un serveur Minecraft très fréquenté un vendredi soir.

Trois choses que PufferPanel n’a pas

C’est la section à lire avant de vous engager sur PufferPanel comme plateforme de vente.

Pas de suspension

PufferPanel n’a pas de suspension propre. Pas de colonne, pas d’endpoint ; le statut d’un serveur ne connaît que running et installing.

Alors quand une plateforme « suspend » un serveur de jeu PufferPanel pour impayé, voici ce qui se passe réellement : le conteneur est arrêté, et l’accès à ce serveur est bloqué dans le panneau de la plateforme. C’est réel et utile, mais ce n’est pas imposé par PufferPanel lui-même, ce qui signifie que quiconque a un accès direct à l’installation PufferPanel peut redémarrer le serveur.

Si vos clients n’ont aucun accès au panneau sous-jacent, c’est sans conséquence. S’ils en ont un, vos relances ont un trou, et aucune dose d’automatisation ne le comble. C’est une propriété du panneau, pas de l’outil que vous placez devant. À comparer avec Pelican, qui possède un vrai indicateur suspended.

Pas de console en direct

PufferPanel a une console, mais elle repose sur du sondage : GET /console renvoie des logs en base64 avec un curseur epoch, et POST /console envoie une commande. Une poignée de main WebSocket conforme à la spécification sur /console renvoie 200 JSON au lieu de 101, essayé avec un jeton bearer comme avec le cookie de session.

Le relais de console de Provibr est un tunnel (il transporte des WebSockets NDJSON Wings et du VNC), et un modèle par sondage n’y entre pas sans construire une seconde forme de relais. La console est donc désactivée pour PufferPanel, délibérément, plutôt que de livrer un bouton de console menant à un onglet qui retombe sur la vue d’ensemble.

Pour un serveur de jeu, la console est sans doute le produit. Vendez en conséquence : vos clients l’obtiennent dans PufferPanel lui-même, pas dans votre tableau de bord.

Presque aucun relevé d’utilisation

Le point de statistiques de PufferPanel renvoie le pourcentage de processeur et la mémoire en octets. Pas de disque, pas de réseau, pas de durée de fonctionnement.

Le jeu de graphiques standard pour un serveur de jeu, c’est processeur, mémoire, disque et réseau. Deux de ces quatre resteraient vides en permanence. Un graphique bloqué à zéro pour toujours est pire que pas de graphique : les graphiques d’utilisation sont donc eux aussi désactivés pour PufferPanel.

Alors quand PufferPanel est-il le bon choix ?

C’est un panneau sincèrement bon, et les frontières ci-dessus ne le disqualifient pas : elles sont simplement précises. PufferPanel vous convient si :

• Vos clients n’ont pas d’accès direct à l’hôte du panneau, l’absence d’application de la suspension étant alors sans effet.
• Vous vendez des plans fixes plutôt que des ressources mesurées.
• Vous faites tourner un seul nœud, ou vous acceptez d’être votre propre planificateur de capacité.
• Vous préférez un panneau petit, rapide et peu dépendant à la profondeur fonctionnelle.

Il vous convient moins si vous vendez à un public technique disposant d’un accès au panneau, ou si les graphiques d’utilisation par serveur font partie de ce que vous facturez.

Vous n’êtes pas obligé de choisir un seul panneau

La réponse réaliste pour la plupart des hébergeurs de jeu, c’est les deux. PufferPanel pour la gamme légère, Pelican ou Pterodactyl là où la console et l’application des règles comptent, et probablement de l’hébergement web ou des VPS à côté.

Provibr fait tourner ses panneaux de contrôle, ses hyperviseurs et ses panneaux de jeu côte à côte dans un seul tableau de bord, avec une seule API et un seul chiffre de capacité pour l’ensemble. Là où un fournisseur ne sait pas faire quelque chose, la plateforme refuse avec un motif qui nomme la capacité manquante, au lieu de faire semblant.

La page suivante détaille le chemin de commande et celui des relances : automatiser la facturation avec PufferPanel.