Pelican statt Pterodactyl: warum ich das Panel gewechselt habe

Für den geplanten Umbau brauchte ich ein Panel, das Container verwaltet. Aus der Spielserver-Welt kenne ich Pterodactyl seit Jahren — ein Panel, das genau das tut: Dienste in Containern betreiben, mit Ressourcengrenzen, Konsole, Dateiverwaltung und Nutzerrechten.

Ich habe mich für Pelican entschieden, den Nachfolger aus derselben Community.

Was so ein Panel eigentlich macht

Für alle, die das nur aus dem Spieleumfeld kennen und den Nutzen für normale Dienste nicht sehen — der Kern ist:

Ein Dienst ist eine Definition. Welches Abbild, welcher Startbefehl, welche Variablen, welche Grenzen für Speicher, Rechenzeit und Speicherplatz.

Jeder Dienst hat ein Volume. Ein Verzeichnis auf dem Wirtssystem, das im Container eingehängt ist. Alles Dauerhafte liegt dort — das ist die Grenze zwischen austauschbarem Container und bleibenden Daten.

Es gibt eine Konsole und einen Dateizugriff. Man kann Protokolle live sehen, Befehle absetzen und Dateien bearbeiten, ohne sich auf die Maschine zu verbinden.

Es gibt Nutzer und Rechte. Jemand kann Zugriff auf genau einen Dienst bekommen, ohne die Maschine zu sehen.

Es gibt Sicherungen und Zeitpläne — pro Dienst, ohne eigene Skripte.

Das ist genau die Liste von Dingen, die ich mir für meine Webdienste gewünscht hatte. Dass diese Panels aus dem Spieleumfeld kommen, ist historisch — die Aufgabe ist dieselbe.

Warum der Nachfolger

Pelican ist im Kern eine Neuentwicklung derselben Idee, vom selben Umfeld. Drei Gründe haben den Ausschlag gegeben:

Aktive Entwicklung. Bei einem System, das die gesamte Infrastruktur trägt, ist die Frage, ob es in drei Jahren noch gepflegt wird, wichtiger als jedes einzelne Feature.

Einfachere Installation. Weniger Vorbedingungen, ein moderner Unterbau, die Verwaltungsoberfläche auf einem Framework, das ich kenne.

Erweiterbarkeit über Plugins. Der Punkt, den ich zu diesem Zeitpunkt am wenigsten gewichtet habe und der sich später als der wertvollste erwiesen hat. Ein Panel, das man um eigene Seiten erweitern kann, ohne den Kern zu ändern, ist etwas anderes als ein fertiges Produkt.

Was der Umstieg bedeutet

Jeder Dienst braucht eine Definition. Für Spielserver gibt es fertige. Für „meine Next.js-Anwendung" nicht — die muss man selbst beschreiben: Welches Abbild, welcher Startbefehl, welche Variablen.

Der Startbefehl ist eine Zeile. Und das ist eine Umstellung, wenn man vorher mit Prozessmanagern gearbeitet hat, bei denen mehrere Schritte hintereinander liefen. Alles, was vor dem eigentlichen Start passieren soll — Abhängigkeiten installieren, bauen —, muss entweder in diese Zeile oder ins Abbild.

Das Volume ist die Grenze. Alles außerhalb ist beim nächsten Neustart weg. Das klingt selbstverständlich und ist der häufigste Anfängerfehler: Etwas im Container installieren, das nicht im Abbild und nicht im Volume liegt.

Was mir Sorgen macht

Eine zusätzliche Abhängigkeit an sehr zentraler Stelle. Wenn das Panel kaputt ist, sind meine Dienste nicht weg — die Container laufen weiter, weil sie von einem eigenen Prozess verwaltet werden. Aber ich kann sie nicht mehr bequem bedienen. Das ist ein Risiko, das ich vorher nicht hatte.

Ein Panel ist eine Weboberfläche mit sehr weitreichenden Rechten. Dateizugriff, Konsole, Steuerung. Sie gehört nicht öffentlich erreichbar ins Internet, ohne dass man sich sehr genau überlegt, wie sie abgesichert ist.

Ich lerne ein neues System, während ich umziehe. Genau der Zustand, vor dem ich mich selbst gewarnt habe. Die Abhilfe: erst eine Testinstallation aufsetzen, dort mit unwichtigen Diensten üben, und erst danach das Echte anfassen.

Was ein Dienst im Panel tatsächlich braucht

Beim Übertragen meiner Anwendungen hat sich gezeigt, dass eine Definition aus wenigen Angaben besteht — und dass jede davon eine Entscheidung ist.

Das Abbild. Welche Laufzeitumgebung in welcher Fassung. Das ist der Punkt, an dem man festlegt, was verfügbar ist — und wo man später stolpert, wenn eine Anwendung mehr braucht.

Der Startbefehl. Eine Zeile. Alles, was mehr Logik enthält, gehört in ein Skript im Volume.

Die Variablen. Alles, was sich zwischen Umgebungen unterscheidet.

Die Grenzen. Speicher, Rechenzeit, Plattenplatz. Der eigentliche Grund für den ganzen Umbau.

Die Ports. Und hier lauert die Falle: Ein veröffentlichter Port ist von außen erreichbar, unabhängig von der Firewall — dazu gibt es einen eigenen Eintrag, weil ich es auf die harte Tour gelernt habe.

Was mir am Panel-Ansatz am besten gefällt

Nach einiger Zeit im Betrieb ist es nicht die Oberfläche, die den Unterschied macht, sondern eine Eigenschaft dahinter: Jeder Dienst ist gleich aufgebaut.

Vorher hatte ich für jede Anwendung ein eigenes Verfahren — teils Prozessmanager, teils Systemdienst, teils Container, mit unterschiedlichen Wegen für Protokolle, Neustarts und Sicherungen.

Jetzt gilt für alles dasselbe: Ein Dienst hat ein Volume, einen Startbefehl, Grenzen, eine Konsole, Sicherungen. Ob darin eine Webanwendung, ein Spielserver oder ein Datenbankdienst läuft, ändert an der Bedienung nichts.

Der Wert davon zeigt sich nicht am ersten Tag, sondern beim zehnten Dienst — und bei jedem, den ich neu anlege. Einheitlichkeit ist keine Schönheit, sondern die Voraussetzung dafür, dass man ein System bedienen kann, ohne über jeden Teil einzeln nachzudenken.

Der Plan

1. Neue Maschine, Panel installieren, alles Neue nur dort.
2. Einen unwichtigen Dienst umziehen und zwei Wochen laufen lassen.
3. Die Webseite umziehen — sichtbar, aber verkraftbar bei Ausfall.
4. Zuletzt Bot, Verwaltung und Datenbank, in einem Rutsch, weil sie zusammengehören.
5. Alter Server bleibt vier Wochen stehen.

Ich schreibe das hier auf, damit ich mich später daran messen kann. Meine Erfahrung mit solchen Plänen sagt, dass Punkt 4 der ist, bei dem es interessant wird.