Terraform Fundamentals

Ciao, sono Alex di DEV STORIES DOT EU. Terraform Fundamentals, episodio 1 di 13. Un tempo, fare il provisioning dei server significava aprire un helpdesk ticket e aspettare due settimane che qualcuno cliccasse all'interno di una cloud console. Oggi, lo stesso identico processo è una semplice pull request che fa il deploy in modo sicuro in pochi minuti. Questo cambiamento è interamente guidato dal paradigma Infrastructure as Code, e HashiCorp Terraform è il motore principale che lo alimenta. Infrastructure as Code è esattamente quello che sembra. Gestisci i tuoi database, le virtual network e le compute instance usando dei semplici file di testo al posto dei click manuali. Questi file possono essere version-controlled, revisionati dai colleghi e testati automaticamente. Per capire perché questo sia così potente, pensa a un system administrator che ha bisogno di una nuova virtual machine su Azure. Usando un imperative workflow, potrebbe scrivere un complesso script PowerShell. Quello script deve definire esplicitamente ogni azione in ordine. Dice al sistema di fare il log in, controllare se esiste una network, crearla se non c'è, allocare un IP pubblico e infine fare il boot del server. Se lo script fallisce al quarto passaggio, ti ritrovi con un'infrastruttura costruita a metà. Lanciare lo script una seconda volta spesso causa errori perché alcune risorse esistono già. Terraform usa invece un declarative approach. Non scrivi la sequenza dei passaggi. Definisci semplicemente l'end-state desiderato. Scrivi un configuration file in cui dichiari di volere una virtual machine su Azure collegata a una network specifica. Terraform confronta lo state richiesto con quello che esiste attualmente nel cloud. Poi calcola l'esatta sequenza di API call necessarie per colmare quel divario. Se la network esiste già, Terraform la lascia stare e costruisce solo il server. Ecco il punto chiave. Molti engineer confondono i tool di infrastructure provisioning come Terraform con i tool di configuration management come Chef, Puppet o Ansible. Non sono la stessa cosa. Terraform costruisce la casa. I tool di configuration management sistemano i mobili. Terraform fa il provisioning delle risorse cloud grezze, come i load balancer e le virtual machine. Ansible o Chef poi fanno il log in su quelle macchine per installare i pacchetti software e avviare i background service. I tool di configuration management sono stati fondamentalmente progettati per la mutable infrastructure. Si aspettano che un server viva a lungo e subisca costanti patching e tweaking. Terraform ti spinge verso la immutable infrastructure. Se un environment ha bisogno di una versione diversa del sistema operativo, Terraform non fa il log in per lanciare un upgrade script. Distrugge il vecchio server e fa il provisioning di uno nuovo di zecca con l'image corretta. Questo approccio rigoroso garantisce che il tuo codice corrisponda sempre alla realtà, eliminando completamente il configuration drift. Questo workflow è particolarmente prezioso perché è platform agnostic. Un'enterprise usa raramente un solo vendor. Potresti far girare i tuoi workload principali su Azure, gestire il tuo DNS tramite Cloudflare e gestire l'incident routing su PagerDuty. Terraform gestisce tutto questo tramite un provider model. Un provider è semplicemente un plugin che capisce una specifica vendor API. Usando più provider, puoi costruire una singola configuration che fa lo spin up di un database Azure, configura i record DNS necessari e imposta i monitoring alert simultaneamente. Le API call sottostanti cambiano, ma il tuo workflow rimane esattamente lo stesso. Se vuoi aiutare a far continuare questi episodi, puoi cercare DevStoriesEU su Patreon per supportare lo show. Un tool che si limita ad automatizzare i task ti rende più veloce, ma un tool che impone un declarative state rende l'intero sistema prevedibile. Vorrei prendermi un momento per ringraziarti per l'ascolto: ci aiuta tantissimo. Buona giornata!

Ciao, sono Alex di DEV STORIES DOT EU. Fondamenti di Terraform, episodio 2 di 13. Fai deploy, guardi la console e incroci le dita, sperando di non aver appena buttato giù l'ambiente di produzione. Questo salto nel vuoto è un rischio enorme, ed è esattamente ciò che il workflow di base di Terraform elimina. Il workflow si compone di tre fasi precise: write, plan e apply. Ogni fase opera in modo indipendente per tradurre i tuoi requisiti in risorse funzionanti. Inizi con la fase di write. Crei dei file di configurazione che dichiarano l'esatta infrastruttura che desideri. Non stai scrivendo uno script procedurale che spiega passo passo come costruire un server. Stai descrivendo lo stato finale e desiderato del tuo ambiente. Salvi questi file e il tuo codice diventa la single source of truth per ciò che dovrebbe esistere. I nuovi utenti a volte pensano che il passo successivo sia semplicemente eseguire questi file in sequenza dall'alto verso il basso. Non è così che funziona questo tool. Non esegue comandi alla cieca. Passa invece alla fase di plan. La fase di plan è il vero superpotere di questo workflow. Quando lanci il comando plan, il tool valuta la tua nuova configurazione rispetto allo stato attuale e reale della tua infrastruttura. Calcola un diff preciso tra la realtà e il codice desiderato. Ecco il punto chiave: il tool legge questo diff e genera un dry run super dettagliato di ogni singola azione che intende eseguire. Pensa a un ingegnere che deve aggiungere un Azure Load Balancer a un ambiente live. Aggiorna i suoi file di configurazione e lancia il comando plan. Il sistema si connette al cloud provider, verifica lo stato attivo e stampa un riepilogo preciso. L'ingegnere legge l'output e vede una risorsa da aggiungere, zero da modificare e zero da distruggere. L'output descrive in dettaglio le esatte proprietà del nuovo Load Balancer. L'ingegnere convalida questo dry run. Sa che la modifica è sicura prima che una singola API call modifichi l'infrastruttura reale. Non si va a tentativi. Dopo aver convalidato l'output, passi alla fase di apply. Questo è il momento dell'esecuzione. Il tool prende l'esatto diff calcolato durante la fase di plan e costruisce un rigoroso execution graph. Mappa tutte le dipendenze. Se il tuo nuovo Load Balancer richiede un indirizzo IP pubblico dedicato, l'execution graph garantisce che l'IP venga provisionato per primo. Il sistema attende che l'IP diventi disponibile, recupera il suo nuovo indirizzo e solo allora crea il Load Balancer. Gestisce automaticamente le tempistiche e l'ordine. Poiché la fase di apply segue rigorosamente l'execution plan approvato, non ti ritrovi mai con risorse che si avviano nell'ordine sbagliato o a cancellare accidentalmente database esistenti a causa di un typo. Il workflow ti costringe a separare l'intenzione dall'esecuzione. L'aspetto più potente di questo processo non è il provisioning automatizzato in sé. È la completa eliminazione dell'ansia operativa grazie a dry run prevedibili e verificabili. Questo è tutto per questo episodio. Grazie per aver ascoltato, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Fondamenti di Terraform, episodio 3 di 13. Di base, l'applicazione core di Terraform non sa effettivamente come creare una Virtual Machine su Azure o un database. È strettamente un engine che valuta il codice, determina le dipendenze e gestisce lo state. Per fare del vero e proprio lavoro, si affida a migliaia di plugin di traduzione scaricabili. Questo ci porta ai provider e a come connetti il tuo codice ad Azure. Un punto di confusione comune è pensare che l'applicazione Terraform stessa contenga la logica per ogni piattaforma cloud. Non è così. Il binario che installi sulla tua macchina è completamente agnostico rispetto all'infrastruttura. Comprende il linguaggio di configurazione e il workflow di deploy, ma ha zero conoscenza hardcoded di qualsiasi API cloud specifica. Invece, Terraform utilizza dei plugin chiamati provider. Un provider è un pezzo di software standalone che comprende gli endpoint, i metodi di autenticazione e i comportamenti delle risorse per una piattaforma specifica. C'è un provider per Microsoft Azure, uno per Amazon Web Services e altri per piattaforme Software as a Service come GitHub o Datadog. Questi plugin sono pubblicati e ospitati in una directory centrale chiamata Terraform Registry. Quando avvii un nuovo progetto infrastrutturale, devi dichiarare esplicitamente quali provider userà il tuo codice. Specifichi anche la versione esatta del provider che desideri. Fare il lock di una versione è una pratica fondamentale. Garantisce che, se l'API cloud cambia o il plugin del provider riceve un major update domani, il tuo deploy non si romperà inaspettatamente. Sei tu a controllare esattamente quando fare l'upgrade. Dichiarare semplicemente il provider nel tuo file di testo non lo installa. Devi lanciare un comando di inizializzazione nel tuo terminale. Questo step di inizializzazione contatta attivamente il Terraform Registry, scarica i plugin dei provider richiesti e li mette in cache in una directory locale nascosta. Finché non esegui questo step, il tuo progetto Terraform non può interagire con nessun sistema esterno. Vediamo come fare il setup per un nuovo progetto che si connette a una subscription enterprise di Azure. Userai il provider ufficiale Azure Resource Manager, chiamato azurerm. Dopo aver dichiarato la versione di cui hai bisogno, devi configurare il comportamento specifico del provider. Ogni provider ha i propri requisiti di configurazione basati sull'API sottostante. Per Azure, il plugin ti richiede di dichiarare esplicitamente come dovrebbe gestire determinati comportamenti delle risorse. Ad esempio, devi dire al provider se deve eliminare permanentemente gli storage disk collegati quando una Virtual Machine viene distrutta. Il provider richiede questa configurazione in anticipo, in modo che le azioni distruttive siano sempre intenzionali. Una volta inizializzato e configurato, il provider agisce come un layer di traduzione plug-and-play. Quando esegui il tuo codice, l'engine core di Terraform calcola la differenza tra la tua infrastruttura attuale e il tuo desired state. Poi passa queste istruzioni generiche al plugin del provider Azure. Il plugin prende il controllo, traducendo il tuo intento in richieste HTTP autenticate inviate direttamente all'API di Azure Resource Manager. Il plugin aspetta che Azure finisca di creare o modificare le risorse, traduce la response dell'API in un formato che Terraform capisce, e restituisce i dati finali al core engine. Terraform stesso non parla mai direttamente con il tuo ambiente cloud; delega ogni singola chiamata API al plugin del provider, rendendo il provider il vero e proprio ponte tra il tuo codice e la tua infrastruttura live. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Terraform Fundamentals, episodio 4 di 13. Guardi il tuo codice e vedi un database etichettato come primary, ma quando fai login nella tua cloud console, quello stesso identico database ha un nome completamente diverso, come db-cluster-node-one. Se vuoi che qualcosa esista fisicamente nel tuo ambiente cloud, devi richiederlo usando il costrutto più importante di Terraform, ma devi anche capire come Terraform assegna i nomi alle cose. Oggi parliamo di come dichiarare l'infrastruttura usando le resource. Le resource sono i componenti fondamentali della tua infrastruttura. Ogni volta che vuoi creare, aggiornare o distruggere un oggetto, scrivi un resource block. Questo oggetto potrebbe essere un componente fisico come una compute instance o uno storage drive, oppure un costrutto logico come un record DNS o un role assignment. Il resource block è il modo in cui traduci l'idea di un componente dell'infrastruttura in una API request che il tuo cloud provider riesce effettivamente a capire. Quando dichiari un resource block, definisci la sua identità usando due label distinte. Per prima cosa, dichiari il resource type. Questo dice a Terraform esattamente che tipo di oggetto vuoi creare e quale provider lo creerà. Il tipo inizia sempre con il namespace del provider, come Azure o AWS, seguito dal servizio specifico. In sostanza, stai dicendo a Terraform che ti serve un resource group di Azure, o uno storage bucket di AWS. Subito dopo il resource type, definisci il local identifier. Si tratta semplicemente di un nickname. Esiste solo all'interno della tua configurazione Terraform. Usi questo nickname per fare riferimento all'oggetto da altre parti del tuo codice. Non ha assolutamente alcun effetto su ciò che vede il tuo cloud provider. Questo ci porta al configuration block vero e proprio. Una volta dichiarati il tipo e il nickname locale, definisci gli argument per quella resource. Gli argument sono i setting e i valori specifici che configurano l'oggetto. È qui che passi i parametri effettivi richiesti dalle API del cloud provider. Per mettere tutto insieme, immagina di fare il deploy di un resource group di Azure. Dichiari il resource type per un resource group di Azure, e gli dai un nickname locale come main. All'interno del configuration block, fornisci gli argument effettivi. Definisci un argument name e lo imposti a rg-enterprise-prod, e definisci un argument location impostandolo su una region specifica. Quando lanci il tuo deploy, Terraform usa il resource type per sapere quali API del provider chiamare. Usa i tuoi argument per dire alle API esattamente come configurare la resource. Nel portale di Azure, il tuo resource group apparirà come rg-enterprise-prod. Azure non sa nulla del nickname main. Ma tornando al tuo codice, ogni volta che devi recuperare l'ID o la location di quel resource group per passarli a una virtual machine o a un database, ti basta chiedere a Terraform i dati contenuti nella resource locale chiamata main. Ogni resource type ha il suo set unico di argument. Alcuni sono obbligatori, come la location per un resource group o l'instance size per un virtual server. Altri sono opzionali, come il tagging o specifiche routing rule. La documentazione del provider stabilisce esattamente quali argument puoi usare. Devi solo mappare i valori che ti servono nel resource block, e Terraform gestisce la traduzione nelle API call che fanno effettivamente il provisioning della tua infrastruttura. Il tuo local identifier appartiene a Terraform per mantenere il tuo codice leggibile, ma i tuoi argument appartengono al cloud per definire la realtà. Grazie per averci seguito. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Fondamenti di Terraform, episodio 5 di 13. Se un database deve esistere prima che un web server possa connettersi ad esso, come fa un tool di infrastruttura a sapere quale creare per primo senza script sequenziali? Se vieni da un background di scripting imperativo come Bash o Python, potresti cercare un modo per forzare l'esecuzione riga per riga. Ma in Terraform, l'ordine delle righe nel tuo file non ha alcuna importanza. L'unica cosa che conta sono le relazioni e le dipendenze tra le resource. Terraform è un execution engine estremamente intelligente. Prima di creare qualsiasi cosa, analizza la tua configurazione e costruisce un grafo aciclico diretto. Questo grafo mappa esattamente come ogni elemento dell'infrastruttura si connette agli altri. Usa questa mappa per determinare l'ordine di creazione più efficiente, creando in parallelo le resource non correlate e mettendo in sequenza quelle che dipendono l'una dall'altra. Non scrivi mai script manuali di wait o sleep. Nella maggior parte dei casi, Terraform determina automaticamente questa sequenza tramite le dipendenze implicite. Una dipendenza implicita si verifica quando una resource fa riferimento a un attribute di un'altra resource. Considera uno scenario in cui stai creando una Virtual Network di Azure e una Subnet. Una subnet non può esistere senza una Virtual Network. Nella tua configurazione, definisci il block della Virtual Network e poi definisci il block della subnet. All'interno del block della subnet, imposti l'argument del nome della Virtual Network in modo che punti direttamente all'attribute del nome della resource Virtual Network che hai appena definito. Quando Terraform parsa questo codice, vede la connessione. Sa implicitamente che deve finire di creare la Virtual Network e recuperare il suo nome generato prima ancora di poter iniziare a creare la subnet. Non devi dirgli cosa fare. Passi semplicemente i dati, e Terraform gestisce le tempistiche. Questa è la parte che conta. Usa sempre le dipendenze implicite se puoi. Facendo riferimento direttamente agli attribute, dai a Terraform le informazioni esatte di cui ha bisogno per ottimizzare i tuoi deploy in modo sicuro. A volte la relazione tra due resource non è visibile nel codice. Potresti avere una situazione in cui una resource richiede che un'altra resource sia completamente attiva, ma non ha effettivamente bisogno di recuperare alcun dato da essa. Considera di fare il deploy di una Virtual Machine che fa girare un'applicazione, mentre fai anche il provisioning di un database gestito. L'applicazione ha bisogno che il database finisca il boot prima di poter partire. Tuttavia, la configurazione della Virtual Machine non fa riferimento ad alcun attribute della resource del database. Poiché non c'è alcun data link, Terraform presume che queste due resource siano completamente slegate e cercherà di crearle allo stesso tempo. L'applicazione farà il boot, cercherà un database che non esiste ancora e fallirà. Per risolvere questo problema, usi le dipendenze esplicite. Terraform fornisce un meta-argument chiamato depends on. Aggiungi questo argument al block della Virtual Machine e gli passi una lista che contiene la resource del database. Questo dice esplicitamente a Terraform di mettere in pausa la creazione della Virtual Machine finché il database non ha completamente finito il provisioning. Dovresti trattare le dipendenze esplicite come ultima spiaggia. Forzano Terraform a essere più conservativo nella sua esecuzione, il che rallenta i tuoi deploy. Possono anche rendere la tua configurazione più difficile da mantenere nel tempo, dato che il vero motivo della dipendenza non è sempre ovvio al prossimo engineer che leggerà il file. Lasciare che sia l'execution graph a fare il lavoro sporco è ciò che separa l'infrastruttura dichiarativa dagli script procedurali, quindi smetti di cercare di microgestire l'ordine di esecuzione e lascia che sia il data flow a dettare la sequenza. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Terraform Fundamentals, episodio 6 di 13. Scrivi il codice della tua infrastruttura, esegui apply e i tuoi server si avviano perfettamente. Ma se esegui di nuovo apply cinque minuti dopo, non succede nulla. Terraform sa che il lavoro è già stato fatto. A differenza dei semplici script di automazione che eseguono i comandi alla cieca, Terraform ha una memoria. Senza di essa, sarebbe completamente cieco rispetto all'infrastruttura che ha appena finito di costruire. Questa memoria si chiama Terraform State. Quando esegui Terraform, crea un file locale chiamato terraform dot tfstate. Molti engineer all'inizio vedono questo file come una seccatura. Sembra un artifact in più da gestire e mettere in sicurezza. Ma questo file è il cuore di come opera Terraform. Terraform ha bisogno di un meccanismo per mappare le resource logiche definite nei tuoi file di configurazione agli oggetti fisici remoti che vivono nel tuo ambiente cloud. Un malinteso comune è che Terraform si limiti a guardare i tag del cloud provider per capire cosa gestisce. Potresti pensare che assegni un tag a un server durante la creazione, e che in seguito cerchi nel cloud quel tag specifico per sapere cosa aggiornare. Questo approccio crolla in fretta. Non tutte le risorse cloud supportano i tag. Inoltre, qualcuno potrebbe modificare o eliminare un tag a mano, rompendo il collegamento. Infine, cercare tag specifici in un enorme account cloud enterprise ogni volta che esegui un plan sarebbe incredibilmente lento. Dato che i tag non sono affidabili, Terraform usa uno state file dedicato e altamente strutturato. Lo state file fa da database di mapping privato. Quando dichiari una resource nel tuo codice, Terraform la crea tramite le API del provider. Il provider restituisce un identificatore fisico univoco per l'oggetto appena creato. Terraform prende il nome logico della tua resource dal codice, lo associa a quel cloud ID univoco e scrive la coppia nello state file. Prendi uno scenario pratico. Decidi di cambiare la size di una virtual machine Azure nel tuo codice. Quando esegui apply, Terraform non tira a indovinare quale macchina modificare. Controlla lo state file, cerca il nome logico della tua resource e recupera l'esatto instance ID di Azure. Poi invia una richiesta di update puntando a quello specifico ID. Senza lo state file, Terraform non saprebbe se fare l'update di una macchina esistente o crearne semplicemente un duplicato. Oltre al mapping, lo state gestisce il tracciamento dei metadati. Terraform deve conoscere l'ordine esatto in cui le resource sono state create per poterne fare l'update o il destroy in modo sicuro. Se un web server richiede un database, quella dipendenza è scritta nel tuo codice. Tuttavia, se elimini quell'intero blocco di codice per buttare giù l'ambiente, Terraform non può più leggere il codice per trovare la dipendenza. Lo state file conserva una copia di questi metadati storici, assicurandosi che Terraform faccia il destroy del web server prima del database. Lo state fornisce anche un caching cruciale per le performance. Interrogare le API di un cloud provider per recuperare lo stato attuale di migliaia di regole di rete, storage bucket e compute node richiede una quantità di tempo notevole. I cloud provider impongono anche rigidi API rate limit. Lo state file fa da cache per gli attributi della tua infrastruttura. Facendo riferimento a questa cache, Terraform riduce al minimo il numero di chiamate API lente e costose necessarie per calcolare un plan. Ecco il punto chiave. La tua configurazione descrive ciò che vuoi, il cloud provider contiene ciò che esiste realmente, e lo state file è l'unico ponte definitivo che li collega. Per questo episodio è tutto. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Terraform Fundamentals, episodio 7 di 13. L'hardcoding dei valori va bene per un test rapido, ma cosa succede quando devi fare il deploy della stessa identica configurazione sia in un ambiente di sviluppo che in produzione? Non puoi duplicare e riscrivere il codice per ogni nuovo deploy. Il meccanismo che risolve questo problema è la parametrizzazione con le input variables. Le input variables fungono da parametri per un module Terraform. Ti permettono di personalizzare aspetti della tua infrastruttura senza modificare il codice sorgente sottostante. Questo è il passaggio esatto in cui il tuo codice passa da una proof of concept a un template production-ready. Utilizzando le variabili, scrivi la configurazione una sola volta e la riutilizzi ovunque. Prima di entrare nel dettaglio, dobbiamo chiarire un equivoco comune. C'è una netta differenza tra dichiarare una variabile e assegnarle un valore. Dichiarare una variabile indica semplicemente a Terraform che un parametro esiste e ne definisce le regole. Assegnare un valore è l'atto di fornirgli effettivamente dei dati durante un deploy. Dichiari una variabile utilizzando un blocco variable seguito da un nome univoco. All'interno di questo blocco, definisci il data type previsto. Terraform supporta diversi tipi. Una string è un semplice testo. Una list è una sequenza ordinata di valori, come ad esempio più availability zone. Una map è una collection di coppie chiave-valore, ideale per applicare tag di risorsa standard. All'interno del blocco variable, puoi anche impostare un valore di default. Se fornisci un default, la variabile diventa opzionale. Se l'utente non fornisce un valore durante il deploy, Terraform utilizza semplicemente il default. Se non imposti un default, Terraform obbligherà l'utente a fornire un valore prima di procedere. Facciamo un esempio pratico. Supponiamo che tu abbia un deploy su Azure. In questo momento, la tua configurazione richiede esplicitamente una virtual machine di piccole dimensioni chiamata Standard B2s, e fa l'hardcoding di un tag environment come dev. Per rendere il tutto riutilizzabile, sostituisci quel testo hardcoded con una reference. In Terraform, fai riferimento a una input variable digitando var punto seguito dal nome della variabile. Quindi, invece di scrivere Standard B2s, scrivi var punto vm size. Invece di dev, scrivi var punto environment. Ora il tuo codice è flessibile, ma Terraform ha comunque bisogno di sapere quali valori utilizzare quando viene effettivamente eseguito. È qui che entrano in gioco i file di definizione delle variabili. Si tratta di file che terminano in punto tfvars. Un file tfvars è semplicemente una lista di nomi di variabili e dei relativi valori. Per il tuo deploy in produzione, crei un file chiamato prod punto tfvars. Al suo interno, imposti la variabile environment su prod e la variabile vm size su un'istanza più grande, come Standard D4s. Quando esegui Terraform, lo punti verso questo file. Terraform legge il file tfvars, inietta quei valori nelle tue reference var punto, ed effettua il provisioning dell'ambiente di produzione. Domani, puoi puntare lo stesso identico codice Terraform verso un file dev punto tfvars per tirare su un piccolo ambiente di test. Ecco il punto chiave. Mantenere la tua logica completamente separata dai dati specifici dell'ambiente è ciò che rende l'infrastruttura veramente ripetibile. Se trovi utili questi episodi e vuoi supportare lo show, puoi cercare DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Terraform Fundamentals, episodio 8 di 13. Il deploy della tua infrastruttura cloud si conclude perfettamente, ma hai ancora un grosso problema: devi conoscere il suo indirizzo IP pubblico per poterti connettere. Spulciare le dashboard del cloud provider vanifica lo scopo dell'automazione. Hai bisogno di un modo per estrarre quel dato specifico direttamente da Terraform. È qui che entra in gioco l'esposizione dei dati con i valori di output. I valori di output sono essenzialmente i valori di ritorno di una configurazione Terraform. Quando definisci e crei una risorsa, il cloud provider genera dinamicamente alcuni attributi. Sono cose che non puoi sapere prima del deploy, come un indirizzo IP assegnato, una password del database generata o un nome a dominio specifico. Usi i blocchi output per catturare quegli attributi generati dinamicamente ed esporli al mondo esterno. Per definirne uno, scrivi un blocco output seguito da una label. Questa label è semplicemente il nome che vuoi assegnare all'output. All'interno del blocco, definisci un singolo argomento obbligatorio chiamato value. Questo argomento punta al dato specifico che vuoi estrarre. Ad esempio, se crei una macchina virtuale, potresti impostare l'argomento value in modo che punti direttamente all'attributo public IP di quella specifica risorsa macchina. Prendi uno scenario concreto. Hai una pipeline automatizzata che fa il deploy di un nuovo cluster Azure Kubernetes Service. Quando il deploy finisce, i tuoi sviluppatori hanno bisogno dell'endpoint Kubernetes raw generato automaticamente per configurare i loro tool di connessione locali. Senza un output, qualcuno dovrebbe loggarsi nel portale cloud, trovare il cluster e copiare l'URL manualmente. Invece, scrivi un blocco output chiamato cluster endpoint. Imposti il suo value per fare riferimento all'attributo fully qualified domain name del cluster Kubernetes appena creato. Quando Terraform finisce di applicare la tua configurazione, raccoglie tutti i valori di output definiti e li stampa direttamente nella command line interface. La tua pipeline di automazione può quindi leggere quel testo e passare l'endpoint direttamente agli sviluppatori. Puoi anche recuperare questi valori in seguito senza eseguire un nuovo deploy. Ti basta lanciare il comando Terraform output nel tuo terminale. Per gli script di automazione, puoi persino dire a quel comando di restituire i dati come testo raw o in formato JSON, rendendo facile il parsing per altri tool software. A volte i dati che devi mandare in output sono confidenziali, come la password di un database o una chiave privata. Non vuoi che quelle stringhe scorrano sullo schermo di un terminale condiviso o rimangano permanentemente nei log di build della tua continuous integration. Per evitarlo, aggiungi l'argomento sensitive all'interno del blocco output e lo imposti a true. Terraform nasconderà quindi il vero value nella console, sostituendolo con un tag placeholder che indica che il valore è sensitive. Ecco il punto chiave. Impostare un output a sensitive lo nasconde solo dal display del terminale. Non cripta né nasconde i dati all'interno del file di state di Terraform. La password o la chiave è ancora memorizzata in plain text all'interno dei dati di state sul disco o nel tuo backend remoto. Il flag sensitive è puramente un filtro di visualizzazione per la command line interface, non un meccanismo di sicurezza per il tuo storage. I valori di output fungono in definitiva come le API della tua configurazione. Sono il modo strutturato e prevedibile in cui restituisci informazioni critiche agli umani o ai tool di automazione nel momento in cui una run viene completata. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Fondamenti di Terraform, episodio 9 di 13. Non tutta l'infrastruttura del tuo ambiente cloud è stata creata dal codice Terraform che stai scrivendo. Tuttavia, il tuo codice ha comunque bisogno di un modo per connettersi a questi sistemi esistenti in modo sicuro, senza modificarli accidentalmente. Fare query tramite i Data Source è esattamente il modo in cui gestisci questa situazione. Un grande punto di confusione quando impari Terraform è la differenza tra un resource block e un data block. Chiariamo subito questo punto. Un resource block dice a Terraform di creare, aggiornare e avere la proprietà di un oggetto dell'infrastruttura. Un data block esegue solo un lookup in sola lettura. Chiede all'API del provider di trovare un oggetto esistente e di restituirne i dettagli in modo che la tua configurazione possa leggerli. Questa capacità di sola lettura è il fondamento di un'architettura infrastrutturale disaccoppiata. Considera un setup enterprise standard. Un team di networking centralizzato crea e gestisce la Virtual Network aziendale. Come application developer, devi fare il deploy di una Virtual Machine su Azure e collegarla esattamente a quella rete. Non sei tu l'owner del codice di rete. Inoltre, non dovresti hardcodare l'ID univoco della rete nei tuoi file Terraform, perché gli ID hardcodati si rompono facilmente se gli environment vengono ricreati. Invece, ti basta cercare la rete. Lo fai definendo un data block. La sintassi è molto simile a quella di un resource block. Inizi con la keyword data. Poi, specifichi il tipo di data source, come azurerm virtual network. Quindi gli dai un nome locale, come corporate, che userai per farci riferimento più avanti nel tuo codice. All'interno del blocco, definisci gli argomenti di ricerca. Questi agiscono come filtri rigorosi. Potresti passare il nome human-readable della Virtual Network e il resource group a cui appartiene. Terraform utilizza questi argomenti per costruire una query. Quando esegui un Terraform plan, Terraform contatta l'API di Azure e cerca una Virtual Network che corrisponda ai tuoi filtri. Se l'API restituisce esattamente un match, Terraform scarica le proprietà di quella rete in memoria. Se la query restituisce zero match, o se i filtri sono troppo larghi e restituiscono match multipli, Terraform si ferma immediatamente e lancia un errore. Questa rigidità è intenzionale. Ti impedisce di fare accidentalmente il deploy della tua applicazione nella subnet o nell'environment sbagliato. Una volta che il data source ha recuperato con successo le informazioni, puoi estrarne qualsiasi attributo esportato. La sintassi per referenziare un data source è altamente strutturata. Inizi con la parola data, seguita da un punto, il tipo di data source, un punto, il tuo nome locale, e infine l'attributo specifico di cui hai bisogno. Nel nostro scenario, digiteresti data punto azurerm virtual network punto corporate punto id. Passi quella stringa specifica direttamente nel tuo resource block della Virtual Machine, bypassando completamente la necessità di hardcodare un valore statico. Ecco la parte che conta. I data source ti permettono di trattare l'infrastruttura circostante come un servizio dinamico. Non devi costruire l'environment per interagirci, e puoi unire in sicurezza workspace indipendenti semplicemente facendo query sugli identificatori esatti di cui hai bisogno a runtime. Grazie per avermi fatto compagnia. Spero tu abbia imparato qualcosa di nuovo.

Ciao, sono Alex di DEV STORIES DOT EU. Terraform Fundamentals, episodio 10 di 13. Se devi fare il deploy di cinquanta web server identici, l'ultima cosa che vuoi fare è copiare e incollare lo stesso blocco di codice cinquanta volte. Potresti pensare a un tradizionale while-loop o for-loop, ma Terraform non funziona in questo modo. Invece, gestisci la scalabilità a livello di block usando count e for each. Di default, un resource block configura esattamente un oggetto dell'infrastruttura. Per fare il provisioning di più oggetti, aggiungi il meta-argument count all'interno di quel block. Accetta un numero intero. Se imposti count a tre, Terraform fa il provisioning di tre oggetti da quel singolo configuration block. Nel mondo reale, questi oggetti in genere non possono essere strettamente identici. Hanno bisogno di nomi o indirizzi IP univoci. Per gestire questa situazione, Terraform fornisce l'oggetto count dot index. Questa è una variabile speciale disponibile solo all'interno dei block che hanno un argument count. Mettiamo che tu stia facendo il deploy di tre Virtual Machine su Azure. Scrivi un resource block per la Virtual Machine e imposti il count a tre. All'interno del block, assegni il nome della macchina combinando la parola web, un trattino e il valore di count dot index. Dato che l'index parte da zero, Terraform valuta questo block e restituisce tre macchine separate chiamate web-zero, web-one e web-two. Aggiungere count cambia il modo in cui Terraform traccia la risorsa internamente. Una singola risorsa viene indirizzata semplicemente tramite il suo tipo e il nome assegnato. Una volta aggiunto count, quell'indirizzo diventa un array. Ora fai riferimento a istanze specifiche in altre parti del tuo codice usando i loro numeri di index tra parentesi quadre. Count è molto efficiente, ma presenta un rischio meccanico specifico legato all'ordine della lista. Ecco il punto chiave. Count identifica le risorse esclusivamente in base alla loro posizione intera. Se usi una lista di valori per configurare un block con count, la posizione dell'index è l'unica cosa che interessa a Terraform. Se hai tre elementi e cambi il count a due, Terraform distrugge l'ultimo elemento dell'array, l'index due. Se inserisci una nuova string in mezzo alla tua source list, tutte le posizioni di index successive scalano verso il basso. Terraform noterà che la configurazione per l'index uno è cambiata, l'index due è cambiato, e così via. Probabilmente distruggerà e ricreerà un'infrastruttura perfettamente sana solo perché l'ordine della source list è cambiato. Per risolvere questa vulnerabilità, usi invece il meta-argument for each. Mentre count accetta un numero intero, for each accetta una map o un set di string. Anziché creare un array di oggetti indicizzati da numeri sequenziali, for each crea una map di oggetti tracciati da string key esplicite. Se gli passi un set contenente le string frontend e backend, Terraform crea risorse indirizzate esattamente con quei nomi. Se in seguito aggiungi una nuova string, o ne rimuovi una, Terraform aggiunge o distrugge solo quella specifica risorsa. Il resto rimane intatto perché i loro identificatori sono string key fisse, non fragili posizioni numeriche. Usa count quando gli oggetti dell'infrastruttura sono veramente intercambiabili, ma passa a for each nel momento in cui quegli oggetti richiedono identità distinte che devono sopravvivere alle modifiche della tua configuration list. Grazie per averci seguito. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Terraform Fundamentals, episodio 11 di 13. Il tuo singolo file di configurazione Terraform andava bene per un semplice web server, ma man mano che la tua infrastruttura cresce, sta rapidamente diventando un monolite disordinato e illeggibile. Stai copiando e incollando gli stessi resource block più e più volte solo per cambiare una singola stringa del nome o un tag di environment. È ora di smettere di ripeterti e iniziare a creare componenti riutilizzabili con i moduli. Un modulo è un contenitore per più risorse che vengono utilizzate insieme. Se hai familiarità con un qualsiasi linguaggio di programmazione, puoi pensare a un modulo come a una funzione. Scrivi la logica complessa una volta, la incapsuli e poi la richiami più volte da altre parti. In Terraform, ogni configurazione ha già almeno un modulo. I file che si trovano nella tua working directory principale formano quello che viene chiamato root module. Quando il tuo root module fa riferimento a un altro set di file di configurazione, questo secondo set è noto come child module. Considera uno scenario specifico. Un team DevOps centralizzato vuole garantire che ogni storage account creato in azienda sia sicuro di default, con encryption, private endpoint e diagnostic logging rigorosamente applicati. Invece di sperare che ogni sviluppatore dell'applicazione configuri correttamente dieci risorse complesse diverse, il team DevOps crea un modulo standard Secure Azure Storage. Quando un team di sviluppo ha bisogno di storage, non scrive un blocco enorme di definizioni di risorse. Scrive semplicemente un module block nella sua configurazione root. All'interno di quel module block, la primissima cosa che definisce è un argomento source. Il source indica a Terraform esattamente dove trovare i file del child module, che si tratti del path di una directory locale o di un repository remoto. Sotto al source, il team di sviluppo passa gli argomenti. Proprio come quando passi degli argomenti a una funzione, fornisce i dati specifici di cui il child module ha bisogno per funzionare, come un nome univoco per l'applicazione o un identificatore di environment. Questi argomenti vengono mappati direttamente alle variabili di input definite all'interno del child module. Il child module prende questi input, esegue le configurazioni delle risorse sottostanti e crea l'infrastruttura. Il team di sviluppo ottiene automaticamente uno storage compliant, completamente isolato dalla complessità sottostante. Ecco il punto chiave. Spesso si fa confusione su come Terraform gestisce lo scope tra questi moduli. Quando chiami un child module, le risorse al suo interno sono rigorosamente incapsulate. Il tuo root module non può leggere direttamente un indirizzo IP, una connection string o uno storage ID generati all'interno di quel child module. Il child module è una black box. Se il tuo root module ha bisogno di un dato generato all'interno del child module, il child module deve esportarlo esplicitamente usando un output block. Le variabili fungono da parametri di input, e gli output da valori di ritorno. Formano un'interfaccia rigorosa. Una volta che il child module esporta quel dato come output, il root module può finalmente leggerlo. Puoi accedere a questo dato facendo riferimento alla parola module, seguita dal nome specifico che hai assegnato al tuo module block, e infine dal nome dell'output. Se il child module restituisce in output l'ID generato di uno storage account, il tuo root module può recuperarlo usando quella sintassi e passarlo a un database o a una virtual machine che deve connettersi. Il vero potere dei moduli non è solo farti risparmiare righe di codice. È la capacità di definire uno standard architetturale una volta per tutte, nascondere la complessità e presentare un'interfaccia pulita e prevedibile al resto della tua organizzazione. Grazie per l'ascolto. Un saluto a tutti.

Ciao, sono Alex di DEV STORIES DOT EU. Terraform Fundamentals, episodio 12 di 13. Uno state file locale sul tuo hard drive funziona perfettamente quando sviluppi da solo. Ma nel momento in cui due engineer tentano di aggiornare la stessa infrastruttura nello stesso identico secondo, ti trovi di fronte alla ricetta perfetta per corrompere l'environment. Questa è la soglia tra la sperimentazione individuale e la collaborazione in team, e ci porta all'enterprise readiness: remote state e locking. Di default, Terraform scrive la sua visione attuale della tua infrastruttura in un file locale chiamato terraform dot tfstate. Questo file è la source of truth fondamentale che mappa il tuo codice di configurazione alle risorse del mondo reale. Il problema nasce quando aggiungi altre persone al tuo progetto. Se un tuo collega fa una modifica dalla sua macchina, il tuo portatile non ha idea che l'environment sia appena cambiato. Stai operando su informazioni obsolete. A volte, i team cercano di risolvere questo problema facendo il commit dello state file nel loro version control system. Questo è un grave rischio per la sicurezza. Gli state file memorizzano regolarmente dati sensibili, come password del database o chiavi private, in plain text. L'approccio corretto è configurare un remote backend. Invece di salvare lo state file su una macchina locale, Terraform legge e scrive questi dati da un data store centralizzato e sicuro. In genere si tratta di un servizio di object storage come un bucket Amazon S3, un container Azure Blob Storage o un bucket Google Cloud Storage. Quando usi un remote backend, ogni volta che qualcuno lancia un comando, Terraform interroga quello storage centrale per recuperare la fotografia più accurata e aggiornata dell'infrastruttura. Passare a questo setup richiede l'aggiunta di un blocco di configurazione del backend al tuo codice, per definire dove dovrebbe risiedere lo state. Fai attenzione a questa parte. Un errore molto comune è scrivere quella configurazione, salvare il file e dare per scontato che lo state ora sia remoto. Non lo è. Dopo aver aggiunto il blocco del backend, devi lanciare di nuovo terraform init. Lanciare questo comando di inizializzazione è il trigger che dice a Terraform di copiare fisicamente il tuo state file locale esistente e migrarlo sul cloud backend. Spostare lo state file in una posizione condivisa risolve il problema della visibilità, ma ti espone a modifiche concorrenti. Se due pipeline di deploy attivano un aggiornamento simultaneamente, potrebbero entrambe tentare di scrivere contemporaneamente sul remote state file, corrompendolo completamente. Ecco perché i remote backend supportano lo state locking. Considera un environment che utilizza Azure Blob Storage per il suo remote state. Due engineer stanno lavorando su aggiornamenti diversi. L'engineer A lancia un apply. Prima di fare qualsiasi modifica alle risorse cloud effettive, Terraform contatta lo storage container di Azure e piazza un lock sul remote state file. Una frazione di secondo dopo, l'engineer B tenta di lanciare il proprio apply. Terraform controlla il remote backend, rileva il lock attivo e intercetta immediatamente la run dell'engineer B. Invece di entrare in collisione, Terraform si ferma in modo sicuro e restituisce un errore, spiegando che un altro processo detiene attualmente il lock. Una volta che la prima run si completa con successo, Terraform rilascia automaticamente il lock. Implementare un remote backend con lock è il passaggio decisivo per l'infrastructure as code di livello enterprise. Mette al sicuro i tuoi dati sensibili ed elimina pericolose race condition. Il remote state garantisce che, indipendentemente da chi lancia il codice o da dove, tutto il tuo team sia saldamente ancorato alla stessa identica realtà. Grazie per l'ascolto, e happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. Terraform Fundamentals, episodio 13 di 13. Hai scritto la tua configurazione, l'hai testata in locale e hai fatto il deploy delle tue risorse. Ma eseguire modifiche all'infrastruttura dal laptop di uno sviluppatore è un collo di bottiglia, non una strategia. Gli apply manuali portano a state in conflitto, modifiche senza review e rischi per la sicurezza. La vera automazione gira in modo sicuro in una pipeline, triggerata automaticamente dal version control. Questo ci porta agli Enterprise Workflow e alla CI/CD. Quando passi da operatore singolo a un team, il workflow principale di Write, Plan e Apply si sposta completamente dalla tua macchina locale. Il version control diventa la source of truth assoluta. Smetti di lanciare i comandi direttamente, e inizi a lasciare che le pipeline di continuous integration orchestrino le modifiche allo state. Ecco il punto chiave. La pipeline divide la tradizionale fase di plan in due concetti distinti: speculative plan e concrete plan. Capire la differenza è fondamentale per il design della pipeline. Prendi uno sviluppatore che deve aumentare la size di una virtual machine su Azure. Aggiorna la size dell'istanza nella configurazione, fa il commit del codice e apre una Pull Request. In questo preciso istante, la pipeline triggera automaticamente uno speculative plan. Uno speculative plan mostra semplicemente cosa Terraform intende fare. Confronta il codice proposto con il remote state per calcolare il delta, ma è strettamente read-only. Non se ne può fare l'apply in nessun caso. La pipeline prende l'output di questo speculative plan e lo pubblica direttamente come commento di testo sulla Pull Request. Quando un senior engineer fa la review del codice, non vede solo la modifica di sintassi. Vede l'esatto impatto sull'infrastruttura. Sa esattamente quali risorse Azure verranno modificate, create o distrutte prima di dare l'approvazione. Una volta che la Pull Request viene approvata e mergiata nel main branch, la pipeline triggera la seconda fase. Genera un concrete plan su quel main branch. Si tratta di un plan file eseguibile. Dato che il main branch è la source of truth affidabile, la pipeline prende questo concrete plan e ne fa immediatamente l'apply. L'infrastruttura live viene aggiornata automaticamente dal robot, non dall'umano. Far girare Terraform in automazione apre le porte a controlli enterprise avanzati. La policy-as-code, usando framework come Sentinel, si integra direttamente in questa pipeline. Sentinel valuta il plan prima ancora che avvenga l'apply. Se uno sviluppatore richiede per sbaglio un'istanza database che viola le restrizioni di costo o le regole di compliance, il policy engine la segnala e blocca immediatamente la pipeline. Questo workflow automatizzato è ciò che abilita un modello di infrastruttura self-service. I platform engineer creano e testano moduli riutilizzabili, mentre gli application developer inviano semplicemente una Pull Request per richiedere le risorse di cui hanno bisogno. La pipeline fa il plan della modifica, la policy-as-code verifica la compliance, e un collega fa la review dell'intento. L'application team ottiene rapidamente la sua infrastruttura, e il platform team fa rispettare la sicurezza senza fare da blocco manuale. Questo conclude la nostra serie sui fondamenti. Ora sai come Terraform scala da un singolo comando locale a un motore enterprise automatizzato. Il modo migliore per consolidare queste conoscenze è costruire qualcosa, leggere la documentazione ufficiale e sperimentare tu stesso con queste pipeline. Se hai idee per argomenti futuri, visita devstories dot eu. Vorrei prendermi un momento per ringraziarti dell'ascolto: ci aiuta tantissimo. Buona giornata!