Es wird mal wieder Zeit einen Technik Beitrag zu leisten … bzw. meine Erfahrungen damit.
Grundlegend hab ich für etwaige Projekte in denen ich Mitwirke immer etwas Technikarbeit im Hintergrund. Aktuell bereite ich eine Fallbacklösung für eine Twitch Community vor, für den Fall das eine Partnerschaft mit einem größerem Serveranbieter keine Früchte trägt, bzw. die Interessen diesbezüglich auseinanderdriften. Da das Projekt eigentlich eher für die Community des Streamers als für den Stream selbst gedacht ist kommt es hier natürlich zu Problemen weshalb umso mehr die Alternative bzw. Fallback nötig wird.
Grundlegend benötigen wir ja nur den Server aber leider auch Möglichkeiten einer schnellen Administration und vor allem einem einfach Weg notfalls ein Update auszulösen.
Die Grundvorrasussetzungen sind somit klar, ein Docker basierender Ansatz der uns sofern möglich alles in einem Container oder bei bedarf das ganze in multiplen Containern anbieten kann. Auch Mods spielen mit eine Rolle bei Palworld, also sollte die Server Instanz zumindest Durchsuchbar sein, damit Files hinzugefügt werden können.
Der Erste Ansatz: War vielversprechend da er Grundlegend alle wichtigen Punkte in einem Feld zusammenfasste … Der Testlauf war ok, das alter des Docker Images jedoch fast 1 Jahr … und dann merkte ich schnell die Probleme. Das Mitgelieferte Webinterface, hat eine Standard Authentifizierung mit User Password über einen Login Seite, das Dashboard zeigt aber im ausgeloggtem Zustand auch alle Serverconfigs incl. dem gesetzten Server / Admin Passwort an … schonmal semioptimal, genauso wie der Fakt das Server Start / Stop / Neustart offensichtlich auch ohne Login funktionierten und das WI auch nicht wirklich gut aussah.
Leider war ein trennen des WIs von der Palworld Server Instanz nicht wirklich einfach, also fiel die Entscheidung das ganze zu verwerfen und uns das ganze fein säuberlich von Hand zu bauen als Zweiten Ansatz.
Palworld Server ist der Docker Container von thijsvanloef und zwar weil er einen Basic Palworld Server anbietet der auch weiterhin Updates erhält und vor allem die Dateien Lokal zugreifbar hält. Der Testlauf und Spinup des Servers verlief ohne Probleme. Inclusive Config und Pfadanpassungen für den Zielserver, würde ich sagen, lag der Zeitaufwand hier bei ca. 30 Minuten.
Als Webinterface setzen wir auf das palworld-server-dashboard von rnz01, welches ebenfalls ein Docker Container ist und uns mehr als die notwendigen Funktionen gibt um den Server ordentlich administrieren zu können. So gehört neben Server Online Check, einem Restarter und Annoncements, auch ein ausgeklügeltes Playermanagement samt Live-Karte zur Verfügung. Die Einrichtung war auch hier relativ straight forward und nach ca. 5-10 Minuten erledigt.
Das ganze hab ich dann auf dem Zielserver für einen Abschlusstest deployed und musste erstmal feststellen das zum einen mein Portainer macht was es will ( und das war garnix , weil es keine Verbindung zur lokalen Docker Instanz mehr bekommen hat ) und zum anderem der Reverse Proxy meines Servers mich dem Wahnsinn nahe gebracht hat.
Nach einem Update von Portainer auf die aktuellste Version und etwas gefummel mit den HTTP(S) Ports, hat das ganze dann funktioniert.