Infrastructure as Code con Terraform — Provider, State e Moduli per PMI che Vogliono Scalare

Stai gestendo server, database e servizi cloud a mano? Ogni volta che un collega tocca un config, qualcosa si rompe. E sei stanco di sentire “funziona sul mio PC” quando in produzione è tutto spento.

Noi di Meteora Web ci siamo passati. Gestiamo stack per clienti da anni, e quando il caos cresce, l’infrastruttura come codice con Terraform è la risposta. Non una moda: una necessità per chi vuole deploy riproducibili, rollback sicuri e un unico punto di verità.

In questa guida vediamo i tre pilastri operativi di Terraform: provider, state e moduli. Non teoria: codice che puoi usare subito, errori da evitare e una visione concreta per la tua PMI.

Perché usare Terraform per Infrastructure as Code invece di Click e Console?

Ogni volta che configuri un server via web console, stai accumulando debito tecnico. Nessun audit trail, nessuna riproducibilità. Con Terraform dichiari lo stato desiderato: lui lo applica e lo mantiene. Se qualcuno cancella manualmente una risorsa, al prossimo terraform apply la ricrea. Sembra magia, è solo codice.

Il problema concreto che risolve

Immagina di dover replicare l’ambiente di produzione per un nuovo cliente: stesso server MariaDB, stesso bucket S3, stessa VPC. A mano ci metti ore e sbagli. Con Terraform, un file di 50 righe e un terraform apply da un ambiente all’altro. Lo abbiamo fatto per clienti che passavano da hosting condiviso a infrastruttura AWS gestita: da 3 giorni di lavoro a 20 minuti.

Come si sceglie un provider Terraform e quali sono i criteri giusti per la tua PMI?

I provider sono i plugin che parlano con i servizi cloud: AWS, Azure, Google Cloud, ma anche Cloudflare, GitHub, Kubernetes, Proxmox. Scegliere il provider giusto significa valutare:

• Maturità: un provider ufficiale di HashiCorp è più affidabile di uno di terze parti.
• Copertura: supporta tutte le risorse che ti servono? Per AWS il provider AWS è vastissimo, per servizi di nicchia meglio verificare.
• Manutenzione: provider con commit recenti e risposte alle issue.

Esempio pratico: provider AWS con autenticazione

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-south-2"
  # Credenziali da variabili d'ambiente o file ~/.aws/credentials
}

Regola importante: mai scrivere credenziali in chiaro nel codice. Usa variabili d’ambiente o strumenti come AWS Vault. Noi abbiamo visto clienti con access key hardcoded su GitHub — una falla di sicurezza evitabilissima.

Come gestire lo state di Terraform in team senza conflitti e perdite di dati?

Lo state file (terraform.tfstate) è il cuore di Terraform: mappa le risorse reali nel tuo codice. Se lo perdi o lo condividi male, Terraform non sa più cosa gestire. Lo state deve essere remoto e bloccato per lavoro di squadra.

Backend S3 con locking DynamoDB — il setup standard

terraform {
  backend "s3" {
    bucket         = "my-company-terraform-state"
    key            = "prod/network/terraform.tfstate"
    region         = "eu-south-2"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Senze locking, due persone lanciano apply contemporaneamente e corrompono lo state. Con DynamoDB, solo uno vince. Lo abbiamo risolto per un cliente che aveva 4 sviluppatori sulla stessa infrastruttura: zero conflitti da allora.

Errori comuni sullo state

• State locale in team: lo condividono via Git? No: state in .gitignore. Va in backend remoto.
• State con dati sensibili: mai pushare un file .tfstate che contiene password. Usa terraform state show solo in locale sicuro.
• Non backup: abilita versioning sul bucket S3. Se qualcuno cancella lo state per errore, puoi ripristinarlo.

Come strutturare i moduli Terraform per non avere un unico file di 2000 righe?

Se scrivi tutto in un unico main.tf, dopo poche risorse diventa illeggibile. I moduli sono come componenti riutilizzabili: un modulo per la VPC, uno per il database, uno per il cluster Kubernetes. Ogni modulo fa una cosa e la fa bene.

Un modulo minimo per un server web su AWS

Creiamo una directory modules/webserver:

# modules/webserver/main.tf
resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = var.instance_type
  subnet_id     = var.subnet_id

  tags = {
    Name = var.name
  }
}

# modules/webserver/variables.tf
variable "ami_id" {}
variable "instance_type" { default = "t3.micro" }
variable "subnet_id" {}
variable "name" {}

Poi nel root module:

module "web_prod" {
  source = "./modules/webserver"

  ami_id    = "ami-0123456789abcdef0"
  instance_type = "t3.small"
  subnet_id = aws_subnet.public.id
  name      = "web-prod-01"
}

Vantaggio: puoi riusare lo stesso modulo per staging, produzione, disaster recovery — cambi solo le variabili. Noi abbiamo un modulo base per server WordPress che usiamo in tutti i progetti: risparmiamo ore di boilerplate.

Registro Terraform e moduli pubblici

Non reinventare la ruota. Il Terraform Registry ha migliaia di moduli verificati. Esempio: per un database RDS, usa il modulo terraform-aws-modules/rds/aws. Si installa semplicemente:

module "database" {
  source  = "terraform-aws-modules/rds/aws"
  version = "~> 6.0"

  identifier = "mydb"
  engine     = "mysql"
  # ... altre variabili
}

Cosa fare adesso — checklist operativa per iniziare con Terraform

1. Installa Terraform (locale o in CI/CD).
2. Scegli un backend remoto (S3 + DynamoDB per AWS, Terraform Cloud per multi-cloud).
3. Crea un tuo primo provider (per il cloud che usi di più) e applica una risorsa semplice (es. un bucket).
4. Struttura il progetto: usa directory separate per ambiente (prod/staging) e moduli riutilizzabili.
5. Blocca lo state con locking e versioning.
6. Non hardcodare segreti — usa variabili d’ambiente o strumenti come Vault.
7. Leggi la documentazione ufficiale: Terraform docs.

Noi di Meteora Web usiamo Terraform su base quotidiana, dai server Linux ai cluster Kubernetes. Se vuoi saperne di più su come integrarlo in una pipeline CI/CD, parti dalla nostra guida pillar su DevOps e CI/CD.

Ricorda: l’infrastruttura come codice non è un lusso per grandi aziende. È lo strumento che trasforma il caos in controllo. E noi lo vediamo tutti i giorni nei progetti delle PMI italiane. Inizia oggi.