# Cos'è l'Infrastructure as Code e perché conviene
Table of Contents
Chi gestisce anche solo un paio di server conosce bene la scena. Si entra nel pannello di controllo di un provider cloud, si clicca per creare una macchina virtuale, si aprono a mano le porte del firewall, si collega un dominio. Funziona. Poi, sei mesi dopo, serve rifare tutto uguale in un secondo ambiente, oppure ricostruire in fretta qualcosa che si è rotto, e nessuno ricorda più l’esatta sequenza di clic. È esattamente il problema che l’Infrastructure as Code prova a risolvere.
Cos’è l’Infrastructure as Code
L’Infrastructure as Code - spesso abbreviato in IaC, letteralmente “infrastruttura come codice” - è l’idea di descrivere l’infrastruttura in file di testo, invece di configurarla a mano cliccando in un pannello. Al posto di ricordare quali pulsanti premere, si scrive un documento che dice come deve essere fatto tutto: quante macchine devono esistere, che dimensione hanno, quali reti le collegano, quali regole di firewall si applicano, quali record DNS puntano dove.
Un programma legge quei file e si occupa di rendere l’infrastruttura reale identica a quanto descritto. Se nel testo c’è scritto che devono esistere due server e ce n’è solo uno, il programma crea il secondo. Se qualcosa non corrisponde più, lo riporta com’è scritto.
Il punto chiave è che questi file sono testo normale, come il codice di un programma. E come il codice, possono essere conservati in un sistema di versionamento come Git - uno strumento che tiene traccia di ogni modifica, di chi l’ha fatta e quando. L’infrastruttura smette di vivere solo dentro la console del provider e nella testa di chi l’ha creata, e diventa qualcosa che si può leggere, condividere e ricostruire.
Perché conviene
I vantaggi non sono astratti. Riguardano problemi che si presentano ogni volta che un’infrastruttura cresce o cambia mani.
Ripetibilità. Lo stesso file produce sempre lo stesso risultato. Serve un ambiente di collaudo identico a quello di produzione? Si riusa la stessa descrizione. Un’intera configurazione va ricreata dopo un guasto? Si riparte dal testo, non dalla memoria. Ciò che era una procedura manuale lunga e soggetta a dimenticanze diventa un’operazione ripetibile.
Revisione. Quando l’infrastruttura è testo, ogni modifica si può leggere e discutere prima di applicarla, ed eventualmente far verificare a una macchina come avviene in una pipeline CI/CD, esattamente come si fa con il codice di un’applicazione. Si vede in anticipo cosa cambierà, un collega può controllare, e resta uno storico di chi ha cambiato cosa. Un’apertura di porta sul firewall smette di essere un clic invisibile e diventa una riga che qualcuno ha scritto, con una data e un motivo.
Meno errori umani. Configurare tante cose a mano, magari in fretta, è il terreno ideale per le sviste: una regola dimenticata su un server, un parametro diverso tra due ambienti che dovrebbero essere identici. Descrivere tutto in un file e lasciare che sia una macchina ad applicarlo elimina buona parte di questi scarti. La stessa descrizione produce la stessa infrastruttura, senza variazioni introdotte dalla stanchezza o dalla fretta.
Documentazione implicita. Nella maggior parte dei progetti la documentazione dell’infrastruttura o non esiste, o è vecchia. Con l’IaC il problema si attenua alla radice: i file sono la descrizione aggiornata di ciò che gira davvero, perché sono la stessa cosa che l’ha creato. Non c’è un documento separato che rischia di divergere dalla realtà: la realtà è il documento.
Stato desiderato e idempotenza
Due concetti aiutano a capire come funziona un sistema IaC, e ricorrono in quasi tutti gli strumenti.
Il primo è lo stato desiderato. Con l’approccio manuale si danno comandi imperativi, uno dopo l’altro: “crea questa macchina”, “poi apri questa porta”, “poi installa questo”. Con l’IaC si fa il contrario: si descrive il risultato finale che si vuole ottenere - lo stato desiderato - e si lascia allo strumento il compito di capire quali passi servono per arrivarci. Non si dice come fare, si dice cosa deve esistere. Questo modo di ragionare si chiama dichiarativo, e ha un vantaggio pratico: la descrizione resta valida sia che si parta da zero, sia che quasi tutto esista già.
Il secondo è l’idempotenza. È un termine tecnico per un’idea semplice: applicare la stessa descrizione una volta o dieci volte porta allo stesso risultato. Se l’infrastruttura corrisponde già a quanto scritto, applicare di nuovo non crea doppioni e non cambia nulla. Questa proprietà è ciò che rende gli strumenti IaC sicuri da rieseguire: non c’è il rischio che lanciare due volte lo stesso file raddoppi i server. Lo strumento confronta ciò che c’è con ciò che è descritto, e agisce solo sulla differenza.
Come si presenta in pratica
Un file IaC assomiglia a una serie di descrizioni ordinate. Ecco, a titolo di esempio, come si potrebbe descrivere una singola macchina virtuale con Terraform, uno degli strumenti più diffusi:
resource "aws_instance" "web" { instance_type = "t3.micro"
tags = { Name = "web-server" }}Non serve conoscere la sintassi per cogliere il senso: il blocco dice “deve esistere una macchina virtuale di questo tipo, chiamata web-server”. Non spiega come crearla, dice solo che deve esistere. È testo, quindi si può leggere, commentare, versionare.
Il ciclo di lavoro tipico è composto da pochi passi ricorrenti. Prima si scrive la descrizione. Poi si chiede allo strumento un’anteprima - spesso chiamata plan - che confronta il testo con la realtà e mostra esattamente cosa creerebbe, modificherebbe o eliminerebbe, senza toccare ancora niente. Solo dopo aver letto e approvato quell’anteprima si passa ad applicarla, e a quel punto lo strumento esegue le modifiche nell’ordine giusto. Questo passaggio di anteprima è una delle differenze più importanti rispetto al lavoro manuale: si vede cosa succederà prima che succeda.
Terraform e l’ecosistema
Quando si parla di IaC per infrastrutture cloud, lo strumento più citato è Terraform, sviluppato dall’azienda HashiCorp. La documentazione ufficiale lo descrive come uno strumento che permette di “costruire, cambiare e versionare risorse cloud e on-prem in modo sicuro ed efficiente”, definendole in file di configurazione leggibili.
Terraform usa un proprio linguaggio, l’HCL (HashiCorp Configuration Language), pensato per essere leggibile anche da chi non lo conosce a fondo. Non parla direttamente con ogni piattaforma: usa dei provider, cioè componenti che traducono la descrizione nelle chiamate specifiche di un servizio - Amazon Web Services, Google Cloud, Azure, e molti altri. HashiCorp e la comunità hanno scritto migliaia di provider, disponibili in un registro pubblico, il che spiega perché lo stesso approccio funzioni su piattaforme molto diverse. Terraform tiene inoltre un file di stato che gli serve da riferimento su ciò che ha già creato.
Vale la pena sapere una cosa sul contesto. Nel 2023 HashiCorp ha cambiato la licenza di Terraform, passando da una licenza open source alla Business Source License, più restrittiva. In risposta, parte della comunità ha creato una versione derivata e indipendente chiamata OpenTofu, oggi ospitata dalla Linux Foundation e mantenuta open source. Per la maggior parte di chi usa questi strumenti per gestire la propria infrastruttura la differenza pratica quotidiana è minima, ma è utile saperlo per orientarsi: Terraform resta lo strumento più diffuso, e non è più l’unico.
In sintesi
L’Infrastructure as Code sposta l’infrastruttura da una serie di clic difficili da ricordare a una descrizione in file di testo, leggibile e versionata. I vantaggi sono concreti: si ricrea tutto allo stesso modo, si rivede ogni modifica prima di applicarla, si riducono gli errori manuali e la descrizione diventa essa stessa la documentazione. Alla base ci sono due idee: dichiarare lo stato desiderato invece di dare comandi passo passo, e l’idempotenza, che rende sicuro riapplicare la stessa descrizione. Terraform è oggi lo strumento più diffuso per farlo, ma il valore vero non è lo strumento: è smettere di affidare l’infrastruttura alla memoria e iniziare a scriverla.
