Non sempre è a tutti chiara la differenza sostanziale che c’è tra una Container e Macchina Virtuale. Ma soprattutto, quali sono i vantaggi e gli svantaggi e quando è più appropriato implementare l’uno o l’altro modello?

I Container e le Macchine Virtuali sono due modi profondamente diversi di implementare servizi isolati multipli in una singola piattaforma host.

I Container (volgarmente, “contenitori) e le Virtual Machine (meglio note come VM, ossia: Macchine Virtuali) hanno delle sostanziali differenze. Ma quali sono queste differenze? Cosa è necessario tenere presente quando si affronta la virtualizzazione di sistemi o applicazioni?

È proprio su questi aspetti , che cercheremo di fare luce attraverso questo post.

Più oltre farò riferimento a macchine virtuali e containers creati e gestiti con la piattaforma di virtualizzazione Proxmox, di cui abbiamo già parlato

Infatti, Proxmox è lo strumento ideale per sviluppare e testare architetture virtuali anche complesse che fanno uso di VM e di Container, in quanto entrambe le tecnologie sono disponibili in questo

Differenza tra Macchina Virtuale e Container

Molto spesso si fa una grande confusione quando ci si addentra nel magico mondo della virtualizzazione; soprattutto se non si utilizzano i termini giusti per descrivere gli oggetti in gioco e la tecnologia che li rende possibili.

Le sostanziali differenze che intercorrono tra una architettura di sistema basata su macchine virtuali ed una basata sui container è, a mio modesto parere, egregiamente sintetizzata nell’immagine riportata qui d’appresso.

Osservando attentamente l’immagine, cerchiamo ora di tracciare sinteticamente le sostanziali differenze tra le due tecnologie.

Macchina Virtuale

Una macchina virtuale, in buona sostanza è un sistema operativo completo in esecuzione all’interno di un sistema operativo host, il quale rende disponibile l’hardware (quello fisico) al sistema operativo guest, tramite uno strato software chiamato Hypervisor, spesso volgarmente indicato col nomignolo di virtualizzatore.

L’Hypervisor è in grado di fare una astrazione dell’hardware e di “presentarlo” (passatemi il termine) ai sistemi operativi guest, in modo che quest’ultimo abbia la percezione di essere in esecuzione su un hardware fisico.

È quindi l’Hypervisor il vero motore che rende possibile tutto questo. A tale proposito, va detto, che esistono diversi tipi di Hypervisor e diversi tipi di virtualizzazione:

• sHype – Secure Hypervisor di IBM
• ESXi – Lo standard de facto di VMWare
• Hyper-V – La virtualizzazione scondo Microsoft
• QEMU – Progetto Open Source rilasciato con licenza GPL/LGPL
• KVM (Kernel-Based VM) – Progetto Open Source

Questi sono solamente un assaggio dei più noti ed utilizzati, ognuno con le sue caratteristiche, i suoi pregi ed i suoi difetti, che comunque non approfondiremo qui per evitare confusione. L’elenco comunque è tutt’altro che completo ed esaustivo; vogliano perdonarmi tutte le aziende e gli sviluppatori che ho omesso di citare per questione di spazio e di sintesi.

Per concludere il discorso sugli Hypervisor, e quindi sulle macchine virtuali in generale, osservando di nuovo l’immagine, risulta subito evidente che per ogni istanza di VM sul Hypervisor viene “replicato” un intero sistema operativo guest, con l’ovvio risultato che in taluni casi questo si traduce in un enorme speco di risorse.

Container

Se, come abbiamo visto, un Hypervisor è in grado di fare una astrazione dell’hardware; allora, a questo punto, una domanda è d’obbligo: In un ambiente virtualizzato, Che cos’è un container?

Un container non è altro che una astrazione a livello di applicazione.

Che detto in questo modo può significare tutto o niente, allo stesso tempo. Ma se facciamo nuovamente riferimento all’immagine “Differenze tra Macchine Virtuali e Containers” più sopra, la precedente citazione comincia ad assumere un significato più comprensibile, nella definizione di container.

Mentre in un Hypervisor viene virtualizzato lo strato hardware sottostante, per quanto riguarda i Container, solo il sistema operativo è virtualizzato. Infatti, i container vengono a trovarsi direttamente sopra lo strato software del sistema operativo che li ospita; condividendo così con quest’ultimo sia il Kernel che lo strato delle librerie di sistema.

Condividere il sistema operativo, porta quindi notevoli vantaggi, in termini di efficienza e leggerezza dell’applicazione che “gira” all’interno di un container. Il che non è affatto un elemento trascurabile quando si tratta di data-center dove il numero di applicazioni può raggiungere anche diverse migliaia.

I Container software più noti

Ma quali sono i software più utilizzati per la creazione dei Container che possiamo scaricare e provare subito nel nel nostro laboratorio?

• LXC (Linux Container) – Progetto Open Source sviluppato da IBM, Google e molti altri, con licenza GPL V2 e BSD.
• Docker – Progetto Open Source supportato da Red Hat^® e Docker^® Inc. con licenza Apache 2.

Anche per questo elenco ho preferito proporre solo un piccolo assaggio dei software più popolari da scaricare e provare in proprio su un buon server anche dalle prestazioni non superlative.

Se invece non hai a portata di mano un server per entrare nel magico mondo dei container, puoi sempre affidarti ai big della rete, che rendono disponibili ormai da qualche tempo servizi orientati ai container:

• Container Linux by CoreOS
• Amazon ECS
• Google Kubernetes Engine
• AWS Fargate

… Tanto per fare qualche esempio

Vantaggi e Svantaggi delle VM

Le Macchine Virtuali in esecuzione all’interno di un hardware con adeguate risorse di CPU, memoria RAM, Storage, presenta sicuramente notevoli vantaggi.

• Isolamento tra le differenti VM
• Emulazione di diverse architetture di CPU
• Coesistenza di diversi Kernel in esecuzione (Solaris, *BSD, Linux, Windows, ecc.)

Di contro, gli svantaggi di un’architettura interamente basata su Machine Virtuali, può porre qualche problema di non poco conto. Infatti, tra i più evidenti svantaggi di questo tipo di implementazione, possiamo elencare:

• Elevato Footprint per singola applicazione
• Performance sicuramente meno brillanti
• Bassa densità di VM per singola macchina fisica.

Vantaggi e svantaggi dei Containers

I container, come già accennato, presentano il notevole vantaggio in termini di occupazione di spazio; anche se questo spesso non non può essere considerato né una vera e propria priorità, né un grandissimo risparmio di risorse.

I vantaggi sono ben altri:

• Migliori performance per singola applicazione
• Deployment semplificato;
• Elevato grado di portabilità;
• Disponibilità immediata;
• Controllo granulare;
• Leggerezza;
• Elevata densità di applicazioni per singola macchina fisica.

Gli svantaggi, d’altro canto, sono ben pochi, anche se è comunque interessante menzionarne qualcuno:

• Almeno in certe implementazioni, seguono il sistema operativo della macchina host;
• Le applicazioni devono rispettare la stessa architettura della CPU
• In alcuni casi possono essere soggetti a problemi di sicurezza;
• Creare manualmente un container può non essere così banale

Comunque, niente paura! Proxmox mette a disposizione un eccellente numero di Container Templates, ossia dei modelli preconfezionati di container, per le applicazioni più comuni, già belli e pronti per l’uso. Per utilizzarli non bisogna far altro che scaricarli, tramite l’interfaccia web di gestione, ed attivarli: in pochi minuti puoi avere la tua applicazione Up-and-Running senza sudare sette camicie.

Conclusioni

In questo post ci siamo addentrati solo in una sintetica introduzione sulle differenze sostanziali tra Macchina Virtuale e Container.

Tuttavia, non abbiamo ancora approfondito alcuni aspetti fondamentali dei singoli casi elencati. Cosa che mi riprometto di fare molto presto in qualche articolo espressamente dedicato almeno ai più importanti ed utilizzati strumenti di virtualizzazione.

Non va dimenticato l’importante aspetto che in un ambiente in cui convivono centinaia di macchine virtuali e migliaia di Containers, uno degli aspetti critici che emerge a questo punto è come gestire tutta questa popolazione di sistemi virtuali e soprattutto renderli sicuri. Ma questa è un’altra storia.