L'IaC (Infrastructure as Code) è una pratica DevOps che automatizza il provisioning e la gestione dell'infrastruttura IT utilizzando file di configurazione anziché processi manuali.
L'IaC tratta l'infrastruttura come un software. I team utilizzano l'IaC per gestire versioni, test e distribuzioni dell'infrastruttura utilizzando le stesse pratiche utilizzate per il codice delle applicazioni.
Questo approccio consente ai team di aggirare la tradizionale configurazione manuale, che può essere complessa e soggetta a errori. La configurazione manuale spesso comporta la configurazione individuale del server, la gestione basata su console e modifiche non documentate.
I team definiscono invece i requisiti infrastrutturali nei file di configurazione che specificano le risorse necessarie (server, reti, database, policy di sicurezza) e come configurarle. Questi file risiedono quindi nei sistemi di controllo delle versioni, che forniscono funzionalità di tracciamento, revisione e rollback.
L'IaC è un elemento importante della più ampia pratica dell'automazione dell'infrastruttura, che utilizza codice e automazione per gestire l'infrastruttura IT durante tutto il suo ciclo di vita. Con l'IaC, gli sviluppatori non devono più eseguire il provisioning manuale dei componenti dell'infrastruttura ogni volta che sviluppano, testano o distribuiscono applicazioni. Questa automazione aiuta le organizzazioni a controllare i costi, ridurre i rischi e rispondere rapidamente alle nuove opportunità di business.
Man mano che le organizzazioni adottano architetture cloud-native, l'IaC è sempre più essenziale. Gli ambienti IT ora si estendono su più cloud, migliaia di container e microservizi distribuiti. I processi manuali che una volta gestivano alcuni server non sono in grado di gestire queste architetture, dove i team distribuiscono spesso centinaia di applicazioni al giorno e provvedono costantemente a fornire, scalare e dismettere l'infrastruttura.
L'IaC aiuta a gestire questi ambienti complessi in tre modi critici:
Ad esempio, un'azienda retail che si prepara per il Black Friday potrebbe dover scalare 100-1.000 server entro poche ore. Con l'IaC, questa scalabilità avviene automaticamente nell'infrastruttura on-premise e cloud, in base a modelli predefiniti. Questa capacità di scalare consente di garantire che ogni nuovo server mantenga le stesse configurazioni di sicurezza e conformità.
Secondo l'IBM Institute for Business Value, il 65% dei dirigenti riferisce che le tecnologie di automazione come l'IaC stanno migliorando la produttività dei propri team IT.
Resta al passo con le tendenze più importanti e interessanti del settore relative ad AI, automazione, dati e oltre con la newsletter Think. Leggi l' Informativa sulla privacy IBM.
L'IaC combina un workflow ripetibile con tooling automatizzato. Il workflow (scrittura, versione, provisioning e distribuzione) definisce il modo in cui i team passano dai requisiti infrastrutturali alle risorse distribuite. Gli strumenti (file di configurazione, sistemi di controllo delle versioni e motori di automazione) forniscono i meccanismi per definire, tracciare e creare l'infrastruttura.
Insieme, questi elementi trasformano la gestione dell'infrastruttura da un processo manuale e soggetto a errori in una funzione automatizzata e ripetibile. I team scrivono l'infrastruttura come codice, con versioni univoche come per il software, e implementano ambienti identici su richiesta.
Il workflow IaC segue quattro fasi:
Gli sviluppatori creano script IaC utilizzando linguaggi quali HCL, YAML o JSON, in modo simile a come scrivono il codice dell'applicazione in Java™ o Python. I team scrivono definizioni dell'infrastruttura che specificano le risorse necessarie e le modalità di configurazione. Spesso scrivono questi file in ambienti di sviluppo integrati (IDE), che forniscono caratteristiche di controllo degli errori e completamento automatico.
Il codice sorgente viene memorizzato nei sistemi di controllo delle versioni, noti anche come controllo del codice sorgente o repository di codice sorgente, come Git o GitHub. Il controllo delle versioni tiene traccia delle modifiche, mantiene le versioni alternative e consente ai team di ripristinare le versioni precedenti in caso di problemi.
Un motore di automazione legge i file di configurazione e fornisce le risorse infrastrutturali specificate. Questa fase trasforma il codice in una vera e propria infrastruttura, creando macchine virtuali (VM), configurando reti, configurando database e stabilendo gruppi di sicurezza. Il processo di provisioning è idempotente, il che significa che può essere eseguito più volte senza creare risorse duplicate.
I team eseguono script per distribuire l'infrastruttura in vari ambienti, con l'IaC che aiuta a garantire configurazioni coerenti tra gli ambienti. La coerenza degli script aiuta soprattutto quando si utilizza la distribuzione continua, in cui le modifiche al software a un'applicazione vengono rilasciate automaticamente nell'ambiente di produzione.
Gli strumenti automatizzati forniscono meccanismi per definire, tracciare e creare infrastrutture tramite codice.
I file di configurazione definiscono l'infrastruttura. Possono essere scritti in HCL, JSON, YAML o linguaggi specifici del dominio. Questi file sono blueprint che descrivono esattamente l'infrastruttura di cui si ha bisogno, quanti server, quali dimensioni, quali impostazioni di rete, in un formato che gli strumenti di automazione possono leggere ed eseguire.
Questi file diventano la singola fonte affidabile per i team, contribuendo a garantire la coerenza in più ambienti. Possono essere aggiornati, riutilizzati o variati per nuove installazioni man mano che i team aggiungono altri asset.
I sistemi di controllo di versione memorizzano la cronologia di ogni file. Tracciano il codice originale e le eventuali modifiche, incluso cosa è stato modificato, da chi e quando. Questo monitoraggio consente ai team di comprendere le modifiche, recuperare le eliminazioni ed eseguire il rollback quando si verificano problemi.
Il controllo delle versioni consente alle organizzazioni di suddividere l'infrastruttura in moduli che si combinano tramite l'automazione. Questo approccio modulare consente di creare, aggiornare e creare versioni di ambienti complessi, riducendo al contempo la duplicazione e semplificando il test e il riutilizzo degli script.
I motori di automazione automatizzano il provisioning e la configurazione utilizzando codice predefinito. Eseguono le definizioni dell'infrastruttura nei file di configurazione, trasformando il codice in risorse IT effettive come server, reti e database.
Alcuni motori sono specifici del cloud, come AWS CloudFormation, Azure Resource Manager o Google Cloud Deployment Manager. Altri funzionano su tutti i cloud, come Terraform, OpenTOFU (un fork open source di Terraform) o Pulumi (che utilizza linguaggi di programmazione generici come Python).
Questi motori di automazione sono spesso abbinati a strumenti di orchestrazione, come Kubernetes, per coordinare risorse e workload su larga scala.
Gli strumenti IaC si integrano spesso con piattaforme cloud tramite application programming interface (API). Queste connessioni API consentono agli strumenti IaC di comunicare direttamente con i cloud service, creando e gestendo risorse in modo programmatico anziché tramite interazioni manuali con la console.
L'IaC incorpora anche pratiche standard di sviluppo software per garantire l'affidabilità. I test automatici possono aiutare a verificare le configurazioni dell'infrastruttura prima della distribuzione, identificando errori che potrebbero altrimenti causare interruzioni o vulnerabilità di sicurezza. Alcuni sistemi di controllo della versione possono attivare automaticamente questi test quando si verificano modifiche al codice, contribuendo a garantire che ogni modifica venga convalidata prima di raggiungere la produzione.
Quando implementano l'IaC, le organizzazioni fanno due scelte principali: come definire un'infrastruttura (dichiarativa o imperativa) e se un'infrastruttura può essere modificata dopo la distribuzione (mutabile o immutabile).
Gli approcci dichiarativi e imperativi differiscono nel modo in cui si scrive il codice dell'infrastruttura.
L'approccio dichiarativo, noto anche come approccio funzionale o IaC dichiarativo, è il metodo più comune. L'utente descrive lo stato desiderato (ad esempio, "Ho bisogno di 3 server con queste specifiche") e l'IaC gestisce l'implementazione. Crea le risorse, installa il software necessario, risolve le interdipendenze e gestisce automaticamente il controllo delle versioni.
L'approccio imperativo, noto anche come approccio procedurale, richiede che l'utente scriva istruzioni dettagliate per il provisioning dell'infrastruttura. I comandi esatti sono specificati in ordine preciso: "Prima crea un server, quindi installa questo software, quindi configura queste impostazioni." Questo approccio richiede più esperienza e può rendere più difficile mantenere la coerenza.
L'infrastruttura mutabile può essere modificata dopo il provisioning, mentre l'infrastruttura immutabile non può essere modificata dopo il provisioning.
L'infrastruttura mutabile offre flessibilità per modifiche ad hoc, come la risoluzione di requisiti specifici di applicazione o patch di sicurezza di emergenza. Tuttavia, questa flessibilità può compromettere la coerenza e rendere difficile il rilevamento delle versioni.
La maggior parte delle organizzazioni sceglie un'infrastruttura immutabile. Per modificare un server o una configurazione, i team devono sostituire l'intera infrastruttura con nuove risorse.
Sebbene possa sembrare un limite, in realtà può rivelarsi vantaggioso per diversi motivi. Innanzitutto, l'infrastruttura immutabile elimina la deriva della configurazione. La deriva è un problema comune nelle infrastrutture mutabili, dove le modifiche manuali si accumulano nel tempo, rendendo più difficile mantenere la coerenza tra i diversi ambienti.
In secondo luogo, l'infrastruttura immutabile fornisce funzionalità affidabili di tracciamento e rollback delle versioni perché ogni modifica crea una nuova istanza con versione. Ciò significa che i team possono tornare istantaneamente a qualsiasi configurazione precedente.
Infine, con l'IaC basato sul cloud, è possibile effettuare il provisioning di una nuova infrastruttura rapidamente, spesso in pochi minuti, in modo che il reprovisioning di tutte le risorse dell'infrastruttura sia molto più pratico di quanto sembri inizialmente.
Automatizzando la gestione dell'infrastruttura che utilizza il codice, l'IaC offre diversi benefici:
Il provisioning manuale dell'infrastruttura può richiedere settimane di configurazione dell'hardware, installazione del sistema operativo e configurazione della rete da parte di personale specializzato.
L'IaC riduce i tempi di provisioning da settimane a minuti in tutti gli ambienti. Ad esempio, l'IaC può automatizzare il provisioning di infrastrutture legacy che altrimenti richiederebbero processi manuali come l'estrazione di un ticket. Invece di attendere giorni per la configurazione del database e del server, gli sviluppatori possono eseguire uno script per implementarli in pochi minuti.
Con l'IaC, ogni volta che viene eseguito il provisioning dell'infrastruttura, segue la configurazione identica definita nel codice.
Questa coerenza consente di eliminare gli errori di configurazione manuale, ad esempio errori tipografici, passaggi mancati o impostazioni errate, evitando al contempo deviazioni della configurazione o dipendenze mancanti.
Le incongruenze di configurazione possono anche creare vulnerabilità di sicurezza e violare i requisiti normativi, come il Sarbanes-Oxley Act (SOX) o il Regolamento generale sulla protezione dei dati (GDPR). Ad esempio, le porte aperte non necessarie o l'HTTPS disabilitato potrebbero causare violazioni della conformità o errori di controllo. L'IaC aiuta a garantire configurazioni di ambiente identiche ogni volta, fino a quando non sono necessarie modifiche.
L'IaC può aiutare ad accelerare ogni fase del ciclo di vita della distribuzione del software. Gli sviluppatori possono rapidamente predisporre sandbox e ambienti su richiesta. I team QA possono avviare immediatamente gli ambienti di test. I team operativi possono automatizzare l'infrastruttura per i test di sicurezza e accettazione degli utenti.
Quando il nuovo codice supera i test, sia l'applicazione che la relativa infrastruttura vengono quindi implementate insieme, con conseguente distribuzione più rapida delle caratteristiche e implementazioni più frequenti.
Le organizzazioni senza IaC in genere si affidano a pochi specialisti per il provisioning. Quando uno di questi specialisti se ne va, spesso le sue conoscenze lo accompagnano.
L'IaC aiuta a preservare la conoscenza dell'infrastruttura nel codice, contribuendo a garantire che le competenze critiche rimangano all'organizzazione.
L'IaC può ridurre significativamente il tempo, l'impegno e le competenze specialistiche necessarie per il provisioning e la scalabilità dell'infrastruttura. Inoltre ottimizza i prezzi basati sul consumo del cloud computing: le organizzazioni possono fornire risorse solo quando necessario e annullarle automaticamente quando sono inattive.
Questo approccio pay-as-you-go può ridurre significativamente la spesa per le infrastrutture, in particolare per gli ambienti di sviluppo e test che non richiedono una disponibilità continua.
L'IaC è essenziale per le pratiche DevOps perché consente all'infrastruttura di spostare alla velocità dello sviluppo del software.
Senza IaC, il provisioning dell'infrastruttura può diventare un collo di bottiglia. Mentre il codice viene implementato in pochi minuti, la configurazione dell'infrastruttura potrebbe richiedere ore o giorni. Ad esempio, l'aggiunta di un nuovo database potrebbe richiedere un ticket per il team dell'infrastruttura e giorni di attesa.
L'IaC elimina questa lacuna applicando l'integrazione continua e la distribuzione continua (CI/CD) alle distribuzioni dell'infrastruttura. L'infrastruttura e il codice dell'applicazione possono essere testati, convalidati e distribuiti insieme in parallelo, anziché come processi eterogenei.
In pratica, il codice dell'infrastruttura spesso si affianca al codice dell'applicazione nel controllo della versione. Quando gli sviluppatori apportano modifiche, la pipeline CI/CD può fornire l'infrastruttura di test utilizzando modelli IaC, eseguire test automatici e utilizzare gli stessi modelli per distribuire in produzione. Questo aiuta a garantire che ogni ambiente (di sviluppo, di test, di staging, di produzione) abbia configurazioni identiche dell'infrastruttura.
Il vantaggio fondamentale è la coerenza. Senza IaC, possono verificarsi deviazioni ambientali quando gli ambienti di test non corrispondono alla produzione, causando errori di implementazione. L'IaC aiuta a garantire che ciò che funziona nei test funzioni anche in produzione perché entrambi utilizzano le stesse definizioni di infrastruttura. I team possono esaminare le modifiche all'infrastruttura tramite pull request, tenere traccia delle modifiche e ripristinare quando necessario, trattando l'infrastruttura con lo stesso rigore del codice dell'applicazione.
Gli strumenti IaC si dividono in due categorie: strumenti di provisioning che creano e distribuiscono l'infrastruttura e strumenti di gestione della configurazione che mantengono l'infrastruttura dopo la distribuzione.
Alcuni strumenti vengono eseguiti su tutti i cloud (funzionando su più fornitori), mentre altri sono specifici della piattaforma.
Le organizzazioni in genere combinano strumenti di entrambe le categorie per creare pipeline IaC complete.
Gli strumenti di provisioning creano e distribuiscono le risorse dell'infrastruttura: server, reti e sistemi storage. Si concentrano sull'impostazione iniziale e sulla configurazione dei componenti dell'infrastruttura, trasformando i requisiti dell'infrastruttura in risorse.
Terraform di HashiCorp, un'azienda IBM, è uno strumento IaC che può funzionare su tutti i cloud e che utilizza la configurazione dichiarativa per gestire l'infrastruttura su più piattaforme.
I team scrivono le definizioni dell'infrastruttura in HCL (HashiCorp Configuration Language) e possono implementare lo stesso codice su AWS, Azure, Google Cloud o nei data center on-premise. Questa portabilità consente alle organizzazioni di evitare il blocco da fornitore e combinare provider di cloud in base ai loro punti di forza, ad esempio utilizzando AWS per il calcolo e Google cloud per machine learning.
Terraform velocizza anche le distribuzioni fornendo risorse su più provider contemporaneamente. Analizza le dipendenze tra le risorse e ne crea di indipendenti in parallelo. Ad esempio, se si implementano 10 server AWS e 5 database di Azure senza dipendenze, Terraform crea tutte e 15 le risorse contemporaneamente anziché in sequenza, riducendo i tempi di distribuzione.
AWS CloudFormation è la soluzione IaC nativa di Amazon per l'infrastruttura AWS. I team definiscono interi stack di applicazioni, dalle istanze EC2 ai database di Rational Directory Server, utilizzando modelli JSON o YAML. CloudFormation gestisce automaticamente le dipendenze delle risorse, creandole nell'ordine corretto e ripristinandole in caso di errori.
Sebbene limitato ad AWS, CloudFormation offre una profonda integrazione con i servizi AWS e un supporto immediato per quelli nuovi. Le organizzazioni impegnate in AWS potrebbero preferire le sue prestazioni native e l'accesso alle caratteristiche proprietarie.
Azure Resource Manager (ARM) è lo strumento IaC nativo di Microsoft per l'infrastruttura di Azure. Sebbene sia limitato ad Azure, offre una profonda integrazione con la piattaforma.
Le organizzazioni utilizzano i modelli ARM (formato JSON) per definire, implementare e gestire le risorse di Azure. ARM fornisce caratteristiche integrate tra cui il controllo degli accessi basato sui ruoli per la sicurezza, l'etichettatura delle risorse per l'organizzazione, i blocchi per prevenire l'eliminazione accidentale e la mappatura delle dipendenze per garantire che le risorse vengano implementate nell'ordine corretto.
Google Cloud Deployment Manager è lo strumento IaC nativo di Google che utilizza modelli YAML o Python per orchestrare le distribuzioni di Google Cloud. Sebbene sia specifico per la piattaforma, crea e configura risorse su più servizi (Cloud Storage per i dati, Compute Engine per le macchine virtuali, Cloud SQL per i database) aiutando a garantire che funzionino insieme come uno stack completo.
Gli strumenti di gestione della configurazione mantengono l'infrastruttura dopo il provisioning, contribuendo a garantire che i sistemi rimangano correttamente configurati, aggiornati e coerenti.
Ansible® è uno strumento di automazione di Red Hat® che gestisce la configurazione senza richiedere agenti sui sistemi di destinazione. In altre parole, Ansible non ha bisogno di software speciali installati sui server che gestisce. Si connette direttamente utilizzando SSH per eseguire i comandi.
Questo approccio senza agenti significa che Ansible funziona in ambienti cloud, on-premise e ibridi. I team scrivono playbook YAML che definiscono gli stati desiderati e Ansible aiuta a garantire che i sistemi corrispondano a quegli stati. È popolare per la gestione dei container Docker e delle implementazioni Kubernetes .
Puppet utilizza la configurazione dichiarativa per gestire grandi infrastrutture in ambienti cloud, on-premise e data center.
Controlla continuamente migliaia di server per assicurarsi che corrispondano alle configurazioni definite, correggendo automaticamente eventuali deviazioni. Puppet genera report dettagliati che mostrano cosa è cambiato e quando, rendendolo efficace per implementazioni più ampie.
Chef utilizza "ricettari" e "ricette" per definire le configurazioni dell'infrastruttura in qualsiasi ambiente: cloud, on-premise o ibrido.
Le organizzazioni si rivolgono spesso a Chef per il suo framework di test. I team possono verificare le configurazioni negli ambienti di test prima di eseguire il push in produzione. Questo approccio basato sull'individuazione precoce dei problemi può renderlo popolare nelle organizzazioni che richiedono aggiornamenti frequenti dell'infrastruttura e apprezzano framework di test solidi.
IBM® Terraform offre alle organizzazioni un unico workflow per fornire le infrastrutture cloud, i data center privati e le soluzioni SaaS, gestendoli in modo continuativo per tutto il loro ciclo di vita.
IBM aiuta i team DevOps a costruire, implementare e operare in modo più sicuro collegando le analisi del rischio tra codice, infrastruttura e ambienti di tempo di esecuzione.
Migliora il valore del tuo hybrid cloud e utilizza appieno le opportunità dell'agentic AI.