Panoramica
I container Linux® e le macchine virtuali (VM) sono entrambi pacchetti di ambienti di elaborazione che combinano vari componenti IT e li isolano dal resto del sistema. La distinzione fondamentale è da ricercare nella loro scalabilità e portabilità.
- La dimensione dei container è in genere calcolata nell'ordine dei megabyte. Di solito contengono soltanto un'app e tutti i file necessari per eseguirla; vengono utilizzati per raggruppare singole funzioni che eseguono attività specifiche, i cosiddetti microservizi. Essendo ottimizzati per natura, i container e il sistema operativo che condividono sono facili da spostare tra diversi ambienti.
- La dimensione delle macchine virtuali è invece calcolata in gigabyte. Poiché contengono il proprio sistema operativo, le VM possono eseguire contemporaneamente più funzioni a elevato utilizzo di risorse. L'alto numero di risorse a disposizione delle VM consente loro di estrarre, suddividere, duplicare ed emulare interi server, sistemi operativi, desktop, database e reti.
Oltre alle specificità tecnologiche di ciascuna soluzione, confrontare container e VM significa individuare le differenze tra procedure IT emergenti e architetture IT convenzionali.
Le procedure IT emergenti (sviluppo cloud native, flussi CI/CD e DevOps) si concretizzano nei container, che consentono di suddividere i carichi di lavoro nelle loro più piccole unità costitutive, ovvero una funzione o un microservizio, raggruppate in modo ottimale. Più team possono perciò lavorare su singole parti di un'app o di un servizio, senza interrompere o ostacolare l'esecuzione del codice contenuto in altri container.
Le architetture IT convenzionali, preesistenti e monolitiche, integrano ogni componente del carico di lavoro in un unico file di grandi dimensioni, indivisibile, che deve necessariamente essere raggruppato come singola unità in un ambiente di grandi dimensioni, in genere una VM. Fino a qualche tempo fa, l'approccio più diffuso prevedeva l'esecuzione di un'intera app in una VM, malgrado la presenza di tutto il codice e delle relative dipendenze in un'unica posizione generasse VM voluminose, con tempi di aggiornamento lunghi, soggette a errori e a tempi di inattività prolungati.
Quale soluzione usare?
La scelta della soluzione più adatta dipenderà dalle esigenze, ad esempio un'istanza di un componente che può essere facilmente spostato (container) oppure un'allocazione semi-permanente di risorse IT personalizzate.
Leggeri e di poco ingombro per natura, i container possono essere facilmente spostati tra sistemi bare metal e ambienti di cloud pubblico, privato, ibrido e multicloud. Sono inoltre l'ambiente ideale per la distribuzione delle recenti app cloud native, ovvero raccolte di microservizi progettate per offrire esperienze di gestione e sviluppo automatizzate in ambienti di cloud pubblico, privato, ibrido e multicloud. Le app cloud native accelerano la realizzazione di nuove app, l'ottimizzazione di quelle esistenti e la connessione tra le due. I container devono essere compatibili con il sistema operativo sottostante. Rispetto alle VM, l'impiego dei container è ottimale per:
- Creare app cloud native
- Raggruppare microservizi
- Adottare procedure DevOps o CI/CD
- Spostare progetti IT scalabili in un contesto IT diverso che condivide lo stesso sistema operativo
Le VM possono eseguire molte più operazioni rispetto a un singolo container ed è per questo che sono state a lungo (e sono tuttora) impiegate per raggruppare i tradizionali carichi di lavoro monolitici. Tuttavia, questa funzionalità estesa e la dipendenza da sistema operativo, applicazione e librerie ne limita fortemente la portabilità. Rispetto ai container, le VM sono indicate per:
- Ospitare carichi di lavoro tradizionali, esistenti e monolitici
- Isolare cicli di sviluppo ad alto rischio
- Eseguire il provisioning delle risorse dell'infrastruttura quali reti, server e dati
- Eseguire un sistema operativo diverso in un altro sistema operativo, ad esempio Unix su Linux
Come funzionano?
Virtualizzazione
Un software, definito hypervisor, separa le risorse dalle rispettive macchine fisiche, così che possano essere suddivise ed eseguite su specifiche VM. Quando un utente invia un'istruzione VM con una richiesta di ulteriori risorse rispetto all'ambiente fisico, l'hypervisor inoltra la richiesta al sistema fisico e memorizza le modifiche nella cache. Per aspetto e comportamento, le VM sono simili ai server virtuali, il che incrementa gli inconvenienti dovuti alle dipendenze delle applicazioni e alle dimensioni dei sistemi operativi, fattori che in generale non sono necessari per eseguire una singola app o microservizio.
Container
Un container raggruppa in un'immagine un microservizio o un'app e tutto il necessario per la sua esecuzione. L'immagine è un file basato su codebase che include tutte le librerie e le dipendenze. Possiamo paragonare questi file all'installazione di una distribuzione Linux, poiché includono pacchetti RPM, file di configurazione e così via. Data la loro ridotta dimensione, in genere sono presenti centinaia di container a basso livello di accoppiamento; le attività di provisioning e gestione vengono perciò affidate a piattaforme di orchestrazione dei container come Red Hat OpenShift e Kubernetes.
Perché scegliere Red Hat?
Red Hat supporta la virtualizzazione e lo sviluppo dei container da lungo tempo. Contribuiamo alle community KVM (Kernel-based Virtual Machine) e oVirt sin dalla loro fondazione; siamo inoltre il secondo contributore ai codebase Docker e Kubernetes. Abbiamo investito nel futuro di queste due tecnologie, impegnandoci nella virtualizzazione container native, in KubeVirt e nelle infrastrutture iperconvergenti, per migliorare il modo in cui i container e le VM collaborano nell'ambito dello stesso sistema IT.
