Container

Virtualizzazione a livello del sistema operativo

• La virtualizzazione a livello del sistema operativo è composta da un solo kernel

(quello del sistema operativo host) e multiple istanze isolate di partizioni o
container, che possono essere avviate e spente in maniera indipendente tra di
loro.

• Ogni container contiene un proprio filesystem e proprie interfacce di rete. Viene

garantito l'isolamento del filesystem, IPC e network. Inoltre fornisce un sistema di
gestione delle risorse quali CPU, memoria, rete e operazioni I/O.

- Vantaggi: basso overhead per il context-switch, basso overhead di memoria

- Svantaggi: non può ospitare sistemi operativi differenti, l'isolamento non può
Virtualizzazione a livello del sistema operativo (Segue)

• Creano uno spazio utente isolato, con proprie interfacce di rete, librerie e files,
isolando una applicazione dal resto del sistema operativo.

- È possibile pacchettizzare un’applicazione, rendendola pronta per il

deployment.

- Più container possono appoggiarsi ad uno stesso spazio kernel, risparmiando

spazio disco e condividendone i servizi di base.

- Costruito e customizzato un container per una specifica applicazione, posso

replicare quel container più volte, anche su una stessa VM o su VM diverse.
Virtualizzazione hardware vs Containerizzazione (Segue)
• Virtualizzazione hardware
- Permette l’esecuzione di sistemi operativi eterogenei
- Isolamento pesante delle macchine virtuali
- Teoricamente è possibile emulare qualsiasi architettura
- La macchina virtuale si avvia tramite un completo processo di bootstrap
- Soluzioni orientate alla piattaforma
- Ottimizzata per offrire soluzioni generiche
Virtualizzazione hardware vs Containerizzazione (Segue)
• Cointainerizzazione
- Avvia processi
- Namespaces leggeri a livello kernel
- L’emulazione è meno flessibile, non è possibile emulare altre architetture
- I namespaces e la creazione dei processi è molto più veloce dell’avvio completo
di una
macchina virtuale
- Soluzione orientata ai servizi
- Ottimizzata per soluzioni minimaliste e veloci
Virtualizzazione hardware vs Containerizzazione
Virtualizzazione hardware vs Containerizzazione: Vulnerabilità e sicurezza
• Virtualizzazione
Gli hypervisor forniscono un’ulteriore livello di astrazione dato dal sistema
operativo guest installato così come dall’orchestratore delle macchine virtuali che
rendono molto più difficile attaccare il sistema host. Tuttavia gli hypervisor non
sono ancora a prova di attacco e le conseguenze si possono riscontrare sulla
stabilità di tutto il sistema

• Containerizzazione
I container sono viste indipendenti di un sistema operativo, che condividono tutte
lo stesso kernel: questo significa che se un processo in un container è in grado di
danneggiare il kernel, può teoricamente danneggiare l’intero sistema. Tuttavia i
Containers nel sistema operativo GNU/Linux: un po’ di storia
• Sono state sviluppate molte tecnologie basate sull’utilizzo dei container nei
sistemi operativo basati su GNU/Linux

• Il kernel Linux 2.6.24 segna un importante punto di svolta con l’introduzione di

cgroups, un modulo che fornisce il pieno controllo delle risorse dando il via allo
sviluppo dei namespace del kernel

• LXC (LinuX Containers) è uno delle prime soluzioni di virtualizzazione orientate ai

container per GNU/Linux basata su cgroups
 Docker

• Docker è una piattaforma per sviluppatori ed amministratori di sistema

(DEVOPS) per sviluppare, trasportare ed eseguire il deploy di applicazioni e servizi
basata sull’utilizzo di container

• Docker è open-source, sviluppato principalmente con il linguaggio Go ed

utilizzando nativamente la libreria libvirt e LXC, successivamente unificati in una
libreria, libcontainer, scritta completamente in Go.

• Docker semplifica e standardizza la creazione e la gestione dei containers

fornendo in aggiunta una API (Application Program Interface) remota per fornire
Architettura di
Docker
 Architettura di
Docker
• Docker Engine: permette di sviluppare, comporre, trasportare e avviare le
applicazioni (cointainer) utilizzando i seguenti componenti

- Docker Daemon: un processo sempre attivo in background (systemcl start

docker) che
esegue costantemente le richieste passate attraverso la riga di comando o
attraverso le
API REST
- Docker REST API: API utilizzate da un’applicazione che permettono di
comunicare con
 Architettura di Docker
(Segue)
• Docker Host: fornisce un ambiente di esecuzione completo per eseguire e
avviare le applicazioni e i servizi. Contiene il Docker Engine, le Immagini, i
Container, le interfacce di rete e lo fornisce lo Storage (volumi)

• Docker Registry: è un servizio che offre la possibilità di caricare e scaricare le

immagini docker. In altri termini un docker registry contiene un repository dove
mettere a disposizione una o più immagini. I comandi principali utilizzati sono:
- docker push: carica un’immagine nel registry
- docker pull: scarica un’immagine dal registry
- docker run: scarica un’immagine dal registry e crea un container
 Immagini e
Container
• Immagini: sono file che contengono tutte le informazioni e le librerie
(soddisfando quindi tutte le dipendenze) necessarie per poter eseguire
un’applicazione di un container. È inerte, non produce cambiamenti nel sistema
(entità passiva) e non è modificabile.

• Container: è un’istanza dell’immagine e come tale è un’entità attiva. Come

qualsiasi software eseguito su un computer, un container Docker in esecuzione
utilizza le risorse di sistema, la memoria di lavoro e i cicli della CPU. Inoltre, lo
stato di un container cambia durante il suo ciclo di vita.
 Immagini e Container (Segue)

• Per meglio chiarire quali sono le differenze tra immagini e container, ragioniamo
per analogia ad un linguaggio object oriented, dove la classe rappresenta
l’immagine e l’istanza di quella classe, l’oggetto, è il container.

• La stessa immagine può dar vita a più container.

• La virtualizzazione a container si basa quindi fondamentalmente sulle immagini,

ovvero i file reperibili sul Docker Hub e utilizzate per la creazione e
l’inizializzazione di una applicazione in un nuovo contenitore Docker.