Aller au contenu

Blog ·

Vendre du Minecraft avec MCSManager

MCSManager fait tourner des serveurs de jeu sans exiger Docker, sur plusieurs nœuds, depuis un panneau léger. Ce que cela offre, et ce qui manque pour vendre.

Par Provibr

L’hébergement Minecraft est le point de départ de la plupart des activités d’hébergement de jeu, et pour de bonnes raisons : la demande est constante, les clients sont indulgents envers les petits fournisseurs, et la barrière technique jusqu’au premier client payant est réellement basse. Le panneau sur lequel on démarre est en général celui qui tournait sur le matériel dont on disposait.

MCSManager est celui sur lequel beaucoup de gens atterrissent. Il est libre, il est léger, il couvre plusieurs machines, et (la propriété qui tranche pour beaucoup) il n’exige pas Docker. Ce seul fait le rend utilisable sur du matériel où la famille Pterodactyl est impraticable, et il vaut la peine de comprendre pourquoi avant d’y bâtir une activité.

Ce qu’est réellement MCSManager

Deux morceaux, dans la forme désormais classique : un panneau web et un démon. Le panneau est l’interface et l’endroit où se fait l’administration entre nœuds ; le démon tourne sur chaque machine et c’est lui qui démarre, arrête et surveille réellement les processus. Un panneau peut parler à plusieurs démons, donc grandir consiste à ajouter une machine plutôt qu’à monter un second panneau.

Il est écrit en TypeScript (Node.js et Vue côté interface, Node.js sur les démons), ce qui le rend léger à exploiter et facile à lire le jour où vous devez savoir exactement ce qu’il fait. Environ 4 800 étoiles sur GitHub à l’heure où ces lignes sont écrites, activement développé, et traduit en plusieurs langues.

Le périmètre est Minecraft d’abord, avec les titres Steam à côté : Palworld, Terraria, Project Zomboid et le reste de cette famille. Si votre catalogue tient en « Minecraft, plus le jeu de survie auquel tout le monde joue cette année », cela correspond proprement à MCSManager.

La question Docker, et pourquoi elle tranche

Pterodactyl et ses descendants exigent des conteneurs. C’est un choix de conception défendable (il vous offre l’isolation et les limites de ressources gratuitement), mais il fixe aussi un plancher sur les endroits où vous pouvez tourner.

MCSManager prend en charge Docker sans l’imposer. Les serveurs peuvent tourner comme de simples processus gérés par le démon. Trois conséquences pratiques :

  • Il tourne sur du matériel bon marché et biscornu. Un petit VPS où les conteneurs imbriqués sont pénibles, une machine OpenVZ ou LXC, un poste recyclé dans un bureau : MCSManager y fonctionnera.
  • Il tourne sur Windows. Pour un amateur qui se transforme en entreprise, c’est souvent ce qui est réellement disponible.
  • La contrepartie est l’isolation. Sans conteneurs, « le serveur de ce client a mangé toute la mémoire » n’est pas automatiquement le problème de quelqu’un d’autre, contenu ailleurs. L’isolation et les limites que vous voulez, c’est vous qui les organisez : cgroups, utilisateurs séparés, machines séparées, ou activer Docker malgré tout.

Ce dernier point est celui auquel il faut réfléchir avant votre dixième client plutôt qu’après. Faire tourner des processus non isolés pour des gens qui vous ont payé va très bien à trois serveurs et devient une mauvaise idée à trois cents. Le panneau vous laissera faire les deux.

Authentification et multi-utilisateur

MCSManager a plusieurs utilisateurs et des clés d’API : une clé est générée par utilisateur et c’est elle qui authentifie l’accès programmatique, tandis que le démon a sa propre clé, seul moyen d’authentifier un panneau auprès de lui.

Il vaut la peine d’être clair sur ce à quoi ce modèle sert : les utilisateurs MCSManager sont des personnes qui exploitent des serveurs. Ce ne sont pas des clients avec un abonnement. Aucune formule n’est attachée à un utilisateur, pas d’échéance, pas de prix, pas de facture, et rien qui dise qu’un utilisateur a cessé de payer. Si vous donnez à chaque client un accès au panneau, vous lui avez donné un compte d’exploitation sur votre infrastructure, et vous suivez ailleurs qui vous doit de l’argent.

Ce n’est pas un défaut. C’est pareil dans tous les panneaux de jeu, y compris ceux pour lesquels les gens paient. C’est simplement la ligne où le panneau s’arrête et où votre activité commence.

Ce que vendre exige réellement

Le panneau vous donne la moitié machine : créer un serveur, le démarrer, l’arrêter, le redémarrer, accéder à une console, le supprimer. La moitié commerciale est entièrement à construire ou à acheter :

  • Un formulaire de commande et un catalogue, avec des formules qui veulent dire quelque chose en mémoire, en emplacements ou en stockage.
  • Un paiement qui provisionne en quelques secondes. Dans l’hébergement de jeu, ce n’est pas un agrément : le client est généralement assis avec ses amis en attendant de rejoindre la partie, et un délai qui se compte en minutes est la façon dont on le perd.
  • Un parcours de relance : en retard, averti, suspendu, rétabli. La suspension compte davantage ici qu’en hébergement web, car un serveur de jeu laissé en marche consomme de la mémoire en continu pour quelqu’un qui a cessé de payer.
  • Une capacité visible, pour savoir ce que vous portez sur l’ensemble de ces démons avant que la facture d’hébergement ne vous le dise.
  • Un journal d’activité, pour que « qui a supprimé ce monde » ait une réponse. Dans l’hébergement Minecraft en particulier, cette question se pose, et la réponse doit valoir mieux qu’un haussement d’épaules.
  • Un modèle de droits pour votre équipe, afin qu’un bénévole du support puisse redémarrer un serveur sans pouvoir en supprimer un.

La plupart des petits hébergeurs Minecraft font tourner cette moitié sur un tableur, un lien de paiement et beaucoup de bonne volonté. Cela marche jusqu’à ce que cela ne marche plus, et l’échec est rarement spectaculaire : c’est une accumulation lente de serveurs que personne ne paie, de remboursements que vous ne pouvez pas reconstituer, et d’une soirée par mois passée à rapprocher les comptes à la main.

Une remarque pratique sur le projet lui-même

MCSManager vient de la communauté sinophone et c’est encore là que se trouve son centre de gravité. Le panneau est correctement internationalisé et une documentation anglaise existe, mais lorsque vous cherchez une réponse pointue (un cas limite du protocole du démon, un déploiement inhabituel), la matière la plus riche et les réponses les plus rapides sont souvent en chinois. La traduction automatique s’en sort très bien. Mieux vaut le savoir avant d’avoir besoin d’aide à minuit que de le découvrir à ce moment-là.

Où Provibr s’insère

La prise en charge de MCSManager est en production. Un agent dans votre propre réseau parle au panneau web en http ou en https, de sorte que ni le panneau ni les démons derrière lui n’ont à être exposés. Créer, démarrer, arrêter, redémarrer, suspendre et supprimer des instances fonctionne, et ce qui se trouve déjà sur le panneau peut être importé. Autour de cela se trouve la couche décrite plus haut : des formules et de la capacité à un prix unitaire, un modèle de droits pour votre équipe, un journal d’activité complet, ainsi qu’une API REST et un module WHMCS pour que ce avec quoi vous facturez déjà puisse le piloter.

MCSManager répartit déjà une seule installation sur plusieurs démons : grandir revient donc à ajouter une machine et non un second panneau. Provibr lit cette liste et place le nouveau serveur sur la mémoire libre ; s’il y a plus d’un démon et aucun choix par défaut, il refuse au lieu de deviner. La suspension est ici bien réelle : MCSManager maintient lui-même une instance expirée à l’arrêt, si bien qu’un client ayant accès au panneau ne peut pas la relancer.

Ce que l’intégration ne peut pas faire, c’est effacer les manques du panneau. Il n’y a pas de console, car celle de MCSManager passe par socket.io, et il n’y a pas de graphiques d’usage, car le panneau ne les mesure pas. Il n’y a pas non plus de réinstallation : MCSManager ne reconstruit qu’à partir d’un préréglage, et Provibr construit à partir d’une commande de démarrage. Sans Docker, le panneau n’impose aucune limite, et l’intégration le dit au lieu de faire semblant.

Ce que cela ne fera pas

Gérer des serveurs n’est pas gérer le panneau. Installer MCSManager, le mettre à jour, ajouter des démons, choisir d’utiliser Docker ou non et entretenir les machines en dessous reste chez vous. Les mondes, les greffons, les mods et les sauvegardes restent dans le panneau, là où vous et vos clients continuez de les utiliser.

L’hébergement de jeu reste rarement seulement de l’hébergement de jeu. Provibr fait tourner aujourd’hui ses panneaux de contrôle, ses hyperviseurs et ses panneaux de jeu côte à côte, avec un seul inventaire, un seul modèle de droits et un seul journal d’activité. Des serveurs Minecraft sur un panneau, le VPS vers lequel un client évolue sur un autre, et un endroit unique où vous voyez les deux.

Commencez avec un hôte et un agent

Créez un compte, installez l’agent avec une seule commande et connectez votre premier hôte Proxmox. La période d’essai dure 14 jours et ne demande aucune coordonnée de paiement.