Infrastructure as Code con Terraform: Moduli, State Management e CI/CD per Cloud

🧰 Materiali necessari

• Terraform CLI 1.7+
• AWS account o cloud provider equivalente Azure o GCP
• AWS CLI configurato
• aws-vault per credential management sicuro
• Git e GitHub account
• GitHub Actions o Atlantis per CI/CD
• S3 e DynamoDB per state backend
• tflint per linting Terraform
• tfsec o Checkov per security scanning
• conftest e OPA per policy as code
• terratest e Go per integration testing
• Infracost per cost estimation
• driftctl per drift detection
• Terragrunt per advanced workflow multi-account

📋 Passi

1. 1
   Setup AWS account e Terraform locale
   {"step":1,"title":"Setup AWS account e Terraform locale","description":"Crea AWS account dedicato per testing o usa sandbox aziendale. Installa Terraform CLI 1.7+ tramite brew install terraform su macOS o binary download. Verifica con terraform version. Configura AWS credential: aws configure con access key e secret key, oppure aws-vault per credential management sicuro. Crea IAM user dedicato terraform-poweruser con policy minima necessaria. Testa connessione con aws sts get-caller-identity."}
2. 2
   Primo workflow Terraform completo
   {"step":2,"title":"Primo workflow Terraform completo","description":"Crea directory progetto con main.tf semplice: provider AWS region us-east-1, resource aws_s3_bucket con nome unico. Esegui sequenza completa: terraform init scarica provider, terraform plan mostra creation plan dettagliato, terraform apply con confirm yes esegue. Verifica bucket creato in AWS console. Esegui terraform destroy per cleanup. Familiarizza con output di ogni comando, struttura .terraform directory, e terraform.tfstate locale generato."}
3. 3
   Setup remote state backend S3 e DynamoDB
   {"step":3,"title":"Setup remote state backend S3 e DynamoDB","description":"Crea S3 bucket per state storage: nome unico, versioning enabled, encryption AES256, public access blocked. Crea DynamoDB table per locking con nome terraform-locks e partition key LockID string. Crea IAM policy che limita accesso al Terraform user. Aggiungi backend block in terraform block con S3 bucket, key, region, dynamodb_table, encrypt true. Esegui terraform init per migrare state locale al remote. Verifica file in S3 e funzionamento lock DynamoDB."}
4. 4
   Primo modulo riutilizzabile ec2-instance
   {"step":4,"title":"Primo modulo riutilizzabile ec2-instance","description":"Crea directory modules\/ec2-instance con main.tf (resource aws_instance e security_group), variables.tf (input instance_type, ami_id, vpc_id, environment), outputs.tf (output instance_id e public_ip), README.md con documentazione completa. Ogni resource interno usa variable di input. Tag resource con environment per traceability. Usa modulo nel root main.tf: module web_server con source .\/modules\/ec2-instance e parametri. Applica e verifica resource creata correttamente."}
5. 5
   Module versioning con Git tag
   {"step":5,"title":"Module versioning con Git tag","description":"Push modulo a repository Git separato terraform-modules. Tag release con git tag v1.0.0 e git push --tags. Aggiorna consumer Terraform: module source con URL Git completo e ref=v1.0.0. Versione pinned esplicitamente garantisce stability. Modifica modulo, tag v1.1.0, consumer su v1.0.0 rimane non affetto fino a update esplicito del ref. Documenta API module in CHANGELOG.md per comunicare breaking change al team in modo trasparente."}
6. 6
   Multi-environment con directory structure separata
   {"step":6,"title":"Multi-environment con directory structure separata","description":"Crea struttura directories: environments\/dev, environments\/staging, environments\/production. Ogni directory ha proprio main.tf che invoca moduli shared con parametri environment-specific. Backend configuration separato per environment: dev usa S3 key dev\/terraform.tfstate, production usa production\/terraform.tfstate. Variable file terraform.tfvars con valori specifici per environment. Isolation completa tra environment, nessuna possibilita di contaminazione accidentale."}
7. 7
   Module composition VPC e EC2 con dependency
   {"step":7,"title":"Module composition VPC e EC2 con dependency","description":"Usa terraform-aws-modules\/vpc\/aws community module per VPC creation con subnet public e private, NAT gateway, route table configurati. Custom module ec2-cluster dipende da output di VPC module: subnets passati come input. Dimostra dependency chain: VPC must exist before EC2. terraform plan mostra dependency graph con VPC resource prima e EC2 dopo. Output VPC module (vpc_id, subnet_ids) usati come input EC2 module. Pattern fondamentale per infrastruttura reale."}
8. 8
   Secret management con AWS Secrets Manager
   {"step":8,"title":"Secret management con AWS Secrets Manager","description":"Mai committare password in HCL o variable file. Crea secret in AWS Secrets Manager manualmente o via Terraform. Recupera value in Terraform tramite data source aws_secretsmanager_secret_version. Resource RDS usa data source per master_password invece di variable. State file ancora contiene value ma encryption at rest mitiga il rischio. Documenta policy team: secret sempre da Secrets Manager o Vault, mai hardcoded o in env variable nei log CI."}
9. 9
   CI/CD con GitHub Actions e OIDC federation
   {"step":9,"title":"CI\/CD con GitHub Actions e OIDC federation","description":"Crea workflow .github\/workflows\/terraform.yml: trigger su pull_request e push main. Job terraform-plan: setup-terraform, terraform fmt check, terraform init, terraform validate, terraform plan -out=tfplan, upload plan come artifact. Usa OIDC federation per AWS credential senza secret statici in GitHub. Job terraform-apply: needs terraform-plan, condition su push a main, download plan artifact, terraform apply tfplan. Environment production con required reviewer per approval gate."}
10. 10
    Atlantis self-hosted per PR workflow completo
    {"step":10,"title":"Atlantis self-hosted per PR workflow completo","description":"Deploy Atlantis nel cluster Kubernetes via Helm con values: webhook URL esposto via Ingress, GitHub token credential, repo whitelist. Configura GitHub webhook verso Atlantis. Workflow: PR triggera atlantis plan automatico con comment PR che mostra plan output completo. Reviewer commenta atlantis apply per execute. Lock per PR previene concurrent apply sullo stesso workspace. Audit trail completo in GitHub PR history, ogni apply tracciato con autore."}
11. 11
    Policy as Code con OPA conftest
    {"step":11,"title":"Policy as Code con OPA conftest","description":"Definisci policy Rego per Terraform: deny resource senza tag environment e team, deny S3 bucket senza encryption, deny security group con 0.0.0.0\/0 ingress su porte sensitive. Installa conftest CLI. Genera plan output JSON: terraform show -json tfplan > plan.json. Esegui conftest test plan.json. Policy violation blocca CI pipeline prima di apply. Aggiungi step conftest che runs su ogni PR e breaks build se policy fallisce."}
12. 12
    Drift detection automation con schedule
    {"step":12,"title":"Drift detection automation con schedule","description":"Schedula weekly drift detection: workflow cron ogni lunedi mattina esegue terraform plan in tutti gli environment. Plan output non-empty indica drift tra state Terraform e reality cloud. Notification Slack se drift detected con dettaglio resource e tipo di divergenza. Investiga drift: identifica resource changed, determina causa (manual change in console, automation esterna), rimedia aggiornando Terraform per matchare reality o vice versa. Documenta drift incidents."}
13. 13
    Testing Terraform con terratest
    {"step":13,"title":"Testing Terraform con terratest","description":"Crea directory test con Go test file usando terratest library. Test modulo ec2-instance: setup terraform options con directory modulo, terraform apply esegue provisioning reale, valida resource exists con AWS SDK Go, terraform destroy in cleanup defer. Esegui test con go test -timeout 30m. Testa deployment reale di resource con assertions concrete. Esegui in CI per critical module su schedule notturno usando dedicated test AWS account."}
14. 14
    Cost estimation con Infracost nel CI
    {"step":14,"title":"Cost estimation con Infracost nel CI","description":"Installa Infracost CLI o usa Infracost GitHub Action ufficiale. Configura API key disponibile free tier. In CI pipeline dopo terraform plan: infracost breakdown --path tfplan -o json, infracost comment su PR che mostra cost impact. PR comment mostra monthly cost current vs proposed change e breakdown per resource. Threshold alert: deployment con monthly cost increase superiore a 100 USD richiede review aggiuntiva da team lead o FinOps team."}
15. 15
    Multi-account strategy e state organization enterprise
    {"step":15,"title":"Multi-account strategy e state organization enterprise","description":"Architect multi-account: account separato per dev, staging, production, piu shared-services account per Terraform state e CI. Terraform configuration usa provider AWS con assume_role da CI account a target account con role specifico. State file in shared-services account S3 con encryption KMS key custom. Cross-account access via IAM role e trust policy carefully managed con principle of least privilege. Documenta runbook per onboard nuovo environment con checklist completa."}