Gameye

Containerizing your game server

Build Flow

Requirements

  • A working game server executable that runs on Linux
  • An automated build pipeline such as Jenkins or CircleCI.
  • Linux or Windows build machine with Docker installed.
  • A Pro or Teams Docker Hub account. (hub.docker.com/pricing)

Choosing an Operating System

We can support any Linux flavor if needed, but currently, we recommend choosing an OS from the list below as our packages are pre-build for these releases. Please contact [email protected] if your flavor of choice isn't on the list.

Ubuntu 16 LTS
Ubuntu 18 LTS
Debian 9
Debian 10

Preparing the build

Your build pipeline should produce a game server executable including all files and dependencies that are required for the game server to start successfully, such as third-party libraries like Steam or anti-cheat services.

Set the entrypoint

The entrypoint refers to the executable that will be started when a container is booting up.
In this case, we won't point directly to the game server executable but to a tool called igniter.

The igniter can be seen as a wrapper that controls the game server state. It can react to log output in STDOUT by the game server and write dynamic config files to disk before the game server starts

It's opensource and can be found on Github

https://docs.docker.com/engine/reference/builder/#entrypoint

Dockerfile

Docker builds images by reading instructions from a Dockerfile. A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image.

Please see our example Dockerfile on how to include the server files

Building the game server image

Build the Docker image:

docker build -t <repository>:<tagname> <path-to-dockerfile>

You can also build an image with multiple tags:

docker build -t gameye/example-game-image:master -t gameye/example-game-image:v2.1.4 .

It's required to push an image with a unique version tag, we recommend using your internal build number for this.

Pushing the game server image

Before we can push images to a Docker Hub repository we first need to authenticate.
This is done via docker login:

docker login --username --password

More information about this can be found here:
https://docs.docker.com/engine/reference/commandline/login/
https://docs.docker.com/docker-hub/access-tokens/

Push the image to Docker Hub:

docker push gameye/example-game-image:<tag>

As the image can be several or even tens of gigabytes big, it's recommended to run on the image push job on a machine with a high-speed upload connection.

Sending a build notification

When a new image has been pushed Gameye needs to be notified that a new image has been build and is ready for distribution.

For Docker Hub, you can add the following webhook URL: https://image-updater-docker-hub.gameye.com/webhook

When the first server has been populated with the new image this automatically considered the new "live" version of the game. A image of 5GB takes around 1-3 minutes to be downloaded and extracted,
depending on how close they are to the CDN endpoints.

Image Permissions

When the image is pushed successfully to Docker hub we need to set up access management so that Gameye is able to pull the image.

For this, first, you need to create a team. When you have a team, you can add Docker hub accounts to it. Next, the team needs to have permission to access the repository. Read-only permission is sufficient.

Please contact [email protected] to request the Gameye Docker accounts that need to be added to the team.

Separating development and production builds

Separating development and production builds can be accomplished by setting up two different Docker repositories and pushing the different builds to their respective repo.

Example repository layout:

organization/example-game-prod
organization/example-game-dev

Gameye will supply a separate gameKey and API token the second repository.

Updated 3 months ago


Containerizing your game server


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.