Gameserverhosting verkopen met Pelican Panel

Pelican draait gameservers. Het neemt geen bestellingen aan, het stuurt geen facturen, en het besluit niet dat een server moet stoppen omdat er niemand betaald heeft. Dat gat, tussen het paneel werkt en de zaak loopt, is waar deze pagina over gaat.

Pelican is een fork van Pterodactyl en op het moment van schrijven nog in bèta. Provibr koppelt eraan als live integratie en is getest tegen Pelican 1.0.0.

Wat Pelican je geeft, en wat niet

Pelican is een controlepaneel. Het kent drie dingen goed:

Wat Pelican níet kent: een klant, een factuur, een betaling, een abonnement dat afloopt. Er is een suspended-vlag op een server, maar niets in het paneel zet hem ooit voor je.

Een gameserverbedrijf op Pelican bestaat dus uit drie delen, niet uit één:

1. 01Het paneel: Pelican, dat je servers draait.
2. 02De winkel: waar een klant een plan kiest en betaalt. WHMCS, Blesta, FOSSBilling, je eigen afrekenpagina.
3. 03De brug: het ding dat van een betaalde bestelling een draaiende server maakt, en van een onbetaalde een gestopte.

De meeste mensen bouwen dat derde deel met de hand en krijgen er spijt van. Daar zitten namelijk de randgevallen: een node die vol is, een egg-variabele die leeg bleef, een klant die opzegt terwijl de installatie nog loopt.

Koppelen: twee sleutels, en één valkuil

Pelican heeft twee API's met twee verschillende sleutels, en een provisioningbrug heeft ze allebei nodig. Ze komen van twee verschillende schermen, en ze moeten allebei bij een account met beheerdersrechten horen.

Geef de application-sleutel lees- en schrijfrechten op Server, Node, Allocation, User en Egg. Minder betekent dat het aanmaken halverwege stukloopt, en dat is erger dan meteen stuklopen.

Twee dingen hieraan kosten mensen een middag:

Kopieer de client-sleutel zodra hij verschijnt. Pelican toont hem één keer. Daarna houdt de lijst alleen een korte identifier over, en die identifier wordt als sleutel geaccepteerd, dus als je hem plakt krijg je een gewone authenticatiefout in plaats van een hint dat je het verkeerde gekopieerd hebt. De application-sleutel kun je wél volledig uit de lijst teruglezen; de client-sleutel niet.

Let op welke sleutel in welk veld gaat. Pelican accepteert een client-sleutel óók op de beheer-API, dus als je de twee verwisselt krijg je geen zichtbare fout. De prefix is het enige wat ze uit elkaar houdt. Provibr controleert die prefix aan beide kanten om precies die reden: het alternatief is een integratie die lijkt te authenticeren en zich daarna een week lang vreemd gedraagt.

Er is hier geen snelle route via de commandoregel: Pelican levert geen artisan-commando voor API-sleutels, dus je maakt ze allebei via de webinterface aan.

Presenteert het paneel een zelfondertekend certificaat, pin dan zijn fingerprint in plaats van de verificatie uit te zetten. Een paneel dat over gewoon http bereikbaar is werkt, maar dan reizen beide sleutels onversleuteld over je netwerk. En een fingerprint naast een http-adres wordt geweigerd, want er is geen certificaat om te pinnen.

Van eggs naar iets wat je kunt verkopen

Een egg is geen product. Het heeft geen prijs, geen naam die een klant herkent, en geen limieten. Een plan is de laag die het één in het ander verandert: het draagt het egg, het Docker-image, het startcommando en de resourcelimieten die een server krijgt.

Twee details die mensen verrassen bij het instellen van limieten:

• Geheugen, schijf en CPU accepteren 0 voor onbeperkt.
• De CPU-limiet telt in procenten van één core. 100 is één volle core, 200 zijn er twee. Een plan dat je als "2 vCPU" verkoopt is 200, niet 2.
• Het IO-gewicht loopt van 0 tot 1000, en 500 is de gebruikelijke waarde.

De regel voor verplichte variabelen

Een egg legt zijn eigen variabelen vast en markeert er een aantal als verplicht. Hier een beslissing die het kopiëren waard is, of je Provibr nu gebruikt of niet:

Weiger de bestelling als een verplichte variabele leeg is, ook al zou Pelican hem accepteren.

Pelican maakt de server namelijk toch aan. De container crasht dan bij zijn eerste start, de klant ziet een dode server, en je supportwachtrij krijgt een ticket met "het werkt niet". Een veld dat rood wordt bij het afrekenen is een veel beter antwoord dan een server die bestaat en niet draait.

Provibr leest de eggenlijst uit je paneel, dus het bestelformulier biedt de eggs aan die je werkelijk hebt in plaats van om een nummer te vragen.

Waar een server landt

Pelican meldt hoeveel geheugen en CPU elke node heeft, en hoeveel daarvan al is uitgedeeld. Een verstandige brug gebruikt allebei: een nieuwe server gaat naar een node die er plaats voor heeft, en wordt met een reden geweigerd als geen enkele node die heeft.

⚠️ De cijfers die het paneel meldt zijn boekhouding, geen meting. Ze tellen de limieten op van de servers op een node, inclusief die nog aan het installeren zijn. Een node kan er dus vol uitzien terwijl er in werkelijkheid weinig draait.

Dat is commercieel van belang. Als je oververkoopt (en dat doen de meeste gamehosts, want een Minecraft-server met 4 GB toegewezen gebruikt zelden 4 GB), dan houden Pelicans cijfers je veel eerder tegen dan je hardware. Stel je nodebudgetten dus af op wat je van plan bent te verkopen, niet op wat de machine fysiek aankan.

Wat de klant werkelijk aanraakt

Voor een gameserver ís de console het product. Commando's, spelers die binnenkomen, en de logregel die een crash verklaart wonen daar allemaal. Pelican heeft een echte console, en Provibr geeft die door aan de klant over dezelfde uitgaande verbinding als al het andere: geen aparte poort, geen tweede login, geen tweede wachtwoord om te resetten.

Bestanden, back-ups, databases en planningen blijven in Pelican. Dat is met opzet: dat zijn paneelfuncties, en ze in een tweede interface nabouwen geeft je klanten twee plekken waar de waarheid zou kunnen staan.

Een bestaand paneel meenemen

Draai je Pelican al met betalende klanten, dan hoef je niets opnieuw te bouwen. Servers die buiten de brug om zijn aangemaakt blijven met rust; je importeert ze zodat ze in je dashboard verschijnen en meetellen voor je capaciteit.

Importeren raakt de server niet aan. Het begint hem alleen te tellen. Tot je hem importeert wordt hij niet beheerd en niet gefactureerd. Je kunt een paneel dus in porties overzetten, op je eigen tempo, in plaats van tijdens een onderhoudsvenster.

Wat hier niet onder valt

Wees duidelijk over de grens voordat je ertegenaan verkoopt:

• Paneelbeheer blijft in Pelican. Nodes toevoegen, eggs bewerken, paneelgebruikers beheren: daar verhuist niets van.
• Bestanden, back-ups, databases en planningen blijven ook in Pelican.
• Pelican is zelf nog in bèta en zijn API verandert tussen releases. Het paneel biedt geen manier om te vragen welke versie het draait, dus een upgrade die een antwoord verandert komt naar boven als een fout in plaats van vooraf als waarschuwing. Lees de release notes voordat je een paneel bijwerkt waar je automatisering mee praat. Dit is geen beperking van Provibr: het is een eigenschap van het paneel, en elke brug die je bouwt heeft hem.

Je hoeft geen paneel te kiezen

De meeste gamehosts draaien uiteindelijk meer dan één paneel: Pelican voor de nieuwe voorraad, Pterodactyl voor wat er al stond, en iets anders voor een klant die erop stond. En de meesten verkopen er ook webhosting of VPS'en naast.

Provibr draait zijn controlepanelen, hypervisors en gamepanelen naast elkaar in één dashboard. Eén capaciteitsgetal, één set API-sleutels, één plek waar het leven van een server wordt vastgelegd, ongeacht op welk paneel hij toevallig draait.

De volgende pagina behandelt de andere helft: wat er met een Pelican-server gebeurt als een factuur onbetaald blijft.