Managed Game Server Hosting (Clanforge) - Zero downtime patching

You can implement zero-downtime patching by maintaining two versions of your game image. For example, one might be named Image A, and the other Image B. At any point, you’ll have one version live while you’re updating the other. Once you’re ready to deploy the updated image version, you’ll switch the live game version by switching your fleet to the profile associated with the updated build. Once the profile switch completes, Image B will be live in production, while Build A is ready for the next update.

Zero-downtime patching is possible because profiles and game versions are tightly coupled. In the above scenario, the Image A image version would have a profile named Image A, and the Image B image version would have a profile named Image B. When you want to switch your active image to Image B, all you need to do is call the Fleet Profile Switch endpoint. Once you’ve started the switch, you can check the switch status by calling the Fleet Profile Switch Status endpoint.

Zero downtime patching requirements

There are a few prerequisites for implementing zero-downtime patching. First, you must create a mirror profile and game image version pairing for each of your existing pairings. For example, if you have a branch for production, development, and staging, you’ll have two profiles for production, two profiles for development, and two profiles for staging.

Zero downtime patching workflow

Apart from the prerequisites, the zero downtime patching workflow is like the process for updating via the CLI, with the addition of the Fleet Profile Switch step. The flow comprises four primary steps:

1. Create an image update on your build machine.

2. Create a difference analysis from the update.

3. Create a new image version from the difference analysis results.

4. Switch your fleet profile to the profile associated with the game image version you updated.

We highly recommend that you test your game image on your build machine before proceeding from step one to step two.

Step 1. Deploy the update to your build machine

Once you've prepared the updated game image by uploading it to your Steam bucket, Google Cloud bucket, or AWS bucket, you’re ready to deploy the updated game image to your build machine. Deploy the updated game image to your build machine with the Image Create Update endpoint.

Check the status of the Image Create Update job with the Image Update Status endpoint. If the status returns a failed state, troubleshoot the cause of the failure, then use the Image Update Retry endpoint to retry the update.

Step 2. Create a difference analysis

After you’ve confirmed that the updated game image works correctly on your build machine, create a difference analysis (also called a diff analysis) from the updated image with the Image Diff Create endpoint.

Check the status of the diff analysis with the Image Diff Status endpoint. If the diff analysis failed, you can retry the diff analysis with the Image Diff Retry endpoint.

Once the diff analysis completes successfully, you can reject the diff analysis with the Image Diff Reject endpoint or create a new image version from the diff analysis with the Image Version Create endpoint.

Step 3. Deploy the update to your fleet machines

Once you’ve accepted the diff analysis by calling the Image Version Create endpoint with the diff ID, you can check on the status of the Image Version Create job with the Image Version Status endpoint.

The statuses (job states) of the Image Version Status endpoint are described in the table below.

Step 4. Switch the fleet profile

After the result of the Image Version Status endpoint confirms that the image version is ready, switch your start allocating servers with the Server Allocate endpoint with the Profile ID that’s associated with the updated game version. The response body should contain a success message and the Profile ID that you supplied in the request body.