Community discussion and support for fabianvf/game-server-operator. Currently focused on Minecraft. Roadmap located here: https://github.com/fabianvf/game-server-operator/issues/5
if my kubecon talk is accepted I'll probably be able to get a week or two of work time, which should be enough for most of the implementation as long as the design is shored up
@itzg hey, sorry been doing a lot of firefighting recently. Just looking at picking up the minecraft stuff again now, working on slimming down/cleaning up the CRD. Got an updated version of the
MinecraftServer CRD up, curious if you had any thoughts about the options exposed?: https://github.com/fabianvf/game-server-operator/pull/8/files#diff-13d87b9e4187945561e84595b4f55190R1 . Also added a new field that allows the user to specify arbitrary environment variables to be applied to the minecraft deployment, which serves as both an escape hatch and a way to easily move from running the container by hand/existing deployment objects/docker-compose to the operator without having to manually translate all of your options to the CRD. Once the CRD API is nailed down implementation should be pretty easy
I was afraid I would forget, so I already looked at the options there. Looks good. In
mods I would suggest including forgeVersion since I see people mention that in their issues/questions
@itzg yeah, I tried to make the mod variables a little more generic since there was a lot of shared semantics, so I made the
mods.modLoaderVersion variable https://github.com/fabianvf/game-server-operator/pull/8/files#diff-13d87b9e4187945561e84595b4f55190R138 which I was going to map to the variable matching mods.serverType. Perhaps that's unnecessary complexity for the sake of brevity though
my other idea was to create
forgeSettings/spigotSettings/paperSettings etc
Perhaps I can make it so that rather than specifying server type and some settings, you can just say
mods:
forge:
version: X
modpack: https://X.Y.Z/modpack
...
bukkit:
...and I can pick up the server type from that, while also allowing only a single entry to be specified
well that example is invalid obviously, but pretend it's two examples, one with forge, one with bukkit
in the case where they just want the default version of forge and no mods (not sure why, but maybe doing manual installs) an empty
forge: {} object would suffice, right?
if you see any fields in there that you think can be removed, because they can be automatically inferred due to the kubernetes environment, because there is a best practice that we should enforce, or because they are so niche an option that the envvar escape hatch is enough, definitely comment on those. My minecraft server administration experience is sparse so I have a hard time telling which options are important and which aren't
and yeah,
forge: {} should work fine
not sure why that reminded me, but I do have a Bedrock supported image too
https://hub.docker.com/r/itzg/minecraft-bedrock-server
would be interesting if that could be blended into the same CRD
https://hub.docker.com/r/itzg/minecraft-bedrock-server
would be interesting if that could be blended into the same CRD
but that might get too "polymorphic" so totally just a thought to throw out there
Does it work behind bungeecord?
well if they're similar enough we could definitely look at blending it in, though if it doesn't work behind bungeecord the networking layer is going to be quite different, since I was looking at using the bungeecord kubernetes plugin we were discussing a while ago for any deployed server. Alternatively, maybe always putting a proxy in front is a bad idea
yeah,
SERVER_NAME is the correct variable
have you had any experience rolling out minecraft servers? I assume if I start two servers looking at the same directory, at least one of them will be very unhappy? Mostly curious because some curseforge mods can take 10-15 minutes to load, so anything that leads to a redeploy ends up in significant downtime. Wasn't sure if there was anything I could do to load up all the server mods without routing players in, until the server reports ready at which point I can safely switch
maybe there's a way to coordinate the
save-off and save-on commands to prevent the new instance from writing to world data until it's become "activated"
as an experiment could startup a container with a pre-existing
/data but mounted read only and see at which point the server complains. You'd think it wouldn't bother with tick updates, etc when no player is connected
@itzg https://github.com/itzg/docker-minecraft-server#running-a-bukkitspigot-server can both bukkit and spigot be built from source, or only spigot?
also here: https://github.com/itzg/docker-minecraft-server#running-a-server-with-a-feed-the-beast-ftb--curseforge-modpack , do curseforge and FTB differ other than that they host at different URLs?
@itzg updated with descriptions and reorganized mod configuration: https://github.com/fabianvf/game-server-operator/pull/8/commits/2f871ef1e2393bb4e158101a2c71f46fa3a619c4
I passed both -e MEMORY=8G and -e JVM_XX_OPTS="-Xmx8G" in it
@MirceaZisu your question fits better in https://gitter.im/itzg/dockerfiles , but in any case I'm not sure why you're attempting to pass both options. How do you know that it is stuck on 2G? Did you use
-e DEBUG_EXEC=true to determine that?