Gameserver-Hosting verkaufen mit Pelican Panel

Pelican betreibt Gameserver. Es nimmt keine Bestellungen an, es verschickt keine Rechnungen, und es entscheidet nicht, dass ein Server stoppen soll, weil niemand bezahlt hat. Diese Lücke (zwischen das Panel läuft und das Geschäft läuft) ist das Thema dieser Seite.

Pelican ist ein Fork von Pterodactyl und zum Zeitpunkt dieses Textes noch in der Beta. Provibr bindet es als Live-Integration an und ist gegen Pelican 1.0.0 getestet.

Was Pelican Ihnen gibt, und was nicht

Pelican ist ein Control Panel. Drei Dinge kann es gut:

Was Pelican nicht kennt: einen Kunden, eine Rechnung, eine Zahlung, ein Abonnement, das ausläuft. Es gibt ein suspended-Flag an einem Server, aber nichts im Panel setzt es jemals für Sie.

Ein Gameserver-Geschäft auf Pelican besteht also aus drei Teilen, nicht aus einem:

1. 01Das Panel: Pelican, das Ihre Server betreibt.
2. 02Der Shop: wo ein Kunde einen Plan wählt und bezahlt. WHMCS, Blesta, FOSSBilling, Ihre eigene Kasse.
3. 03Die Brücke: das, was aus einer bezahlten Bestellung einen laufenden Server macht und aus einer unbezahlten einen gestoppten.

Die meisten bauen diesen dritten Teil von Hand und bereuen es. Dort wohnen nämlich die Randfälle: eine volle Node, eine leer gelassene Egg-Variable, ein Kunde, der kündigt, während der Installer noch läuft.

Anbinden: zwei Keys und eine Falle

Pelican hat zwei APIs mit zwei verschiedenen Keys, und eine Provisionierungsbrücke braucht beide. Sie stammen aus zwei verschiedenen Bildschirmen, und beide müssen zu einem Konto mit Administratorrechten gehören.

Geben Sie dem Application-Key Lese- und Schreibrechte auf Server, Node, Allocation, User und Egg. Weniger heißt, dass das Anlegen auf halber Strecke scheitert, und das ist schlimmer, als gleich zu scheitern.

Zwei Dinge daran kosten Menschen einen Nachmittag:

Kopieren Sie den Client-Key sofort, wenn er erscheint. Pelican zeigt ihn einmal. Danach behält die Liste nur eine kurze Kennung, und diese Kennung wird als Key akzeptiert. Fügen Sie sie ein, bekommen Sie einen gewöhnlichen Authentifizierungsfehler statt eines Hinweises, dass Sie das Falsche kopiert haben. Den Application-Key können Sie vollständig aus der Liste zurücklesen, den Client-Key nicht.

Achten Sie darauf, welcher Key in welches Feld gehört. Pelican akzeptiert einen Client-Key auch auf der Verwaltungs-API, ein Vertauschen erzeugt also keinen sichtbaren Fehler. Das Präfix ist das Einzige, was sie unterscheidet. Provibr prüft dieses Präfix auf beiden Seiten genau deshalb: Die Alternative ist eine Integration, die sich scheinbar authentifiziert und sich danach eine Woche lang merkwürdig verhält.

Eine Abkürzung über die Kommandozeile gibt es hier nicht: Pelican liefert keinen Artisan-Befehl für API-Keys, beide entstehen also über die Weboberfläche.

Präsentiert das Panel ein selbstsigniertes Zertifikat, pinnen Sie dessen Fingerabdruck, statt die Prüfung abzuschalten. Ein Panel über einfaches http funktioniert, aber dann reisen beide Keys unverschlüsselt durch Ihr Netz, und ein Fingerabdruck neben einer http-Adresse wird abgelehnt, denn es gibt kein Zertifikat zum Pinnen.

Von Eggs zu etwas, das man verkaufen kann

Ein Egg ist kein Produkt. Es hat keinen Preis, keinen Namen, den ein Kunde wiedererkennt, und keine Limits. Ein Plan ist die Schicht, die das eine ins andere verwandelt: Er trägt das Egg, das Docker-Image, den Startbefehl und die Ressourcengrenzen, die ein Server bekommt.

Zwei Details, die beim Setzen der Limits überraschen:

• Arbeitsspeicher, Festplatte und CPU akzeptieren 0 für unbegrenzt.
• Das CPU-Limit zählt in Prozent eines Kerns. 100 ist ein voller Kern, 200 sind zwei. Ein als „2 vCPU“ verkaufter Plan ist 200, nicht 2.
• Das IO-Gewicht reicht von 0 bis 1000, und 500 ist der übliche Wert.

Die Regel für Pflichtvariablen

Ein Egg legt seine eigenen Variablen fest und markiert einige als erforderlich. Hier eine Entscheidung, die es wert ist, übernommen zu werden, ob Sie Provibr nutzen oder nicht:

Lehnen Sie die Bestellung ab, wenn eine Pflichtvariable leer ist, auch wenn Pelican sie akzeptieren würde.

Pelican legt den Server nämlich trotzdem an. Der Container stürzt dann beim ersten Start ab, der Kunde sieht einen toten Server, und Ihre Support-Warteschlange bekommt ein Ticket mit „geht nicht“. Ein Feld, das an der Kasse rot wird, ist eine weitaus bessere Antwort als ein Server, der existiert und nicht läuft.

Provibr liest die Egg-Liste aus Ihrem Panel, das Bestellformular bietet also die Eggs an, die Sie tatsächlich haben, statt nach einer Nummer zu fragen.

Wo ein Server landet

Pelican meldet, wie viel Arbeitsspeicher und CPU jede Node hat und wie viel davon bereits vergeben ist. Eine vernünftige Brücke nutzt beides: Ein neuer Server geht auf eine Node, die Platz für ihn hat, und wird mit einer Begründung abgelehnt, wenn keine Node welchen hat.

⚠️ Die Zahlen, die das Panel meldet, sind Buchhaltung, keine Messung. Sie addieren die Limits der Server auf einer Node, auch die derjenigen, die noch installieren. Eine Node kann deshalb voll aussehen, während tatsächlich wenig läuft.

Das ist kaufmännisch relevant. Wenn Sie überbuchen (und das tun die meisten Gamehoster, denn ein Minecraft-Server mit zugewiesenen 4 GB nutzt selten 4 GB), dann stoppen Sie Pelicans Zahlen weit früher als Ihre Hardware. Planen Sie Ihre Node-Budgets also nach dem, was Sie verkaufen wollen, nicht nach dem, was die Maschine physisch trägt.

Was der Kunde tatsächlich anfasst

Bei einem Gameserver ist die Konsole das Produkt. Befehle, beitretende Spieler und die Logzeile, die einen Absturz erklärt, wohnen alle dort. Pelican hat eine echte Konsole, und Provibr reicht sie über dieselbe ausgehende Verbindung an den Kunden durch wie alles andere: kein separater Port, kein zweiter Login, kein zweites Passwort zum Zurücksetzen.

Dateien, Backups, Datenbanken und Zeitpläne bleiben in Pelican. Das ist Absicht: Es sind Panel-Funktionen, und sie in einer zweiten Oberfläche nachzubauen gibt Ihren Kunden zwei Orte, an denen die Wahrheit stehen könnte.

Ein bestehendes Panel mitnehmen

Betreiben Sie Pelican bereits mit zahlenden Kunden, müssen Sie nichts neu aufbauen. Server, die außerhalb der Brücke entstanden sind, bleiben unangetastet; Sie importieren sie, damit sie in Ihrem Dashboard erscheinen und auf Ihre Kapazität zählen.

Der Import fasst den Server nicht an. Er beginnt nur, ihn zu zählen. Bis Sie ihn importieren, wird er weder verwaltet noch berechnet. Sie können ein Panel also portionsweise übernehmen, in Ihrem eigenen Tempo, statt während eines Wartungsfensters.

Was hier nicht dazugehört

Seien Sie klar über die Grenze, bevor Sie dagegen verkaufen:

• Die Panel-Verwaltung bleibt in Pelican. Nodes hinzufügen, Eggs bearbeiten, Panel-Benutzer verwalten: davon zieht nichts um.
• Dateien, Backups, Datenbanken und Zeitpläne bleiben ebenfalls in Pelican.
• Pelican ist selbst noch in der Beta, und seine API ändert sich zwischen Releases. Das Panel bietet keine Möglichkeit zu erfragen, welche Version es ausführt. Ein Upgrade, das eine Antwort ändert, zeigt sich also als Fehler und nicht vorab als Warnung. Lesen Sie die Release-Notes, bevor Sie ein Panel aktualisieren, mit dem Ihre Automatisierung spricht. Das ist keine Einschränkung von Provibr, sondern eine Eigenschaft des Panels: Jede Brücke, die Sie bauen, hat sie.

Sie müssen sich nicht für ein Panel entscheiden

Die meisten Gamehoster betreiben am Ende mehr als ein Panel: Pelican für den neuen Bestand, Pterodactyl für das, was schon da war, und etwas anderes für einen Kunden, der darauf bestand. Und die meisten verkaufen daneben auch Webhosting oder VPS.

Provibr betreibt seine Controlpanels, Hypervisoren und Gamepanels nebeneinander in einem Dashboard. Eine Kapazitätszahl, ein Satz API-Schlüssel, ein Ort, an dem das Leben eines Servers festgehalten wird, unabhängig davon, auf welchem Panel er zufällig läuft.

Die nächste Seite behandelt die andere Hälfte: was mit einem Pelican-Server passiert, wenn eine Rechnung offen bleibt.