On Day 9 of the 30-Day Terraform Challenge, I explored advanced features of Terraform modules. Building on what I learned on Day 8, I focused on versioning modules and reusing them across multiple environments.
By versioning modules using Git tags (e.g., v1.0.0
), I can safely introduce changes and test them in dev
before promoting to prod
. This ensures better traceability, rollback capability, and clean infrastructure workflows.
I refactored my EC2 module and hosted it in its own GitHub repository. Each environment now uses the module like this:
module "ec2_instance" {
source = "git::https://github.com/myusername/terraform-aws-ec2-instance-module.git?ref=v1.0.0"
ami = var.ami
instance_type = var.instance_type
tags = var.tags
}
Environment-specific configurations (like AMI, instance size, and tags) are defined in separate folders for dev, staging, and production.
I also enabled versioning on the S3 bucket used for storing Terraform state, helping to protect against accidental deletions or changes.
resource "aws_s3_bucket" "tf_state" {
bucket = "my-tfstate-bucket"
acl = "private"
versioning {
enabled = true
}
tags = {
Name = "Terraform State Bucket"
Environment = "global"
}
}
Day9/
└── Submissions/
└── julietwainoi/
├── terraform/
│ ├── terraform-ec2-instance/
│ │ ├── main.tf
│ │ └── outputs.tf
│ └── terraform-ec2-environments/
│ ├── dev/
│ │ └── main.tf
│ ├── staging/
│ │ └── main.tf
│ └── prod/
│ └── main.tf
└── Day9_submission.md
Today’s work helped me transform my Terraform code into reusable, environment-agnostic modules. With versioning, I now have a safe way to evolve infrastructure without breaking production. Next steps: add CI/CD and tests!
#InfrastructureAsCode #Terraform #AWS #DevOps #ModuleVersioning #IaC