Guide to a Well Structured Terraform Project

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.

Before we begin... a big thank you to today's sponsor The Rundown AI.

  • AI won't replace your job, but people who effectively use AI will.

  • Try The Rundown AI โ€“ learn how to apply AI in just 5 minutes a day.

  • Join 700,000+ early AI adopters for FREE!

IN TODAY'S EDITION

๐Ÿง  Use Case

  • Guide to a Well Structured Terraform Project

๐Ÿš€ Top News

๐Ÿ“ฝ๏ธ Videos

๐Ÿ“š๏ธ Resources

๐Ÿ› ๏ธ 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!

Sponsored
The CAIO (The Chief AI Officer)The 7-Minute Weekly AI Strategy Meeting for Business Owners Who Want to Grow their business with AI - Delivered FREE to your inbox every Thursday at 6:13 am EST.

๐Ÿง  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:

Learn how to make AI work for you

AI wonโ€™t take your job, but a person using AI might. Thatโ€™s why 800,000+ professionals read The Rundown AI โ€“ the free newsletter that keeps you updated on the latest AI news and teaches you how to use it in just 5 minutes a day.

Sponsored
Forests Over TreesA Tech Strategy Newsletter

Looking to promote your company, product, service, or event to 17,000+ TechOps Professionals? Let's work together.