- TechOps Examples
- Posts
- Guide to a Well Structured Terraform Project
Guide to a Well Structured Terraform Project
Govardhana M K
November 04, 2024
TechOps Examples
Hey — It's Govardhana MK 👋
Along with a use case deep dive, we identify the top news, tools, videos, and articles in the TechOps industry.
IN TODAY'S EDITION
🧠 Use Case
Guide to a Well Structured Terraform Project
🚀 Top News
15k Cloud Credentials Stolen in Operation Targeting Exposed Git Config Files
📽️ Videos
Elasticsearch in 60 seconds
📚️ Resources
Visual guide to SSH tunneling and port forwarding
Deploying Applications with GitHub Actions and ArgoCD to EKS: Best Practices and Techniques
🛠️ TOOL OF THE DAY
profileme - Create an amazing GitHub profile in minutes.
Show off your skills, experience and projects.
Generate markdown for your profile with just a few clicks!
🧠 USE CASE
Guide to a Well Structured Terraform Project
Why care about Terraform project structure? Simple—it keeps things organized so you can scale up, work well with your team, and keep everything secure. No fuss, just a setup that works.
This setup follows a layered structure, separating resources by environment (development, staging, production etc.,) and using centralized modules for reusable components.
Modules are kept in a central repository, allowing environments to source specific versions for controlled updates and consistent configurations.
Environment Directory Structure:
main. tf
Defines core resources for the environment by referencing modules from the central repository. Each module is tagged to ensure a specific version is used.
Example:
module "network" {
source = "git::https://github.com/terraform-aws-modules/terraform-aws-vpc.git//?ref=v3.19.0"
vpc_cidr = var.vpc_cidr
}
module "compute" {
source = "git::https://github.com/terraform-aws-modules/terraform-aws-ec2-instance.git//?ref=v4.2.0"
instance_count = var.instance_count
instance_type = var.instance_type
}
variables. tf
Declares input variables, making the configuration adaptable. For example, instance_type might vary between environments (e.g., t2.micro in dev, t3.large in prod).
variable "vpc_cidr" {
type = string
description = "CIDR block for the VPC"
}
variable "instance_count" {
type = number
description = "Number of compute instances"
}
variable "instance_type" {
type = string
description = "Type of instance"
default = "t2.micro"
}
provider. tf
Configures the cloud provider and backend for remote state storage, which tracks deployed resources. This setup is crucial for collaborative workflows.
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "${terraform.workspace}/terraform.tfstate"
region = "us-west-2"
}
}
provider "aws" {
region = "us-west-2"
}
outputs. tf
Defines output values, making it easy to retrieve information, like IP addresses or resource IDs, after deployment.
output "vpc_id" {
value = module.network.vpc_id
}
output "instance_ips" {
value = module.compute.instance_ips
}
dev. tfvars (Environment-Specific Variables)
Contains values for variables declared in variables. tf, tailored to this environment. Each environment (dev, staging, prod) will have its own .tfvars file.
vpc_cidr = "10.0.0.0/16"
instance_count = 2
instance_type = "t3.micro"
Centralized Modules Repository Breakdown
Modules are organized into folders by type (e.g., network, compute) within a separate repository. This structure allows consistent usage across environments by sourcing each module from a specific version tag in the central repository.
Modules Directory Structure:
Points to consider while using modules:
Use versioned module tags.
Centralize module source in a remote repository.
Refactor modules for reusability as project scales.
Avoid hardcoding values; use variables for flexibility.
Keep module logic focused on a single responsibility.
Define clear input and output variables for each module.
Document module usage and parameters in a README.
Test modules independently before applying in environments.
With this structured approach, each team or environment can deploy, test, and update infrastructure independently.
Hope this was useful in clarifying how to structure your Terraform projects.
You may even like: