DevOps: Dalle macchine virtuali ai container

Una delle ragioni della fortuna di DevOps¹ è la focalizzazione sulla risoluzione del conflitto esistente tra lo sviluppo (Dev) e la gestione (Ops) dei sistemi informativi. Il Dev ha la responsabilità di soddisfare tempestivamente i requisiti di business, mentre l’Ops quella di mantenere i sistemi stabili e disponibili. La maturità di un’architettura rispetto allo stato dell’arte si riconduce proprio alla garanzia offerta nel coniugare queste due esigenze, ovvero la rapidità con cui è possibile l’introduzione dei cambiamenti e la stabilità offerta dal sistema.
Ogni applicazione in esecuzione è composta dal codice sorgente scritto dagli sviluppatori con l’aggiunta di altri elementi necessari a farla funzionare. Questi possono essere librerie statiche o dinamiche (moduli database, API, driver, funzioni matematiche), file binari per l’esecuzione del codice (interpreti di linguaggio, ambienti di esecuzione, script, server applicativi) e le configurazioni.
A corredo di tali componenti possono essere presenti altri file come risorse statiche (traduzioni, immagini, dati precompilati e ottimizzati). Questo insieme di componenti prende il nome di ambiente di esecuzione e si colloca nello user-space del sistema.
L’ambiente di esecuzione e l’applicazione necessitano altresì di un sistema operativo, che a sua volta viene preconfigurata dai sistemisti per funzionare su di una particolare infrastruttura e può includere componenti specifici in kernel-space.

Per funzionare, un servizio ha bisogno di tutte e tre le componenti: ambiente di esecuzione, applicativo e sistema operativo.

Le macchine virtuali² sono state per lungo tempo una tecnica efficiente per gestire i sistemi operativi e rendere indipendenti le applicazioni dall’hardware. La loro gestione è stata tradizionalmente posta in carico ai sistemisti. Una macchina virtuale (VM) offre all’utente la stessa interfaccia d’uso di un server reale, completo delle sue componenti hardware, senza in realtà monopolizzare un hardware. Grazie alle VM è possibile installare un sistema con la sua configurazione su una singola macchina server, rendendolo indipendente dagli altri in esecuzione su di essa. Un server host può gestire un elevato numero di macchine virtuali a seconda delle risorse disponibili.

Il funzionamento di una VM è legato all’installazione di un software di virtualizzazione chiamato hypervisor (supervisore) sull’infrastruttura o nel sistema operativo. L’hypervisor si occupa della gestione (ossia della creazione, modifica, cancellazione, replica, backup…) e del mantenimento in operatività della VM. L’hypervisor distribuisce tra le diverse macchine le risorse infrastrutturali disponibili, a seconda della priorità di assegnazione indicata a priori dall’operatore.

Le VM isolano i servizi dal sistema hardware sottostante, riproducendo interamente l’ambiente di esecuzione nel sistema operativo installato al suo interno. Il sistema operativo, in presenza di una VM, gestisce le risorse tra le applicazioni presenti nel proprio user-space.

Se ci troviamo a dover distribuire un servizio su larga scala, o più semplicemente su tipi di infrastruttura differenti (cloud , workstation, server fisici) è necessario creare un’intera copia dell’ambiente di esecuzione. Quando uno o più servizi installati sulla stessa macchina fanno ricorso alle medesime componenti (librerie, binari, file o parti del kernel-space), otteniamo una duplicazione dei componenti stessi poiché è necessario ripetere l’allocazione di queste risorse in ogni macchina virtuale. Esaurite le risorse fisse di una macchina virtuale, è necessario crearne una nuova oppure arrestarne l’esecuzione per incrementare le risorse assegnate al sistema operativo. Per replicare una macchina virtuale è necessario fare una copia completa di tutta questa struttura.

I container

La tecnica dei container si occupa di fornire un sistema di virtualizzazione più efficiente e sofisticato, rispetto alle VM, creando un singolo livello di astrazione virtuale detto layer per ogni singolo elemento richiesto dall’applicazione.

L’assonanza del termine con il mondo del trasporto merci non è accidentale: deriva dall’idea di trovare la forma standard per un’unità adatta al trasporto di generi di natura differente. Indipendentemente dal vettore e dall’infrastruttura utilizzata (navi, treni, autotreni…) è possibile seguire uno standard di interfaccia comune per l’aggancio di queste unità. I container software sono composti da una stratificazione di livelli, allocati nelle risorse dell’infrastruttura una singola volta.

Trasportare, avviare e gestire un’unità container è un’operazione molto più semplice e rapida rispetto a quanto possibile con una VM. Il container preserva buona parte delle caratteristiche di isolamento offerte da una macchina virtuale, ma è eseguito in user-space. Si tratta quindi di una normale applicazione. Il kernel-space utilizzato dai container non è più replicato dall’hypervisor, ma offerto dal sistema di virtualizzazione, detto container engine.

Il container elimina la necessità di distribuire pacchetti intermedi (come i file di installazione) e include la definizione dell’ambiente per il funzionamento applicativo con le tecniche di infrastructure-as-code e configuration-as-code.

Questo pacchetto consente di trasportare servizi modulari da un cloud all’altro ed è rapido da rilasciare. Si rende più veloce anche tutta la parte di provisioning delle configurazioni ed elimina le operazioni manuali di configurazione in carico ai sistemisti, responsabilità ora condivisa con gli sviluppatori, che si fa più intensa e flessibile durante tutto il processo di sviluppo.

I container mettono a disposizione un meccanismo di pacchettizzazione logico grazie al quale le applicazioni possono essere astratte dall’ambiente in cui sono eseguite. Questo disaccoppiamento consente di eseguire facilmente e in modo coerente il deployment delle applicazioni basate su container, indipendentemente dal fatto che l’ambiente di destinazione sia on-premises³ o cloud. La containerizzazione consente una chiara separazione dei compiti, in quanto gli sviluppatori si concentrano sull’applicazione, mentre le operations IT possono concentrarsi sul deployment e sulla gestione, senza preoccuparsi di dettagli relativi alle applicazioni, quali le versioni software e le configurazioni specifiche dell’applicazione.

Invece di virtualizzare lo stack hardware, come nel caso delle macchine virtuali, i container eseguono la virtualizzazione a livello del sistema operativo. In tal modo, diversi container possono essere eseguiti direttamente sul kernel del sistema operativo. Ciò significa che i container sono molto più leggeri, condividono il kernel del sistema operativo, si avviano molto più velocemente e utilizzano una frazione della memoria rispetto a quanto richiede l’avvio di un intero sistema operativo.

I container consentono di creare ambienti isolati da altre applicazioni e sono realizzati per funzionare praticamente ovunque, facilitando notevolmente lo sviluppo e il deployment su sistemi operativi Linux,

Windows e Mac, su macchine virtuali o bare metal, sulla macchina di uno sviluppatore o in data center on-premise e, naturalmente, nel cloud.

I container virtualizzano le risorse in termini di CPU, memoria, archiviazione e rete a livello di sistema operativo, offrendo agli sviluppatori una visualizzazione del sistema operativo logicamente isolata da altre applicazioni.

Dall’architettura monolitica a quella basata sui servizi

I container funzionano meglio nelle architetture basate sui servizi. Contrariamente alle architetture monolitiche, dove ogni parte dell’applicazione è intrecciata alle altre, le architetture basate sui servizi separano i prodotti in componenti distinti. La separazione e la suddivisione delle operazioni consentono ai servizi di rimanere in esecuzione anche se alcune operazioni si interrompono, aumentando l’affidabilità dell’applicazione nel suo complesso.

La divisione in servizi consente inoltre di sviluppare più velocemente e in modo più affidabile. Le componenti più piccole sono più facili da gestire e, poiché i servizi sono separati, è più semplice testare gli output di input specifici.

I container sono perfetti per le applicazioni basate sui servizi, poiché è possibile eseguire un controllo di integrità di ogni container, limitare ogni servizio a risorse specifiche e avviarli e arrestarli indipendentemente l’uno dall’altro.

Poiché i container astraggono dal codice, consentono di trattare i servizi separati come scatole nere, riducendo ulteriormente lo spazio che lo sviluppatore deve gestire. Quando gli sviluppatori lavorano su servizi che dipendono da altri servizi, possono facilmente avviare un container per quel servizio specifico, senza dover configurare l’ambiente corretto e risolvere i problemi in anticipo.

¹ DevOps è un insieme di pratiche che combina lo sviluppo di software e le operazioni IT. Ha lo scopo di abbreviare il ciclo di vita dello sviluppo dei sistemi e fornire consegne continue con alta qualità del software. DevOps è complementare allo sviluppo del software Agile, infatti diversi aspetti di DevOps sono derivati dalla metodologia Agile.

² In informatica il termine macchina virtuale (Virtual Machine o VM) indica un software che, attraverso un ambiente virtuale, emula il comportamento di una macchina fisica (sia essa un PC o un server) grazie all’assegnazione di risorse hardware (porzioni di Hard Disk, RAM e CPU).
³ Il software on-premises (letteralmente “in sede”), in contrapposizione al software come servizio (SaaS), prevede l’installazione ed esecuzione del software direttamente su macchine locali.

Bibliografia:

• https://azure.microsoft.com/it-it/free/kubernetes-service/
•  https://cloud.google.com/containers
•  https://cloud.google.com/kubernetes
•  https://aws.amazon.com/it/containers/
•  DevOps Guida per integrare Development e Operations e produrre software di qualità, APOGEO, Fabio Mora
•  https://docs.docker.com
•  Clean architecture. Guida per diventare abili progettisti di architetture software, APOGEO, 2018, Robert C. Martin
•  Clean Code: Guida per diventare bravi artigiani nello sviluppo agile di software, APOGEO, Robert C. Martin