Panoramica
I container e le macchine virtuali (VM) sono due approcci caratterizzati da pacchetti di ambienti di elaborazione che coniugano vari componenti IT, astraendoli dal resto del sistema. La principale differenza tra le due tecnologie riguarda il tipo di componenti isolati, che incide sulla scalabilità e sulla portabilità di ciascun approccio.
Che cos'è un container?
Un container è un'unità di software che contiene tutti i componenti e le funzionalità necessari per eseguire un'applicazione. La maggior parte delle applicazioni moderne è costituita da un certo numero di container, ciascuno adibito a una funzione specifica. In genere i container hanno dimensioni definite in megabyte, non prevedono l'uso di hypervisor e offrono una soluzione veloce e agile per gestire l'astrazione dei processi.
Uno dei principali fattori alla base dell'adozione dei container è la loro portabilità. Offrendo una notevole duttilità, i singoli container possono essere intercambiati e spostati con flessibilità in diversi ambienti. Una volta impacchettata in un container insieme alle sue dipendenze, un'applicazione può essere distribuita ovunque sia necessario ed eseguita come di consueto, che sia sul laptop dello sviluppatore, nel datacenter, cloud o all'edge.
Docker, una piattaforma open source utilizzata per creare, distribuire e gestire le applicazioni containerizzate, ha svolto un ruolo fondamentale nell'evoluzione dei container nel tempo.
Risorse da Red Hat
Che cos'è una macchina virtuale?
Le macchine virtuali sono essenziali al cloud computing, poiché emulano i computer fisici eseguendo i sistemi operativi in istanze isolate. In genere un singolo server ospita più macchine virtuali, con un hypervisor che funge da software leggero tra l'host fisico e le VM. L'hypervisor gestisce l'accesso alle risorse in modo efficiente e consente alle macchine virtuali di operare come server distinti, offrendo al tempo stesso più agilità e flessibilità.
Grazie alle iniziative di consolidamento e riduzione dei costi, le VM hanno iniziato a diffondersi negli anni 2000 per poi evolversi nel tempo. Le aziende hanno potenziato le proprie macchine virtuali, andando oltre al consolidamento per estendere il loro utilizzo a diversi scenari. Tra questi sono inclusi l'approvvigionamento di risorse on demand per le applicazioni e l'ottimizzazione dell'accesso alle risorse dispendiose come le GPU.
In passato le VM fungevano anche da base per i primi ambienti di cloud computing, in cui avevano lo scopo di agevolare la virtualizzazione delle risorse e di supportare l'isolamento e la multitenancy: in altre parole, di consentire a più clienti di eseguire i sistemi utilizzando le stesse risorse.
Ogni macchina virtuale contiene il suo sistema operativo, che le permette di eseguire contemporaneamente diverse funzioni a elevato utilizzo di risorse. Il numero di risorse sempre maggiore a disposizione delle VM consente loro di astrarre, suddividere, duplicare ed emulare interi server, sistemi operativi, desktop, database e reti.
Cloud native e IT tradizionale
Oltre alle specificità tecnologiche di ciascuna soluzione, confrontare container e macchine virtuali significa individuare le differenze tra procedure IT cloud native moderne e architetture IT convenzionali.
Le procedure IT emergenti
(sviluppo cloud native, flussi CI/CD e DevOps) consentono di suddividere i carichi di lavoro in più piccole unità costitutive, ovvero una funzione o un microservizio, ed eseguirle in isolamento, dove vengono sviluppate, distribuite e gestite in maniera scalabile e indipendente.
Queste piccole unità vengono impacchettate in container, che permettono a più team di lavorare sui singoli aspetti di un'app o un servizio senza incorrere in interruzioni o comportare rischi per il codice impacchettato in altri container.
Le architetture IT tradizionali
(monolitiche ed esistenti) prevedono l'accoppiamento elevato di ogni aspetto dei carichi di lavoro, rendendo impossibile il loro funzionamento al di fuori dell'architettura in loco. Poiché gli aspetti non possono essere separati, devono essere impacchettati come una singola unità all'interno di un ambiente più grande, spesso 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, soggette a errori e a tempi di inattività prolungati durante gli aggiornamenti.
Come funzionano container e VM?
Virtualizzazione
Un software, detto hypervisor, separa le risorse dalle relative macchine fisiche in modo che possano essere suddivise e destinate alle VM. Quando un utente invia alla VM un'istruzione che richiede ulteriori risorse dell'ambiente fisico, l'hypervisor inoltra la richiesta al sistema fisico ed esegue il caching delle modifiche. Per molti aspetti, le VM assomigliano ai server fisici: questo può moltiplicare gli svantaggi delle dipendenze delle applicazioni e degli ambienti operativi di grandi dimensioni, che generalmente non servono per eseguire una singola app o un singolo microservizio.
Container
Tutti gli elementi compresi in un container vengono impacchettati e distribuiti utilizzando un'immagine del container, ossia un file che include tutte le librerie e le dipendenze. I file delle immagini dei container sono simili ai pacchetti di installazione dei software, come gli RPM di Linux. Tuttavia, per eseguire l'applicazione necessitano solo di un kernel compatibile e runtime del container, a prescindere da quale sistema operativo sia stato utilizzato per creare il container o da quale sia la sorgente delle librerie al suo interno. Date le loro dimensioni ridotte, di solito si opera con centinaia di container a basso accoppiamento; per questo il provisioning e la gestione avvengono su piattaforme di orchestrazione dei container, come Red Hat OpenShift e Kubernetes.
Quale soluzione usare?
Dipende: è necessaria un'istanza piccola di un elemento che possa essere spostato facilmente (container) o un'allocazione semipermanente delle risorse IT personalizzate?
Tra gli altri fattori da prendere in considerazione sono inclusi l'architettura delle applicazioni, le procedure di sviluppo, gli aspetti legati alla sicurezza e i requisiti normativi.
Leggeri e di poco ingombro per natura, i container possono essere facilmente distribuiti tra sistemi bare metal e ambienti di cloud pubblico, privato, ibrido e multicloud. Molto spesso i container vengono eseguiti sulle macchine virtuali, se queste sono alla base dell'infrastruttura già utilizzata dall'azienda: un'ulteriore prova della loro flessibilità.
I container sono inoltre l'ambiente ideale per la distribuzione delle recenti app cloud native, ovvero raccolte di microservizi progettate per offrire esperienze di sviluppo e gestione automatizzata 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.
Rispetto alle VM, i container sono indicati per:
- Creare app cloud native
- Raggruppare microservizi
- Integrare applicazioni nelle procedure DevOps o CI/CD
- Spostare progetti IT scalabili in un ambiente IT diverso
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 (come reti, server e dati)
- Eseguire un sistema operativo diverso in un altro sistema operativo, ad esempio Unix su Linux
Inoltre, se le applicazioni vengono eseguite sia sulle macchine virtuali sia nei container, con Red Hat Service Interconnect è possibile connettere applicazioni e servizi tra diversi ambienti.
Bare metal, VM e container
Le macchine virtuali e i container possono essere distribuiti in diversi tipi di infrastrutture, tra cui i server bare metal.
Che cos'è il bare metal?
Con l'espressione bare metal ci si riferisce a un computer o un server, eseguito su un hardware fisico, che non richiede hypervisor, macchine virtuali o container. I server bare metal sono detti anche server dedicati, perché i componenti hardware sono interamente dedicati a un singolo tenant, anziché essere condivisi tra più utenti.
Sono in grado di elaborare un grande volume di dati con bassa latenza, perciò sono considerati rapidi ed efficienti. Con l'approccio bare metal, l'utente ha il controllo completo dell'infrastruttura dei server; di conseguenza può scegliere il sistema operativo che preferisce e ottimizzare l'hardware e il software in base ai carichi di lavoro specifici.
Tuttavia, sebbene siano utili in scenari di utilizzo in cui le prestazioni e l'accesso diretto all'hardware sono essenziali, le distribuzioni bare metal potrebbero non garantire lo stesso livello di flessibilità e gestione delle risorse che offrono i container e le macchine virtuali.
È possibile ospitare le VM sui server bare metal?
Sì, i server bare metal sono in grado di ospitare le macchine virtuali insieme al relativo hypervisor e al software di virtualizzazione.
È possibile ospitare i container sui server bare metal?
Sì, le piattaforme come Docker, Kubernetes e Podman sono progettate per consentire agli utenti di gestire e distribuire i container con modalità scalabili in più infrastrutture, inclusi i server bare metal.
Perché scegliere Red Hat?
Red Hat® OpenShift® è una piattaforma applicativa containerizzata pensata per le aziende e dotata di una serie di opzioni di deployment e di modelli di consumo compatibili con qualsiasi app o ambiente. Aiuta le imprese a creare, distribuire, eseguire e gestire le applicazioni ovunque e in maniera scalabile, veloce e sicura.
Red Hat OpenShift Virtualization, una funzionalità di Red Hat OpenShift, consente ai team IT di eseguire le macchine virtuali insieme ai container sulla stessa piattaforma Kubernetes, semplificando la gestione e migliorando il tempo di messa in produzione.
In questo modo le aziende possono sfruttare i vantaggi degli investimenti già impegnati nell'ambito della virtualizzazione e usufruire al contempo della semplicità e velocità di una piattaforma applicativa moderna. L'integrazione delle macchine virtuali nella piattaforma applicativa OpenShift fornisce un ambiente uniforme per lo sviluppo e il deployment delle applicazioni. Gli sviluppatori possono creare, testare e distribuire le applicazioni più rapidamente, accelerando i tempi di rilascio.
Il blog ufficiale di Red Hat
Leggi gli articoli del blog di Red Hat per scoprire novità e consigli utili sulle nostre tecnologie, e avere aggiornamenti sul nostro ecosistema di clienti, partner e community.
