Terraform
We've fully adopted infrastructure as code (IaC) philosophies at Thanx and heavily leverage Terraform.
For all of our repositories, we've co-located our app and ops logic. Each
deployed Thanx service has an ops/
folder that contains the Terraform config
necessary to launch that service.
For all cross-service infrastructural resources (DNS, VPC config, etc), those live in a shared devops repository.
#
Setupbrew tap hashicorp/tapbrew install hashicorp/tap/terraform
#
Repo Structurerepo/ ops/ # contains terraform logic module/ # bulk of infrastructure logic; shared between services production/ # production-environment specific configuration sandbox/ # sandbox-environment specific configuration staging/ # staging-environment specific configuration app/ # application logic
#
FormattingWe except all Terraform configuration files to be formatted in canonical format and style. This can be accomplished by leveraging terraform fmt.
terraform fmt --recursive .
This is also expected to be asserted as part of the project's CI pipeline.
# .circleci/config.yml validate-format: machine: true steps: - *add_github_key - *restore_repo - *setup_path - *setup_workspace - *setup_terraform - run: name: Validate Formatting (to resolve, run `terraform fmt -recursive .`) working_directory: ~/project command: terraform fmt -recursive -check .
#
ChangesAll repositories are configured to run terraform plan
for any PRs. Quick
introspection into the CI results will display what (if any) infrastructural
changes are needed to be applied.
#
Branch WorkflowsEach repository that has an ops/
directory is set up with a few different
workflow branches:
ops-production
- apply production terraform planops-sandbox
- apply sandbox terraform planops-staging
- apply staging terraform plan
In addition, in order to ensure that any Terraform diffs don't go unnoticed,
upstream/master
is configured to fail CI if there are any outstanding diffs.