Home

Running a game server inside a linux container is not an easy task. This specification is aimed at standardizing game server containers to both simplify the process of containerizing a game server, and also increase compatibility between different containers.

Version History Updated At v0.1 3/16/15 Getting Started This specification aims to be simple, and pluggable. A game server consists of a number of the components, the game server itself, a metadata file as part of the game server repository, a controller, a storage component, and watcher component. According to best practices, each component of a game server should be split into a different repository, with the primary game server residing within the main repo, although this is not enforced. Each component should be single purpose, with the main repo only serving the game server itself.

Metadata The metadata documents how the game server is created, executed, configured, controlled and viewed. The file must adhere to a json schema, to make it easy to consume by both individual users an pluggable systems. For a more detailed overview of the metadata file, it's components, and how to create one, view the metadata documentation

Storage Primarily containers are meant to be ephemeral, meaning you run them once, and delete them. In order to adhere to best practices, instead of having a container that is started, stopped, and restarted over a long period of time, the persisted components of the application are extracted to a data container. This is achieved through volume mounting, mapping a directory containing ONLY persisted data between the game server container and the data container. The data container must be started first, and then the game server started with the --volumes-from data-container type flag. This allows the game server container to be destroyed and re-created without losing any data.

A data container should have the same base image as the game server itself, however should need no scripts, applications or configuration. It exists purely to be a lightweight volume provider, and spends most of its time in a stopped state.

Here is an example of a simple data container

Main Repo The game server repository is the most complex component. This should be responsible for;

building the game server image through a Dockerfile pulling down configuration prepping directory structure and ownership writing any scripts and config files executing the game server These components should execute in series, with the game server being the last component executed. The container should only remain running while the game server is still running, this allows the orchestration platform to decide what action to take should the game server stop, as well as directly control the process and send signals to it. Most of the steps for creating the main game server repo involve implementing the metadata definition.

Dockerfile Find which linux distro is most supported or most efficient for your game server a stick with it. ubuntu is a safe bet since it is well supported.

FROM ubuntu Next you may need to install certain libraries, depending on the server:

RUN sudo apt-get update && sudo apt-get -y install lib32gcc1 lib32z1 lib32ncurses5 lib32bz2-1.0 lib32stdc++6 gdb Download your game server itself:

install teamspeak

ENV TS3_VERSION 3.0.11.1 ENV TS3_DIR /opt/teamspeak3-server RUN wget -O /tmp/teamspeak-server.tar.gz http://dl.4players.de/ts/releases/$TS3_VERSION/teamspeak3-server_linux-amd64-$TS3_VERSION.tar.gz RUN tar -xf /tmp/teamspeak-server.tar.gz -C /opt && mv /opt/teamspeak3-server_linux-amd64 $TS3_DIR Define one, or several, mount points. There can be an overlap with your storage container volumes, these define the folders provided to the controller and watcher. Persisted data will be stored in the volumes-from the data container, however should any further non-persisted state information, such as logs, need to be provided to the controller or watcher, it must be defined as a volume. The game server should also define a volume for the persisted state so the watcher and controller do not also need to mount volumes from the storage container separately.

VOLUME /opt/data VOLUME /opt/logs Expose any ports your game server uses, this helps port discovery in some cases.

expose the teamspeak ports

EXPOSE 9987/udp EXPOSE 10011 EXPOSE 30033 Define an entrypoint as a script or command that executes the steps required to launch the game server:

ENTRYPOINT ["/opt/scripts/run"] Configuration Controller Watcher Example repos Garry's Mod