setting-up-terraform

Setup Terraform

Use this skill when the user asks to set up Terraform, infrastructure as code, cloud provisioning, or IaC.

Steps

1. Initialize the project structure

   infra/
   ├── main.tf
   ├── variables.tf
   ├── outputs.tf
   ├── terraform.tfvars      # (gitignored)
   ├── providers.tf
   └── modules/
   

2. Configure the provider — in providers.tf:

terraform {
  required_version = ">= 1.5"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
  }
}

provider "aws" {
  region = var.aws_region
}

Adapt the provider for the user's cloud (AWS, GCP, Azure).

1. Define variables — in variables.tf, define inputs with types, descriptions, and defaults:

   variable "aws_region" {
     type        = string
     default     = "us-east-1"
     description = "AWS region for resources"
   }
   
   variable "environment" {
     type        = string
     description = "Deployment environment (dev, staging, prod)"
   }
   

2. Create resources — in main.tf, define the infrastructure the user needs (VPC, RDS, ECS, S3, Lambda, etc.). Extract reusable patterns into modules under modules/.

3. Configure remote state — use an S3 bucket (AWS), GCS bucket (GCP), or Azure Storage for state. Enable state locking with DynamoDB (AWS).

4. Add to .gitignore

   *.tfstate
   *.tfstate.*
   .terraform/
   terraform.tfvars
   *.tfvars
   

5. Add CI pipeline — create a GitHub Actions workflow that runs terraform fmt -check, terraform validate, and terraform plan on PRs, with terraform apply on merge to main (with approval gate).

Notes

• Never commit state files or .tfvars with secrets.
• Use workspaces or separate state files for dev/staging/prod.
• Pin provider versions to avoid breaking changes.
• Run terraform fmt before committing.