Tag: kubernetes

Show the world: gameserver.express

(Currently servers in Germany only. Helsinki as a backup. But this will change very soon!)

If you’ve been looking for a way to host game servers without burning money on unused server time, you might want to check out what I’ve been working on. After a couple years of development, gameserver.express is finally live and working 🙂

The Problem with Traditional Game Server Hosting

Here’s the thing – most game server hosts charge you monthly. Doesn’t matter if you play 2 hours or 200 hours. You’re paying for the whole month. That never made sense to me, especially for games you only fire up on weekends with friends.

When I was looking for a Valheim server with pay by the hour back in the day, i did not found any solution. So I started working …

Pay-Per-Hour: The Easy Solution

gameserver.express uses a pay-per-hour billing model. You spin up your server, play with your friends, shut it down when you’re done. You only pay for the hours you actually used. Simple as that.

The cost calculator on the site lets you see exactly what you’d pay. For example, if you play Valheim for 20 hours a month, you’re looking at a couple euros instead of 15-20€ monthly fees elsewhere. The math just works out better for casual gaming sessions.

Focus on Coop Games

The platform focuses on cooperative multiplayer games – stuff like Minecraft, Valheim, Palworld, Satisfactory, Terraria, 7 Days to Die. Basically games where you and your friends build, explore, or survive together rather than compete.

These games are perfect for the per-hour model. You don’t need a server running 24/7. You want it up for your gaming night, then off until next week.

How It Actually Works

You pick your game, select your server specs, and it spins up in a few minutes. When you’re done playing, you stop the server. The interface shows your running time and costs in real-time, so no surprise bills at the end of the month.

Servers run on proper hardware with decent CPUs. Nothing fancy, but it gets the job done. And if you found friends along the way you can easily upgrade your server to the next performance level.

Why This Took So Long

Building this wasn’t trivial. Getting the automated server provisioning right, making sure billing is accurate down to the minute, handling save files and backups properly – all of that took time. The infrastructure needs to be reliable because nobody wants their world corrupted or progress lost.

But it’s working now. This is an industry-grade setup. If you’re tired of paying for server time you don’t use, give it a try. The pay-per-hour model makes a lot more sense for how most people actually play coop games 😉

Note: I built this service because I faced this problem myself. Your gaming habits might differ, so check the calculator to see if the hourly model works for your use case.

Merge two kubernetes contexts into one config file

This was created with the help of https://coreos.com/blog/kubectl-tips-and-tricks where it is explained how you can use two contexts from two different files at once. However sadly it was not explained how to save this state to a kubernetes config file in order to get rid of the need to export every time.

So here it is:

export KUBECONFIG=emptyfile:conf1.yml:conf2.yml

kubectl config get-contexts
kubectl config view --raw=true > config

Gitlab runners with Kubernetes in (nearly) no time

Photo by chuttersnap on Unsplash

The gitlab ci/cd toolchain has become a great companion for me in the past years. Since I started using kubernetes more and more I always wanted to utilize the power of kubernetes for the gitlab runners. Furthermore I wanted to get rid of that pesky little badly secured gitlab instance and secure it with TLS (“https”) which became quite necessary later…

As always there is not much to do after you once made it work and invested an hour or two. To spare you the time, let’s get to the details.

Prerequisites

General workflow

  1. Make sure you have the proper certificates at hand: One for the gitlab nginx and (if needed) your local CA.
  2. Create a namespace for your runners.
  3. Insert the certificates as a secret in your kubernetes cluster.
  4. Modify the gitlab-runner yaml file for your needs.
  5. Use the yaml file and helm to install the runners in your kubernetes cluster.

1. Security / Certificates

For obvious reasons it is a good idea to secure the gitlab nginx with TLS. In my case I used TinyCA for local network signing, which can be obtained easily through the package manager of various distributions. But anything that will result in a certificate which works for you will do.

2. Create the namespace

Basically you can be creative here, but seriously do not name it ‘gitlab’ because that can seriously interfere with your routing inside kubernetes!

Here let’s call it runners:

kubectl create namespace runners

3. Create a secret with your certificates

The runners need to be sure that your code repository is exactly what it is supposed to be. We don’t want a man-in-the-middle. So we create a secret with the certificates. This needs at least the certificate from your nginx and in my case I even had to include the CA certificate. (So the crt file contained two BEGIN CERTIFICATE and two END CERTIFICATE blocks.)

kubectl --namespace runners \
  create secret generic gitlab-domain-cert \
  --from-file=gitlab.crt

IMPORTANT sidenote: The crt file has to be formated as in <the-full-hostname-of-gitlab>.crt . Otherwise it won’t work.

4. Modify the gitlab runner yaml file

You need to get a configuration file for your runner. (A click on ‘raw’ helps.) Next step is to modify some values:

  • gitlabUrl should be your gitlab instance url including https.
  • runnerRegistrationToken should be the token gitlab provides in its GUI = webpage runner admin settings.
  • certsSecretName has to be the name of our previously set secret: gitlab-domain-cert
  • namespace has to be runners
  • Change RBAC to your needs.
  • (optional) Personally I reduced checkInterval to 5 seconds.

5. Use helm to install your runners

With all the configuration in place, you can initiate the helm magic.

helm install --namespace runners \
  --name gitlab-runner \
  -f gitlab-helm-runner-settings.yml \
  gitlab/gitlab-runner

And you’re done 🙂