21 lug 2025·8 min
Terraform e Vagrant: collegare infrastruttura e delivery
Scopri come gli strumenti di Mitchell Hashimoto—Terraform e Vagrant—aiutano i team a standardizzare l’infrastruttura e creare workflow di delivery ripetibili.
Scopri come gli strumenti di Mitchell Hashimoto—Terraform e Vagrant—aiutano i team a standardizzare l’infrastruttura e creare workflow di delivery ripetibili.
La delivery ripetibile non riguarda solo il rilascio di codice. Significa poter rispondere con sicurezza: Cosa cambierà? Perché cambierà? E possiamo farlo di nuovo domani? Quando l’infrastruttura è costruita a mano—o le macchine degli sviluppatori divergeno nel tempo—la delivery diventa un gioco d’indovinelli: ambienti diversi, risultati diversi e tanti “funziona sul mio laptop”.
Terraform e Vagrant restano rilevanti perché riducono quell’imprevedibilità da due lati: infrastruttura condivisa e ambienti di sviluppo condivisi.
Terraform descrive l’infrastruttura (risorse cloud, networking, servizi gestiti e talvolta anche configurazioni SaaS) come codice. Invece di cliccare in una console, definisci ciò che vuoi, rivedi un piano e applichi cambiamenti in modo coerente.
Lo scopo non è “fare qualcosa di sofisticato”. È rendere le modifiche all’infrastruttura visibili, revisionabili e ripetibili.
Vagrant crea ambienti di sviluppo coerenti. Aiuta i team a eseguire la stessa configurazione di base—OS, pacchetti e configurazione—sia che siano su macOS, Windows o Linux.
Anche se oggi non usi quotidianamente macchine virtuali, l’idea centrale di Vagrant è ancora importante: gli sviluppatori dovrebbero partire da un ambiente noto e funzionante che rispecchi come il software funziona realmente.
Questo è un walkthrough pratico pensato per non specialisti che vogliono meno termini di marketing e più chiarezza. Tratteremo:
Alla fine dovresti poter valutare se Terraform, Vagrant o entrambi sono adatti al tuo team—e come adottarli senza creare un nuovo livello di complessità.
Mitchell Hashimoto è noto per aver creato Vagrant e per essere cofondatore di HashiCorp. Il contributo duraturo non è un singolo prodotto—è l’idea che gli strumenti possano codificare il workflow di un team in qualcosa di condivisibile, revisionabile e ripetibile.
Quando si dice che “il tooling è un ponte”, si intende colmare il divario tra due gruppi che vogliono lo stesso risultato ma parlano linguaggi quotidiani diversi:
La prospettiva di Hashimoto—riflessa dagli strumenti HashiCorp—è che il ponte è un workflow che tutti possono vedere. Invece di passare istruzioni tramite ticket o conoscenza tribale, i team catturano le decisioni in file di configurazione, li versionano e eseguono gli stessi comandi nello stesso ordine.
Lo strumento diventa l’arbitro: standardizza i passaggi, registra cosa è cambiato e riduce le discussioni “funzionava sul mio computer”.
I workflow condivisi trasformano infrastruttura e ambienti in un’interfaccia trattata come un prodotto:
Questa impostazione mantiene l’attenzione sulla delivery: gli strumenti non servono solo ad automatizzare, servono a creare accordo. Terraform e Vagrant si inseriscono in questa mentalità perché rendono esplicito lo stato desiderato e incoraggiano pratiche (versioning, revisione, esecuzioni ripetibili) che scalano oltre la memoria di una singola persona.
La maggior parte dei dolori nella delivery non è causata da “codice cattivo”. È causata da ambienti non corrispondenti e da passaggi manuali invisibili che nessuno sa descrivere completamente—fino a quando qualcosa non si rompe.
I team spesso partono con una configurazione funzionante e poi fanno piccole modifiche ragionevoli: un aggiornamento di un pacchetto, una modifica al firewall, un hotfix su un server perché “è urgente”. Settimane dopo, il laptop del dev, la VM di staging e la produzione sono tutti leggermente diversi.
Quelle differenze emergono come errori difficili da riprodurre: i test passano in locale ma falliscono in CI; lo staging funziona ma la produzione restituisce 500; un rollback non ripristina il comportamento precedente perché il sistema sottostante è cambiato.
Quando gli ambienti vengono creati a mano, il processo reale vive nella memoria tribale: quali pacchetti OS installare, quali servizi avviare, quali impostazioni del kernel modificare, quali porte aprire—e in quale ordine.
I nuovi arrivati perdono giorni a mettere insieme una macchina “abbastanza simile”. Gli ingegneri senior diventano un collo di bottiglia per domande di setup di base.
I fallimenti sono spesso banali:
.env in locale, ma recuperate diversamente in produzione—i deploy falliscono o, peggio, i segreti vengono esposti.Questi problemi si traducono in onboarding più lento, lead time più lunghi, outage imprevisti e rollback dolorosi. I team rilasciano meno frequentemente, con meno fiducia, e passano più tempo a diagnosticare “perché questo ambiente è diverso” invece di migliorare il prodotto.
Terraform è Infrastructure as Code (IaC): invece di navigare la console cloud sperando di ricordare ogni impostazione, descrivi la tua infrastruttura in file.
Quei file vivono tipicamente in Git, quindi le modifiche sono visibili, revisionabili e ripetibili.
Pensa alla configurazione Terraform come a una “ricetta di build” per l’infrastruttura: reti, database, bilanciatori, record DNS e permessi. Non stai documentando ciò che hai fatto a posteriori—stai definendo ciò che deve esistere.
Questa definizione è importante perché è esplicita. Se un collega ha bisogno dello stesso ambiente, può usare la stessa configurazione. Se devi ricreare un ambiente dopo un incidente, puoi farlo dallo stesso sorgente.
Terraform ruota attorno all’idea di stato desiderato: dichiari ciò che vuoi e Terraform calcola quali cambi sono necessari per arrivarci.
Un loop tipico è:
Questo approccio “preview poi apply” è dove Terraform dà il meglio per i team: supporta la code review, le approvazioni e rollout prevedibili.
“IaC significa fully automated.” Non necessariamente. Puoi (e spesso dovresti) mantenere checkpoint umani—specialmente per i cambi in produzione. IaC riguarda la ripetibilità e la chiarezza, non l’esclusione delle persone dal processo.
“Un solo strumento risolve tutti i problemi.” Terraform è ottimo per il provisioning e la modifica dell’infrastruttura, ma non sostituisce una buona architettura, monitoring o disciplina operativa. Non gestisce tutto allo stesso modo (alcune risorse sono meglio gestite da altri sistemi), quindi funziona meglio come parte di un workflow più ampio.
Il compito di Vagrant è semplice: fornire a ogni sviluppatore lo stesso ambiente funzionante, su richiesta, da un’unica configurazione.
Al centro c’è il Vagrantfile, dove descrivi l’immagine base (una “box”), CPU/RAM, networking, cartelle condivise e come la macchina deve essere configurata.
Poiché è codice, l’ambiente è revisionabile, versionato e facile da condividere. Un nuovo collega può clonare il repo, eseguire un comando e ottenere una configurazione prevedibile che include la versione OS giusta, i pacchetti, i servizi e i default.
I container sono ottimi per impacchettare un’app e le sue dipendenze, ma condividono il kernel dell’host. Questo significa che puoi comunque incontrare differenze nel networking, nel comportamento del filesystem, nei servizi di background o negli strumenti a livello OS—specialmente quando la produzione è più simile a una VM completa che a un runtime per container.
Vagrant usa tipicamente macchine virtuali (via provider come VirtualBox, VMware o Hyper-V). Una VM si comporta come un vero computer con il proprio kernel e init system. Questo la rende più adatta quando devi testare cose che i container non modellano bene: servizi di sistema, impostazioni del kernel, regole iptables, networking multi-NIC o problemi specifici di una distro (es. “si rompe solo su Ubuntu 22.04”).
Non è una gara: molti team usano container per il packaging dell’app e Vagrant per sviluppo e testing full-system realistici.
In breve, Vagrant è meno “virtualizzazione fine a sé stessa” e più “fare dell’ambiente di sviluppo un workflow condiviso di cui l’intero team si può fidare”.
Terraform e Vagrant risolvono problemi diversi, ma insieme creano un percorso chiaro da “funziona sul mio PC” a “gira in modo affidabile per tutti”. Il ponte è la parità: mantenere coerenti le ipotesi dell’app mentre cambia il luogo in cui gira.
Vagrant è la porta d’ingresso. Fornisce a ogni sviluppatore un ambiente locale ripetibile—stesso OS, stessi pacchetti, stesse versioni di servizio—così l’app parte da una baseline nota.
Terraform è le fondamenta condivise. Definisce l’infrastruttura su cui i team fanno affidamento insieme: reti, database, compute, DNS, bilanciatori e regole di accesso. Quella definizione diventa la fonte di verità per test e produzione.
La connessione è semplice: Vagrant ti aiuta a costruire e validare l’app in un ambiente che somiglia alla realtà, e Terraform assicura che la realtà (test/prod) sia provisioningata e modificata in modo coerente e revisionabile.
Non usi lo stesso strumento per ogni target—usi lo stesso contratto.
DATABASE_URL e REDIS_URL.Vagrant fa rispettare quel contratto in locale. Terraform lo fa rispettare negli ambienti condivisi. L’app resta la stessa; cambia solo il “dove”.
Laptop (Vagrant): uno sviluppatore esegue vagrant up, ottiene una VM con runtime dell’app più Postgres e Redis. Itera rapidamente e intercetta i problemi “funziona in locale” presto.
Test (Terraform): una pull request aggiorna Terraform per provisioningare un database di test e istanze dell’app. Il team valida il comportamento contro i vincoli infrastrutturali reali.
Produzione (Terraform): gli stessi pattern Terraform vengono applicati con impostazioni di produzione—maggiore capacità, accessi più restrittivi, alta disponibilità—senza reinventare l’impostazione.
Questo è il ponte: la parità locale ripetibile alimenta un’infrastruttura condivisa ripetibile, rendendo la delivery una progressione controllata invece di una reinvenzione a ogni stadio.
Un buon workflow Terraform/Vagrant è meno memorizzare comandi e più rendere i cambi facili da revisionare, ripetere e ripristinare.
L’obiettivo: uno sviluppatore può partire in locale, proporre un cambiamento infrastrutturale insieme a una modifica dell’app e promuovere quel cambiamento attraverso gli ambienti con sorprese minime.
Molti team tengono codice applicativo e infrastruttura nello stesso repository così la storia della delivery resta coerente:
/app — codice applicativo, test, asset di build/infra/modules — moduli Terraform riutilizzabili (rete, database, servizio app)/infra/envs/dev, /infra/envs/test, /infra/envs/prod — layer sottili per ambiente/vagrant — Vagrantfile più script di provisioning per rispecchiare le dipendenze “reali”Il pattern importante è “env sottili, moduli spessi”: gli ambienti principalmente selezionano input (dimensioni, conteggi, nomi DNS), mentre i moduli condivisi contengono le definizioni reali delle risorse.
Un approccio trunk-based semplice funziona bene: branch di feature a vita breve, merge tramite pull request.
In fase di review richiedi due artefatti:
terraform fmt, validate e produce l’output di terraform plan per la PR.I revisori dovrebbero poter rispondere a “Cosa cambierà?” e “È sicuro?” senza dover ricreare nulla localmente.
Promuovi lo stesso set di moduli da dev → test → prod, mantenendo le differenze esplicite e piccole:
Evita di copiare intere directory per ambiente. Preferisci promuovere cambiando variabili, non riscrivendo definizioni di risorsa.
Quando una modifica all’app richiede nuova infrastruttura (ad esempio una coda o una nuova config), consegnale nella stessa PR così vengono revisionate come un’unica unità.
Se l’infrastruttura è condivisa tra molti servizi, tratta i moduli come prodotti: versionali (tag/release) e documenta input/output come contratto. Così i team possono aggiornare in modo intenzionale invece di divergere accidentalmente verso “quello che è più recente”.
Il superpotere di Terraform non è solo creare infrastruttura—è modificarla in sicurezza nel tempo. Per farlo, ha bisogno di una memoria di ciò che ha creato e di cosa pensa esista.
Lo state di Terraform è un file (o un dato memorizzato) che mappa la tua configurazione alle risorse reali: quale istanza database appartiene a quale aws_db_instance, qual è il suo ID e quali impostazioni sono state applicate l’ultima volta.
Senza state, Terraform dovrebbe indovinare cosa esiste riesaminando tutto, il che è lento, inaffidabile e talvolta impossibile. Con lo state, Terraform può calcolare un piano: cosa verrà aggiunto, modificato o distrutto.
Poiché lo state può includere identificatori di risorse—e talvolta valori che preferiresti non esporre—va trattato come una credenziale. Se qualcuno può leggerlo o modificarlo, può influenzare ciò che Terraform cambia.
La deriva avviene quando l’infrastruttura cambia fuori da Terraform: una modifica in console, un hotfix alle 2 di notte o un processo automatico che altera impostazioni.
La deriva rende i piani futuri sorprendenti: Terraform può cercare di “annullare” la modifica manuale o fallire perché le assunzioni non corrispondono più alla realtà.
I team solitamente archiviano lo state in remoto (piuttosto che sul laptop) così tutti pianificano e applicano contro la stessa fonte di verità. Una buona configurazione remota fornisce anche:
La delivery sicura è per lo più noiosa: uno state, accesso controllato e cambi che passano tramite piani revisionabili.
Terraform diventa davvero potente quando smetti di copiare gli stessi blocchi tra i progetti e inizi a impacchettare pattern comuni in moduli.
Un modulo è un bundle riutilizzabile di codice Terraform che prende input (es. CIDR VPC o dimensione istanza) e produce output (es. ID subnet o endpoint db). Il vantaggio è meno duplicazione, meno setup “snowflake” e delivery più veloce perché i team possono partire da un blocco noto e funzionante.
Senza moduli, il codice infrastrutturale tende a divergere in varianti da copia/incolla: un repo modifica le regole di security group, un altro dimentica un’impostazione di cifratura, un terzo fissa una versione diversa del provider.
Un modulo crea un unico posto per codificare una decisione e migliorarla nel tempo. Anche le revisioni diventano più semplici: invece di riesaminare 200 righe di networking ogni volta, rivedi una piccola interfaccia del modulo (input/output) e il modulo evolve quando serve.
I moduli buoni standardizzano la forma di una soluzione lasciando spazio a differenze importanti.
Esempi di pattern da modularizzare:
Evita di codificare ogni opzione possibile. Se un modulo necessita di 40 input per essere utile, probabilmente sta cercando di coprire troppi casi. Preferisci default sensati e poche decisioni di policy, lasciando escape hatch rare ed esplicite.
I moduli possono trasformarsi in un labirinto se tutti pubblicano versioni leggermente diverse (“vpc-basic”, “vpc-basic2”, “vpc-new”). La sprawl nasce quando non c’è un proprietario chiaro, nessuna disciplina di versioning e nessuna guida su quando creare un nuovo modulo o migliorare uno esistente.
Regole pratiche:
Ben fatto, i moduli trasformano Terraform in un workflow condiviso: i team si muovono più velocemente perché il “modo giusto” è confezionato, scoperto e ripetibile.
Terraform e Vagrant rendono gli ambienti riproducibili—ma rendono anche riproducibili gli errori. Un singolo token compromesso in un repo può propagarsi su laptop, job CI e cambi in produzione.
Alcune abitudini semplici prevengono la maggior parte degli errori comuni.
Tratta “cosa costruire” (configurazione) e “come autenticarsi” (segreti) come due preoccupazioni distinte.
Le definizioni d’infrastruttura, i Vagrantfile e gli input dei moduli dovrebbero descrivere risorse e impostazioni—non password, chiavi API o certificati privati. Recupera invece i segreti a runtime da uno store provato (un vault dedicato, il secret manager del cloud o lo store segreto del CI). Questo mantiene il codice revisionabile e i valori sensibili tracciabili.
Dai a ogni attore solo i permessi di cui ha bisogno:
terraform plan non necessariamente deve poter applicare cambi in produzione. Separa i ruoli così approvazione ed esecuzione non ricadono sempre sulla stessa persona.Evita di inserire credenziali nel codice, file locali che vengono copiati in giro o “chiavi del team” condivise. I segreti condivisi cancellano la responsabilità.
Questi guardrail non rallentano la delivery—ridurreanno l’area di impatto quando qualcosa va storto.
CI/CD è dove Terraform smette di essere “qualcosa che fa una persona” e diventa un workflow di team: ogni cambiamento è visibile, revisionato e applicato nello stesso modo ogni volta.
Una baseline pratica è composta da tre passi, collegati alle pull request e alle approvazioni di deployment:
terraform fmt -check e terraform validate per catturare errori evidenti presto.terraform plan e pubblica l’output sulla PR (come artefatto o commento). I revisori dovrebbero poter rispondere: Cosa cambierà? Dove? Perché?terraform apply usando la stessa revisione di codice che ha prodotto il plan.# Example (GitHub Actions-style) outline
# - fmt/validate on PR
# - plan on PR
# - apply on manual approval
La chiave è separazione: le PR producono evidenza (plan), le approvazioni autorizzano il cambiamento (apply).
Vagrant non sostituisce il CI, ma può far sembrare i test locali di qualità CI. Quando un bug report dice “funziona sul mio computer”, un Vagrantfile condiviso permette a chiunque di avviare lo stesso OS, pacchetti e versioni di servizio per riprodurlo.
Questo è particolarmente utile per:
Se il tuo team sta standardizzando i workflow di delivery, strumenti come Terraform e Vagrant rendono il massimo se abbinati a scaffolding applicativo coerente e passi di rilascio ripetibili.
Koder.ai può aiutare come piattaforma di vibe-coding: i team possono generare una baseline funzionante web/backend/mobile da chat, poi esportare il codice sorgente e inserirlo nello stesso workflow Git descritto sopra (inclusi moduli Terraform e gate CI plan/apply). Non sostituisce Terraform o Vagrant; riduce il tempo per arrivare al primo commit mantenendo pratiche di infrastruttura e ambiente esplicite e revisionabili.
Per evitare che l’automazione diventi automazione accidentale:
Con questi guardrail, Terraform e Vagrant supportano lo stesso obiettivo: cambi che sai spiegare, ripetere e di cui ti puoi fidare.
Anche gli strumenti solidi possono generare nuovi problemi se trattati come “imposta e dimentica”. Terraform e Vagrant funzionano meglio quando mantieni chiaro lo scope, applichi alcuni guardrail e resisti alla tentazione di modellare ogni singolo dettaglio.
Deriva di lunga durata: modifiche infrastrutturali fatte “giusto una volta” nella console cloud possono divergere silenziosamente da Terraform. Mesi dopo, l’apply successivo diventa rischioso perché Terraform non descrive più la realtà.
Moduli eccessivamente complessi: i moduli sono ottimi per il riuso, ma possono trasformarsi in un labirinto—dozzine di variabili, moduli nidificati e default “magici” che solo una persona capisce. Il risultato è delivery più lenta, non più veloce.
VM locali lente: le box Vagrant possono diventare pesanti nel tempo (immagini grandi, troppi servizi, provisioning lento). Gli sviluppatori iniziano a saltare la VM e l’“ambiente ripetibile” diventa opzionale—fino a quando qualcosa si rompe in produzione.
Mantieni Vagrant quando hai bisogno di un ambiente a livello OS completo che rispecchi il comportamento di produzione (system services, differenze di kernel, networking) e il team beneficia di una baseline nota.
Sposta sui container quando la tua app gira bene in Docker, vuoi avvii più rapidi e non ti servi del confine kernel di una VM. I container spesso riducono il problema “la mia VM è lenta”.
Usa entrambi quando hai bisogno di una VM per emulare l’host (o eseguire infrastruttura di supporto), ma l’app gira in container dentro quella VM. Così bilanci realismo e velocità.
Suggested links: /blog/terraform-workflow-checklist, /docs, /pricing
Terraform rende le modifiche all’infrastruttura esplicite, revisionabili e ripetibili. Invece di fare tutto con i clic sulla console o affidarsi a runbook, si commettono configurazioni in controllo versione, si usa terraform plan per anticipare l’impatto e si applicano le modifiche in modo coerente.
È più utile quando più persone devono comprendere e modificare in sicurezza un’infrastruttura condivisa nel tempo.
Vagrant fornisce agli sviluppatori un ambiente a livello OS noto e coerente a partire da un singolo Vagrantfile. Riduce i tempi di onboarding, elimina la deriva del tipo “funziona sul mio laptop” e aiuta a riprodurre bug legati a pacchetti OS, servizi o rete.
È particolarmente utile quando le assunzioni di produzione somigliano più a una VM che a un container.
Usa Vagrant per standardizzare l’ambiente locale (OS, servizi, impostazioni). Usa Terraform per standardizzare gli ambienti condivisi (rete, database, compute, DNS, permessi).
L’idea di connessione è un “contratto” stabile (porte, variabili d’ambiente come DATABASE_URL, presenza dei servizi) che resta coerente mentre si passa da laptop → test → produzione.
Inizia con una struttura che separa i blocchi riutilizzabili dalle impostazioni specifiche dell’ambiente:
/infra/modules/infra/envs/dev, /infra/envs/prod)/vagrantIn questo modo la promozione tra ambienti diventa per lo più una , non una riscrittura o copia/incolla.
Lo “state” di Terraform è il modo in cui Terraform ricorda quali risorse reali corrispondono alla tua configurazione. Senza stato, Terraform non può calcolare cambi sicuri.
Tratta lo state come una credenziale:
La deriva succede quando l’infrastruttura reale cambia al di fuori di Terraform (modifiche in console, hotfix d’emergenza, processi automatici). Rende i piani futuri imprevedibili e può portare Terraform a ripristinare o a fallire.
Modi pratici per ridurre la deriva:
plan regolarmente (per esempio sulle PR)Usa i moduli per standardizzare pattern comuni (rete, database, deployment dei servizi) ed evitare duplicazioni. Un buon modulo ha:
Evita moduli con troppi parametri: se servono 40 variabili probabilmente stai cercando di coprire troppi casi.
Separa configurazione e segreti:
Vagrantfileplan e apply, controlli più severi per produzioneRicorda che lo state può contenere identificatori sensibili e proteggilo di conseguenza.
Una pipeline minima e scalabile:
terraform fmt -check e terraform validateterraform plan per la revisioneterraform apply usando la stessa revisione di codice che ha prodotto il planQuesto mantiene le modifiche auditabili: i revisori possono rispondere a “cosa cambierà?” prima che accada.
Mantieni Vagrant se hai bisogno di:
Considera i container se vuoi avvii più rapidi e la tua app non dipende dal comportamento della VM. Molte squadre usano entrambi: container per l’app e Vagrant per un host che assomiglia a produzione.