Terraform: Domare il Cloud con il Codice

Cosa succede se devi ricreare lo stesso identico server in tre minuti, ma l'unica persona che sa come farlo è in ferie?

Fino a pochi anni fa, creare un'infrastruttura cloud era un lavoro di pura pazienza. Entravi nella console web di AWS o Azure, cliccavi su decine di menu, selezionavi la dimensione del server, impostavi i permessi di rete e speravi di non aver dimenticato una spunta cruciale lungo la strada.

Questo approccio manuale, chiamato amichevolmente ClickOps, porta con sé tre problemi enormi:

1. Zero replicabilità: Se hai bisogno di un ambiente di test identico a quello di produzione, devi rifare tutto da capo, sperando di ricordare ogni singolo clic.
2. La documentazione bugiarda: I documenti di testo che descrivono come configurare i server non vengono mai aggiornati e diventano obsoleti dopo due settimane.
3. L'errore invisibile: Basta un solo clic sbagliato in un sottomenu per esporre un database a tutta internet, senza che nessuno se ne accorga.

La soluzione a questo incubo si chiama Infrastructure as Code (IaC), ovvero Infrastruttura come Codice. Invece di cliccare su un'interfaccia grafica, descriviamo l'infrastruttura che desideriamo (ad esempio, il nostro web_server virtuale) all'interno di un semplice file di testo.

Terraform è lo strumento che legge questo file di testo e si occupa di parlare con i provider cloud per renderlo reale. Se il file dice che vogliamo un server, Terraform lo crea. Se lo cancelliamo dal file, Terraform lo distrugge.

Con l'IaC, il file di configurazione non è solo il foglio di istruzioni per creare il server: è la documentazione vivente, precisa e aggiornata al millisecondo di ciò che esiste davvero nel cloud.

Terraform unisce il mondo del codice testuale con la realtà dei servizi cloud attraverso tre componenti fondamentali che lavorano insieme.

Esplora i collegamenti tra il codice scritto, i comandi del motore e le risorse reali sul cloud.

Se dovessi chiedere a un robot di prepararti un caffè, preferiresti elencargli ogni singolo movimento del braccio meccanico o semplicemente mostrargli la foto di una tazzina piena?

La differenza tra programmazione imperativa e dichiarativa sta tutta qui. Nei sistemi tradizionali (imperativi), scrivi uno script che dice: "Fai questo, poi fai quello, se fallisce prova quest'altro". Se un passaggio si interrompe a metà, ti ritrovi con un sistema instabile e difficile da ripristinare.

Terraform usa un approccio dichiarativo. Tu descrivi il risultato finale desiderato — la tazzina di caffè pronta — e lasci che sia il motore di Terraform a capire quali passaggi intermedi compiere.

Per farlo, usiamo l'HCL (HashiCorp Configuration Language), un linguaggio semplice e leggibile. Ecco come dichiariamo il nostro server virtuale:

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

Analizziamo questo blocco:

1. resource: indica a Terraform che vogliamo creare un pezzo di infrastruttura.
2. "aws_instance": è il tipo di risorsa. Dice a Terraform cosa creare (in questo caso, un server virtuale su AWS).
3. "web_server": è il nome logico che usiamo dentro il codice per identificare questa risorsa.
4. ami e instance_type: sono i parametri che definiscono la configurazione reale (il sistema operativo e la dimensione del server).

Terraform di per sé non sa cosa sia un server AWS, un database Google Cloud o una playlist di Spotify: è solo un motore logico vuoto.

Abbiamo visto come definire la nostra risorsa nel codice HCL. Ma chi traduce quel testo in azioni reali sulle API dei diversi provider cloud?

La risposta sono i Provider. Un provider è un plugin specifico per una determinata piattaforma, scaricato automaticamente da Terraform all'inizio di ogni progetto.

Per esempio, per dire a Terraform che vogliamo lavorare con Amazon Web Services nella regione europea di Irlanda, dichiariamo un blocco come questo:

provider "aws" {
  region = "eu-west-1"
}

Grazie a questa separazione tra il motore Terraform e i plugin dei provider, lo stesso linguaggio può gestire contemporaneamente infrastrutture su AWS, Microsoft Azure, Google Cloud Platform o persino servizi SaaS di terze parti.

Cosa succede se qualcuno modifica la tua infrastruttura di nascosto, cliccando direttamente sulla console web di AWS?

Quando scrivi nel codice che desideri un server web_server di tipo t2.micro, Terraform deve associarlo a un'entità reale. Nel cloud, quel server riceverà un ID univoco generato da AWS (ad esempio, i-0a12b34c56d78e9f0). Per ricordarsi questa associazione, Terraform crea un file speciale chiamato terraform.tfstate.

Questo file di stato è l'unica fonte di verità: mappa i tuoi blocchi HCL alle risorse reali nel cloud. Se un amministratore modifica manualmente la dimensione del server sulla console di AWS (il temuto drift o disallineamento), Terraform se ne accorge al volo.

Durante ogni esecuzione, Terraform confronta tre elementi:

1. Il tuo codice HCL (ciò che vuoi).
2. Lo stato reale su AWS (ciò che esiste).
3. Il file terraform.tfstate (ciò che Terraform ricorda di aver fatto).

Se trova discrepanze, propone le modifiche necessarie per riportare la realtà in perfetto allineamento con il tuo codice.

Modificare manualmente il file .tfstate è il modo più rapido per corrompere l'infrastruttura. Lascia che sia sempre e solo Terraform a scriverci dentro.

Ora che abbiamo visto come dichiarare il nostro web_server, come fa Terraform a trasformare questo testo in un vero server cloud? Segue una rigorosa sequenza di quattro comandi fondamentali.

Iniziare da zero è facile. Ma cosa succede quando l'infrastruttura esiste già e decidi di cambiare le regole del gioco?

Quando modifichi il file di configurazione del nostro web_server, Terraform non cancella tutto per partito preso. Confronta il nuovo codice con lo stato reale salvato nel file terraform.tfstate e decide la strategia ottimale.

Esistono due strade che Terraform può intraprendere:

1. Aggiornamento sul posto (In-Place Update): Se cambi un parametro non strutturale, come i tags (i tag identificativi) o alcune regole di sicurezza soft, Terraform modifica solo quel dettaglio. Il server rimane acceso e attivo. Nel terminale, questo è rappresentato dal simbolo ~ (giallo).
2. Distruzione e Ricreazione (Destroy and Recreate): Se modifichi una proprietà fondamentale che il cloud provider non permette di cambiare "a caldo" — come la availability_zone (la zona fisica del data center) o l'immagine del sistema operativo (ami) — Terraform è costretto a distruggere la risorsa esistente e crearne una nuova. Nel terminale vedrai il simbolo -/+ (rosso e verde).

Questo comportamento previene configurazioni instabili, ma significa che un innocuo cambio di riga nel codice può causare un'interruzione del servizio (downtime) o la perdita di dati non salvati.

Immagina di essere l'amministratore di sistema responsabile del nostro server web_server su AWS. Hai aperto il file di configurazione HCL e devi applicare una modifica. Scegli la mossa giusta per ogni scenario e scopri se Terraform aggiornerà il server in modo sicuro o se scatenerà una distruzione.

Metti alla prova la tua memoria sui termini chiave che abbiamo incontrato. Rigira ogni carta per verificare la definizione esatta.

Affronta questa serie di affermazioni per verificare se hai interiorizzato i concetti chiave visti finora. Valuta ogni affermazione come vera o falsa.

Metti in ordine cronologico i comandi da digitare nel terminale per gestire il ciclo di vita del nostro server web su AWS, partendo da un progetto appena scaricato fino alla sua pulizia finale.

Ti trovi a gestire l'infrastruttura di produzione dell'azienda. Devi rinominare la risorsa del database relazionale nel codice HCL per seguire una nuova convenzione di naming aziendale. Nel codice esistente avevi:

resource "aws_db_instance" "db"

Che hai modificato in:

resource "aws_db_instance" "database_produzione"

Lanci il comando terraform plan e l'output ti mostra una situazione critica:

Terraform will perform the following actions:

  # aws_db_instance.database_produzione must be created
  + resource "aws_db_instance" "database_produzione" {
      # ... parametri del db ...
    }

  # aws_db_instance.db must be destroyed
  # (because aws_db_instance.db is not present in the new configuration)

Plan: 1 to add, 0 to change, 1 to destroy.

Se procedi con terraform apply, Terraform distruggerà il database esistente db (e con esso tutti i dati di produzione!) per crearne uno nuovo da zero chiamato database_produzione. Devi risolvere questo problema senza perdere i dati.