Close

Container contro macchine virtuali

Scopri le differenze tra container e macchine virtuali (VM), i provider più popolari per ciascuna soluzione, e come possono essere utilizzati insieme

Foto di Ian Buchanan
Ian Buchanan

Principal Solutions Engineer


I container e le macchine virtuali sono tecnologie di virtualizzazione delle risorse molto simili. La virtualizzazione è il processo tramite cui una singola risorsa di sistema come RAM, CPU, disco o rete può essere "virtualizzata" e rappresentata come più risorse. Il principale elemento di differenziazione tra container e macchine virtuali è che le macchine virtuali virtualizzano un'intera macchina fino ai livelli hardware e i container virtualizzano solo i livelli software al di sopra del livello del sistema operativo.

Un container che mostra le differenze tra macchine virtuali e container.

Che cos'è un container?


I container sono pacchetti software leggeri che contengono tutte le dipendenze necessarie per eseguire l'applicazione software contenuta. Queste dipendenze includono elementi come librerie di sistema, pacchetti di codice esterni di terze parti e altre applicazioni a livello di sistema operativo. Le dipendenze incluse in un container esistono in livelli di stack superiori al sistema operativo.

Pro

  • Velocità di iterazione
    Poiché i container sono leggeri e includono solo software di alto livello, sono molto veloci da modificare e ripetere.
  • Ecosistema robusto
    La maggior parte dei sistemi runtime per container offre un repository pubblico ospitato di container predefiniti. Questi repository di container contengono molte applicazioni software popolari come database o sistemi di messaggistica e possono essere scaricati ed eseguiti istantaneamente, consentendo ai team di sviluppo di risparmiare tempo

Contro

  • Exploit di host condivisi
    I container condividono tutti lo stesso sistema hardware sottostante al di sotto del livello del sistema operativo; è possibile che un exploit in un container possa uscire dal container e influire sull'hardware condiviso. I runtime dei container più diffusi dispongono di repository pubblici di container predefiniti. C'è un rischio per la sicurezza nell'uso di una di queste immagini pubbliche in quanto possono contenere exploit o potrebbero essere vulnerabili a essere dirottate da malintenzionati.

Fornitori di container popolari


icona di compilazione del codice
materiale correlato

Kubernetes e Docker a confronto

icona di tre anelli
Scopri la soluzione

Gestisci i componenti con Compass

  • Docker
    Docker è il runtime di container più popolare e più ampiamente utilizzato. Docker Hub è un enorme repository pubblico di popolari applicazioni software containerizzate. I container su Docker Hub possono essere scaricati e distribuiti istantaneamente in un runtime Docker locale.
  • RKT
    Pronunciato " Rocket", RKT è un sistema di container incentrato sulla sicurezza. I container RKT non consentono funzionalità dei container non sicure a meno che l'utente non abiliti esplicitamente funzionalità non sicure. I container RKT mirano ad affrontare i problemi di sicurezza dello sfruttamento della contaminazione incrociata sottostanti di cui soffrono altri sistemi runtime dei container.
  • Linux Containers (LXC)
    Il progetto Linux Containers è un sistema runtime per container Linux open source. LXC viene utilizzato per isolare i processi operativi a livello di sistema l'uno dall'altro. In realtà, Docker utilizza LXC dietro le quinte. Linux Containers mira a offrire un runtime di container open source indipendente dal fornitore.
  • CRI-O
    CRI-O è un'implementazione della Kubernetes Container Runtime Interface (CRI) che consente l'uso di runtime compatibili con Open Container Initiative (OCI). È un'alternativa leggera all'utilizzo di Docker come runtime per Kubernetes.

Che cos'è una macchina virtuale?


Le macchine virtuali sono pacchetti software pesanti che forniscono l'emulazione completa di dispositivi hardware di basso livello come CPU, disco e dispositivi di rete. Le macchine virtuali possono anche includere uno stack software complementare da eseguire sull'hardware emulato. Questi pacchetti hardware e software combinati producono un'istantanea completamente funzionale di un sistema computazionale.

Pro

  • Sicurezza in totale isolamento
    Le macchine virtuali vengono eseguite in modo isolato come sistema completamente autonomo. Ciò significa che le macchine virtuali sono immuni a qualsiasi exploit o interferenza da parte di altre macchine virtuali su un host condiviso. Una singola macchina virtuale può comunque essere dirottata da un exploit, ma la macchina virtuale sfruttata sarà isolata e non sarà in grado di contaminare altre macchine virtuali vicine.
  • Sviluppo interattivo
    I container sono generalmente definizioni statiche delle dipendenze e della configurazione previste necessarie per eseguire il container. Le macchine virtuali sono più dinamiche e possono essere sviluppate in modo interattivo. Una volta specificata la definizione hardware di base per una macchina virtuale, la macchina virtuale può essere trattata come un computer essenziale. È possibile installare manualmente software sulla macchina virtuale e sulla macchina virtuale può essere creata un'istantanea per acquisire lo stato di configurazione corrente. Le istantanee delle macchine virtuali possono essere utilizzate per ripristinare la macchina virtuale a quel momento o avviare altre macchine virtuali con quella configurazione.

Contro

  • Velocità di iterazione
    La compilazione e la rigenerazione delle macchine virtuali richiedono molto tempo perché comprendono un sistema full stack. Qualsiasi modifica a un'istantanea di una macchina virtuale può richiedere molto tempo per rigenerarsi e convalidare il comportamento come previsto.
  • Dimensioni dello spazio di archiviazione
    Le macchine virtuali possono occupare molto spazio di archiviazione. Possono crescere rapidamente fino a diversi gigabyte di dimensione. Questo può portare a problemi di carenza di spazio su disco sulla macchina host delle macchine virtuali.

Provider di macchine virtuali popolari

  • Virtualbox
    Virtualbox è un sistema di emulazione dell'architettura x86 gratuito e open source di proprietà di Oracle. Virtualbox è una delle piattaforme di macchine virtuali più popolari e affermate con un ecosistema di strumenti supplementari per aiutare a sviluppare e distribuire immagini di macchine virtuali.
  • VMware
    VMware è una società quotata in borsa che ha costruito la propria attività su una delle prime tecnologie di virtualizzazione hardware x86. VMware viene fornito con un hypervisor che è un'utilità che distribuisce e gestisce più macchine virtuali. VMware dispone di una solida interfaccia utente per la gestione delle macchine virtuali. VMware è un'ottima opzione di macchina virtuale aziendale che offre supporto.
  • QEMU
    QEMU è l'opzione di macchina virtuale di emulazione hardware più affidabile. Supporta qualsiasi architettura hardware generica. QEMU è un'utilità solo da riga di comando e non offre un'interfaccia utente grafica per la configurazione o l'esecuzione. Questo compromesso rende QEMU una delle opzioni di macchine virtuali più veloci.

Qual è l'opzione migliore per te?


Se hai requisiti hardware specifici per il tuo progetto, o stai sviluppando su una piattaforma hardware e devi scegliere come passare a un'altra come Windows o MacOS, dovrai utilizzare una macchina virtuale. La maggior parte degli altri requisiti "solo software" può essere soddisfatta utilizzando i container.

Come si possono usare container e macchine virtuali insieme?


È completamente possibile utilizzare container e macchine virtuali all'unisono, sebbene i casi d'uso pratici possano essere limitati. È possibile creare una macchina virtuale che emuli una configurazione hardware univoca. Un sistema operativo può quindi essere installato nell'hardware di questa macchina virtuale. Una volta che la macchina virtuale è funzionante e avvia il sistema operativo, è possibile installare un runtime container sul sistema operativo. A questo punto abbiamo un sistema computazionale funzionale con hardware emulato su cui possiamo installare container.

Un uso pratico di questa configurazione è la sperimentazione per le distribuzioni system-on-chip. Il popolare sistema su dispositivi computazionali con chip come Raspberry Pi o le schede di sviluppo BeagleBone possono essere emulati come una macchina virtuale, per sperimentare l'esecuzione di container su di essi prima di testare l'hardware effettivo.

Ma la maggior parte delle volte, le tue esigenze saranno probabilmente soddisfatte da uno dei due. La chiave per decidere tra container o macchine virtuali per le tue esigenze di virtualizzazione è comprendere le tue esigenze di risorse e i compromessi che sei disposto a fare.

Ian Buchanan
Ian Buchanan

Ian vanta una lunga e approfondita esperienza in materia di Java e .NET ed è noto per essere un campione in fatto di metodi Agile nelle imprese di grandi dimensioni. Attualmente si occupa dell'emergente cultura DevOps e degli strumenti per migliorare la continuous integration, la continuous delivery e l'analisi dei dati. Nel corso della sua carriera, ha gestito con successo strumenti per lo sviluppo software aziendale in tutte le fasi del loro ciclo di vita. Si è occupato del miglioramento dei processi a livello di organizzazione riuscendo a ottenere maggiore produttività, qualità superiore e migliore soddisfazione del cliente. Ha creato team multinazionali in cui viene valorizzata la capacità di gestire e organizzare autonomamente il lavoro. Quando non parla o codifica, Ian si dedica alle sue passioni: parser, metaprogrammazione e linguaggi specifici di dominio. Segui Ian all'indirizzo @devpartisan.


Condividi l'articolo
Argomento successivo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Illustrazione su Devops

Community di Compass

illustrazione del superamento di ostacoli

Tutorial: Creare un componente

Illustrazione di una mappa

Inizia a utilizzare Compass gratuitamente

Iscriviti alla nostra newsletter DevOps

Thank you for signing up