Production-grade Terraform development with HCL best practices, module design, state management, multi-cloud patterns, and AI-enhanced infrastructure as code for scalable cloud deployments
El comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.
¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.
Mostrando SKILL.md
SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
Terraform Infrastructure as Code
skill_id
terraform-infrastructure
version
1.0.0
description
Production-grade Terraform development with HCL best practices, module design, state management, multi-cloud patterns, and AI-enhanced infrastructure as code for scalable cloud deployments
This skill provides comprehensive guidance for building production-grade infrastructure with Terraform following 2024-2025 best practices. Terraform is the industry standard for Infrastructure as Code (IaC), enabling version-controlled, reproducible, and automated cloud infrastructure management across AWS, Azure, GCP, and 100+ providers.
Automating infrastructure changes with CI/CD pipelines
Creating reusable infrastructure modules for teams
Migrating from manual cloud console provisioning to IaC
Core Principles
1. State Management is Critical
Terraform state is the source of truth - protect it
# CORRECT: Remote state with locking
terraform {
backend "s3" {
bucket = "myapp-terraform-state"
key = "prod/vpc/terraform.tfstate"
region = "us-east-1"
encrypt = true
dynamodb_table = "terraform-state-lock" # Prevents concurrent modifications
# State versioning for recovery
versioning = true
}
}
# WRONG: Local state in production
# terraform {
# backend "local" {
# path = "terraform.tfstate" # Never use local state in teams!
# }
# }
State Best Practices:
✅ Always use remote state backends (S3, Azure Blob, GCS, Terraform Cloud)
✅ Enable state locking to prevent concurrent runs
✅ Enable encryption at rest for sensitive data
✅ Use versioning for state file recovery
✅ Separate state files per environment and major component
❌ Never commit .tfstate files to version control
❌ Never share state files via email or Slack
2. Module Design for Reusability
Build composable, tested modules with clear interfaces
# modules/vpc/main.tf - Well-designed module
variable "vpc_cidr" {
description = "CIDR block for VPC"
type = string
validation {
condition = can(cidrhost(var.vpc_cidr, 0))
error_message = "VPC CIDR must be valid IPv4 CIDR block"
}
}
variable "environment" {
description = "Environment name (dev, staging, prod)"
type = string
validation {
condition = contains(["dev", "staging", "prod"], var.environment)
error_message = "Environment must be dev, staging, or prod"
}
}
variable "tags" {
description = "Additional tags for all resources"
type = map(string)
default = {}
}
resource "aws_vpc" "main" {
cidr_block = var.vpc_cidr
enable_dns_hostnames = true
enable_dns_support = true
tags = merge(
{
Name = "${var.environment}-vpc"
Environment = var.environment
ManagedBy = "Terraform"
},
var.tags
)
}
output "vpc_id" {
description = "ID of the created VPC"
value = aws_vpc.main.id
}
output "vpc_cidr" {
description = "CIDR block of the VPC"
value = aws_vpc.main.cidr_block
}
# Usage in root module
module "vpc" {
source = "./modules/vpc"
vpc_cidr = "10.0.0.0/16"
environment = "prod"
tags = {
Team = "platform"
Project = "myapp"
}
}
Module Design Checklist:
✅ Single responsibility - one purpose per module
✅ Input validation with variable validation blocks
✅ Descriptive variable names and descriptions
✅ Sensible defaults where appropriate
✅ Outputs for all important resource attributes
✅ README.md with examples and terraform-docs
✅ Versioning for published modules
3. Resource Naming and Tagging
Consistent naming prevents confusion and enables automation
# WRONG: Hardcoded configuration
resource "aws_instance" "app" {
ami = "ami-12345678" # Will break in other regions!
instance_type = "t3.micro"
tags = {
Environment = "production" # Hardcoded environment
}
}
# CORRECT: Use variables and data sources
data "aws_ami" "app" {
most_recent = true
owners = ["self"]
filter {
name = "name"
values = ["myapp-*"]
}
}
resource "aws_instance" "app" {
ami = data.aws_ami.app.id
instance_type = var.instance_type
tags = merge(local.common_tags, {
Name = "${var.environment}-app"
})
}
❌ DON'T: Use count with lists that may reorder
# WRONG: Count with list - reordering causes recreations
variable "instance_names" {
default = ["web1", "web2", "web3"]
}
resource "aws_instance" "app" {
count = length(var.instance_names)
ami = var.ami_id
instance_type = "t3.micro"
tags = {
Name = var.instance_names[count.index]
}
}
# If you remove "web2", "web3" gets destroyed and recreated!
# CORRECT: Use for_each with map
variable "instances" {
default = {
web1 = { type = "t3.micro" }
web2 = { type = "t3.small" }
web3 = { type = "t3.micro" }
}
}
resource "aws_instance" "app" {
for_each = var.instances
ami = var.ami_id
instance_type = each.value.type
tags = {
Name = each.key
}
}
# Now you can safely add/remove instances without affecting others
❌ DON'T: Mix environments in same state
# WRONG: All environments in one state file
# terraform apply # Applies to dev AND prod!
# CORRECT: Separate directories and state files
# environments/dev/main.tf
# environments/prod/main.tf
❌ DON'T: Use local-exec for critical operations
# WRONG: Critical operations in local-exec
resource "null_resource" "bad_db_init" {
provisioner "local-exec" {
command = "psql -c 'CREATE DATABASE app'"
}
}
# If this fails, no error in Terraform!
# CORRECT: Use proper resources or automation tools
resource "postgresql_database" "app" {
name = "app"
}
