Reading Time: 9 minutes
The last 12 months have seen some exciting Docker developments for game servers.
The core product has become significantly more mature, the user base has grown considerably, and a number of advanced features have emerged solving many of the core barriers to containerization of game servers and other opinionated applications. We’ve also seen a number of exciting new products and hacks showcasing some of the wilder potential pairings of container technologies and game servers.
As a software engineer with a passion for gaming, I work on gaming-related projects in my spare time. I also talk about game server automation when I have the opportunity. In this article I’ll take a look at how the last 12 months in the Docker world have impacted game servers and the gaming world in general.
While Docker has been widely embraced in the world of web services, adoption has been much slower in the the gaming industry.
Traditionally this industry has been highly focused on deadlines and deliverables rather than reusable code, developer experience, or codebase longevity. This kind of deliverable-focused development promotes innovation but primarily within the context of the core product. As such, the gaming industry has been hugely innovative when it comes to its core strengths — AI, rendering, physics, distributed simulation and prediction, etc. — but spearheads far fewer new technologies amongst what would be fringe or incidental services.
Because of this, the web services industry tends to pull ahead in areas like public APIs and tooling, container technologies, and new languages and frameworks. Coupling that with the typical closed-source, compiled product in the gaming industry, it becomes clear as to why Docker and other container technologies have not flourished, despite the obvious suitability. Containers assist in solving many issues common to many industries, especially those issues critical to game servers, such as portability, dependencies, and resource control.
This is not to say Docker has not found its way into the industry. Improbable.io has been using Docker for some time to power their simulation platform, and earlier this year, EA had a great talk on how they are using Docker. Both are cases of Docker being used to host game servers, but for a hosted, highly automated platform.
Thomas Shaw also gave a fantastic talk at DockerCon 2015 on using Docker to drive cultural change. Demonware uses the Docker toolset as part of their development pipeline to aid in supporting long-running projects and reduce problems with the wide range of dependencies across projects. This was a great example of using Docker in a very approachable and widely applicable way, regardless of what the end product or hosting solution might be.
Current Barriers to Game Servers in Docker
As we’ve seen, Docker is being adopted within the games industry in cases where generic workflows can be applied, or where the application is exclusively run in a centralized, highly automated hosted environment. These inroads mean great news for game servers as a whole, which stand to benefit significantly from adaption to suit containerization.
Currently, game servers come in several flavors:
- Exclusively hosted. Companies like EA make it far harder for groups to run their own game servers, but they do provide a decent pool of servers for gamers to use for public and private matches. This homogenous game server environment means that containerization is simple to adopt and allows game servers to be highly automated. It does not leave a lot of room for innovation via mods and custom game modes.
- Unhosted. When large scale multiplayer is not a feature of a game, quite often one of the few gamers act as host for a short time, removing the need for a dedicated game server. In this case the server is often integrated into the game client itself, making any containerization an issue. Since the game is locally hosted, gamers do tend to have much more control over content.
- Mixed. In most cases, game servers come with a dedicated server that users can run, but a pool of official servers is provided by the developer to safeguard the players’ experience of the game. With a dedicated server, a user can host in any way they see fit, which is where the option of containerization comes in. This is the sector we’ll be focusing on.
These different usage patterns greatly affect the type of game server administrator. Obviously, in a hosted environment, this is most likely a team of devops backed up by automation running a significant number of servers.
When a dedicated server is available, the user base becomes a lot more diverse. Along with the typical hosting platforms, either by the developer itself or in an independent organization, you often find smaller gaming groups and clans hosting just a few servers, either on a platform or independently, as well as individual gamers running servers, often on a temporary basis.
Skill levels across these groups change dramatically, which greatly affects whether technology like Docker is adopted. The simpler the setup and the lower the technical experience of the admin, the less likely that user is to use nonstandard hosting methods like containerization.
Adding to that, the diverse technical nature of game servers makes it clear why Docker is not a common component. Given the complex ways that different game servers are architected in terms of persistence, configuration, and network, it becomes clear that game servers simply add some limitations to containers.
While many of the dependency-related issues are perfectly solved simply by using containers, other issues are not as easy to solve. Often IP addresses much travel with a game server in order for it to be favorited by users, and the idea of providing high-availability features as part of a game server is often far from the mind of the developer.
These issues around standardization, complexity, and understanding make it clear why there is less of a drive to host game servers in containers. Despite this, some of the earliest container images are hobbyist implementations of Minecraft and other game servers.
Containers do solve many common issues, such as isolation, resource control, speed, and portability just as well for game servers as they do elsewhere. Much of the game server hosting industry is driven by the speed/cost metric, represented as a cost per slot value. The potential efficiency and speed of containers makes containerization a great candidate for this industry, but barriers to adoption have thus far prevented widespread usage.
The Most Disruptive Docker Changes in 2015
In the last 12 months, there have been many changes in the core Docker product and elsewhere, which will have huge impacts in terms of the containerization of game servers.
Arguably the most dramatic addition from this year was support for CRIU, perfectly showcased in the Quake migration demo from DockerCon 2015.
This gave an early example of how using CRIU as part of your container infrastructure would allow the live migration of running opinionated applications, with minimal interruption. CRIU should be making its way into the core Docker feature set through the base runC library.
Since CRIU preserves memory, processes, and even open sockets, it should be widely compatible with different game servers, as well as many other types of application. This means most modern game servers could simply be moved from one host to another, even across datacenters, with the expectation that connected users would remain connected, although with some expected lag.
Obviously this is a substantial change for most game servers, where clustering and other typical features of larger web services are unsupported, and would heavily depend upon the network architecture of the relevant server. As such this may not be compatible with many game servers out of the box.
Weave, Calico, and other container network technologies have been around for some time. However, with the addition of the Docker plugin framework, these will be far more accessible. Volume plugin support is also significant, but persistence is generally far less central to the functionality of a game server.
Many game servers self-register with a master server list and report their IP address along with port automatically. This allows clients to automatically locate and connect to game servers, however it assumes a simply architected network stack and is not compatible with the container paradigm.
Through the use of network plugins, we can use advanced routing methods to make container IPs first class within the infrastructure. That would not only make dynamic routing much simpler but also give the added benefit of allowing an IP address to be attached to subsequent instances of a game server as it is migrated across the stack. This is critical as in many cases the server favoriting method used simply involves storing the IP and port from the connection info.
Most importantly, by using Docker network plugins, it is possible to add the CRIU feature set to a far wider list of game servers with more complicated network architectures.
Rancher and SpotInst
In November, Rancher announced SpotInst integration. This integration abstracts the complexities of using a service like SpotInst to host infrastructure of any kind, which is great news for a hosting industry as driven by the bottom line as the game servers industry is.
AWS Spot Instances and Google Preemptible VMs both use spare cluster capacity on a temporary basis and reserve the right to revoke and remove the VM on very short notice. Hosting with a poor uptime guarantee is generally a cheap and convenient fit for game servers, since very few servers have an expectation of high uptime. Restarts and frequent disconnects are in many cases part of the norm.
With SpotInst integration, Rancher users gain the ability to host containers on a Docker cluster comprised of dynamic spot instances, without introducing the complexity of managing container migration and host replacement.
This Docker mod for Minecraft was showcased at DockerCon EU. Gaming related talks and hacks are always popular, and this was no exception. In the spirit of Docker Doom, this mod allows users to create and control containers using blocks within the game itself.
It’s always fantastic to see new ways of integrating and controlling complex systems. Personally, I can’t wait to see a Space Engineers mod, although the practical uses of this type of mod are somewhat limited. In terms of game servers, this makes it easier for the principles of containers to be taught to a game-focused audience via a relevant medium.
What Does This Mean for 2016?
Clearly, adoption is increasing in the games industry, and both the Docker product and the container ecosystem are evolving in ways that greatly benefit game servers. We can fully expect to see many more large-scale, self-hosting companies to join EA in using Docker as part of their platform, as well as games development teams to continue integrating Docker into their development workflow.
What I think will be far more interesting to watch will be the effect that CRIU, SpotInst, and the network plugins have on the public game server hosting industry as a whole. These are highly disruptive features in a highly competitive market, but there are still a number of obstacles to wider adoption.
Docker has a high learning curve
Many game server admins come from a Windows-only environment, and most only know enough about server administration and hosting to get their server up and running. Windows support is already greatly reducing this curve, and tools like Dockercraft help introduce people to the core concepts.
No two game servers are the same
Different game servers have different application and operating system dependencies, and Docker is a perfect tool to solve this.
While this does generalize solving application dependencies, there is still significant divergence in the way different game servers are operated. Some have interactive consoles and write secrets to stdout. Different servers use different configuration methods and have different components requiring persistence.
The vast majority of game servers are closed-source applications, and by default are not particularly easy to containerize. Implementing community requested changes with the aim of standardization can be extremely difficult.
As Docker achieves much wider adoption in the gaming industry, hopefully this will push game server implementations into a much more compatible form.
Over the next year, we can expect to see improvements in all of these areas. More Docker tooling and custom container services will help to reduce the learning curve, and game servers should move toward a container-compatible design as larger companies adopt containers.
The lack of current standardization and usability do remain significant barriers to widespread adoption, which can be improved through tooling and abstracting the common containerization issues with game servers. This is something I am personally working on reducing with my gscs project, a container specification aimed at reducing the complexity in containerizing different types of game servers.
With sufficient standardization and Docker cross platform compatibility, we could even see containers become the standard distribution of dedicated game servers in the future! What changes are you most looking forward to for game servers this year? What do you think will be disruptive to the industry and when? Which projects do you think will have an impact on game server hosting and gaming in general?
I look forward to what the next year will bring in the world of game servers. The time is ripe for containers in gaming.