Terraform modules for infrastructure

Containers to run this: https://hub.docker.com/u/dfdsdk

• main.tf
• outputs.tf
• vars.tf

We recommend a folder structure for Terraform modules like so:

module-category
 └ module-name
    └ README.md
    └ main.tf
    └ outputs.tf
    └ vars.tf

Example:

security
 └ iam-account-alias
    └ README.md
    └ main.tf
    └ outputs.tf
    └ vars.tf
 └ org-account
    └ README.md
    └ main.tf
    └ outputs.tf
    └ vars.tf
network
 └ ...

Branch protection is not enabled on this repo. Instead we rely on release tags to ensure we do not commit straight to production.

When creating a new release, it's important to ensure only the intended changes are included, not changes others may have committed to master without also creating a release.

Before creating the release, you should compare the commit you want to release against the latest release, and ensure only intended changes are included.

In this example, I am comparing the lastest release (0.1.35) against the commit I plan to release (75bec8f).

https://github.com/dfds/infrastructure-modules/compare/0.1.35..75bec8f

The general structure of these modules, file layout etc. are largely based on Gruntwork's recommendations. More specifically the blog posts:

• Gruntwork blog: How to manage Terraform state
• Gruntwork blog: How to create reusable infrastructure with Terraform modules
• Gruntwork blog: How to use Terraform as a team

Gruntwork's example repos, of both modules and live/input data, along with their README files have also proven very useful:

• Github: gruntwork-io/terragrunt-infrastructure-live-example
• Github: gruntwork-io/terragrunt-infrastructure-modules-example

To workaround some of Terraform's quirks and shortcomings:

• Gruntwork blog: Terraform tips & tricks: loops, if-statements, and gotchas

Other inspiration:

• https://www.ybrikman.com/writing/2017/10/13/reusable-composable-battle-tested-terraform-modules/