Tekton, ArgoCD and... Minecraft?
One could certainly make the argument that it's so easy to spin up a Minecraft server that using a full CI/CD solution is a little ridiculous. One could also argue that running all of this on an enterprise container orchestration platform like Openshift is more than ridiculous, bordering on ludicrous.
Go big or go home
If you think using Tekton, ArgoCD and Openshift to run a Minecraft server is a bit overkill - it is. But at the same time, Minecraft and GeyserMC (more on that in a little bit) at the end of the day are just OpenJDK apps. They lend themselves easily to containers and micro services, but more importantly they have aggressive rolling release schedules requiring frequent in-tandem upgrades.
For those who are unaware, GeyserMC is proxy service that acts as a companion to a Java Minecraft server that allows Bedrock (mobile devices, game consoles and PC) clients to connect to a Java server.
Personally, I run the standalone version of GeyserMC alongside a plain Jane vanilla Minecraft Java server. I've been hosting a Minecraft server in one capacity or another since around the time the game first came out that I've more or less continually updated. If you've ever hosted a Minecraft server for any length of time, you're aware that Minecraft gets updated every few weeks or so which creates a cat and mouse game of updating clients and plugins.
GeyserMC (and GeyserConnect before it) have always been a particular challenge as development of Geyser always lags a little bit behind Minecraft releases. Thankfully these days, GeyserMC is shipped as a .jar file with updates usually being available a day or two after a new version of Java Minecraft drops. Back when I was still running GeyserConnect, I used to have to pull in the source code and compile it with Maven.
Automating Building Minecraft
As for updating my Minecraft server itself, that's always been a manual process because Mojang do not expose any public APIs to access new server builds and the website you download the server .jar from (https://www.minecraft.net/en-us/download/server) cannot be accessed by any scriptable methods, eg; curl, wget (probably intentionally). Not only that, but the server filename changes with each release. Eventually, I got sick of manually downloading the Minecraft server and building a new container image every few weeks so I decided to automate the process once and for all. I did run the itzg/minecraft-server Docker image for a while but I'm not a huge fan of running random container images from Docker hub on Openshift, plus it tended to lag a little bit after new versions of Minecraft would be released.
While Mojang do not expose any public APIs, it didn't take too much effort to reverse engineer the how they publish Minecraft builds. There's one URL that publishes a list of links to individual build repos in a long .json list, which in turn links to the .json list for the build artifacts of each version.
Below is the whole script in its entirety. The first variable reads the .json file for the first release version of Minecraft on the list (my first attempt just grabbed the latest version which also included snapshots as well as releases which ended up breaking my Minecraft server world). Then the second variable sets the location of the latest server.jar file, and finally the file is downloaded with curl. I tried a couple of different methods within Tekton but ran into weirdness with escaping single and double quotes. Ultimately I ended up having to build a custom image including the curl and jq commands and then just using that as the base image in a git-cli task. A little hacky, but it gets the job done.
#!/bin/bash
MANIFEST=https://launchermeta.mojang.com/mc/game/version_manifest.json
LATEST=$(curl -s $MANIFEST | jq -r '.versions[] | select(.type == "release") | .url' | head -n 1)
JAR=$(curl -s $LATEST | jq -r '.downloads.server.url')
curl -o server.jar $JARThe entire pipeline consists of 5 simple steps:
- generate a build ID. This is used to tag the resulting container image
- Git clones the repo containing my Dockerfile and files needed to build the image
- A custom git-cli task pulls down the Minecraft server.jar
- Buildah builds the new image and pushes it to my registry
- git-cli updates the deployment.yaml and pushes the changes back up to git
After which, ArgoCD picks up the changes and syncs the application, completing the "CD" (continuous delivery) portion of this CI/CD pipeline.
Automating Building GeyserMC
Building GeyserMC follows more or less the same steps as building my Minecraft image. They're both just OpenJDK apps that run a .jar file. The biggest difference is that Geyser-Standalone.jar is always available at the same URL, so I can just download the latest build with a simple wget task.
Although I can't solve the problem of the lead time between when a new build of Minecraft is released and when a new version of Geyser is released, and thus be able to connect Bedrock clients to my Java server (since Bedrock clients are for all intents and purposes always on the latest version), but at least now when a new version of Geyser is released, I can update both Minecraft and Geyser with zero effort. Literally just kick off the pipelines and a minute or so later the pods restart on the latest versions.
