Overview

Architettura

1. Struttura dei File e Blocchi Fondamentali di Terraform

I file di configurazione di Terraform utilizzano l'estensione .tf. La struttura logica si basa su blocchi nativi in sintassi HCL (HashiCorp Configuration Language), ciascuno con una precisa tipologia e funzione:

• Blocco Terraform (terraform)
  • Tipo: Configurazione del motore (Core).
  • Funzione: Definisce i vincoli globali della CLI di Terraform e dichiara i provider richiesti con le relative sorgenti (source) e versioni minime ammesse.
• Blocco Backend (backend)
  • Tipo: Configurazione dello Stato (nidificato all'interno del blocco terraform {}).
  • Funzione: Specifica dove e come deve essere archiviato il file di stato (.tfstate). Può essere di tipo Local (file locale) o Remote (es. s3, azurerm, gcs, http) per garantire persistenza, sicurezza e meccanismi di congiunzione (state locking) nei team.
• Blocco Provider (provider)
  • Tipo: Configurazione delle API di destinazione.
  • Funzione: Inizializza i plug-in specifici (es. aws, azurerm, google) definendo i parametri di autenticazione, le credenziali e l'ambito geografico (es. region) per l'interazione con i Cloud Provider.
• Blocco Risorsa (resource)
  • Tipo: Definizione dell'Infrastruttura (oggetti reali o logici).
  • Funzione: Rappresenta l'elemento infrastrutturale da creare e gestire (es. macchine virtuali, VPC, database). Accetta due argomenti stringa: il tipo di risorsa dichiarato dal provider e il nome logico locale.
• Blocco Dati (data)
  • Tipo: Query in sola lettura.
  • Funzione: Interroga le API del Cloud provider o infrastrutture esistenti per recuperare attributi e metadati di risorse preesistenti (gestite esternamente) e renderli disponibili nel codice corrente.
• Blocco Variabile (variable)
  • Tipo: Canale di Input.
  • Funzione: Definisce parametri d'ingresso tipizzati (es. string, number, list, map, object) per evitare valori hardcodati e rendere i moduli flessibili e riutilizzabili in più ambienti.
• Blocco Output (output)
  • Tipo: Canale di Output.
  • Funzione: Espone informazioni strutturate al termine dell'esecuzione (es. indirizzi IP pubblici, stringhe di connessione) o trasferisce dati tra moduli diversi.
• Provisioners (provisioner)
  • Tipo: Azione post-deployment (nidificato all'interno di un blocco resource).
  • Funzione: Utilizzato come ultima risorsa per eseguire script, comandi o trasferimenti file locali (local-exec) o remoti (remote-exec) sulla risorsa appena istanziata.

---

2. Il Flusso di Lavoro Operativo (Terraform Workflow)

Il ciclo di vita di Terraform segue un modello rigorosamente dichiarativo basato su quattro fasi sequenziali:

1. Write (Scrittura): L'operatore definisce lo stato desiderato dell'infrastruttura scrivendo il codice dichiarativo HCL all'interno dei file .tf.
2. Init (Inizializzazione): Si esegue il comando terraform init. Il core predispone la directory di lavoro locale, scarica i file binari dei provider dichiarati nel codice e aggancia il backend configurato per la gestione dello stato.
3. Plan (Pianificazione): Si esegue il comando terraform plan. Terraform esegue un ciclo di lettura confrontando lo stato reale (tramite il backend) con la configurazione locale. Produce un'anteprima atomica delle operazioni necessarie (creazioni, modifiche sul posto, distruzioni) senza alterare le risorse.
4. Apply (Applicazione): Si esegue il comando terraform apply. Previa autorizzazione dell'utente, Terraform esegue le chiamate API necessarie verso i target provider per allineare l'infrastruttura reale al codice, scrivendo e bloccando i nuovi metadati all'interno del backend di stato.

Esempio Pratico (AWS) con Backend Web (HTTP) e Stato Remoto

Nel ciclo di vita DevOps e GitOps (ad esempio utilizzando GitLab, Terraform Cloud o soluzioni custom), il backend di tipo http viene utilizzato per memorizzare lo stato in modo centralizzato tramite chiamate API REST (funzioni GET, POST e DELETE per la gestione dello state locking).

Di seguito viene aggiornato l'esempio AWS sostituendo il backend S3 con un backend web/http generico, ideale per l'integrazione in pipeline CI/CD.

# 1. BLOCCO TERRAFORM & BACKEND WEB (HTTP)
# Configura il core, i vincoli del provider AWS e lo stato remoto via API Web HTTP
terraform {
  required_version = ">= 1.5.0"

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

  # Configurazione del backend web. I parametri sensibili (URL, credenziali)
  # vengono omessi qui e iniettati dinamicamente via CLI con -backend-config
  backend "http" {
    lock_method   = "POST"
    unlock_method = "DELETE"
  }
}

# 2. BLOCCO PROVIDER
# Inizializza il plug-in e imposta la regione di destinazione per le API AWS
provider "aws" {
  region = var.aws_region
}

# 3. BLOCCHI VARIABILE (Input)
variable "aws_region" {
  type    = string
  default = "us-east-1"
}

variable "ambiente" {
  type        = string
  default     = "Staging"
  description = "Ambiente operativo dell'infrastruttura"
}

# 4. BLOCCO DATA (Query)
# Interroga AWS per recuperare la lista delle Availability Zones disponibili
data "aws_availability_zones" "disponibili" {
  state = "available"
}

# 5. BLOCCHI RISORSA (Infrastruttura)
resource "aws_vpc" "vpc_principale" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true

  tags = {
    Name        = "vpc-${lower(var.ambiente)}"
    Environment = var.ambiente
  }
}

resource "aws_subnet" "subnet_pub_1" {
  vpc_id            = aws_vpc.vpc_principale.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = data.aws_availability_zones.disponibili.names[0]

  tags = {
    Name        = "subnet-${lower(var.ambiente)}-pub-1"
    Environment = var.ambiente
  }
}

# 6. BLOCCO OUTPUT (Output)
output "vpc_id" {
  value       = aws_vpc.vpc_principale.id
  description = "ID della VPC AWS generato dopo il deployment"
}