Container e Containerization: cos'è e come funziona

In questo articolo cercheremo di spiegare cosa si intende per Container in ambito IT, illustrando non soltanto il significato del termine ma anche il notevole impatto in termini di efficienza, prestazioni e affidabilità nei principali scenari in cui questo paradigma di virtualizzazione viene ad oggi utilizzato: lo sviluppo di software e il deploy dei servizi negli ambienti di produzione, che corrispondono alle fasi di coding, releasing e operating della metodologia DevOps.

Cenni storici

Per capire cosa sono i Container, può essere utile fare qualche passo indietro nel tempo e mettere a fuoco le tre principali modalità di gestione dei data center, delle server farm e più in generale delle infrastrutture hardware deputate all'erogazione di servizi e applicativi negli ultimi decenni.

1970-2000: Infrastrutture Fisiche

Per almeno trent'anni dall'introduzione del concetto stesso di server farm, il deploy di applicazioni avveniva all'interno di una infrastruttura tradizionale formata da macchine fisiche: in altre parole, ogni volta che si aveva la necessità di mettere in piedi un singolo nuovo server era necessario affrontare una pluralità di investimenti non banali in termini di hardware e software necessari, oltre ovviamente agli inevitabili costi di trasporto, installazione, manutenzione, etc.

Non parliamo poi della necessità, estremamente frequente quando si parla di applicazioni non banali e/o non rivolte a una ristretta cerchia di utenti, di mettere in piedi sistemi scalabili (web garden, database cluster, etc.). Si tratta di un approccio estremamente oneroso, che presenta costi elevati sia in fase di startup che in termini di manutenzione: inevitabilmente, già a partire dai primi anni 2000, si è cercato di trovare alternative più sostenibili, soprattutto per quelle aziende che non avevano l'infrastruttura dati come core business.

2000-2012: Macchine Virtuali

Un primo passo verso la semplificazione è stato compiuto nei primi anni 2000, con l'avvento della tecnologia VMware e delle macchine virtuali.  L'idea alla base delle VM è piuttosto semplice: il sistema operativo installato sul server (host) viene messo in grado di condividere le risorse hardware della macchina con una pluralità di altri sistemi operativi (guest); la responsabilità di questa "orchestrazione" delle risorse hardware disponibili è affidata a un sistema operativo apposito, chiamato Hypervisor, installato sulla macchina server e con il compito di coordinare l'attività dei sistemi guest.

In questo modo si riduce fortemente la necessità da parte dell'azienda di investire in hardware, in quanto la creazione di nuovi server può essere effettuata a livello logico semplicemente aggiungendo un sistema guest all'interno dell'hypervisor già presente: anche la gestione dell'infrastruttura risulta più semplice, poiché i sistemi guest possono essere ricavati da template preconfigurati con una serie di applicazioni preinstallate e pronte all'uso, così da poter essere messi in esercizio in pochi minuti. Inutile dire che si riducono anche i point of failure a livello hardware, poiché il numero di periferiche e componenti acquistati si riduce drasticamente, così come le possibilità che qualcosa possa rompersi, smettere di funzionare o risultare "incompatibile" con driver, software o configurazioni particolari.

Gli indubbi punti di forza della virtualizzazione nella modalità di gestione dei data center hanno portato a un vero e proprio boom di questa tecnologia, che ha rivoluzionato l'assetto della maggior parte delle server farm a livello mondiale nel giro di pochissimi anni (dal 2000 al 2010 circa, con un picco a partire dal 2006), sposandosi alla perfezione con la crescente popolarità delle architetture in cloud. La quasi totalità dei servizi di server hosting offerti in quegli anni veniva erogata in questo modo, provocando la nascita di una serie di sigle a tutt'oggi utilizzate per definire le varie tipologie di prodotto IaaS (Infrastructure as a Service):

• VPS, acronimo per Virtual Private Server: una singola macchina virtuale utilizzabile tramite servizi di gestione managed (es. Plesk) e/o accessibile in modalità unmanaged mediante sistemi di remote desktop (RDP, VNC, etc.).
• Public Cloud: una o più macchine virtuali istanziabili all'interno di un sistema host utilizzato da una pluralità di utenti diversi. La condivisione è limitata alle risorse hardware utilizzate e/o al relativo Hypervisor, mentre le singole VM restano accessibili unicamente dal singolo cliente.
• Private Cloud: un sistema host configurato secondo le necessità del singolo utente, con possibilità di creare una o più macchine virtuali al suo interno mediante un accesso dedicato all'Hypervisor. A differenza del Public Cloud, le risorse hardware disponibili (solitamente pre-allocate al momento della creazione del Private Cloud) sono utilizzate in modo esclusivo dal singolo cliente, tanto quanto le VM create al suo interno.

A fronte degli indubbi vantaggi descritti, le macchine virtuali comportano però anche una serie di limitazioni:

• Vincoli legati al sistema operativo, sia in termini di compatibilità hardware e software che di licensing costs, oltre ovviamente ai costi di installazione e manutenzione.
• Portabilità: le macchine virtuali non sono facili da spostare da un host all'altro, in quanto hanno spesso una serie di dipendenze (ad es. a livello di hardware, driver e networking) che ne vincolano l'utilizzo all'interno dell'Hypervisor nel quale sono state create.
• Scalabilità: le macchine virtuali hanno delle esigenze hardware minime che, anche se non in misura pari a quanto avveniva con i server fisici, obbliga comunque a dover sostenere costi in termini di risorse hardware da pre-acquistare e/o pre-allocare (soprattutto CPU, RAM e spazio di archiviazione) nel caso in cui si voglia avere la libertà di aggiungere elementi aggiuntivi all'infrastruttura.
• Agilità: le macchine virtuali, proprio come le macchine fisiche, dipendono da un sistema operativo e sono quindi soggette a tutte le limitazioni di quest'ultimo in termini di tempi di avvio, arresto, aggiornamento, riconfigurazione e così via.

2012-2019 (e oltre): Container

E' proprio per risolvere le limitazioni ancora presenti nella gestione dei server tramite macchine virtuali che sono stati sviluppati i Container, che ad oggi rappresentano lo step più recente del percorso tecnologico che abbiamo fin qui riassunto.  A differenza delle macchine virtuali, il cui scopo è quello di emulare il funzionamento di una macchina fisica all'interno di un host condiviso per mezzo di un Hypervisor, i Container hanno lo scopo di emulare un determinato sistema operativo (e/o applicativo, come vedremo in seguito) all'interno di una macchina condivisa attraverso un Container Engine.

I Container sono dunque, in ultima istanza, delle virtualizzazioni del sistema operativo, che condividono il kernel e gran parte delle dipendenze e librerie dell'host, con la sola eccezione di quelle che si intende modificare o personalizzare: in questo modo, hanno la possibilità di eseguire una pluralità di carichi di lavoro diversi con un'unica installazione del sistema operativo host. Questo li rende estremamente più leggeri e "portabili" di una macchina virtuale, sia in termini di dimensioni (pochi megabytes) che a livello di tempi (pochi secondi per il riavvio), mantenendo nel contempo una eccezionale versatilità in termini di personalizzazione.

Come si può evincere dall'immagine di cui sopra, i Container rappresentano una sorta di "evoluzione logica" delle macchine virtuali, con lo scopo evidente di ridurre le ridondanze evitabili (nel caso specifico, la pluralità di sistemi operativi ospitati all'interno del medesimo Hypervisor) e il relativo carico di risorse. Ovviamente, questo non significa che l'era delle macchine virtuali sia definitivamente conclusa: al contrario, come vedremo in seguito, le infrastrutture basate su Container consentono di ottenere i risultati migliori proprio quando viene utilizzata in combinazione con le macchine virtuali: i due approcci sono quindi da intendere come complementari tra loro.

Macchine Virtuali vs Container: differenze

Nella tabella seguente abbiamo provato a riassumere le principali differenze tra VMs e Container, prendendo in considerazione i principali aspetti degni di nota in ottica di costi, prestazioni, affidabilità, versatilità e sicurezza.

	Virtual Machine	Container
Risorse impiegate:	Heavyweight	Lightweight
Kernel:	Kernel emulato	Kernel nativo
Sistema operativo:	dedicato (ogni VM ha il suo)	condiviso con gli altri Container
Virtualizzazione:	Hardware	Software
Tempi di avvio:	minuti	secondi
Gestione della memoria:	pre-allocata (più RAM necessaria)	dinamica (meno RAM necessaria)
Isolamento:	Completo	A livello di thread/processo

Come si può vedere, i container consentono di ottenere prestazioni migliori e di ridurre nel contempo i costi, cosa che li rende ideali nella maggior parte degli utilizzi applicativi: al tempo stesso, le macchine virtuali presentano un livello di isolamento maggiore e sono dunque maggiormente indicate in tutti gli scenari dove è opportuno mantenere una separazione totale tra gli ambienti.

Per questo motivo, allo stato attuale, il setup ideale è quello che consente di poter disporre di entrambe le tecnologie, unendo la flessibilità e la sicurezza garantite dalle macchine virtuali con l'elevato rapporto costi-benefici assiscurato dall'impiego dei container.

VM e Container: esempi di utilizzo

Volendo fare un esempio concreto, un'azienda che fornisce servizi IT a una pluralità di clienti potrebbe dotarsi di una infrastruttura organizzata nel seguente modo:

• Un servizio Private Cloud, opportunamente replicato/ridondato, che metta a disposizione uno o più host gestiti da un Hypervisor con risorse hardware pre-allocate, su cui poter creare una pluralità di macchine virtuali a seconda del numero dei clienti e delle dimensioni dei servizi richiesti (volume di dati, potenza di calcolo, etc.).
• Una o più VM per ciascun cliente, così da garantire un livello di isolamento totale per quanto concerne i dati trattati e/o memorizzati.
• Un sistema di Container sulle VM dedicate al deploy, così da poter erogare i servizi e applicativi richiesti da ciascun cliente nel modo più efficiente possibile.

Utilità dei Container nello sviluppo software

Prima di concludere questo articolo è opportuno spendere qualche parola su un altro grande vantaggio legato all'utilizzo dei Container, talmente evidente da aver determinato il successo di questa tecnologia negli anni immediatamente precedenti al suo utilizzo effettivo negli ambienti di produzione: il significativo apporto, in termini di efficienza e praticità, che possono fornire al ciclo dello sviluppo software, in particolare ai team che utilizzano metodologie di tipo agile e che prevedano processi di continuous integration e continuous deployment. Di seguito proveremo a riassumere i principali vantaggi del cosiddetto container development, ovvero dello sviluppo basato su container:

• Ambienti di sviluppo e produzione coerenti tra loro: i container consentono di creare ambienti prevedibili isolati da altre applicazioni, contenenti tutte le dipendenze software necessarie all'applicazione, come versioni specifiche del linguaggio di programmazione e altre librerie software. Dal punto di vista dello sviluppatore, questo consente di creare un ambiente di sviluppo estremamente coerente con quello che sarà l'ambiente di produzione effettivo: questo si traduce in una maggiore produttività, in quanto i team di sviluppo impiegheranno meno tempo a eseguire il debug e a risolvere i problemi legati alle differenze fisiologiche tra ambienti di sviluppo e ambiente di produzione, che sono pressoché inevitabili quando si lavora su macchine fisiche o virtualizzate.
• Portabilità estrema: i container possono essere avviati pressoché ovunque, semplificando notevolmente le operazioni necessarie per creare un ambiente di sviluppo; è possibile eseguirli all'interno di sistemi operativi Linux, Windows e Mac, installati su macchine fisiche o virtuali; su macchine pensate per lo sviluppo o direttamente all'interno dei data center aziendali, nonché, eventualmente, su macchine in cloud. In buona sostanza, qualsiasi ambiente che renda possibile l'esecuzione di software è in grado di poter avviare un container.
• Isolamento logico: i container virtualizzano l'attività della CPU, della memoria, dei dispositivi di memorizzazione dati e delle risorse di rete a livello di sistema operativo, consentendo di disporre una vera e propria sandbox di sviluppo isolata dalle altre applicazioni presenti sulla macchina.

Conclusioni

Per il momento è tutto: ci auguriamo che questa introduzione sui container possa essere d'aiuto sia agli appassionati di tecnologia alla ricerca di maggiori informazioni sul reale significato di questa buzz word che ai professionisti IT interessati a valutare gli scenari applicativi di questa nuova, importantissima tecnologia. Alla prossima!