Pulumi: Infrastructure as Code

Ciao, sono Alex di DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 1 di 10. E se potessi scrivere la tua infrastruttura cloud usando esattamente lo stesso linguaggio di programmazione che usi per la tua applicazione? Basta context-switching tra la logica della tua applicazione e migliaia di righe di markup custom. L'episodio "L'infrastruttura per sviluppatori: perché Pulumi?" affronta esattamente questo cambiamento. Storicamente, Infrastructure as Code significava scrivere domain-specific language o infiniti blocchi di YAML. Se volevi fare il deploy di un database e di un server, dovevi imparare una sintassi esclusiva per quello specifico tool di provisioning. Perdevi il ricco ecosistema della software engineering standard. Non potevi scrivere facilmente un loop, integrare framework di testing standard o condividere la logica usando package registry standard. Pulumi cambia queste fondamenta. È una piattaforma di Infrastructure as Code che ti permette di creare, fare il deploy e gestire risorse cloud usando linguaggi di programmazione general-purpose. Invece di imparare un linguaggio di configurazione custom, usi TypeScript, Python, Go, C# o Java. Pensa a uno sviluppatore che definisce risorse cloud usando TypeScript. Con i tool tradizionali, fai continuamente context-switching per cercare gli schema YAML in un web browser. Con Pulumi, resti nel tuo editor. Istanzi una classe di risorse, digiti un punto e l'auto-completion standard dell'IDE ti mostra esattamente quali proprietà sono disponibili. Hai il type-checking inline prima ancora di lanciare un deploy. Se ti servono tre storage bucket identici, scrivi un normale for-loop. Se la tua azienda impone regole di sicurezza specifiche su ogni server, astrai quella logica in una funzione standard, la pubblichi su un package registry standard e permetti agli altri team di importarla proprio come una normale library di codice. Ecco il punto chiave. Dato che scrivi questa infrastruttura in linguaggi imperativi, potresti pensare che Pulumi sia solo uno script di automazione che chiama le API cloud in sequenza. Non è uno script di esecuzione imperativo. Dietro le quinte, Pulumi usa comunque uno state model dichiarativo estremamente robusto. Quando esegui il tuo programma Pulumi, non fa immediatamente il provisioning delle risorse riga per riga. Invece, il tuo codice gira per costruire lo state finale desiderato della tua infrastruttura. L'engine di Pulumi cattura queste definizioni di risorse e costruisce un dependency graph rigoroso. Poi confronta questo state desiderato con lo state attuale effettivo del tuo ambiente cloud. Pulumi calcola la differenza esatta ed esegue solo le specifiche operazioni di create, update o delete necessarie per far sì che la realtà corrisponda al tuo codice. Scrivi con il flow espressivo di un linguaggio imperativo, ma ottieni la sicurezza e la prevedibilità di un engine di deploy dichiarativo. Adottando linguaggi general-purpose, sblocchi l'accesso a linter, framework di unit testing e pipeline di continuous integration esistenti. Pulumi smette semplicemente di trattare l'infrastruttura come un dominio di configurazione separato e la trasforma in software standard, governato esattamente dallo stesso rigore e tooling della tua applicazione core. Se ti va di supportare lo show, puoi trovarci cercando DevStoriesEU su Patreon. Vorrei prendermi un momento per ringraziarti per l'ascolto: ci aiuta tantissimo. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 2 di 10. Crei un'istanza di una classe Python standard nel tuo editor, fai deploy, e pochi secondi dopo uno storage bucket esiste nel cloud. Come si traduce esattamente un oggetto locale in memoria in una risorsa fisica remota? Oggi rispondiamo a questa domanda guardando sotto il cofano: l'architettura di Pulumi. C'è un falso mito molto comune su come funziona questo tool. Quando scrivi un deployment script, il tuo codice non comunica con le API del cloud. L'ambiente che esegue il tuo codice Python, Node o Go non ha la minima idea di come parlare con Amazon Web Services. Invece, Pulumi divide il processo di deploy in tre componenti distinti: il Language Host, il Deployment Engine e i Resource Provider. Tutto inizia con il Language Host. Questo componente valuta il tuo programma ed estrae il tuo intento. Considera uno script Python in cui dichiari un bucket AWS S3 inizializzando un bucket object. Il Python Language Host esegue il tuo script riga per riga. Quando incontra quella dichiarazione del bucket, non fa una richiesta di rete ad AWS. Invia semplicemente una richiesta di registrazione al Deployment Engine. Dice all'engine che vuoi che esista un bucket con proprietà specifiche. Il Language Host comunica questo desired state tramite una connessione locale e poi si ferma, in attesa di una risposta prima di valutare la riga di codice successiva. Il Deployment Engine riceve questa richiesta di registrazione. Questo componente è l'orchestratore. L'engine non sa nulla della sintassi Python e non sa nulla delle API di AWS. Il suo unico compito è lo state management. Guarda il desired state inviato dal Language Host e lo confronta con l'ultimo actual state noto della tua infrastruttura. Se l'engine vede che questo esatto bucket S3 non esiste nello stato corrente, calcola un diff e determina che è necessaria una create operation. Per costruire effettivamente il bucket, l'engine passa il compito al terzo componente, il Resource Provider. I provider sono plugin standalone scaricati per piattaforme specifiche, come AWS, Azure o Kubernetes. Il Deployment Engine invia un'istruzione all'AWS Resource Provider, dicendogli di creare il bucket con le proprietà richieste. Ecco il punto chiave. Il Resource Provider è l'unico componente in tutta questa chain che sa come parlare con il cloud. Prende il comando di creazione generico dall'engine, lo traduce nelle specifiche chiamate REST API richieste da AWS e le esegue sulla rete. Una volta che AWS fa il provisioning del bucket S3, restituisce un physical resource ID. Il Resource Provider intercetta questo physical ID e lo restituisce al Deployment Engine. L'engine aggiorna il suo stato interno per registrare che il bucket ora esiste nel mondo reale. Infine, l'engine segnala al Language Host che la risorsa è pronta, passandogli eventuali output properties come il nome o l'URL del bucket. Il Language Host riprende l'esecuzione e il tuo script Python continua con l'istruzione successiva. Questa rigorosa separazione tra valutazione del linguaggio, orchestrazione dello stato ed esecuzione nel cloud è ciò che dà all'architettura la sua flessibilità. Puoi aggiungere un nuovo linguaggio di programmazione senza toccare i cloud provider, e aggiungere un nuovo cloud provider senza modificare i Language Host. Per questo episodio è tutto. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 3 di 10. Un tempo, configurare un progetto di infrastruttura cloud significava passare ore a lottare con file boilerplate e strutture di cartelle prima di poter scrivere una singola riga di logica. Oggi, puoi fare lo scaffold di un ambiente completo in pochi secondi. Ci concentriamo su Hello Azure: Creare il tuo primo progetto, per vedere esattamente come succede. Un malinteso comune è pensare che eseguire il comando di creazione del progetto costruisca immediatamente l'infrastruttura nel cloud. Non è così. Il comando di cui stiamo parlando genera solo file locali e prepara il tuo state tracking. Nessuna risorsa Azure viene effettivamente creata finché non esegui esplicitamente un comando di deploy in un secondo momento. Per fare il bootstrap di un nuovo progetto, usi la command line interface. Per prima cosa, crei una directory vuota e ti sposti al suo interno. Quindi, esegui il comando pulumi new seguito dal nome di un template. Per Azure, questo template è solitamente azure dash e il linguaggio di programmazione che preferisci, come azure dash typescript o azure dash python. Quando lo esegui, l'interfaccia diventa interattiva. Ti guida attraverso una serie di prompt per configurare il tuo ambiente. Innanzitutto, ti chiede il nome del progetto, che di default corrisponde al nome della tua directory. Successivamente, ti chiede una descrizione del progetto. Poi ti chiede il nome dello stack. Uno stack è un'istanza isolata del tuo progetto, che in genere rappresenta un ambiente come development o production. Lo stack di default si chiama dev. Infine, i template di Azure ti chiedono una location di Azure, come WestUS, che verrà salvata come tua region di deploy di default. Una volta che rispondi ai prompt, il tool scarica il template, installa le dipendenze necessarie per il linguaggio e crea una manciata di file nella tua directory. Ecco il punto chiave. Il file più importante generato è Pulumi dot yaml. Questo è il file core del tuo progetto. Definisce il nome del progetto, il runtime che usa e la descrizione. In sostanza, dice al sistema come eseguire il tuo codice. Vedrai anche un file chiamato Pulumi dot dev dot yaml se hai accettato il nome dello stack di default. Questo file secondario memorizza i valori di configurazione specifici per quello stack, inclusa la region di Azure che hai appena selezionato. Insieme a questi, ottieni i tuoi file delle dipendenze standard, che variano a seconda del linguaggio che hai scelto, e il tuo file di entrypoint. All'interno del file di entrypoint, il template Azure di default fornisce un esempio funzionante di uno storage account di Azure. La logica del codice scorre in tre chiari passaggi. Primo, importa il package Azure Native. Secondo, dichiara un nuovo Resource Group di Azure, dandogli un nome logico che lo state file dovrà tracciare. Terzo, dichiara uno Storage Account di Azure. Ed è qui che la cosa si fa interessante. Invece di hardcodare il nome del Resource Group, lo storage account prende la proprietà name direttamente dall'oggetto Resource Group creato nel passaggio precedente. Questo crea una dependency implicita. Il sistema ora sa che deve finire di creare il Resource Group prima di tentare di creare lo storage account. Il template compila automaticamente anche gli argomenti richiesti per lo storage account, come l'account replication type e l'account tier. Proprio alla fine del file, il codice esporta un valore. In questo esempio scaffoldato, esporta la primary storage key dello storage account appena definito. Quando alla fine farai il deploy, questo valore esportato verrà stampato direttamente nella tua console, rendendo facile recuperare connection string o endpoint senza loggarti nel portale di Azure. Passi da una cartella vuota a un programma di infrastruttura completamente configurato semplicemente rispondendo a pochi prompt, dandoti una base solida e con la sintassi corretta per iniziare a costruire la tua architettura. Grazie per aver ascoltato, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 4 di 10. Il tuo script di deploy funziona perfettamente sul tuo laptop. Fai il push del codice, la tua pipeline automatizzata si attiva e la build fallisce immediatamente perché non riesce a trovare un source file. Non è cambiato nulla nel codice, ma la directory in cui è stato eseguito il comando si è spostata leggermente. Questa è una classica trappola dei path, ed evitarla richiede la comprensione di Projects e Paths: strutturare il codice. In sostanza, un progetto Pulumi è semplicemente una cartella contenente un file chiamato Pulumi.yaml. Questo file è l'ancora. Indica alla command line interface che questa specifica directory contiene la logica della tua infrastruttura. All'interno del file Pulumi.yaml, dichiari metadati come il nome del progetto, una descrizione e il linguaggio di runtime. La proprietà runtime è ciò che decide come viene effettivamente eseguito il tuo codice. Se specifichi Python, il runtime cerca un main file Python in quella directory. Se specifichi Node, cerca l'entrypoint definito nel tuo package file, che di solito è un file index. Se preferisci mantenere il tuo codice sorgente in una sottocartella anziché nella directory principale del progetto, puoi fare l'override esplicito di questo comportamento impostando la proprietà main nel tuo file Pulumi.yaml in modo che punti a quella specifica sottocartella. Ora, analizziamo la confusione più comune relativa ai file path. Supponiamo che tu stia facendo la build di un'immagine container Docker come parte della tua infrastruttura, e che il tuo Dockerfile si trovi in una sottocartella chiamata app, proprio accanto al tuo codice Pulumi. Gli ingegneri spesso passano un path assoluto dalla propria macchina locale per indicare a Pulumi dove si trova il Dockerfile. Ma un path assoluto include la tua directory utente personale. Quando un collega fa il pull del codice e lancia un update, l'engine vede un path assoluto diverso sulla sua macchina. Lo registra come una modifica strutturale alla risorsa, creando un drift non necessario nello state della tua infrastruttura. Per risolvere questo problema, potresti passare a un relative path standard, come punto slash app. I relative path standard si basano interamente sulla current working directory del terminale che esegue il codice. Se il tuo sistema di continuous integration esegue il comando da una directory superiore nel repository, il relative path si risolve in modo errato e il deploy crasha. Ecco il punto chiave. Hai bisogno di path che siano completamente indipendenti dalla macchina su cui girano, e indipendenti da dove l'utente ha digitato il comando di esecuzione. Ti servono dei path project-relative. Pulumi fornisce una funzione built-in per recuperare la posizione esatta del file Pulumi.yaml durante l'esecuzione. A seconda del tuo linguaggio di programmazione, questa funzione viene in genere chiamata get root directory o qualcosa di simile. Quando chiami questa funzione, il runtime restituisce il path assoluto della cartella contenente il tuo file Pulumi.yaml. Invece di hardcodare un path verso il tuo Dockerfile, costruisci il path dinamicamente. Prendi il risultato della funzione root directory e ci appendi la tua sottocartella app. Poiché questa funzione viene valutata dinamicamente a ogni esecuzione, il path risultante è sempre perfettamente su misura per l'environment che esegue il codice. La tua macchina locale, il laptop del tuo collega e il server di build remoto genereranno tutti il path assoluto corretto per i loro specifici file system. Il file path si risolve in modo coerente ogni volta, e l'engine rileva zero modifiche alla definizione della risorsa. Il codice della tua infrastruttura non dovrebbe mai preoccuparsi di dove si trova su un hard disk. Ancora sempre i tuoi file asset alla funzione root directory di Pulumi, assicurandoti che il tuo progetto rimanga completamente portabile in qualsiasi environment. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 5 di 10. Copiare e incollare il codice della tua infrastruttura per creare un ambiente di staging è una ricetta per il drift e il disastro. Ti ritrovi a mantenere più cartelle con file quasi identici e, prima o poi, qualcuno si dimentica di aggiornare la produzione. La soluzione è trattare i tuoi ambienti come istanze isolate di un'unica codebase utilizzando gli Stack. Prima di proseguire, chiariamo un dubbio comune. Un Project in Pulumi è semplicemente una directory che contiene il tuo codice sorgente. Sono solo le istruzioni. Uno Stack è un'istanza di deploy attiva di quel codice. Scrivi il Project una volta e ne fai il deploy più volte come Stack diversi. Gli Stack ti permettono di gestire ambienti diversi, come development, staging e produzione, senza duplicare alcun codice. Quando lanci un Pulumi update, applica il codice del tuo Project allo Stack attualmente attivo. Ogni Stack mantiene il proprio state file isolato, tenendo traccia solo delle risorse create per quello specifico ambiente. La gestione di questi ambienti avviene direttamente nel tuo terminale. Crei un nuovo ambiente lanciando il comando stack initialize, dandogli un nome come dev o prod. Pulumi registra questa nuova istanza e crea un nuovo state dedicato. Per cambiare contesto, usi il comando stack select. La CLI di Pulumi ricorda quale stack è attivo. Se selezioni lo stack dev e lanci un update, Pulumi guarda solo lo state di development. Fa il provisioning o modifica l'infrastruttura di development, lasciando i tuoi ambienti di staging e produzione completamente intatti. Questo copre il deploy di ambienti isolati. Ma cosa succede quando questi ambienti devono comunicare? A volte, uno stack dipende da informazioni generate da un altro. Potresti avere un project che gestisce l'infrastruttura di base e un project completamente separato che gestisce il codice dell'applicazione. Diciamo che hai un project di infrastruttura che fa il provisioning di un cluster Kubernetes. Ne fai il deploy come stack chiamato base-infra-prod. Durante il deploy, il cluster genera una connection string dinamica. Ora, hai un secondo project per un microservizio che deve fare il deploy esattamente in quello stesso cluster. Non vuoi hardcodare la connection string e non vuoi fare il merge di entrambi i project in un unico state file enorme e lento. È qui che la cosa si fa interessante. Puoi collegare in modo sicuro questi deploy usando una Stack Reference. Una Stack Reference permette a uno stack di leggere gli output esportati da un altro stack. Per configurarlo, il programma del tuo cluster Kubernetes deve esportare esplicitamente la connection string al termine della sua esecuzione. Un export è semplicemente una variabile che Pulumi salva nello stack state appositamente per poter essere letta dall'esterno. Successivamente, nel programma del tuo microservizio, crei un oggetto Stack Reference. Gli passi il nome dello stack dell'infrastruttura da cui vuoi leggere. Quindi, chiami un metodo get output su quella reference, chiedendo la connection string tramite il suo nome esportato. Il tuo microservizio può ora usare questo valore per configurare il suo deploy. Lo stack del microservizio non può modificare lo stack del cluster. Può solo leggere i valori specifici che lo stack del cluster ha scelto di esportare. Questo garantisce un confine netto. Puoi aggiornare e scalare la tua infrastruttura di rete principale in modo completamente indipendente dai tuoi workload applicativi, passando in modo sicuro i dettagli di connessione necessari. Disaccoppiando il tuo codice dall'istanza dell'ambiente, garantisci che ogni tier del tuo sistema segua esattamente la stessa logica, eliminando i rischi nascosti della duplicazione manuale. Questo è tutto per oggi. Grazie per l'ascolto e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 6 di 10. Fai il deploy del codice della tua infrastruttura, la sintassi è impeccabile, eppure fallisce immediatamente perché il nome di uno storage bucket è già in uso. O peggio, aggiorni un'istanza di database e il tuo tool elimina la vecchia prima di creare la nuova, causando un hard outage. Puoi risolvere entrambi i problemi capendo come il tuo tool di infrastruttura gestisce le identità. Ed è proprio di questo che parleremo oggi: I Building Block: le resource di Pulumi. In Pulumi, una resource è un oggetto che rappresenta un pezzo di infrastruttura. Ci sono due tipi principali con cui lavorerai. Il primo è una Custom Resource. Questa mappa direttamente un oggetto fisico gestito da un cloud provider. Quando dichiari una Custom Resource, Pulumi fa un'API call ad Amazon, Azure o Google Cloud per creare esattamente quell'oggetto, come una virtual machine o un load balancer. Il secondo tipo è una Component Resource. Una Component Resource non mappa un singolo pezzo di infrastruttura cloud. È invece un contenitore logico per altre resource. Usi le Component Resource per creare astrazioni di livello superiore. Ad esempio, potresti creare una singola Component Resource chiamata Secure Web Server che fa internamente il provisioning di una virtual machine, un security group e un indirizzo IP. La Component Resource stessa si limita a raggrupparle nel tuo state file, rendendo il tuo codice più pulito e più facile da gestire. Che tu stia definendo una Custom Resource o una Component Resource, ognuna richiede un nome. Questo porta a una comune fonte di frustrazione. Le persone digitano un nome nel loro codice, fanno il deploy, e poi controllano la loro cloud console solo per scoprire che la loro resource ha una string casuale di caratteri attaccata alla fine del nome. Questo non è un bug. È una feature fondamentale di come funziona Pulumi, e devi capire la differenza tra un logical name e un physical name. Il logical name è il nome che digiti nel tuo codice come argomento. Pulumi usa questo logical name per tracciare la resource all'interno del suo state file. È così che Pulumi sa che il database nel tuo codice oggi è esattamente lo stesso database di cui hai fatto il deploy ieri. Il physical name è come il cloud provider chiama effettivamente la resource nel proprio sistema. Di default, Pulumi prende il tuo logical name, aggiunge un suffisso casuale, e usa quella string combinata come physical name. Questo si chiama auto-naming. Ecco il punto chiave. L'auto-naming previene le collisioni di nomi a livello globale e permette rimpiazzi con zero-downtime. Pensa a fare il provisioning di più storage bucket identici in un loop usando Azure. Azure richiede che i nomi degli storage account siano globalmente univoci tra tutti i clienti. Se provi a forzare un physical name rigoroso, il secondo bucket nel tuo loop fallirà perché il nome è già preso, o peggio, qualcun altro nel mondo potrebbe già possederlo. Con l'auto-naming, puoi semplicemente usare un logical name come archive-bucket all'interno del tuo loop. Pulumi traccerà ogni iterazione logicamente, assicurando che ogni bucket ottenga un physical name matematicamente univoco in Azure. L'auto-naming protegge anche l'uptime del tuo sistema. Se fai una modifica che forza il rimpiazzo di una resource, Pulumi crea prima la nuova resource, verifica che funzioni, e solo dopo elimina la vecchia. Se fai l'override dell'auto-naming e forzi un physical name rigoroso, il cloud provider non permetterà a due resource di condividere lo stesso nome allo stesso tempo. Pulumi sarebbe costretto a eliminare prima la tua vecchia resource, causando downtime mentre la nuova fa il provisioning. Se vuoi aiutare a far continuare lo show, puoi cercare DevStoriesEU su Patreon. Mantieni flessibili i tuoi physical name. Lascia che il tool gestisca i suffissi casuali, perché mentre il tuo state file richiede un logical name per mantenere l'ordine, il tuo ambiente di produzione si affida alla flessibilità fisica per rimanere online. Grazie per l'ascolto. Statemi bene, tutti.

Ciao, sono Alex di DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 7 di 10. Hardcodare la password del database nel codice della tua infrastruttura è una falla di sicurezza garantita. Ma iniettare manualmente le variabili d'ambiente in ogni singola deployment pipeline è fragile e difficile da tracciare. Hai bisogno di un modo per associare automaticamente valori specifici e crittografati ad ambienti specifici. Questo è Keeping Secrets: Configuration Management. L'idea centrale qui è separare il tuo codice dalla tua configurazione. Vuoi scrivere la logica della tua infrastruttura esattamente una volta. Poi, quando fai il deploy sul tuo stack di sviluppo, il codice fa il provisioning di piccole istanze. Quando fai il deploy in produzione, fa il provisioning di grandi istanze e usa le credenziali del database di produzione. Pulumi gestisce questo tramite un sistema di configurazione integrato. Un punto di confusione comune è come questi valori vengono effettivamente salvati. Impostare un valore di configurazione di Pulumi non imposta le variabili d'ambiente locali del sistema operativo. Invece, salva i valori direttamente in un file chiamato Pulumi punto stack-name punto yaml. Dato che ogni stack ha il suo file di configurazione distinto, la tua configurazione di dev e la tua configurazione di prod vivono fianco a fianco nel tuo repository, separate in modo pulito dal nome del file. Aggiungi dati a questo file usando la command line interface di Pulumi. Se esegui il comando pulumi config set frontendPort 8080, Pulumi scrive quella coppia key-value direttamente nel file yaml per il tuo stack attualmente attivo. Per usare quel valore nel codice della tua infrastruttura, istanzi un oggetto Config. Poi, chiami un metodo come get o require su quell'oggetto, passando il nome della key. La differenza è semplice. Chiamare get restituisce il valore se esiste, o niente se non esiste. Chiamare require lancerà un errore e fermerà il tuo deployment se la configuration key è mancante. Questo è un ottimo modo per assicurarti che un deployment non proceda mai senza un'impostazione obbligatoria. Non sei limitato a semplici string. Puoi salvare e recuperare dati strutturati, come un blocco JSON che definisce i parametri di scaling, e farne il parse direttamente in un oggetto nel tuo codice. Ora, cosa succede quando quel valore di configurazione è altamente sensibile? Supponi che la tua applicazione debba connettersi a un database esterno, e che tu debba passare la password del database alla tua infrastruttura. Non puoi assolutamente salvarla in plaintext nel tuo file yaml, perché quel file viene committato nel version control. È qui che entrano in gioco i secret di Pulumi. Usi l'esatta stessa command line interface, ma aggiungi un flag secret. Esegui pulumi config set dbPassword your-password dash dash secret. Pulumi cripta il valore prima di salvarlo nel file yaml. Se qualcuno guarda il file nel tuo repository, vedrà solo una string ciphertext criptata in modo sicuro dall'encryption provider del tuo stack. Nel tuo codice, recuperi questo in modo sicuro chiamando uno specifico metodo secret sul tuo oggetto Config, come requireSecret. Ecco il punto chiave. Quando recuperi un secret in questo modo, Pulumi lo wrappa in uno speciale tipo secret. Man mano che questo valore fluisce attraverso il codice della tua infrastruttura e viene passato alle risorse, il motore di Pulumi lo traccia. Assicura che il valore in plaintext venga mascherato nel tuo console output durante un deployment, e garantisce che il valore rimanga criptato all'interno del tuo state file di Pulumi. La configurazione ti permette di scrivere il codice dell'infrastruttura una volta sola e di promuoverlo in modo sicuro attraverso gli ambienti. La crittografia nativa dei secret assicura che le tue credenziali sensibili guidino quei deployment senza mai finire nel tuo version control o nei tuoi state file. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 8 di 10. Copi e incolli un blocco di codice di storage e networking per la quinta volta questa settimana. Il tuo codice infrastrutturale cresce, ma non diventa più intelligente. Invece di ripetere configurazioni cloud identiche ogni volta che hai bisogno di un setup standard, puoi crearle con una singola unità logica. Questo è il focus di questo episodio: Scaling Up: Component Resources su Azure. Quando inizi a usare Pulumi, dichiari risorse raw. Un resource group qui, uno storage account lì. Ma man mano che il tuo sistema cresce, fare il deploy di un'architettura standard richiede di fare il provisioning dello stesso identico set di primitive ancora e ancora. Questo viola la regola del don't repeat yourself. Le Component Resources risolvono questo problema permettendoti di incapsulare più risorse cloud fisiche in un'unica astrazione riutilizzabile. Pensa a una Component Resource come a una classe custom che definisci nel tuo linguaggio di programmazione scelto. Una volta definita, la istanzi proprio come una risorsa Pulumi built-in. Considera uno scenario in cui fai spesso il deploy di siti web statici su Azure. Un setup minimo richiede un Resource Group di Azure, uno Storage Account configurato per l'hosting di siti web statici e un oggetto Blob che funge da documento index. Invece di scrivere queste tre definizioni nel tuo programma main ogni singola volta, crei un component per siti web statici di Azure. Per costruirlo, definisci una nuova classe che eredita dalla classe base ComponentResource di Pulumi. Il costruttore della tua classe prende un nome, un set di argomenti per la customizzazione e delle resource options standard. La primissima cosa che fa il tuo costruttore è chiamare il costruttore della classe base. Gli passi un type token univoco, come custom due punti infrastructure due punti static website, insieme al nome. Questo type token dice all'engine come tracciare la tua nuova astrazione nello state file. Successivamente, definisci le vere e proprie primitive di Azure all'interno del tuo costruttore. Dichiari il resource group. Dichiari lo storage account all'interno di quel gruppo. Fai l'upload del blob index in quell'account. Ecco il punto chiave. Quando crei queste risorse interne, devi dire esplicitamente all'engine che appartengono al tuo nuovo component. Lo fai passando l'istanza del component stesso nelle resource options sotto la proprietà parent. Molti engineer dimenticano questo passaggio. Se ometti l'opzione parent, le child resources faranno il provisioning con successo, ma saranno trattate come risorse top-level. L'output della tua command line sarà un elenco piatto e confuso. Impostando la proprietà parent sull'istanza del tuo component, l'engine organizza lo state tree. Quando lanci un update, l'interfaccia annida visivamente il resource group, lo storage account e il blob direttamente sotto il tuo component website custom. Questo mantiene il tuo state gestibile e il tuo output leggibile. Infine, il tuo programma main probabilmente ha bisogno di conoscere l'indirizzo web del sito appena creato. All'interno del tuo component, dopo aver definito lo storage account, mappi il suo web endpoint primario a una proprietà pubblica sulla tua classe. Poi, chiami un metodo chiamato register outputs. Questo finalizza l'inizializzazione e assicura che l'indirizzo finale sia esposto al resto del tuo programma e stampato in console quando il deploy finisce. Nel tuo file main, non vedi più il boilerplate. Semplicemente istanzi il tuo component website, gli passi un file index e fai il deploy. Le risorse sottostanti sono gestite in modo sicuro dietro l'astrazione. Il vero potere dell'Infrastructure as Code è trattare l'architettura cloud come software, e le Component Resources sono il modo in cui costruisci una libreria standard e affidabile per il tuo team. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 9 di 10. Non devi buttare via anni di codice esistente per iniziare a usare un nuovo tool di infrastruttura oggi stesso. La temuta riscrittura massiva del sistema è un rischio enorme e, fortunatamente, è del tutto opzionale. La strategia che rende questo possibile si chiama Peaceful Coexistence: leggere lo state di Terraform. Un malinteso comune è che passare a Pulumi significhi dover migrare tutta la tua infrastruttura esistente in una volta sola. Questo è sbagliato. Pulumi può leggere e dipendere nativamente da risorse che sono gestite attivamente da Terraform. Puoi adottare nuovi tool in modo incrementale, affiancandoli alle tue pipeline di deploy esistenti. Considera un tipico ambiente enterprise. La tua azienda ha una Virtual Private Cloud AWS core gestita da un team di rete centrale usando Terraform. Tu sei uno sviluppatore che sta creando una nuova applicazione, e vuoi usare Pulumi per fare il deploy di task di Elastic Container Service. I tuoi container devono girare all'interno di quella specifica VPC. Non vuoi riscrivere il codice della VPC in Pulumi, e di certo non vuoi farti carico della gestione della rete sottostante. Per gestire questa situazione, usi il provider Terraform di Pulumi. Questo provider include un componente specifico progettato per leggere i file di state, chiamato remote state reference. Il processo si basa su come Terraform memorizza i suoi dati di esecuzione. Per prima cosa, il codice Terraform che gestisce la rete deve esporre esplicitamente i dati di cui la tua nuova applicazione ha bisogno. Lo fa usando i blocchi di output standard di Terraform. Il team di rete configura il proprio codice per restituire in output l'identificativo della VPC e una lista di identificativi delle subnet private. Quando Terraform applica la sua configurazione, quegli output vengono scritti nel file di state di Terraform, che in genere viene archiviato in remoto in un backend come un bucket AWS S3 o Terraform Cloud. Successivamente, passi al tuo programma Pulumi. Scrivi il codice per istanziare la remote state reference. Fornisci a questo oggetto gli stessi identici dettagli di configurazione del backend che Terraform usa per trovare il suo file di state. Questi includono il tipo di backend, la storage location, la region e la key specifica del file di state. Quando esegui il tuo deploy con Pulumi, l'engine si connette a quel backend remoto, apre il file di state di Terraform e analizza gli output disponibili. Ecco il punto chiave. Pulumi tratta lo state di Terraform come strettamente in sola lettura. Non modifica mai il file di state di Terraform, e non assume l'ownership delle risorse di rete. Si limita a interrogare i valori correnti e noti dell'infrastruttura. Una volta che Pulumi recupera gli identificativi della VPC e delle subnet dallo state, tratti quei valori come qualsiasi altra variabile nel tuo codice. Li passi direttamente alla logica di deploy per il tuo nuovo cluster di container. Pulumi fa il provisioning dei tuoi nuovi container in modo trasparente nella rete esistente. Questa architettura mantiene le responsabilità completamente separate. Il team centrale continua a gestire il lifecycle della rete usando Terraform. Se aggiornano una route table o aggiungono un tag, usano il loro workflow standard. Se modificano un output, ad esempio creando una nuova subnet, Pulumi leggerà automaticamente il file di state aggiornato durante il suo prossimo update e adatterà di conseguenza il deploy dei tuoi container. Usare le remote state reference crea un confine di dipendenza pulito e unidirezionale, permettendoti di costruire con sicurezza nuovi sistemi con funzionalità moderne, pur potendo contare su una base stabile gestita da codice legacy. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 10 di 10. Testare la logica complessa dell'infrastruttura è notoriamente difficile. Scrivi migliaia di righe di configurazione, ma verificare se una specifica combinazione di regole firewall si comporta effettivamente come previsto prima del deploy spesso sembra di andare a tentoni. La Grande Migrazione: Convertire HCL in Pulumi è il modo in cui risolvi questo problema. Passare da Terraform a Pulumi non è un semplice find-and-replace sintattico. Non si tratta di cambiare le parentesi graffe con quelle tonde. Si tratta di prendere una configurazione statica e trasformarla in un programma eseguibile, dandoti accesso immediato a loop nativi, funzioni e framework di testing standard. Pensa a una configurazione di security group Terraform molto complessa e ripetitiva. Probabilmente hai decine di port range sovrapposti, allowlist di IP specifiche e definizioni di blocchi pesanti. In HCL, gestire tutto questo richiede strutture rigide, e validare la logica richiede l'esecuzione di un plan contro uno state cloud live. La transizione inizia con il comando pulumi convert. Vai nella directory che contiene i tuoi file Terraform esistenti ed esegui questo comando, specificando il tuo linguaggio di destinazione, come TypeScript o Python. Il tool fa il parsing del tuo codice sorgente HCL, legge le tue variabili, le risorse principali e gli output, e genera un programma Pulumi equivalente. Traduce l'intento dichiarativo dell'HCL nella struttura imperativa del linguaggio di programmazione che hai scelto. Una volta generato quel codice, i vantaggi strategici della migrazione diventano chiari. Ora puoi fare refactoring di quell'enorme lista di regole del security group in un array pulito di data object, oppure tirarle fuori da un file di configurazione esterno. Puoi iterare su quell'array per generare dinamicamente le regole del firewall usando loop standard di TypeScript o Python. Ecco il punto chiave. Dato che la tua infrastruttura ora è scritta in un linguaggio general-purpose, puoi testarla esattamente come il codice dell'applicazione. Puoi scrivere un unit test usando framework standard come Jest o PyTest. Crei un test case che fa il mock del runtime di Pulumi e verifica con un assert che la tua funzione builder del security group non esponga mai accidentalmente la porta ventidue a tutta Internet. Esegui questi test in millisecondi, completamente offline, catturando gli errori logici prima ancora che inizi la fase di plan dell'infrastruttura. Questo passaggio sblocca una profonda integrazione del linguaggio. Il tuo codice infrastrutturale può condividere librerie standard, logica di validazione e definizioni di typing direttamente con il codice della tua applicazione. Ottieni l'accesso agli ecosistemi maturi di package manager come NPM o pip, permettendoti di pacchettizzare e distribuire pattern infrastrutturali con la stessa facilità di qualsiasi altra libreria software. Il comando di conversione fa il lavoro pesante di tradurre il tuo state attuale, ma la vera migrazione avviene quando cambi mentalità, passando dallo scrivere file statici all'ingegnerizzare sistemi testabili. Il più grande vantaggio di convertire il tuo codice è passare dal semplice configurare l'infrastruttura al programmarla veramente. Ti incoraggio vivamente a leggere la documentazione ufficiale di Pulumi, prendere un piccolo modulo Terraform e provare a eseguire la conversione tu stesso per vedere l'output. Se hai idee su quali argomenti tecnici dovremmo trattare nella nostra prossima serie, visita devstories dot eu e faccelo sapere. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!