!!!THIS IS IN DEVELOPMENT AND INCOMPLETE!!!

I copied this from a friend's repo to repurpose it for my own needs, so his stuff is still here until I make more progress

terraria-server

Quickly deploy a dedicated Terraria server to AWS.

Steps involved to deploy your server:

1. Clone/fork this repo.
2. Modify variables.
3. Setup a few things manually in AWS (details below)
4. Commit the code to your repo (let CI do the rest).

Costs Overview

You can run this Terraria Server totally free for 12 months on an AWS Free Tier account.

AWS lets you use its services for free in three different ways:

• Free trials
• 12 months free
• Always free

Services uses in this deployment:

• AWS EC2 (12 months free)
  • Linux instance which will run the Terraria server
• AWS EBS (12 months free)
  • Storage volume for the EC2 instance
• *AWS CloudWatch (Always free)
  • For creating an alarm to monitoring billing
• *AWS SNS (Always free)
  • For receiving the alarms generated by CloudWatch
• *AWS DynamoDB (Always free)
  • For locking Terraform state
• *AWS S3 (12 months free)
  • For storing Terraform state
• *AWS CodePipeline (Always free)
  • Test our container before creating it
• *AWS Systems Manager (Always free)
  • To store some parameters

* Optional - modify the code if you don't want to use the optional services

Something I'm considering adding later:

• AWS Pinpoint
  • Mobile notifications when players join world

Pre-requisites

For both automatic and manual deployments, you'll need:

• An AWS account
  • If you want to use an AWS account you've had for more than 12 months, you will be billed for the use of EC2, EBS, and S3.
• AWS IAM user with programmatic access (access ID and secret key)
• AWS CLI already set up locally (run aws configure and enter access ID and key)
• If you want to use a remote Terraform state, you need an S3 bucket for storing it. Instead, you can also keep the state file in your repo if you'd like
  • See terraform/backend.tf
• If you want to use a remote Terraform state, you'll need a DynamoDB table to manage Terraform state locking
  • See terraform/backend.tf
• If you want to store parameters in AWS, you'll need to create them in advance in the AWS Systems Manager parameter store
  • See terraform/data.tf

For manual deployments, you'll also need to have the following tools installed:

• Packer.
• Terraform
• Ansible
• awscli

Deploy Automatically

So you want your own Terraria Server automatically?! Here's how ya do it.

Clone (or fork) and enter the repo

git clone https://github.com/willquill/terraria-server.git && cd terraria-server

Modify dependencies.tf to change the github_name variable to your own github.

Create your S3 bucket and DynamoDB table for Terraform state:

terraform apply

Change the following variables in the following files for your use-case:

• packer/amzn2-docker.auto.pkrvars.hcl

Create a CircleCI account. Connect it to your GitHub. Click "Set Up Project"

Commit the code

Deploy Manually

Clone and enter this repo

git clone https://github.com/willquill/terraria-server.git && cd terraria-server

Build your AMI

Hashicorp tutorial located here.

What we're doing here:

• Specifying your AWS account credentials
• Creating an AMI on your AWS account for the Terraria server

Export your environmental variables

export AWS_ACCESS_KEY_ID=YOUR_ACCESS_KEY

export AWS_SECRET_ACCESS_KEY=YOUR_SECRET_KEY

Initialize, format, validate, build

packer init .

packer fmt .

packer validate .

packer build .

Deploy the Terraform dependencies

From the root directory (don't be in the terraform directory):

Modify dependencies.tf to change the github_name variable to your own github.

Create your S3 bucket and DynamoDB table for Terraform state:

terraform apply

Deploy the infrastructure

Terraform note: The values you provide in terraform.tfvars override the default values in variables.tf, and the names of variables in variables.tf represent strings, booleans, and such that you use in your various Terraform resources. If you're wondering why there are even two variable files at all, it's so you can provider default variable values yet use custom values with different applies, like terraform apply -var-file="small-ec2.tfvars" and terraform apply -var-file="big-ec2.tfvars". Without specifying a var-file, if terraform.tfvars is present, Terraform will use those values. Otherwise, it will simply use the default variable values provided within input variables. So the tfvars file is optional

Enter the terraform directory and do the following:

• Modify backend.tf to use the bucket you created in dependencies.tf
• Modify terraform.tfvars to use your own values
• In the AWS Console > AWS Systems Manager > Application Management > Parameter Store, manually add the parameters used in data.tf

Finally, while in the ....hold on, I'm still writing this...

Deploy Latest Version

For a Docker environment, see the environment/docker branch

For a Proxmox (PVE) LXC environment, see the environment/pve-lxc branch

You can also see current and previous versions under Releases.

FAQ

Q: Why not used EBS-Optimized? A: Because in us-east-2, t2.micro is not available as EBS-Optimized. It's available for t3.micro, but t3.micro does not qualify in the free tier in us-east-2.

Q: Why not use the newer t3.micro instead of t2.micro? A: See previous answer. In us-east-2, t3.micro does not qualify for free tier.

Q: Why not create a VPC? A: While creating and using a VPC is free, using the NAT Gateway is not free. So I will simply use the default VPC and use a public IP address on my EC2 instance.

License

Distributed under the MIT License. See LICENSE for more information.

Thanks

• A lot of this taken from Robert's rnwood13/cloud-media-requests repo. Thanks, Robert!