Incorporating a well designed suite of container images

[emil-jacero]

Have you investigated using the work from itzg?

The main project is a Minecraft docker image with a lot of tooling and features already delivered. I am thinking of using this as my first go project.

Linkt to docs and a collection of related projects: https://docker-minecraft-server.readthedocs.io/en/latest/misc/related-projects/

[JamesLaverack]

Hey, thanks for opening this issue.

Have you investigated using the work from itzg?

I did actually start out using itzg's excellent container images but decided to move away from them (see https://github.com/JamesLaverack/kubernetes-minecraft-operator/commit/3544d1f4359e1ac4dacd198183dd0158c7910c2a). The main reason is that itzg's image is designed principally to run in Docker, so it does all the heavy lifting internally. But in Kubernetes we have a lot of extra tooling we can take advantage of, so by using that we could make a more minimal deployment image and take advantage of other K8s-native tooling better.

I am thinking of using this as my first go project.

Welcome. :) I'm afraid to say that this is likely not a great choice for a first Go project. A lot of the design isn't very idiomatic, and It's not well maintained.

The other thing is that the reason I've not done anything with this in the last year or so is that I ended up deciding that there was a better way of doing most things. In the background I've been working on a rewrite that works very differently. Unfortunately that's not ready yet, and it's not written in Go either.

Perhaps I should archive this repository in the meantime? I was intending to do so when I had a reasonable v2 available. 🤔

[emil-jacero]

Ok, I can understand why you decided to change the design. I am using CUE to simplify his container stack while waiting for a v2 candidate operator. :)

Who is the target for this operator? Are there any plans to aim for "production" use?

[JamesLaverack]

Who is the target for this operator?

Mostly myself. I host Minecraft servers for myself and friends, mostly various kinds of modded.

Are there any plans to aim for "production" use?

Depends what you mean by "production". Running servers that stay up for a while? Yeah of course. Running thousands of servers across a huge cluster? I don't have the resources to test that, but I'm not inherently opposed.

[davad]

The other thing is that the reason I've not done anything with this in the last year or so is that I ended up deciding that there was a better way of doing most things. In the background I've been working on a rewrite that works very differently. Unfortunately that's not ready yet, and it's not written in Go either.

Did you end up making any progress with the rewrite? Is that the rust branch in this repo?

I'm looking in to standing up a Minecraft server or two on my k8s homelab, The operator approach seems like a great fit for Minecraft + k8s :).

[JamesLaverack]

Did you end up making any progress with the rewrite? […]

Yes actually, in a way. But not in this repo. I realised that I first needed to, much like @emil-jacero originally pointed out, build a container image that looked like I wanted it to look. I ended up writing mrpack-container. Which is a project designed to turn Modrinth modpack files into ready-baked container images. That's pretty rough, but it does the job well enough for now.

My intent is to get a bit more experience running that on K8s, just as a raw image in a pretty simple StatefulSet, before tackling the control plane again with full CRDs. But eventually I'd want to update this operator to use mrpack-container in cluster (it doesn't require a container runtime to make containers, so it can be run inside a container itself without needing docker-in-docker or other workarounds), to build images on-demand from CRDs.