Vendre de l’hébergement de serveurs de jeu avec Pelican Panel

Pelican fait tourner des serveurs de jeu. Il ne prend pas de commandes, il n’envoie pas de factures, et il ne décide pas qu’un serveur doit s’arrêter parce que personne n’a payé. C’est de cet écart (entre le panneau fonctionne et l’activité tourne) que parle cette page.

Pelican est un fork de Pterodactyl et, à l’heure où ces lignes sont écrites, encore en bêta. Provibr s’y connecte comme intégration live et est testé sur Pelican 1.0.0.

Ce que Pelican vous donne, et ce qu’il ne donne pas

Pelican est un panneau de contrôle. Il connaît bien trois choses :

Ce que Pelican ne connaît pas : un client, une facture, un paiement, un abonnement qui expire. Il existe un indicateur suspended sur un serveur, mais rien dans le panneau ne le positionne jamais à votre place.

Une activité de serveurs de jeu bâtie sur Pelican comporte donc trois parties, pas une :

1. 01Le panneau : Pelican, qui fait tourner vos serveurs.
2. 02La boutique : où un client choisit un plan et paie. WHMCS, Blesta, FOSSBilling, votre propre paiement.
3. 03Le pont : ce qui transforme une commande payée en serveur qui tourne, et une commande impayée en serveur arrêté.

La plupart des gens construisent cette troisième partie à la main et le regrettent. C’est là que vivent les cas limites : un nœud plein, une variable d’egg laissée vide, un client qui résilie pendant que l’installateur tourne encore.

Connecter Pelican : deux clés, et un piège

Pelican a deux API avec deux clés différentes, et un pont de provisionnement a besoin des deux. Elles viennent de deux écrans différents, et toutes deux doivent appartenir à un compte disposant des droits d’administrateur.

Accordez à la clé application les droits de lecture et d’écriture sur Server, Node, Allocation, User et Egg. Moins que cela, et la création échoue à mi-chemin, ce qui est pire qu’un échec immédiat.

Deux points là-dessus coûtent un après-midi :

Copiez la clé client dès qu’elle apparaît. Pelican l’affiche une seule fois. Ensuite la liste ne conserve qu’un identifiant court, et cet identifiant est accepté comme une clé, donc le coller vous donne une simple erreur d’authentification plutôt qu’un indice signalant que vous avez copié la mauvaise chose. La clé application, elle, peut être relue intégralement depuis la liste ; la clé client non.

Faites attention à quelle clé va dans quel champ. Pelican accepte aussi une clé client sur l’API de gestion : les intervertir ne produit donc aucune erreur visible. Le préfixe est la seule chose qui les distingue. Provibr vérifie ce préfixe des deux côtés exactement pour cette raison : l’alternative est une intégration qui semble s’authentifier puis se comporte bizarrement pendant une semaine.

Il n’y a pas de raccourci en ligne de commande ici : Pelican ne fournit aucune commande artisan pour les clés d’API, les deux se créent donc via l’interface web.

Si le panneau présente un certificat auto-signé, épinglez son empreinte plutôt que de désactiver la vérification. Un panneau accessible en http simple fonctionne, mais les deux clés circulent alors en clair sur votre réseau. Et une empreinte à côté d’une adresse http est refusée, car il n’y a aucun certificat à épingler.

Des eggs à quelque chose que l’on peut vendre

Un egg n’est pas un produit. Il n’a ni prix, ni nom qu’un client reconnaisse, ni limites. Un plan est la couche qui transforme l’un en l’autre : il porte l’egg, l’image Docker, la commande de démarrage et les limites de ressources qu’un serveur reçoit.

Deux détails qui surprennent au moment de fixer les limites :

• La mémoire, le disque et le processeur acceptent 0 pour illimité.
• La limite de processeur se compte en pourcentage d’un cœur. 100 correspond à un cœur entier, 200 à deux. Un plan vendu comme « 2 vCPU » vaut 200, pas 2.
• Le poids d’E/S va de 0 à 1000, et 500 en est la valeur habituelle.

La règle des variables obligatoires

Un egg définit ses propres variables et en marque certaines comme obligatoires. Voici une décision qui mérite d’être copiée, que vous utilisiez Provibr ou non :

Refusez la commande lorsqu’une variable obligatoire est vide, alors même que Pelican l’accepterait.

Pelican crée quand même le serveur. Le conteneur plante alors à son premier démarrage, le client voit un serveur mort, et votre file de support reçoit un ticket disant « ça ne marche pas ». Un champ qui devient rouge au moment de commander est une bien meilleure réponse qu’un serveur qui existe et ne tourne pas.

Provibr lit la liste des eggs depuis votre panneau : le formulaire de commande propose donc les eggs que vous avez réellement au lieu de demander un numéro.

Où atterrit un serveur

Pelican indique de combien de mémoire et de processeur dispose chaque nœud, et quelle part en est déjà distribuée. Un pont raisonnable se sert des deux : un nouveau serveur va sur un nœud qui a de la place pour lui, et il est refusé avec un motif lorsqu’aucun nœud n’en a.

⚠️ Les chiffres que remonte le panneau sont une comptabilité, pas une mesure. Ils additionnent les limites des serveurs présents sur un nœud, y compris ceux qui sont encore en cours d’installation. Un nœud peut donc paraître plein alors qu’il ne tourne en réalité que peu de choses.

C’est important commercialement. Si vous surallouez (et la plupart des hébergeurs de jeu le font, car un serveur Minecraft doté de 4 Go en utilise rarement 4), alors les chiffres de Pelican vous arrêteront bien avant votre matériel. Calibrez vos budgets de nœud sur ce que vous comptez vendre, pas sur ce que la machine peut physiquement porter.

Ce que le client touche réellement

Pour un serveur de jeu, la console est le produit. Les commandes, les joueurs qui arrivent et la ligne de log qui explique un plantage vivent toutes là. Pelican a une vraie console, et Provibr la transmet au client par la même connexion sortante que tout le reste : pas de port séparé, pas de deuxième connexion, pas de deuxième mot de passe à réinitialiser.

Les fichiers, les sauvegardes, les bases de données et les planifications restent dans Pelican. C’est délibéré : ce sont des fonctions du panneau, et les reconstruire dans une seconde interface donne à vos clients deux endroits où la vérité pourrait se trouver.

Reprendre un panneau existant

Si vous faites déjà tourner Pelican avec des clients payants, vous n’avez rien à reconstruire. Les serveurs créés en dehors du pont sont laissés tranquilles ; vous les importez pour qu’ils apparaissent dans votre tableau de bord et comptent dans votre capacité.

L’import ne touche pas au serveur. Il se contente de commencer à le compter. Tant que vous ne l’importez pas, il n’est ni géré ni facturé. Vous pouvez donc migrer un panneau par lots, à votre rythme, plutôt que pendant une fenêtre de maintenance.

Ce qui n’entre pas dans le cadre

Soyez clair sur la frontière avant de vendre en face :

• L’administration du panneau reste dans Pelican. Ajouter des nœuds, modifier des eggs, gérer les utilisateurs du panneau : rien de tout cela ne déménage.
• Les fichiers, sauvegardes, bases de données et planifications restent aussi dans Pelican.
• Pelican est lui-même encore en bêta et son API change d’une version à l’autre. Le panneau n’offre aucun moyen de demander quelle version il exécute : une mise à niveau qui modifie une réponse se manifeste donc comme une erreur plutôt que comme un avertissement préalable. Lisez les notes de version avant de mettre à niveau un panneau auquel votre automatisation parle. Ce n’est pas une limite de Provibr, c’est une propriété du panneau : tout pont que vous bâtirez l’aura.

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

La plupart des hébergeurs de jeu finissent par faire tourner plus d’un panneau : Pelican pour le nouveau parc, Pterodactyl pour ce qui était déjà là, autre chose pour un client qui y tenait. Et la plupart vendent aussi 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. Un seul chiffre de capacité, un seul jeu de clés d’API, un seul endroit où la vie d’un serveur est consignée, quel que soit le panneau sur lequel il tourne.

La page suivante traite de l’autre moitié : ce qui arrive à un serveur Pelican quand une facture reste impayée.