Introduction

Welcome to the Terraform Playbook for Infrastructure as Code. This playbook is split into 2 parts, covering the following:

• Enforce and Ensure TF Coding best practices are followed:.
  • Via CAW Terraform Coding Standard v1.0 Document.
  • VsCode TF extension
• Terraform CI / Automation best practices covering the following:
  • TF Fmt
  • TFSec
  • TFCost

In this playbook, we'll cover the standards to be followed while setting up your Terraform environment, writing Terraform code, managing costs & security with Terraform, and deploying and managing infrastructure with Terraform. We'll also introduce best practices for organizing your Terraform code, using Terraform modules to manage complex infrastructure, and using Terraform Lint to ensure code quality.

Setting Up Terraform Environment

To Download and install Terraform, please follow the official guide - link

General Terraform Best Practices:

• When creating Terraform code, ensure you write ONLY Modules and not standalone Terraform Scripts.

• DO NOT Copy Terraform examples/snippets from Terraform Registry or Stackoverflow, as they aren’t part of the Coding Standards document.

• Ensure TF code is written in such a way that TF modules are reusable across projects, environments, etc.

• Any TF code before the TF plan (provisioning of actual infra) should go via TF Quality gates concerning Cost, Security, Linting, etc.

• Any team/person outside CAW’s DevOps team wanting to contribute to the TF codebase should submit a pull request to the DevOps team for review.

• Ensure the TF codebase is arranged in the folder structure shown below. This folder structure provides a clear organization for Terraform projects, with separate directories for each project and version. Here's a breakdown of the key elements:

  

  • The top-level terraform/ directory contains all of the Terraform projects.
  • Each project has its directory, such as project-dev-infra/, project-uat-infra/, and project-prod-infra/.
  • Within each project directory, there are separate subdirectories for different versions of the infrastructure, such as v1/ and v2/.
  • Each version directory contains separate directories for Terraform modules used by the infrastructure, such as aws-terraform-modules/.
  • Within each version directory, there are separate directories for each module used by the infrastructure, such as custom-vpc-module/, custom-rds-module/, and custom-alb-module/.
  • Finally, each version directory also contains a separate directory for the core infrastructure module, such as project-core-infra-module/, which includes the main Terraform configuration files, such as main.tf, variables.tf, and terraform.tfvars.

This folder structure provides a clear separation of concerns and allows for easy management of Terraform projects and their dependencies.

Module Creation

Here at CAW Studios, we use a combination of community and custom modules to help speed up the development and provide accessibility to the developers. Creating Terraform modules involves defining reusable infrastructure components that can be easily reused across different Terraform projects. Modules allow for the creation of self-contained pieces of infrastructure code that can be easily tested, maintained, and versioned. We have developed a host of custom modules, including a module for VPC, RDS, ALB, etc.

In the case of community modules being used, these are never fetched from the registry, a custom version compatible with the infrastructure is made available offline as part of the project, and any changes needed for the module are made and pushed as part of the same project so that any version updates do not break existing functionality.