Una risorsa essenziale, grazie alla quale è possibile gestire un’infrastruttura e tutte le sue componenti (rete, macchine virtuali, servizi di bilanciamento del carico e topologia di connessione) seguendo un modello descrittivo efficiente: Infrastructure as Code rappresenta uno strumento estremamente vantaggioso per le imprese moderne.
L’approccio Infrastructure as Code sfrutta la tipologia di controllo delle versioni usato dal team DevOps per il codice sorgente. Una soluzione che consente di generare lo stesso ambiente ogni volta che il modello come codice viene applicato.
L’infrastruttura così configurata comporta numerosi vantaggi e semplifica profondamente il lavoro del team tecnico e i processi di distribuzione. Scopriamo tutto quel che dovresti conoscere sull’Infrastructure as Code, come funziona, approcci e vantaggi.
Indice dei contenuti
Cos’è l’Infrastructure as Code?
L’Infrastructure as Code, o IaC, identifica un approccio alla configurazione di un’infrastruttura tramite codice anziché attraverso processi manuali.
La gestione, quindi, avviene come se si trattasse di un software e si compie in un modello descrittivo. Anche per questo l’infrastruttura viene definita programmabile.
Questo approccio è stato sviluppato per offrire una soluzione al problema della deriva dell’ambiente nella pipeline di versione: la IaC permette ai programmatori di gestire l’infrastruttura nel suo insieme, senza dover configurare singolarmente le impostazioni degli ambienti di distribuzione.
Ogni ambiente, infatti, presenta caratteristiche differenti, tra cui incoerenze che potrebbero provocare problematiche durante il processo di distribuzione. Inoltre, i vari ambienti richiedono processi manuali piuttosto complessi, non affidabili al 100% e difficilmente monitorabili.
In un’Infrastructure as Code i file di configurazione semplificano quindi la distribuzione e le eventuali modifiche, garantendo la ripetibilità del provisioning dello stesso ambiente.
Questi file sono sottoposti al controllo della sorgente, esattamente come gli altri file di codice sorgente software. In tal modo, l’infrastruttura fondata su codice permette di suddividere i componenti modulari. Essi, grazie all’automazione, possono essere connessi reciprocamente in vari modi.
Automatizzando il provisioning dell’infrastruttura, il team tecnico non deve più occuparsi delle attività di provisioning e di gestione dei sistemi operativi, del server e dello storage.
Tutti i principali vantaggi
L’Infrastucture as Code, come anticipato, è innanzitutto un modo per automatizzare i processi affidandosi al codice, evitando di dover eseguire attività manuali e ottenendo, in questo modo, un notevole risparmio di tempo, denaro e risorse.
Non è più necessario configurare e aggiornare gli hardware singolarmente e a livello fisico, ma si possono distribuire diverse macchine virtuali come se fossero dei programmi, sfruttando lo stesso set di codice e creando un’infrastruttura elastica, scalabile e ripetibile.
L’infrastruttura diventa più veloce ed è possibile fare affidamento sulla virtualizzazione, ricorrendo all’ infrastruttura Cloud Computing e ai container-informatica. Grazie all’Infrastucture as Code risulta essere più semplice limitare e ridurre gli errori, eseguendo inoltre dei test in ambienti ad hoc per verificare il corretto funzionamento delle applicazioni nelle prime fasi del ciclo di sviluppo.
Inoltre, la IaC è in grado di fornire ambienti stabili e su larga scala con grande velocità, assicurando la massima coerenza tra i diversi ambienti ed effettuando le operazioni in maniera automatizzata. Valutiamo tutti i vantaggi dell’Infrastucture as Code per comprenderne realisticamente la portata.
Velocità e consistenza
Basandosi su un’infrastruttura come codice, la configurazione risulta essere molto più rapida, perché si effettua seguendo uno script. Questo procedimento può essere applicato a ogni tipo di ambiente, rendendo più agile lo sviluppo dell’intero ciclo di vita del software.
Eliminando i processi manuali è, inoltre, possibile ridurre al minimo l’eventualità di un errore umano: questi ultimi risultano essere piuttosto frequenti e imprevedibili. La configurazione risulterà totalmente affidabile e priva di discrepanze. L’IaC permette di beneficiare non solo di grande velocità, ma anche di una profonda consistenza.
Responsabilità ed efficienza
Eseguendo la versione dei file di configurazione IaC come se fossero normali file di codice sorgente, è possibile ottenere la completa tracciabilità delle modifiche subite da ciascuna configurazione. Tutto ciò che è stato svolto può essere individuato, così come è possibile conoscere quale utente ha operato (e in che modo), avendo quindi pieno controllo e totale responsabilità dell’infrastruttura.
In più, con un’infrastruttura come codice, le architetture possono essere distribuite in diverse fasi, rendendo il ciclo di vita dello sviluppo del software più efficiente e produttivo. Inoltre, la massima efficienza può essere raggiunta trasferendo infrastruttura e codice in produzione in un solo passaggio al momento della distribuzione.
Riduzione tempistiche di produzione e immissione sul mercato
L’automazione offerta da IaC permette di abbattere le tempistiche utili per lo sviluppo, l’esecuzione dei test e la produzione dell’infrastruttura. L’Infrastucture as Code, tracciando e codificando ogni passaggio, permette di automatizzare anche il provisioning delle infrastrutture legacy (che generalmente richiedono processi molto lunghi per la produzione e immissione sul mercato).
Più coerenza
Generalmente, il cosiddetto scostamento della configurazione può avvenire quando le modifiche o l’aggiornamento della configurazione comportano una mancata corrispondenza tra ambienti di sviluppo, implementazione e test. Ciò si ripercuote sulla fase di implementazione, provocando inoltre vulnerabilità della sicurezza e numerosi rischi in fase di sviluppo di applicazioni/servizi (i quali devono rispettare specifici standard di conformità, secondo normativa). L’Infrastucture as Code fornisce sempre lo stesso ambiente, impedendo, di fatto, il fenomeno dello scostamento.
Riduzione dei costi
L’Infrastucture as Code consente di ridurre l’effort necessario, così come il tempo utile e la necessità di coinvolgere competenze specializzate per il provisioning e la scalabilità dell’infrastruttura. Ma non solo: IaC, infatti, permette di impiegare in modo estremamente efficiente la struttura dei costi, formulata in base al consumo del cloud computing. Gli sviluppatori dovranno dedicare meno tempo al collegamento e potranno concentrarsi sullo sviluppo di soluzioni software mission-critical estremamente innovative.
Protezione in caso di abbandono
Le organizzazioni che non impiegano l’Infrastucture as Code delegano, generalmente, al personale IT specializzato o a ingegneri esperti le procedure di provisioning. Nel caso in cui una di queste figure professionali decidesse di abbandonare l’organizzazione, gli altri esperti dovrebbero ricostruire l’intero processo. Grazie all’IaC, però, è possibile proteggere l’azienda dai rischi connessi all’abbandono, poiché l’intelligence del provisioning rimane sempre di proprietà e all’interno dell’organizzazione.
Confronto tra infrastruttura mutabile e infrastruttura immutabile
Per l’automazione intelligente della struttura con Infrastucture as Code è fondamentale scegliere una soluzione ad hoc, in grado di rispondere alle specifiche esigenze. Pertanto, è necessario comprendere la differenza tra infrastruttura mutabile e immutabile. Scopriamo di più nei prossimi paragrafi.
IaC mutabile e immutabile
La differenza principale tra Infrastucture as Code mutabile e immutabile è la possibilità di modificare la struttura una volta implementata.
Le infrastrutture mutevoli sono soggette a modifiche: ciò, però, spesso provoca problematiche relative alla configurazione. Quando una parte della struttura cambia, l’armonia generale viene meno e anche per quanto riguarda la sicurezza potrebbero esserci ripercussioni, poiché tutte le applicazioni devono essere coerenti con la configurazione dell’infrastruttura nella sua globalità.
La Infrastucture as Code immutabile, al contrario, può subire delle modifiche ma solo quando applicate alle dichiarazioni originali. Le modifiche pronte vengono eseguire in modo sistematico e coerente, su ogni dispositivo e configurazione. Ciò permette di garantire maggiore coerenza e sicurezza al sistema, evitando che rimangano porte aperte (che rappresentano i migliori punti di accesso per gli hacker).
IaC mutabile
Come anticipato, l’infrastruttura mutabile può subire una modifica o un aggiornamento successivo al provisioning iniziale. Nonostante questo tipo di struttura garantisca maggiore flessibilità e personalizzazione dei server, essa risulta maggiormente soggetta ai problemi di sicurezza. Inoltre, non permette di mantenere la coerenza tra le implementazioni e all’interno delle versioni, rendendo complesso il processo di tracciamento di queste ultime.
IaC immutabile
La Infrastucture as Code immutabile non può essere modificata a seguito del provisioning iniziale. Per poter modificare una simile struttura, occorre sostituirla con un’infrastruttura nuova. Quest’ultima, essendo semplice da realizzare su IaC e su cloud, assicura massima praticità e fattibilità ai team di lavoro. L’infrastruttura immutabile abbatte totalmente il problema dello scostamento della configurazione, mantenendo sempre la coerenza tra gli ambienti di implementazione e di test. Permette, inoltre, di semplificare le fasi di tracciamento delle versioni e consente di ritornare a qualsiasi versione precedente.
Confronto tra approccio imperativo e dichiarativo
Due i possibili approcci all’Infrastucture as Code: l’approccio dichiarativo e l’approccio imperativo. Il primo viene impiegato per la definizione dello stato del sistema, per decidere quali siano le risorse indispensabili e le proprietà che ogni risorsa deve possedere. L’esecuzione della configurazione scelta viene affidata a uno strumento Infrastucture as Code. L’approccio dichiarativo rappresenta la migliore strategia per semplificare la gestione dell’infrastruttura in caso di arresto, poiché si possiede un elenco dello stato degli oggetti effettivi presenti nel sistema.
L’approccio imperativo, invece, viene utilizzato per la definizione dei comandi necessari per la creazione della configurazione prescelta. Tali comandi verranno, quindi, eseguiti nella corretta sequenza.
Gli strumenti Infrastucture as Code hanno la capacità di operare in entrambe i casi, sia che si preferisca l’approccio dichiarativo sia imperativo, ma generalmente possono preferire l’uno o l’altro approccio in base alle specifiche tecniche. Molti strumenti IaC utilizzano l’approccio dichiarativo, eseguendo in automatico il provisioning dell’infrastruttura desiderata. In questo modo, quando lo stato dovrà essere soggetto a modifiche, sarà lo stesso strumento IaC ad applicarle. Contrariamente, dovrà essere l’utente ad applicare le modifiche quando si predilige un approccio imperativo.
Strumenti principali dell’Infrastructure as Code
Infrastucture as Code impiega specifici strumenti di automazione dei server e per la gestione della configurazione: tali risorse rappresentano, molto spesso, la vera e propria anima dell’infrastruttura IaC.
Tra le opzioni maggiormente diffuse e impiegate vi sono:
- Chef, uno strumento di automazione configurativa che permette di gestire l’infrastruttura come codice. Chef impiega delle “ricette” per definire come il sistema deve essere gestito e configurato;
- Puppet. Anche Puppet è uno strumento di automazione configurativa che automatizza il provisioning e la gestione delle infrastrutture. Tale risorsa impiega i moduli per dichiarare come le risorse devono essere configurate;
- Azure Resource Manager (ARM) Templates (Microsoft Azure). Gli strumenti ARM Templates vengono utilizzati in Microsoft Azure per implementare e gestire le risorse come codice. Scritti in JSON, consentono di definire l’infrastruttura prediligendo l’approccio dichiarativo;
- Google Cloud Deployment Manager (GCP). Deployment Manager è lo strumento di IaC di Google Cloud Platform. Utilizza modelli in formato YAML per dichiarare e implementare l’infrastruttura su Google Cloud;
- Packer. Creato da HashiCorp, questo strumento permette di generare immagini da macchina virtuale da configurazioni codificate. Le immagini possono poi essere utilizzate in Terraform, Ansible o in altri strumenti di automazione;
- Terraform, uno strumento open-source di HashiCorp utile per la creazione, la modifica e la gestione dell’infrastruttura come codice. Supporta una vasta gamma di fornitori cloud, consentendo agli utenti di definire l’infrastruttura in modo dichiarativo;
- Saltstack. Questa risorsa di automazione viene impiegata per gestire e configurare l’infrastruttura. Opera su modello master-minion, secondo il quale è il master a inviare istruzioni ai minion;
- AWS CloudFormation, uno strumento di gestione delle risorse di AWS che consente di definire e implementare l’infrastruttura AWS come codice. Gli utenti possono utilizzare modelli JSON o YAML per descrivere le risorse.
Perché IaC è importante per DevOps?
Infrastructure as Code e DevOps sono strettamente connessi e si può considerare IaC come la componente necessaria per l’adozione della metodologia DevOps. È sempre più difficile, infatti, distinguere tra il codice di configurazione di un’infrastruttura e il codice con cui eseguire le applicazioni. Di conseguenza, risulta complesso percepire le differenze tra sviluppatori e responsabili delle operazioni.
IaC è fondamentale per adottare la pipeline di integrazione e distribuzione continua (CI/ED) e consente agli sviluppatori di ridurre il lavoro di provisioning, dovendosi semplicemente basare su uno script per rendere l’infrastruttura operativa. Con il metodo CI/CD si può contare su automazione costante e monitoraggio continuo per tutto il ciclo di vita delle applicazioni, dalle fasi di test al deployment.
Per evitare discrepanze e incoerenze, i team di IaC e di DevOps devono allinearsi, distribuendo le applicazioni e configurando gli ambienti con le medesime modalità.
Un procedimento relativamente facile grazie all’Infrastructure as Code, che permette alle due parti di ricorrere alla stessa descrizione per il deployment dell’applicazione, favorendo così un approccio DevOps.
Con IaC, inoltre, è possibile applicare all’infrastruttura le migliori procedure di DevOps, che può così fare riferimento alla stessa pipeline di CI/CD usata dalle app durante lo sviluppo software, affidandosi agli stessi test e controlli.
