Terraform — Cheat Sheet

Tag: terraform, iac, devops, cloud, infrastructure, hcl, state

Livello: intermedio

TL;DR: Sintesi rapida dell'infrastruttura come codice con Terraform: ciclo di vita, gestione dello stato, moduli e best practice operative.

Concetti chiave

-

Infrastructure as Code (IaC) dichiarativa: descrive lo stato desiderato, non i passaggi procedurali.

-

File di stato (terraform.tfstate): mappa le risorse dichiarate nel codice con l'infrastruttura reale.

-

Ciclo principale: init prepara l'ambiente, plan mostra il diff, apply esegue le modifiche.

-

Provider: plugin distribuiti separatamente che interagiscono con le API cloud e SaaS.

-

Resource: elemento gestito direttamente da Terraform (istanze, VPC, DNS).

-

Data source: lettura in sola query di risorse esistenti non gestite nel blocco corrente.

-

Remote backend: salvataggio dello stato condiviso (es. S3, GCS) con meccanismo di lock (DynamoDB).

-

Moduli: incapsulamento logico per riutilizzare blocchi di infrastruttura con input e output.

-

Drift: divergenza tra l'infrastruttura reale e lo stato memorizzato localmente.

-

Immutabilità: approccio preferito che distrugge e ricrea le risorse anziché modificarle in-place.

Domande tipiche e risposte pronte

-

Q: A cosa serve il Terraform state e perché non va committato su Git?R: Mappa il codice con le risorse cloud reali; contiene dati sensibili in chiaro e va gestito su un remote backend con lock.

-

Q: Qual è la differenza tra terraform plan e terraform apply?R: Plan calcola solo il diff tra stato desiderato e reale; apply applica concretamente le modifiche alle API del provider.

-

Q: Come si gestisce il configuration drift?R: Con terraform refresh o eseguendo un plan che interroga le API e mostra le modifiche apportate fuori da Terraform.

-

Q: Quando si usa count e quando for_each?R: Uso for_each con mappe o set stabili; evito count su liste mutabili per scongiurare ricreazioni a cascata non volute.

Insidie e errori comuni

-

Rimozione di un elemento da una lista indicizzata con count: ricrea tutte le risorse successive.

-

Modifica manuale delle risorse tramite interfaccia cloud: genera drift e fallimenti nei successivi apply.

-

Mancato locking dello stato: rischio di scritture concorrenti distruttive da pipeline parallele.

-

Secret hardcodati nei file .tf: finiscono tracciati nel repository e nello stato.

-

Mancata parametrizzazione dei moduli: codice duplicato e difficile da manutenere tra ambienti.

-

Mancata esecuzione di terraform validate e tflint in CI: errori di sintassi scoperti tardi in apply.

Snippet e comandi

# Inizializzazione della directory e download dei provider
terraform init

# Validazione sintattica della configurazione
terraform validate

# Generazione del piano di esecuzione su file dedicato
terraform plan -out=tfplan

# Applicazione del piano salvato
terraform apply tfplan

# Distruzione controllata delle risorse
terraform destroy

Terraform

# Definizione di provider e backend remoto
terraform {
  required_version = ">= 1.5.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  backend "s3" {
    bucket         = "my-tf-state-bucket"
    key            = "prod/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-locks"
  }
}

Da ripassare

-

[ ] Regole di precedenza delle variabili (CLI -var, terraform.tfvars, environment variables)

-

[ ] Sintassi e casi d'uso di dynamic block

-

[ ] Comando terraform import e blocchi import nativi

-

[x] Ciclo base init, plan, apply e destroy

-

[x] Differenza funzionale tra count e for_each

Jarvis Interviews
Jarvis