feat(deploy): login-limbo and lobby images with game-port pinning
deploy/limbo assembles LOOHP/Limbo from its loose CI artifacts plus the felis-limbo plugin (and the shared link core), with an entrypoint that pins server-port to the operator's GamePort (25565) on every start. deploy/lobby carries the Paper + felis-paper hub image. .dockerignore re-includes plugins/limbo and plugins/shared so the plugin image build sees them.
This commit is contained in:
6 files changed
+361
-1
No files matched your search
@@ -0,0 +1,31 @@
|
||||
#!/bin/sh
|
||||
# Felis login-limbo entrypoint.
|
||||
#
|
||||
# Pin Limbo's game port to the pod-facing port the operator contract uses. LOOHP/Limbo
|
||||
# defaults server-port to 30000, but the Felis operator drives everything — the Service
|
||||
# Port/TargetPort, the TCP/HTTP readiness probe, the container port and the Velocity
|
||||
# NetworkPolicy — off a single GamePort const (25565). A backend that bound 30000 would
|
||||
# be unreachable through that fence. Limbo writes a full server.properties on first run
|
||||
# and merges any partial we leave in place, so seeding/patching just server-port here is
|
||||
# enough; the spawn schematic still loads from ./spawn.schem.
|
||||
#
|
||||
# Idempotent by design: it runs on every start and rewrites only the server-port line,
|
||||
# so a persisted world volume that already carries a server.properties keeps all its
|
||||
# other settings.
|
||||
set -eu
|
||||
|
||||
PORT="${FELIS_GAME_PORT:-25565}"
|
||||
PROPS="server.properties"
|
||||
|
||||
if [ -f "$PROPS" ]; then
|
||||
if grep -q '^server-port=' "$PROPS"; then
|
||||
sed -i "s/^server-port=.*/server-port=${PORT}/" "$PROPS"
|
||||
else
|
||||
printf 'server-port=%s\n' "$PORT" >> "$PROPS"
|
||||
fi
|
||||
else
|
||||
printf 'server-port=%s\n' "$PORT" > "$PROPS"
|
||||
fi
|
||||
|
||||
echo "felis-limbo: pinned server-port=${PORT} (operator GamePort)"
|
||||
exec java -jar Limbo.jar --nogui "$@"
|
||||
Reference in new issue
Block a user