Infrastructure as a Code (IaC): tutto ciò che serve sapere

L’infrastruttura è uno dei principi fondamentali di un processo di sviluppo software: è direttamente responsabile del funzionamento stabile di un’applicazione.

Questa infrastruttura può variare da server, sistemi di bilanciamento del carico, firewall e database fino a complessi cluster di container.

In questo articolo tratteremo nello specifico tutto ciò che è necessario sapere sull’Infrastructure as a code: definizione, vantaggi e implementazione.

Le considerazioni sull’infrastruttura sono valide al di là degli ambienti di produzione, in quanto si estendono all’intero processo di sviluppo.
Includono strumenti e piattaforme come CI/CD, ambienti di staging e strumenti di test. Questi elementi aumentano con l’aumentare del livello di complessità del software.

L’approccio tradizionale per la gestione manuale dell’infrastruttura diventa una soluzione non scalabile per soddisfare le esigenze dei moderni cicli di sviluppo rapido del software basati su DevOps.

Ed è così che Infrastructure as Code (IaC) è diventata la soluzione de facto in fase di sviluppo.

Lo IaC consente di soddisfare le crescenti esigenze di modifiche dell’infrastruttura in modo scalabile e tracciabile.
È importante sottolineare che IaC non è un derivato dell’infrastruttura come servizio (IaaS) visto che sono due concetti diversi.

L’IaC non è limitato alle sole risorse basate su cloud, come lo IaaS, ma si applica ad una varietà di ambienti, inclusi quelli on-premise. 

Cosa si intende per Infrastructure as a Code (IaC)

Infrastructure as Code o IaC è il processo di provisioning e gestione dell’infrastruttura definito attraverso il codice, invece che tramite un processo manuale.

Poiché l’infrastruttura è definita come codice, consente agli utenti di modificare e distribuire facilmente le configurazioni, garantendo allo stesso tempo lo stato desiderato. Ciò significa che è possibile creare configurazioni di infrastruttura riproducibili.

Inoltre, definendo l’infrastruttura come codice è possibile:

• Integrare facilmente l’infrastruttura nei meccanismi di controllo per creare modifiche tracciabili e verificabili.

• Dare la possibilità di introdurre un’ampia automazione per la gestione dell’infrastruttura. Tutto ciò porta all’integrazione di IaC nelle pipeline CI/CD come parte integrante dell’SDLC.

• Eliminare la necessità di provisioning e gestione manuali dell’infrastruttura, per mantenere tutti gli ambienti all’interno della configurazione definita.

Tipologie di IaC

Sono due le tipologie di IaC:

Mutevole

Le infrastrutture mutevoli cambiano e si trasformano facilmente, mentre le infrastrutture immutabili non sono in grado di cambiare.
Mentre la IaC si impone come nuovo standard per le best practice IT, le infrastrutture si stanno spostando da modalità di funzionamento tradizionali ad altre più immutabili.

Questo perché i reparti IT si stanno impegnando per arrivare al rilascio continuo, con versioning e test di automazione incorporati nel processo DevOps.

L’obiettivo di tutto questo è consentire all’IT di distribuire un pacchetto e le sue dipendenze in modo coerente, con ambienti ogni volta identici.
Soluzioni, prodotti o servizi correlati devono essere costantemente aggiornati per continuare a soddisfare le esigenze in evoluzione.

I professionisti IT devono occuparsi singolarmente di ogni server e di ogni switch, attività che richiede molto tempo per identificare i problemi e generare soluzioni.

Immutabile

La IaC immutabile rappresenta uno scenario semplificato. in base al quale ogni componente deve seguire specifiche esatte, senza eccezioni.

Quando è necessario un cambiamento, il provisioning dell’infrastruttura viene effettuato secondo i nuovi requisiti con la sostituzione della vecchia IaC.

Questa uniformità dell’infrastruttura di base consente di sviluppare e distribuire applicazioni in modo molto più stabile e rapido.

La differenza tra approccio dichiarativo ed imperativo nella IaC

Quando si ha a che fare con gli strumenti IaC, ci sono due principali approcci differenzianti per la scrittura del codice: dichiarativo e imperativo. 

Un approccio imperativo consente agli utenti di specificare i passaggi esatti da eseguire per una modifica; il sistema non si discosta dai passaggi specificati.

Un approccio dichiarativo chiede agli utenti solo di definire il requisito finale: lo strumento o la piattaforma specifica gestisce i passaggi da eseguire per raggiungere il requisito definito.
L’approccio dichiarativo è preferito nella maggior parte dei casi d’uso di gestione dell’infrastruttura in quanto offre un grado maggiore di flessibilità durante la gestione.

Nella programmazione imperativa, si specifica un elenco di passaggi che lo IaC deve seguire per eseguire il provisioning di una nuova risorsa.
Basta chiedere allo strumento come creare ogni ambiente utilizzando una sequenza di imperativi di comando.

La programmazione dichiarativa è un approccio popolare all’infrastruttura come codice.
Bisogna definire lo stato finale desiderato della configurazione finale e la soluzione IaC capisce come arrivarci.

La programmazione dichiarativa è ripetibile, il che significa che può eseguire i comandi IaC più e più volte e ottenere comunque lo stesso risultato.
Il paradigma dichiarativo si adatta bene anche alla deriva della configurazione (le inevitabili e lente modifiche alla tua infrastruttura nel tempo) perché le fasi di provisioning dello strumento IaC non sono definite in modo esplicito.

Il più grande svantaggio dell’approccio dichiarativo è che si rinuncia a molto controllo sui singoli passaggi del processo di provisioning.

Inoltre, non è la scelta migliore per piccole correzioni e aggiornamenti che possono essere gestiti da un semplice script CLI (interfaccia a riga di comando): la programmazione dichiarativa può complicare eccessivamente le cose e rallentare il processo.

La imperativa richiede però una maggiore conoscenza degli script perché è necessario scrivere comandi per ogni fase di provisioning.
Ciò dà il controllo sul modo in cui esegui le attività dell’infrastruttura, il che è l’ideale quando c’è da apportare piccole modifiche, ottimizzare i processi per uno scopo specifico o tenere conto dei cambiamenti del software.

La più grande sfida iniziale per l’approccio imperativo è che richiede un alto livello di abilità con il linguaggio di programmazione, che i team dell’infrastruttura nelle fasi iniziali del viaggio DevOps potrebbero non avere ancora.

Gli script IaC imperativi sono spesso meno idempotenti: i passaggi predefiniti possono portare a risultati diversi a seconda dell’ambiente.
Inoltre, gli script IaC imperativi sono talmente consequenziali che un errore con un passaggio può causare il fallimento dell’intero processo.

Nel complesso, molte organizzazioni che cercano di automatizzare e orchestrare completamente la propria infrastruttura DevOps preferiscono l’approccio dichiarativo.

Si possono utilizzare strumenti IaC dichiarativi per creare script di configurazione altamente ripetibili e adattabili senza anni di esperienza di codifica.

Tuttavia, chi si avvicina all’automazione dell’infrastruttura, o non ha bisogno di una piattaforma di orchestrazione completa, l’approccio imperativo è spesso più semplice e facile da gestire.
Il confronto tra la programmazione dichiarativa e quella imperativa per IaC è solo una fase del processo di automazione dell’infrastruttura DevOps.

I vantaggi dell’infrastracture as code

Ci sono molti vantaggi associati all’infrastruttura come codice, dall’efficienza dell’automazione alla sua flessibilità per allinearsi con altre pratiche IT moderne.

• Velocità ed efficienza
  Il provisioning e la gestione automatizzati sono più veloci ed efficienti dei processi manuali. Ciò si estende non solo alle risorse fornite e alla virtualizzazione, ma anche ai database, al networking, alla gestione degli account utente e ad altri servizi collegati. 
  IaC può anche includere codice che si ridimensiona automaticamente (aggiunge o chiude ambienti e risorse quando non sono più necessari).
• Consistenza
  Gli sviluppatori di software possono utilizzare il codice per eseguire il provisioning e distribuire server e applicazioni in base alle pratiche e ai criteri aziendali, piuttosto che affidarsi agli amministratori di sistema in un ambiente DevOps.
  Uno sviluppatore potrebbe creare un file di configurazione per eseguire il provisioning e distribuire una nuova applicazione per il controllo qualità o prima che le operazioni subentrino per la distribuzione live in produzione.
• Allineamento con DevOps
  Con la configurazione dell’infrastruttura scritta come codice, si può passare attraverso lo stesso controllo della versione, test automatizzati e altri passaggi di una pipeline di integrazione continua e distribuzione continua (CI/CD). 
  Un’organizzazione può scegliere di combinare l’infrastruttura come codice con i contenitori che astraggono l’applicazione dall’infrastruttura a livello di sistema operativo.
  Poiché l’OS e l’infrastruttura hardware vengono forniti automaticamente e l’applicazione è incapsulata su di essa, queste tecnologie si dimostrano complementari per diversi obiettivi di implementazione, come test, staging e produzione.

Nonostante i suoi vantaggi, l’infrastruttura come codice presenta potenziali svantaggi. Richiede strumenti aggiuntivi, come un sistema di gestione della configurazione e di automazione/orchestrazione, che potrebbero introdurre curve di apprendimento e margini di errore. 

Eventuali problemi possono proliferare rapidamente attraverso i server, soprattutto in presenza di un’ampia automazione, quindi, è essenziale monitorare il controllo della versione ed eseguire test pre-rilascio completi.

Casi d’uso dell’infrastructure as code

Non sai quando usare IaC? La risposta più semplice è “quando devi gestire qualsiasi tipo di infrastruttura”.

Ecco i riferimenti per tre macro casi d’uso:

• Gestione delle infrastrutture: Terraform, Pulumi, AWS CloudFormation, Azure Resource Templates

• Gestione della configurazione con capacità di gestione dell’infrastruttura limitate: Ansible, Chef, Puppet.
• Gestione della configurazione: CFEngine

Uno strumento potrebbe non essere sufficiente nella maggior parte degli scenari.
Ad esempio, Terraform può essere eccellente per la gestione dell’infrastruttura in più ambienti cloud, ma può essere limitato quando sono necessarie configurazioni approfondite.

In questo tipo di situazioni, gli utenti possono utilizzare uno strumento come Ansible per eseguire le configurazioni necessarie.

Allo stesso modo, si può combinare qualsiasi strumento IaC e utilizzarlo nelle loro pipeline CI/CD a seconda dei requisiti esatti.

Un esempio reale: IaC per DevOps

Nel contesto dello sviluppo del software, un vincolo fondamentale è la necessità che l’ambiente in cui viene testato il codice sviluppato di recente rispecchi esattamente l’ambiente live in cui tale codice verrà distribuito.

 Questo è l’unico modo per garantire che il nuovo codice non entri in collisione con le definizioni del codice esistente: generando errori o conflitti che potrebbero compromettere l’intero sistema.

Un clone di un ambiente live, creato utilizzando esattamente lo stesso IaC dell’ambiente live, ha l’assoluta garanzia che se funziona nell’ambiente clonato funzionerà in live.

L’aggiunta dell’automazione alle fasi di test e virtualizzazione dei server sostituisce l’intervento umano, migliorando la produttività e l’efficienza.

Se in passato erano necessarie diverse ore di lavoro e risorse umane per completare il ciclo di distribuzione del software (sviluppatori, amministratori di sistema, amministratori di database, tester operativi), ora è possibile che lo sviluppatore completi da solo tutte le attività:

1. Lo sviluppatore scrive il codice dell’applicazione e le istruzioni relative alla gestione della configurazione che attiveranno azioni dall’ambiente di virtualizzazione e altri ambienti come il database, le appliance, gli strumenti di test, gli strumenti di consegna e altro ancora.
2. Alla consegna del nuovo codice, le istruzioni di gestione della configurazione creeranno automaticamente un nuovo ambiente di test virtuale con un server delle applicazioni più un’istanza di database che rispecchi esattamente la struttura dell’ambiente operativo live, sia in termini di service pack e controllo delle versioni, sia di dati live trasferiti a tale ambiente di test virtuale (la parte Infrastructure as Code del processo).
3. Quindi una serie di strumenti eseguirà i test di conformità necessari e l’identificazione e la risoluzione degli errori. 
   Il nuovo codice è pronto per la distribuzione nell’ambiente IT live.

Come implementare l’infrastruttura

Gli strumenti Infrastructure-as-code impongono la configurazione dal modello tramite metodi push o pull.

Nel metodo push, un server centralizzato invia la configurazione desiderata a uno o più sistemi specifici.

Il metodo pull viene avviato da una richiesta a un server centralizzato da uno o più sistemi nell’infrastruttura.

Gli strumenti in genere sono progettati per impostazione predefinita per la distribuzione push o pull del codice, ma possono essere configurati per istanze specifiche.

Questi strumenti dovrebbero inoltre essere in grado di ripristinare le modifiche al codice, come nel caso di problemi imprevisti da un aggiornamento. Esempi di strumenti di infrastruttura come codice includono AWS CloudFormation, Red Hat Ansible, Chef, Puppet, SaltStack e HashiCorp Terraform.

Alcuni si basano su un linguaggio specifico del dominio (DSL), mentre altri utilizzano un formato standard, come YAML e JSON. Per questo, quando si seleziona uno strumento, le organizzazioni dovrebbero considerare la distribuzione di destinazione.

Ad esempio, AWS CloudFormation è progettato per eseguire il provisioning e gestire l’infrastruttura su AWS e funziona con altre offerte AWS. In alternativa, Chef lavora con server locali e soluzioni di Infrastructure-as-a-Service di più fornitori di servizi cloud.