Che cos'è l'infrastruttura immutabile?

Le organizzazioni possono gestire l'infrastruttura attraverso due approcci: mutabile e immutabile. L'infrastruttura immutabile sostituisce completamente i server anziché modificarli. L'infrastruttura mutabile modifica i server sul posto, applicando aggiornamenti, patch e modifiche alla configurazione direttamente ai server di produzione.

Poiché si tratta principalmente di modificare i server esistenti, l'infrastruttura mutevole può sembrare più efficiente. Tuttavia, due fattori spesso rendono l'infrastruttura immutabile più pratica e preferibile.

Innanzitutto, il cloud computing e la containerizzazione hanno trasformato la velocità di distribuzione. Le organizzazioni possono ora sostituire le macchine virtuali (VM) e i contenitori in pochi minuti anziché nelle ore richieste per i server fisici. Gli strumenti di automazione dell'infrastruttura possono fornire e configurare nuovi server e risorse IT e applicare modifiche uniformi su larga scala.

In secondo luogo, l'infrastruttura immutabile può ridurre in modo significativo la deriva della configurazione, una caratteristica comune dell'infrastruttura mutevole, in cui un sistema si discosta gradualmente dallo stato previsto man mano che le modifiche si accumulano. La deriva della configurazione è particolarmente comune quando i problemi di rete interrompono il processo di implementazione, causando aggiornamenti parziali o falliti. Questa deriva può portare a scarse prestazioni, vulnerabilità della sicurezza e violazioni della conformità. 

Ad esempio, quando si implementa un aggiornamento di sicurezza su 100 server di produzione, gli strumenti di automazione possono creare 100 nuovi server con l'aggiornamento preinstallato e convalidarli in isolamento. Una volta convalidati, reindirizzano il traffico e dismettono i vecchi server, il tutto in pochi minuti e senza tempi di inattività.

L'infrastruttura immutabile segue un workflow in tre fasi: approvvigionamento di nuove Risorse, implementazione delle stesse e ripristino istantaneo quando necessario.

Questo workflow si applica a server, container, macchine virtuali, funzioni o qualsiasi altra risorse infrastrutturale per tutto il suo ciclo di vita.

Il provisioning crea automaticamente nuovi componenti dell'infrastruttura IT che utilizzano l'infrastructure as code (IaC), una pratica che utilizza modelli o codice dichiarativi per definire gli stati dell'infrastruttura previsti.

Per aggiornare un ambiente immutabile, i team creano una risorsa completamente nuova con la configurazione definita anziché utilizzare SSH (un protocollo di rete per l'accesso remoto sicuro ai server) per modificare quelli esistenti. 

Tutte le modifiche all'infrastruttura vengono quindi documentate in sistemi di controllo della versione come Git, garantendo che siano testate e riproducibili.

Gli strumenti di provisioning comuni includono: 

• Terraform: la piattaforma infrastructure-as-code di HashiCorp fornisce e gestisce l'infrastruttura su AWS, Google cloud, Azure e on-premise tramite le loro API, con sintassi HCL dichiarativa e file di stato per tenere traccia delle modifiche.

• Docker: crea immagini di container leggere basate su file system a livelli e virtualizzazione a livello di sistema operativo, principalmente su sistemi Linux ma anche Windows e macOS, consentendo una distribuzione più rapida rispetto alle VM tradizionali.

• Packer: HashiCorp’s tool che crea immagini di macchine identiche contemporaneamente per più provider di cloud e piattaforme (AMI per AWS, modelli VMware, container) da un'unica configurazione JSON o HCL.

• AWS CloudFormation: strumento nativo di AWS basato su modelli JSON/YAML per il provisioning di risorse AWS con rollback e rilevamento della deriva integrati. 

• Pulumi: piattaforma IaC che utilizza linguaggi di programmazione familiari (Python, TypeScript, Go) anziché linguaggi specifici del dominio, consentendo agli sviluppatori di utilizzare costrutti di programmazione standard come loop e condizionali.

Vale la pena ricordare che Puppet e Chef sono stati originariamente progettati per le infrastrutture mutabili, dove aggiornano i server in loco, anche se alcuni team li adattano ora accanto ad approcci immutabili.

Le implementazioni in infrastrutture immutabili sono atomiche: o riescono completamente o non si verificano affatto. Questo approccio è in linea con le pratiche DevOps e le pipeline di integrazione continua, che enfatizzano i test automatici, l'iterazione rapida e le distribuzioni affidabili.

Gli strumenti di automazione distribuiscono la nuova versione delle risorse, reindirizzano il traffico verso di essa e quindi dismettono quella vecchia. In caso di problemi durante la distribuzione, la vecchia risorsa rimane intatta e operativa, eliminando il tempo di inattività e i rischi di dipendenza.

Gli strumenti di implementazione e orchestrazione comuni includono: 

• Kubernetes: piattaforma di orchestrazione di container open source che gestisce applicazioni cloud-native containerizzate su larga scala tramite autoriparante, ridimensionamento automatico e aggiornamenti continui su cluster di macchine.

• Jenkins: pipeline CI/CD basate su server che automatizzano la creazione, il test e la distribuzione con un ampio ecosistema di plug-in (oltre 1.800 plug-in) per personalizzare le pipeline di compilazione, test e distribuzione.

• Azioni GitHub: piattaforma CI/CD basata sugli eventi integrata nei repository GitHub, attivata da commit di codice, pull request o pianificazioni senza richiedere server esterni.

• Ansible (Red Hat): principalmente uno strumento di gestione della configurazione, ma utilizzato anche per le implementazioni. Utilizza i playbook YAML per l'automazione senza agenti e non richiede l'installazione di software sui nodi gestiti, a differenza di Puppet o Chef. 

Poiché i server in un'infrastruttura immutabile sono effimeri, vengono cioè costantemente sostituiti, i dati persistenti devono essere memorizzati esternamente. Le organizzazioni utilizzano cloud databases, servizidi block storage o object storage per mantenere i dati separati dai server che vengono sostituiti. 

Quando un nuovo server è online, si riconnette ai dati esistenti tramite questi sistemi di storage esterni. La configurazione e i metadati si trovano spesso in sistemi di controllo delle versioni come Git. 

Ogni aggiornamento crea una nuova istanza, mantenendo un'immagine pulita per il rollback. Gli stessi strumenti di automazione che effettuano il provisioning e possono implementare possono ripristinare le versioni precedenti in pochi minuti. I team ridistribuiscono l'immagine precedente anziché eseguire il debug e la risoluzione dei problemi dei server modificati, riducendo notevolmente il lavoro investigativo tradizionalmente richiesto quando le modifiche alla gestione della configurazione falliscono.

I vantaggi di un’infrastruttura immutabile sono in gran parte legati al processo di distribuzione, che l’immutabilità rende più semplice e più coerente.

L'infrastruttura immutabile elimina gli stati ambigui dei server grazie alle implementazioni atomiche: gli aggiornamenti vanno completamente in porto o falliscono del tutto.

Le infrastrutture mutabili rischiano aggiornamenti parziali che portano a stati “intermedi” imprevedibili, con caratteristiche che non sono del tutto note agli amministratori. Questa situazione può rendere difficile la risoluzione dei problemi e aumentare i rischi per la sicurezza.

Un'infrastruttura immutabile elimina la possibilità di un tale stato. Se un aggiornamento non riesce, il server rimane nel suo stato ben documentato. Se l'operazione ha esito positivo, il nuovo server arriva completamente configurato e testato.

L'infrastruttura immutabile aiuta a consentire una rapida scalabilità orizzontale, la pratica di soddisfare la domanda aggiungendo un numero maggiore di macchine più piccole a una rete (anziché una macchina di grandi dimensioni). Un sistema con scala orizzontale è più tollerante ai guasti e può ridurre i colli di bottiglia di elaborazione distribuendo il carico di lavoro.

Questo approccio si ottiene utilizzando sistemi di bilanciamento del carico, che distribuiscono il traffico di rete su più server per migliorare le prestazioni. Strumenti come Nginx e AWS Elastic Load Balancing (ELB) di Amazon aiutano a supportare questa pratica utilizzando un algoritmo per assegnare le richieste degli utenti al server più efficiente in un determinato momento.

Questa combinazione di bilanciamento del carico e orchestrazione dei container rende l'infrastruttura immutabile, con i suoi modelli riproducibili, essenziale per far funzionare più server identici con breve preavviso. Questa configurazione può essere particolarmente utile quando le reti prevedono enormi picchi di traffico, ad esempio durante una vacanza dedicata allo shopping o la vendita dei biglietti. È utile anche per il coordinamento tra le regioni globali in cui il traffico raggiunge picchi in orari diversi e talvolta sovrapposti.

L'infrastruttura immutabile rafforza la sicurezza eliminando gli “stati snowflake” imprevedibili, server con configurazioni sconosciute dopo gli aggiornamenti non riusciti, e mantenendo percorsi di controllo completi di tutte le modifiche.

Ogni server si conforma esattamente al file immagine sorgente che lo descrive, rendendo più semplice l'identificazione delle vulnerabilità di sicurezza, come l'installazione di software non autorizzato o l'escalation di privilegi, e l'esecuzione di audit di sicurezza. I sistemi di controllo della versione tengono traccia di ogni modifica apportata al sistema, incluso chi l'ha apportata, quando e perché. Questa cronologia immutabile rende più rapide l'analisi forense e la risposta agli incidenti. I team possono identificare immediatamente le configurazioni compromesse ed eseguire il rollback agli stati noti di validità, se necessario.

Un'infrastruttura immutabile elimina inoltre la necessità di utilizzare gli accessi Secure Shell (SSH) per modificare i server internamente, riducendo la superficie di attacco complessiva della rete.

L'immutabilità presenta anche dei compromessi rispetto a un'infrastruttura più tradizionale e mutevole, principalmente per quanto riguarda la data storage.

In un'infrastruttura mutabile, un server potrebbe scrivere dati critici delle applicazioni sul disco locale, rendendo pericolosa o potenzialmente dannosa l'eliminazione e la sostituzione del server e del disco. Pertanto, in un'infrastruttura immutabile i dati devono essere memorizzati esternamente, aggiungendo un ulteriore livello di complessità al sistema.

Questo metodo può essere eseguito utilizzando l'archiviazione di dati esterna come cloud databases, block storage o object storage. Quando una nuova macchina virtuale è online, può riconnettersi senza problemi ai dati esistenti tramite questo storage esterno. Le organizzazioni generalmente mantengono la configurazione e i metadati nei sistemi di controllo delle versioni come Git.

Tuttavia, la vera “immutabilità” di un'infrastruttura immutabile è talvolta contestata. Questa limitazione è dovuta al fatto che i dati degli utenti di rete memorizzati esternamente sono in uno stato di flusso costante e quindi non possono essere confrontati con uno stato noto.