This repo contains code (mostly terraform) for configuring all of my personal infrastructure in code. If you're interested, the terraform modules inside of terraform-modules should be well documented and usable on their own.

I have operated versions of this infrastructure at much larger scale and this repo should be laid out in such a way that you can adapt it to your needs easily.

I take security very seriously. When done properly, this project should not present a secutiy risk to my infrastructure. However, if you notice a vulnerability please email me at [email protected]

The terraform in this repo is organized in a function-specific way. This means that the terraform is separated primarily by the AWS account the the infra lives in, but also can be separated by specific functions to be managed. For example, there is terraform at terraform/aws/accounts/prod, but also at terraform/aws/common/dns. The first manages generic infrastructure in the account whereas the second manages a specific thing (DNS) in a non-specific account (prod).

As infrastructure grows I've found this to be the most scalable solution. One major problem that large terraform infrastructures encounter is the threading of outputs across many different workspaces. This organization mitigates output and remote state usage because we can manage stacks of infrastructure (such as dns or static sites) in separate self-contained workspaces.

A previous version of this repo managed terraform in a more resource-specific way. Meaning there were terraform repos for rds, vpc, etc... This type of organization does not scale as you are constantly threading outputs from vpc -> rds -> ecs -> dns. Instead these should all be handled in a single module and called from a more generic workspace.

Another issue that terraform can encounter with scale is large workspaces that manage too many different things. For example, as the prod account here grows to thousands of resources it will not be wise or easy to manage all of those resources in a single workspace. Instead expansion in that way can be segmented in a new folder structure such as terraform/aws/apps and terraform/aws/sites (for example). This lets you be as granular as needed while still keeping output management to a minimum.

This repo also managed some of my non-aws infrastructure like my GitHub and TLS repos. Terraform is a great tool for these purposes as well.

Everything in this repo is MIT Licensed and free for you to use. Keep in mind that the modules are generic but may still need customization before they work for you. For example, I do not add feature flags to configurations I do not intend on using. The modules generally enforce very strict best practices and security requirements (https, ipv6, etc...)

Also you should not depend on these modules always existing in this location or on any kind of versioning or compatibility guarantees. If you need reassurance that the module will continue to work for you then you should fork it and merge upstream changes in after you test new functionality.

You will notice that this repo uses relative references to modules instead of git references (../../module// instead of [email protected]). This is very beneficial from a speed of development perspective. Since all callers of the module are in the same repo as the modules themselves my changes can incorporate both and local testing will work without any pushes to the repo and changes to branches in the module source. However, in a serious production infrastructure you should consider referencing modules back to a git/package repo and make sure that you reference specific versions of modules.

There was a branch in this repo called atlantis that fully implemented the tool. However, there are a number of remote code execution concerns and UI access concerns that make me uncomfortable hosting Atlantis publicly. Maybe when those are resolved this will be revisted. For now I apply locally.