Setup using GS2-Deploy

Setup using the management console is attractive because it is easy to perform.

However, you must despair when you receive an order to “create another of the same environment”. Game development typically requires multiple server environments: a development environment, a test environment, and a production environment.

It is impossible to configure GS2 in each of them by repeating the same operation in the management console without making mistakes.

GS2-Deploy

GS2 provides GS2-Deploy, a microservice for creating environments.

If you are a cloud-savvy engineer, you can understand the role of this microservice simply by saying that it is the GS2 version of Cloud Formation provided by AWS. If you are, you don’t need to read any further; GS2 can orchestrate microservices using Cloud Formation-like functionality.

If not, don’t worry. We’ll start explaining GS2-Deploy in detail here.

Infrastructure as Code

We hope you already understand the folly of using the admin panel to mirror your configuration to GS2. To combat this folly, various improvements have been made in the world of server infrastructure.

The result is Infrastructure as Code (IaC).

Twenty years ago, infrastructure engineers who needed to spin up a new server would build the environment by typing commands into each server. Install the HTTP server, update the HTTP server configuration file, install the database server, register the schema in the database. This work is fine for one server, but what about setting up 100 servers?

It could take a week to set up 100 servers, but some of them would not work because of misconfiguration.

In 2006, Amazon launched the Elastic Compute Cloud, the foundation of the modern cloud, and instead of waiting months after placing an order for a server to be delivered, servers were available 5 minutes after the order was placed. This was a game changer in the world of server infrastructure.

In the past, we had months of lead time for hardware, so we could fake inefficiency by spending a week setting up the server and fixing any bugs. But then people realized there was something wrong with taking a week to set up a server when you could get one in five minutes.

So they became motivated to automate the server setup process and reduce the time spent on setup. The result is IaC, which encodes the server setup process. With IaC, server setup times are fast and accurate.

IaC Approaches

There are two approaches to IaC. The first is imperative and the second is declarative.

The imperative approach is based on the idea of automating the setup process by running a list of commands such as “apt install httpd”. This is a straightforward idea when trying to automate setup procedures that were previously done by humans.

The declarative type specifies that “a web server is needed”. At this point, you are not thinking about the steps required to create a web server. So which of these two approaches do you think is better?

The best way to judge the superiority of the two approaches is to give a practical example. You are responsible for a service with 100 servers. However, the service has a declining number of users, and you are asked to cut the number of servers in half. You keep 50 servers and shut down the other 50.

Six months later, the service is doing well and requires that the 50 servers that were shut down be brought back up to 100 servers. Now, the servers need to be brought up to date after being turned on for the first time in six months, and this is where the difference between imperative and declarative becomes clear.

The imperative type does not know how far it has come since the last execution, On the other hand, with a declarative type, if you know the difference between the current state and the newly declared state, you can update the server to fill in the difference.

GS2-Deploy implements a declarative type IaC by referring to such past cases.

Templates

GS2-Deploy declares the state required for each GS2 microservice in a template file, which can be applied to build the environment. Let’s use the template file as it is to create a resource in GS2-Inventory through the Management Console.

GS2TemplateFormatVersion: "2019-05-01"
Resources:
  InventoryNamespace:
    Type: GS2::Inventory::Namespace
    Properties:
      Name: test

  InventoryMasterData:
    Type: GS2::Inventory::CurrentItemModelMaster
    Properties:
      NamespaceName: test
      Settings: {
        "version": "2019-02-05",
        "inventoryModels": [
          {
            "name": "inventory",
            "initialCapacity": 5,
            "maxCapacity": 10,
            "itemModels": [
              {
                "name": "Potion",
                "stackingLimit": 99,
                "allowMultipleStacks": true,
                "sortValue": 1
              }
            ]
          }
        ]
      }

This completes the template for creating a namespace named test and registering master data. You can build your environment by uploading this file to GS2-Deploy, so you no longer need to be afraid of creating a new environment.

Updating

GS2-Deploy also behaves wisely in the update process. GS2-Deploy detects differences between the last uploaded template and the newly uploaded template.

• If find new resource, it creates a new resource.
• Delete if remove resource.
• Update if something has changed.

This behavior allows a single template file to be edited by many developers without causing problems.