As I grow more fond to the popular opinion of containerizing applications, I realize just how beneficial the action becomes. Being able to horizontally scale deployments had never been a concept which I was familiar with as a game server developer because game servers must run in a single process.

This is no different today. However, containerizing both this website and the servers of this community will allow the infrastructure backing this community to work just as fluidly as they have before, and allow for much more extensibility for new features and servers which may have caused dependency issues before.

Until now, all of our MySQL database, django web app, Teamspeak server, and dedicated game servers were hosted on a single VPS. This worked fine, but the same cannot be said for what could have developed in the future. To understand the benefits of containerizing applications, we first must understand what it inherently implies.

Containerizing an application is almost exactly like running it in a virtual machine. You setup an environment, or in the case of docker images, an operating system, and deploy your app on that operating system to be the only thing running on it. This gives your app the same benefits as creating a python virtual environment brings to a developer with multiple apps which each have their own specific dependencies which could conflict with dependencies of other apps if they were all installed into the same site_packages directory. Other apps require specific versions of packages while other python apps require other specific versions of the same package. This is no different from any type of application that makes use of libraries on the system.

By deploying containerized apps with docker-compose, we eliminate an issue which we could have faced on a dedicated VPS, instant redeployment of the application in case of spontaneous server failure or combustion. docker-compose allows us to specify how many replicas of each application we want so that we can have dynamic load balancing based on current traffic trends, how many to keep online/offline while updating, all from an extremely readable yaml file and command line interface.

As I mentioned before, game servers can only run on one process, so there will only be a single docker container ever running for our gmod server, one for our l4d2 server, etc. but we will now be able to dynamically allocate resources to those containers as we need them with the help of kubernetes.

I hope that this change will inspire other gaming community owners to make the same switch that the majority of the dev ops industry is also changing their direction towards today.