Terraplay is a combination of a Discord bot (written in Go) and Terraform, designed to automate and manage game server provisioning and related infrastructure. It uses Terraform workspaces to create isolated environments for different game sessions, ensuring that infrastructure for each session is managed separately. There are two main infrastructure layers: global infrastructure and keeper infrastructure, which manage the underlying systems for Terraplay.

Keeper Infrastructure

This is the foundational infrastructure for setting up a remote Terraform backend. You need a storage solution to save the state file and a database to lock the Terraform sessions, preventing errors or race conditions.

This situation often presents a "chicken-and-egg" problem: which comes first? There are two ways to resolve this:

1. Use a local state file to provision this infrastructure.
2. Create the required resources manually via the console or CLI, then import them into Terraform for lifecycle management.

For secure authentication, you can configure OpenID Connect (OIDC) for GitHub Actions, along with an appropriate role. This eliminates the need to use access keys like access_id and secret_access_key, making the setup more secure.

Global Infrastructure

This part of the infrastructure includes the core resources, session management, and control mechanisms necessary for running game servers smoothly.

1. The first component is networking. To keep things simple, I’m using one VPC (Virtual Private Cloud) and a single public subnet. However, this can be expanded to support multiple VPCs or a VPC pool, allowing users to choose the specific VPC and subnet where they want their server deployed.
2. There is a game.yml file, which contains important details about each game, including its firewall configuration, volume paths, and other customizable properties. Currently, only the firewall is being configured, but in the future, this YAML file will enable users to have more control over their game server configurations. After parsing the game.yml, we create the necessary security groups (firewall rules) to control network traffic.
3. Key pair for SSH access to the server. For simplicity, I am using a single SSH key for all servers, though this isn't ideal for security. In a more advanced setup, separate SSH keys can be generated as needed.
4. A virtual machine (VM) that hosts the Discord bot server which orchestrate the whole flow and support various commands. The roles associated with this VM are defined to avoid using direct credentials like access_key_id and secret_access_key, opting instead for roles that provide secure and temporary access. A secret manager is set up to store the environment variables required by the bot.
5. For game data, we create a bucket that will back up the data after each game session or during the halted state of the server machine, allowing to persist the game data between server stop and restart. Additionally, a registry is established to host Docker images for the Discord bot.

Though the Discord bot is currently the primary interface for managing game servers, a CLI or web interface could be created in the future to offer alternatives. However, Discord was chosen initially for ease of use.

we create a global Terraform workspace. All infrastructure state related to the global setup is managed in this workspace, ensuring that changes and resources are tracked properly. Terraform also locks the state to prevent multiple processes from making changes simultaneously, which helps avoid errors or conflicts.