Automatic deployment of server plugin updates

12/22/2019

I am currently developing a game server network with some in-house daemons for scaling and, more importantly, rolling out updates. The structure of these servers consists of a server .jar compiled from a maven project in GitLab, and a set of plugins, also compiled from a maven project in GitLab.

What I'm doing right now to deploy updates to the plugins is making GitLab-CI drop the compiled .jars in a designated update/ folder, and I have a background process which monitors this folder and kills any servers running an outdated version of that plugin. When the server restarts, it will copy its plugins from that folder, picking up the new version.

I've been considering using a more robust container orchestration engine to provision and monitor the game servers, but I'm concerned with implementing deployment of the plugins in that environment. I've set up and configured an OKD 3.10 cluster, so I have a functional OpenShift environment available to me.

My initial thought is to have a "server" image containing the game server .jar, but I need a way of expressing the immediate dependency on separate .jar files for the plugins. There are multiple "types" of servers, each with different sets of plugins, so a single image containing everything doesn't seem like the way to go. Instead, I'm wondering how to design:

1) Some sort of pipeline from GitLab (or any other repo in general) to some cluster-reachable location from which servers can fetch the .jar files on startup

2) A way to signal some service on the cluster that such an event has happened (to facilitate killing old servers)

(Bonus 1): Currently, my "pipeline" has a loophole for rapidly pushing an arbitrary plugin .jar file to the server (FTP access to the update/ folder), to aid with quick testing on a development cluster. Setting up a similar fast-track would be ideal.

I'm not sure how to approach this in an idiomatic way on OpenShift. A PersistentVolumeClaim shared by all the server pods seems the closest to my current strategy, but if there's a simpler or more effective way to accomplish this, I'd really appreciate some advice.

-- Michael Jarrett
automation
continuous-deployment
continuous-integration
kubernetes
openshift

0 Answers