Chi ha gestito server per qualche anno conosce la scena: un sistema che funziona perfettamente, configurato a mano anni prima da qualcuno che non c'è più, e che nessuno osa toccare perché non si sa più come sia stato costruito. Se quel server si guasta, ricostruirlo diventa un lavoro di archeologia. L'infrastruttura come codice nasce per evitare esattamente questa situazione.
L'idea
Infrastruttura come codice (Infrastructure as Code, IaC) significa descrivere server, reti, database, regole di firewall, record DNS e permessi in file di testo, invece di crearli a mano da un pannello web o da riga di comando. Questi file vengono letti da uno strumento che crea o modifica le risorse reali per farle corrispondere alla descrizione.
La conseguenza è che l'infrastruttura acquista le stesse proprietà del software:
- è versionata: ogni modifica ha un autore, una data e un motivo nella cronologia del repository;
- è revisionabile: un collega può controllare una modifica prima che venga applicata;
- è riproducibile: lo stesso codice crea ambienti identici per sviluppo, test e produzione;
- è documentata: il codice stesso descrive com'è fatto il sistema.
Dichiarativo e imperativo
Gli strumenti di IaC seguono due approcci diversi.
| Approccio | Cosa descrivi | Esempi di strumenti |
|---|---|---|
| Dichiarativo | Lo stato finale desiderato | Terraform, OpenTofu, CloudFormation, Kubernetes |
| Imperativo | I passi da eseguire | Script di shell, alcuni usi di SDK e Pulumi |
Con l'approccio dichiarativo scrivi «voglio tre macchine virtuali con queste caratteristiche»; lo strumento calcola cosa manca e cosa va cambiato. Con quello imperativo scrivi «crea una macchina, poi un'altra, poi un'altra». Il primo è più robusto, perché eseguirlo due volte non crea sei macchine. Questa proprietà, detta idempotenza, è il cuore dell'IaC: applicare lo stesso codice più volte deve portare sempre allo stesso risultato.
Gli strumenti di gestione della configurazione, come Ansible, si collocano a metà: descrivono uno stato, ma tramite una sequenza ordinata di compiti.
Il problema che risolve: la deriva
Quando le modifiche si fanno a mano, gli ambienti divergono lentamente. Qualcuno apre una porta sul firewall di produzione per un test e dimentica di chiuderla; qualcun altro aumenta la memoria di un server ma non di quello di staging. Dopo qualche mese, staging non rappresenta più la produzione e i test perdono valore.
Questa divergenza si chiama configuration drift. Con l'IaC il codice è la fonte di verità: lo strumento può confrontare lo stato reale con quello dichiarato e segnalare ogni differenza. Le modifiche manuali diventano visibili invece di restare nascoste.
Vantaggi concreti
- Ripristino dopo un disastro: se un'intera regione cloud diventa indisponibile, ricreare l'infrastruttura altrove richiede l'esecuzione del codice, non giorni di ricostruzione a memoria.
- Ambienti temporanei: puoi creare un ambiente completo per provare una modifica e distruggerlo poche ore dopo, pagando solo quel tempo.
- Revisione delle modifiche rischiose: aprire una porta o cambiare un permesso passa per una richiesta di revisione, come il codice applicativo.
- Conoscenza condivisa: un nuovo collaboratore legge il repository e capisce l'architettura senza dover chiedere a chi l'ha costruita.
I limiti da conoscere
L'IaC non è gratuita. Richiede di imparare uno strumento, di mantenere il codice aggiornato e soprattutto di rinunciare alle modifiche manuali. Se metà del team continua a cliccare nel pannello del provider, il codice smette di rappresentare la realtà e diventa più pericoloso che utile.
Alcune risorse si prestano meno: dati dentro i database, contenuti caricati dagli utenti, chiavi generate una volta sola. L'IaC descrive il contenitore, non il contenuto, e non sostituisce i backup.
Infine, un errore nel codice si propaga con la stessa efficienza di una modifica corretta. Per questo gli strumenti dichiarativi mostrano un piano delle modifiche prima di applicarle, ed è importante leggerlo con attenzione.
Come introdurla senza rivoluzioni
Non serve riscrivere tutto in una volta. Un percorso ragionevole:
- Scegli uno strumento adatto al tuo contesto e al tuo provider, preferibilmente uno usato da altri nel team.
- Comincia dalle nuove risorse: tutto ciò che crei da oggi passa dal codice.
- Importa gradualmente le risorse esistenti più importanti, partendo da quelle che cambiano più spesso, come DNS e regole di rete.
- Metti il codice in un repository con revisione obbligatoria e, appena possibile, applicalo tramite una pipeline invece che dal computer di una singola persona.
- Limita i permessi di modifica manuale nel pannello del provider, così il codice resta l'unica via.
Nel mio lavoro la prima risorsa che porto sotto codice è quasi sempre la zona DNS: cambia spesso, un errore ha effetti immediati e visibili, e avere la cronologia di ogni record si rivela utile molto presto.
In sintesi
- L'infrastruttura come codice descrive server, reti e permessi in file versionati invece che con modifiche manuali.
- L'approccio dichiarativo e l'idempotenza permettono di applicare il codice più volte con lo stesso risultato.
- Il codice diventa la fonte di verità e rende visibile la deriva tra ambienti.
- Funziona solo se si smette di modificare le risorse a mano, e non sostituisce i backup dei dati.
- Conviene iniziare dalle nuove risorse e importare gradualmente quelle esistenti.
