Ti è piaciuto l’articolo?
0
Ti è piaciuto l’articolo?
0

Alternative a Docker: una rassegna delle piattaforme per la gestione dei container

Grazie alle piattaforme per la gestione dei container la virtualizzazione a livello di sistema operativo (operating-system-level virtualization) celebra un revival. Nel giro di pochi anni il team di sviluppatori è riuscito a riportare in vita la tecnologia dei container basata su funzionalità del kernel. Si è infatti affermata oltre i confini dell’universo di Linux come un’alternativa efficiente alla virtualizzazione basata su hypervisor tramite emulazione dell’hardware.

Grazie all’eco mediatica e di un ecosistema in continua crescita, Docker ha spiccato il volo diventando leader di mercato nel settore delle virtualizzazioni basate su container. La snella piattaforma per la gestione dei container non resta tuttavia l’unico progetto software in cui le tecniche di virtualizzazione vengono sviluppate a livello di sistema operativo.

Dunque quali alternative a Docker esistono? E in cosa si differenziano le loro impostazioni rispetto ai meccanismi del leader di mercato?

La tecnologia container in Linux

Di norma nei sistemi Unix-like, come Linux, la virtualizzazione a livello di sistema operativo si basa su un’implementazione avanzata dei meccanismi chroot nativi. Oltre a ciò i progetti container come Docker, rkt, LXC, LXD, Linux-VServer, OpenVZ/Virtuozzo e runC si rivelano utili per la gestione delle risorse come le funzioni native del kernel di Linux, così da realizzare ambienti di runtime isolati per applicazioni oppure interi sistemi operativi.

N.B.

Chroot sta per “change root”, un comando di change directory, e si trova all’interno di sistemi operativi Unix-like per cambiare la root di un processo in esecuzione e i suoi processi figlio. Solitamente un’applicazione che viene utilizzata in un ambiente modificato con chroot (si parla di “chroot jail”) non può accedere a nessun altro dato al di fuori della directory selezionata. Tuttavia, siccome chroot non è stato sviluppato per essere una funzione di sicurezza, è possibile superare senza un grande sforzo un tale isolamento.

Docker

Chi si occupa di software di containerizzazione prima o tardi si imbatterà nel nome “Docker”. Nel giro di pochissimi anni il progetto open source dell’omonima azienda di software Docker Inc. è riuscito ad attirare l’attenzione dei settori di software di deployment, DevOps e integrazione continua sulla tecnologia dei container.

Docker attinge a funzioni di base di Linux per proteggere i processi gli uni dagli altri e, con l’aiuto dell’ambiente di esecuzione indipendente runC, permette di utilizzare contemporaneamente applicazioni all’interno di container isolati senza che sia necessario servirsi di sistemi ospiti ad alto consumo di risorse. In questo modo la leggera piattaforma di containerizzazione conferma di essere un’attraente alternativa alla virtualizzazione basata su hypervisor. Una descrizione dettagliata della piattaforma Docker e dei suoi componenti di base la trovate nel tutorial di Docker per principianti della 1&1 Digital Guide.

La piattaforma di Docker si trova sia gratuitamente come Community Edition (CE) sia a pagamento come Enterprise Edition (EE) e offre supporto per diverse distribuzioni Linux. Oltre a ciò, a partire dal rilascio della versione 1.12, Docker CE è disponibile come app nativa per Windows e macOS. Mentre Docker for Mac si basa sull’hypervisor leggero xhyve, per virtualizzare invece un ambiente di runtime per l’engine di Docker e delle funzioni specifiche di Linux per il demone di Docker, su Windows entra in gioco allo stesso scopo l’hypervisor Hyper-V.

A partire da settembre 2016 è possibile trovare Docker EE anche in formato nativo per Windows Server 2016. Collaborando a stretto contatto con il team di sviluppatori di Docker, Microsoft ha infatti integrato diverse estensioni all’interno del kernel di Windows, che permettono a Docker di avviare i processi come container in un sandbox senza un hypervisor sul livello di astrazione. Il codice sorgente per hcsshim, il driver sviluppato appositamente per questo contesto, è stato messo a disposizione della community open source da Microsoft su GitHub.

La seguente tabella illustra i punti fondamentali della piattaforma Docker:

Requisiti del sistema e sistemi supportati
Kernel Linux richiesto Versione 3.10 di Linux o superiore
Distribuzioni Linux supportate Docker Community Edition (CE): Ubuntu, Debian, CentOS e Fedora; Docker Enterprise Edition (EE): Ubuntu, Red Hat Enterprise Linux, CentOS, Oracle Linux e SUSE Linux Enterprise Server
Altre piattaforme Docker Community Edition (CE): Microsoft Windows 10 (Pro, Enterprise o Education a 64 bit), macOS (Yosemite 10.10.3 o superiore), Microsoft Azure, Amazon Web Services (AWS); Docker Enterprise Edition (EE): Microsoft Windows Server 2016, Microsoft Windows 10 (Pro, Enterprise o Education a 64 bit), Microsoft Azure, Amazon Web Services (AWS)
Formato container Container di Docker
Licenza Apache 2.0
Linguaggio di programmazione Go

Con il passare del tempo attorno al progetto originario di Docker si è venuto a creare un vivace ecosistema. Secondo le dichiarazioni degli sviluppatori, l’engine di Docker è collegato a più di 100.000 progetti creati da terzi.

Il punto di critica principale nell’implementazione della tecnologia dei container di Linux nell’ambito del progetto di Docker è il grado di isolamento dei singoli processi su un sistema di host comune. Utilizzando i container di applicazioni, Docker sfrutta funzioni native del kernel di Linux, come ad esempio Cgroups e namespaces. Tuttavia queste non incapsulano i container in egual misura, come invece è il caso per una virtualizzazione completa sulla base di macchine virtuali. Per garantire un utilizzo sicuro di container di applicazioni, le versioni più recenti della piattaforma di containerizzazione supportano estensioni kernel come AppArmor, SELinux, Seccomp e GRSEC, con le quali è possibile schermare ulteriormente i processi isolati.

Vantaggi Svantaggi
✔ Docker supporta diversi sistemi operativi e piattaforme cloud. ✘ L’engine di Docker supporta esclusivamente il proprio formato di container.
✔ Con Swarm e Compose la piattaforma Docker offre già strumenti di gestione e orchestrazione dei cluster. ✘ Il software è disponibile come file di programma monolitico che contiene tutte le feature.
✔ Grazie all’hub di Docker gli utenti hanno a disposizione un registry centrale per le risorse di Docker. ✘ I container di Docker isolano esclusivamente processi singoli. L’utilizzo di container full-system non è supportato.
✔ L’ecosistema in continua crescita mette a disposizione degli utenti diversi tool per Docker, plug-in e componenti di infrastruttura.  
Fatto

In origine la tecnologia di container è stata sviluppata con lo scopo di riuscire a utilizzare più sistemi operativi virtuali in ambienti isolati sullo stesso kernel. In questo caso si parla di container full-system. La piattaforma di container Docker, al contrario, si concentra su cosiddetti container di applicazioni, in cui ogni applicazione funziona su un proprio ambiente virtuale. Mentre i container full-system vengono progettati in modo tale che al loro interno possano essere avviati diversi processi, un container di applicazioni contiene sempre un solo processo. Con Docker le applicazioni più impegnative vengono quindi realizzate come applicazioni multi-container.

rkt di CoreOS

L’avversario più agguerrito di Docker presente sul mercato della virtualizzazione basata su container è l’ambiente di runtime rkt (pronunciato: “rocket”, “razzo” in italiano) della distribuzione Linux CoreOS. Il progetto è stato presentato già nel 2014.

Un buon motivo per abbandonare la piattaforma di Docker, che fino ad allora poteva contare sul supporto del team di sviluppatori di CoreOS, è stato dato dalla dichiarazione del CEO Alex Polvi di essere insoddisfatto dello sviluppo del progetto Docker. Secondo Polvi, il leader di mercato si sarebbe allontanato dallo scopo principale di sviluppare una tecnologia container standard, mentre ora si concentra sulla commercializzazione di una piattaforma monolitica di sviluppo di applicazioni.

A febbraio del 2016, con il rilascio della versione 1.0 di rkt, CoreOS ha pubblicato la prima release stabile dell’ambiente di runtime di container. Il concorrente intende differenziarsi da Docker in special modo per le sue feature di sicurezza aggiuntive. Di queste fanno parte, oltre che un isolamento di container basato su KVM, il supporto dell’estensione kernel SELinux, ma anche una convalida della firma per immagini della specifica di container sviluppata autonomamente, ovvero App Container (appc). Questa funzione descrive il formato dell’immagine App Container Image (ACI), l’ambiente di runtime, un meccanismo di image discovery, e infine anche la possibilità di raggruppare immagini in app multi-container, i cosiddetti App Container Pods.

Diversamente da Docker, rkt supporta sia le proprie immagini di container sia altri formati. L’ambiente di runtime è compatibile con le immagini di Docker e con il tool open source Quay offre la possibilità di convertire ogni formato container secondo ACI.

Requisiti del sistema e sistemi supportati
Kernel Linux richiesto Qualsiasi kernel amd64 moderno
Distribuzioni Linux supportate Arch Linux, CentOS, CoreOS, Debian, Fedora, NixOS, openSUSE, Ubuntu, Void
Altre piattaforme macOS o Windows tramite Vagrant Virtual Machine
Formato container appc, Docker-Container; altre immagini container possono essere trasferite in formato rkt via Quay
Licenza Apache 2.0
Linguaggio di programmazione Go

Mentre la piattaforma Docker fa riferimento a un demone centrale che lavora in background con permessi di root, rkt riesce a funzionare senza un tale processo e opera invece con sistemi init affermati come systemd e upstart, per avviare e gestire i container. In questo modo rkt elude il problema di Docker, al quale nel frattempo è stato posto rimedio, in cui gli utenti che intendono avviare i container tramite il demone necessitano dei permessi di root e ottengono quindi un accesso illimitato al sistema di host.

Fatto

A partire dalla versione 1.11, i container non possono essere avviati direttamente dal demone di Docker: al suo posto entra in azione un processo con il nome di containerd.

Diversamente da Docker, rkt non è vincolato a funzioni kernel di Linux come Cgroups e namespaces per la virtualizzazione di applicazioni. Con l’ambiente di runtime di CoreOS è possibile avviare container basati su KVM (acronimo per Kernel-based Virtual Machine, come ad esempio LKVM o QEMU) e le tecnologie di container di Intel Clear come macchine virtuali interamente incapsulate.

I grandi del settore come Google, Red Hat e VMware supportano le specifiche APPC e la loro implementazione rkt.

Vantaggi Svantaggi
✔ rkt supporta sia il proprio formato di container sia i container di Docker e fa sì che ogni immagine container sia convertibile tramite Quay nel formato ACI di rkt. ✘ Al contrario di Docker, per rkt esistono molte meno integrazioni messe a disposizione da parte di terzi.
✔ Le tecnologie come KVM e la Clear-Container di Intel fanno sì che i container possano essere protetti l’uno dall’altro. ✘ rkt è ottimizzato per l’utilizzo di container per applicazioni. I container full-system non sono, invece, supportati.

LXC

Per quanto riguarda l’alternativa a Docker LXC, si tratta di una raccolta di tool, template, librerie e language binding che insieme vanno a comporre un’interfaccia userspace per le funzioni container native del kernel di Linux. LXC offre agli utenti di Linux un comodo percorso per la realizzazione e la gestione di applicazioni e sistemi di container.

Fatto

I language binding sono adapter, ovvero i cosiddetti wrapper (dall’inglese to wrap: avvolgere), i quali creano ponti tra diversi linguaggi di programmazione, permettendo quindi di connettere differenti parti del programma tra loro.

Per proteggere i processi gli uni dagli altri, su LXC entrano in azione le seguenti tecnologie di isolamento:

  • Namespace IPC, UTS, Mount, PID, namespace della rete e User namespaces
  • Cgroups
  • Profili AppArmor e SELinux
  • Regole Seccomp
  • Chroot
  • Capacità del kernel

Lo scopo del progetto LXC è quello di creare un ambiente per container di software che si differenzi il meno possibile da un’installazione standard di Linux. Lo sviluppo di LXC è affidato al progetto intersettoriale di LinuxContainers.org, accanto ad altri progetti open source come LXD, LXCFS e CGManager.

Requisiti del sistema e sistemi supportati
Kernel Linux richiesto Versione 2.6.32 di Linux o superiore
Distribuzioni Linux supportate LXC è contenuto nella maggior parte delle distribuzioni di Linux. Sono necessarie le seguenti librerie: Libreria C: glibc, musl libc, uclib o bionic; Altre librerie: libcap, libapparmor, libselinux, libseccomp, libgnutls, liblua, python3-dev
Altre piattaforme Nessuna
Formato container Linux Container (LXC)
Licenza GNU LGPLv2.1+
Linguaggio di programmazione C, Python 3, Shell, Lua

LXC è stato sviluppato per eseguire differenti container di sistema (container full-system) su un sistema di host comune. Solitamente un container di Linux avvia una distribuzione completa in un ambiente virtuale a partire da un’immagine del sistema operativo. Gli utenti interagiscono con essa in maniera analoga come con una macchina virtuale.

Nei container di Linux le applicazioni vengono avviate solo di rado, per cui il software si differenzia in maniera sostanziale dal progetto di Docker. Mentre LXC serve soprattutto alla virtualizzazione del sistema, Docker si concentra invece sulla virtualizzazione di singole app e sul loro deployment. Inizialmente venivano coinvolti anche i container di Linux, oggi, però, Docker si serve di un formato di container sviluppato autonomamente.

La differenza essenziale di entrambe le tecnologie di virtualizzazione è data dal fatto che i container di Linux possono contenere molti processi, mentre all’interno dei container di Docker può venire eseguito esclusivamente un solo processo: per questo motivo di norma le applicazioni Docker complesse sono costituite da più container. Un deployment effettivo di tali app multi-container necessita di strumenti aggiuntivi.

Oltre a ciò i container di Docker sono diversi dai container di Linux per quanto riguarda la portabilità. Se un utente sviluppa un software sulla base di LXC su un sistema di test locale non può dare per scontato che il container funzionerà senza errori anche su altri sistemi (vedi ad esempio un sistema produttivo). La piattaforma di Docker, al contrario, astrae le applicazioni dalla configurazione del sistema alla loro base in maniera decisamente più efficace. Così facendo è possibile gestire un solo container di Docker su un host a scelta dello stesso, ovvero un sistema sul quale è stato installato l’engine di Docker, a prescindere dal sistema operativo e dalla configurazione dell’hardware.

Anche LXC funziona senza un processo di demone centrale. Piuttosto il container si integra in maniera simile a rkt in sistemi init, come systemd e upstart, per avviare e gestire i container.

Vantaggi Svantaggi
✔ LXC è ottimizzato per l’utilizzo di container full-system. ✘ L’utilizzo di container per applicazioni non è comune.
  ✘ Non esistono implementazioni native per altri sistemi operativi al di fuori di Linux.

LXD di Canonical

Nel novembre del 2014 Canonical, distribuzione di Linux, ha voluto dare vita a un progetto successore di LXC, creando un’ulteriore alternativa a Docker: il suo nome è LXD (pronunciato: “lexdi”). Il progetto si basa sulla tecnologia Linux a container, ma la amplia con il processo di demone LXD. Il software è da intendersi come una sorta di hypervisor di container. La struttura tecnica della soluzione a container è costituita da tre componenti: LXC funge da client per la riga di comando, successivamente con l’aiuto di nova-compute-lxd viene integrato un plug-in Nova, componente di OpenStack. La comunicazione tra client e demone avviene tramite un’API REST.

Fatto

Per quanto riguarda Nova si tratta di un componente centrale del sistema operativo cloud open source OpenStack, che serve all’utilizzo e alla gestione dei sistemi virtuali in architetture cloud. OpenStack Nova supporta varie tecnologie di virtualizzazione basate su hypervisor e a livello di sistema operativo.

Lo scopo del progetto di software è di offrire agli utenti una user experience simile all’utilizzo di macchine virtuali, sulla base di tecnologie Linux a container e senza che debba essere preso in considerazione l’overhead di un’emulazione di risorse dell’hardware.

Requisiti del sistema e sistemi supportati
Kernel Linux richiesto Come LXC
Distribuzioni Linux supportate Client di interfaccia a riga di comando (lxc): Ubuntu 14.04 LTS, Ubuntu 16.04 LTS; nova-compute-lxd: Ubuntu 16.04 LTS
Altre piattaforme Nessuna
Formato container Container Linux (LXC)
Licenza Apache 2.0
Linguaggio di programmazione Go

Come LXC, anche LXD si concentra sull’utilizzo di container full-system. Questo ruolo di tool di gestione della macchina differenzia LXD da Docker e rkt, le cui funzioni centrali appartengono piuttosto al settore del deployment del software. LXD sfrutta le stesse tecnologie di isolamento come il progetto LXC alla sua base.

Il demone della soluzione a container necessita di un kernel di Linux. Non vengono supportati altri sistemi operativi. Siccome la comunicazione con il demone avviene tramite un’API REST è possibile prendere contatto con esso da remoto con un client Windows o macOS. Come si configura il client standard LXD per il sistema operativo desiderato, viene descritto dal responsabile del progetto Stéphane Graber nell’articolo del 9 febbraio 2017 sul suo blog personale.

Vantaggi Svantaggi
✔ LXD è ottimizzato per l’utilizzo di container full-system. ✘ L’utilizzo di container per applicazioni non è comune.
✔ Il client LXD può essere configurato per Windows e macOS, e permette un controllo da remoto del demone LXD tramite API REST. ✘ Il demone LXD necessita di un kernel di Linux.

Linux VServer

Il Linux VServer è una tecnologia di virtualizzazione a livello di sistema operativo che, in modo analogo ai container, attinge a tecnologie di isolamento del kernel di Linux. Il progetto fa sì che vengano eseguite più unità virtuali su un kernel di Linux comune, le cui risorse (quindi file system, CPU, indirizzi di rete e memoria) sono suddivise tramite un meccanismo di jail in partizioni isolate. Secondo la terminologia del Linux VServer una tale partizione viene denominata Security Context e realizzata attraverso tecnologie standard come Segmented Routing, Chroot e Quota. Un sistema virtualizzato in un simile Security Context viene chiamato Virtual Private Server (VPS).

Siccome i VPS operano come processi isolati dello stesso sistema di host e utilizzano la stessa interfaccia System Call, non viene a crearsi nessun overhead aggiuntivo tramite emulazione.

Fatto

Una virtualizzazione a livello del sistema operativo tramite Linux VServer non ha nulla a che vedere con il progetto Linux Virtual Server, in cui viene sviluppata una tecnologia di load balancing per i cluster Linux.

Requisiti del sistema e sistemi supportati
Kernel Linux richiesto Versione di Linux 2.6.19.7 o superiore
Distribuzioni Linux supportate Tutte le distribuzioni Linux
Altre piattaforme Nessuna
Formato container Su Linux VServer entra in azione un concetto simile ai container, ovvero Security Context.
Licenza GNU GPL v.2
Linguaggio di programmazione C

Fino a poco tempo fa il progetto open source portato alla luce da Jacques Gélinas, era diretto dall’austriaco Herbert Pötzl. La tecnologia viene ad esempio applicata dai provider di web hosting che intendono proporre ai propri clienti macchine virtuali separate sulla base di un hardware comune.

Per attrezzare il kernel di Linux con funzionalità per la virtualizzazione a livello del sistema operativo è necessario effettuare il patch di questo. Tramite questa modifica kernel di Linux la tecnologia si differenzia in maniera sostanziale dai container di Linux (LXC) che attingono a funzioni di isolamento con Cgroups e Namespaces.

L’ultima release del software è apparsa con il VServer 2.2 nel 2007.

Vantaggi Svantaggi
✔ Mentre su Docker le modifiche effettuate in un container possono essere salvate solamente realizzando una nuova immagine a partire da un container in funzione, Linux VServer offre un file system comune per tutti i VPS sull’host in cui è possibile mettere in sicurezza gli stati attuali. ✘ Linux VServer richiede una modifica del kernel Linux.
  ✘ Nessuna nuova release dal 2007

OpenVZ/Virtuozzo 7

La versione 7 della piattaforma di virtualizzazione OpenVZ di Parallels è a disposizione degli utenti da luglio 2016 come distribuzione Linux indipendente. Il software si basa su Red Hat Enterprise Linux 7 (RHEL) e permette l’utilizzo di sistemi ospiti che possono essere realizzati a scelta o sotto forma di macchine virtuali o di container. Con la nuova base di codice OpenVZ si avvicina a Virtuozzo 7, il quale viene commercializzato da Parallels come prodotto destinato alle aziende. Un confronto diretto di entrambe le soluzioni di virtualizzazione si trova su OpenVZ.

Rispetto alle versioni precedenti OpenVZ 7 offre una serie di nuovi strumenti per l’interfaccia a riga di comando: si tratta infatti dei cosiddetti tool ospiti. Questi fanno sì che gli utenti possano eseguire compiti sui sistemi ospiti direttamente tramite il terminale del sistema di host. Inoltre l’hypervisor sviluppato autonomamente per l’utilizzo di macchine virtuali è stato sostituito dalle ormai affermate tecnologie standard KVM e QEMU.

Per quanto riguarda l’utilizzo del container, invece, OpenVZ continua a fare affidamento su un proprio formato con il container di Virtuozzo: come già LXC, questo serve innanzitutto alla virtualizzazione di interi sistemi (VPS), differenziandosi così da Docker e rkt. Diversamente da LXC, OpenVZ offre la possibilità di effettuare una migrazione in tempo reale attraverso Checkpoint/Restore In Userspace (CRIU), per completare le immagini persistenti di un container ancora in funzione.

Requisiti del sistema e sistemi supportati
Kernel Linux richiesto RHEL7 (3.10)
Distribuzioni Linux supportate Virtuozzo Linux, RHEL7
Altre piattaforme Nessuna
Formato container Virtuozzo Containers
Licenza OpenVZ: GNU GPL v.2; Virtuozzo 7: licenza proprietaria
Linguaggio di programmazione C

Dal punto di vista tecnico OpenVZ e Virtuozzo rappresentano un’estensione del kernel di Linux, i quali mettono a disposizione diversi strumenti di virtualizzazione a livello utente. I sistemi ospiti vengono realizzati all’interno di cosiddetti ambienti virtuali (Virtual Environments, VE), che funzionano in maniera isolata sullo stesso kernel di Linux. Attraverso ciò si evita anche l’overhead tramite un’emulazione dell’hardware basata su hypervisor, come nelle altre tecnologie a container. La divisione del kernel di Linux fa però sì che tutti i sistemi ospiti virtualizzati siano vincolati all’architettura di sistema e alla versione centrale del sistema di host.

Inoltre tra le funzioni principali di OpenVZ rientrano una partizione in tempo reale, la gestione delle risorse e il controllo centrale di più server fisici e virtuali.

  • La partizione dinamica in tempo reale: ogni VPS rappresenta una partizione isolata del server fisico alla base. L’isolamento contiene i propri file system, gruppi di utenti (compresi i propri root user), processi ad albero, indirizzi di rete e oggetti IPC.
  • Gestione delle risorse: in OpenVZ l’allocazione delle risorse dell’hardware avviene tramite cosiddetti parametri di gestione delle risorse, i quali vengono controllati dall’amministratore di sistema all’interno del file di configurazione globale e dei file di configurazione dei container.

Per la gestione di macchine virtuali e di container di sistema, OpenVZ e Virtuozzo si affidano al tool di gestione di Red Hat libvirt, il quale è costituito da un’API open source, dal demone libvirtd e dal programma di interfaccia a riga di comando virsh.

Mentre il prodotto aziendale Virtuozzo viene commercializzato con GUI Parallels Virtual Automation (PVA) integrato, l’installazione di base di OpenVZ non ha un’interfaccia utente grafica. Gli utenti hanno però la possibilità di installarla in seguito tramite un software di terze parti. Il team di sviluppatori di OpenVZ consiglia OpenVZ Web Panel di SoftUnity. Ulteriori alternative possono essere consultate sul Wiki di OpenVZ.

Vantaggi Svantaggi
✔ Con i suoi OpenVZ e Virtuozzo, Parallels offre una distribuzione Linux completa e ottimizzata per tutti gli scenari di virtualizzazione. ✘ OpenVZ e Virtuozzo mettono a disposizione container per l’utilizzo di interi sistemi operativi. Chi è alla ricerca di un’alternativa professionale a Docker per l’isolamento di singoli processi, dovrebbe scegliere un’altra piattaforma.
✔ Con OpenVZ e Virtuozzo è possibile gestire sia container a sistema sia macchine virtuali con un overhead minimale. ✘ L’utilizzo di OpenVZ e Virtuozzo è limitato alle distribuzioni Linux RHEL7 e Virtuozzo.

runC

Il programma runC non è tanto un’alternativa a Docker, quanto più uno scorporamento dell’ambiente di runtime a container sviluppato da Docker e la successiva realizzazione di un progetto open source indipendente sotto l’ala protettiva della Open Container Initiative (OCI).

Come organizzazione di beneficenza della Linux Foundation, l’OCI 2015 è nata grazie a Docker e ad altre aziende del settore container, per stabilire uno standard de facto libero per i container. Al momento OCI offre specifiche per un ambiente di runtime a container (runtime-spec) e un formato di immagini a container (image-spec).

L’ambiente di runtime open source runC è da ritenersi un’implementazione canonica di queste specifiche.

Requisiti del sistema e sistemi supportati
Kernel Linux richiesto Tutti i kernel di Linux
Distribuzioni Linux supportate Tutte le distribuzioni di Linux attuali
Altre piattaforme Nessuna
Formato container OCI Bundle
Licenza Apache 2.0
Linguaggio di programmazione Go

L’ambiente di runtime dell’OCI supporta esclusivamente container in formato OCI Bundle e necessita esclusivamente di un file system root e di un file di configurazione OCI, per eseguire i container. Tuttavia all’interno del progetto non è possibile trovare un tool per la realizzazione di file system root per container. Gli utenti che hanno installato la piattaforma di Docker possono comunque attingere alla funzione di esportazione per estrarre un file system root da un container di Docker esistente, ampliarlo con un file config.json e quindi realizzare un OCI Bundle. In aggiunta a ciò, per la creazione di immagini vengono supportati altri tool esterni come oci-image-tools, skopeo e umoci.

Come per le alternative a Docker rkt e LXC, anche in runC non esiste un processo demone centrale. Al suo posto l’ambiente di runtime a container si integra con il processo init systemd.

Vantaggi Svantaggi
✔ runC si basa sullo standard de facto della Open Container Initiative (OCI). ✘ Per poter creare immagini a container, sono necessari tool esterni.

Alternative a Docker a confronto

La seguente tabella mostra un confronto delle alternative a Docker presentate nell’articolo.

  Docker rkt LXC LXD
Tecnologie di virtualizzazione A livello di sistema operativo A livello di sistema operativo, sull’Hypervisor A livello di sistema operativo A livello di sistema operativo
Container full-system No No
Container per app No No
Licenza Apache 2.0 Apache 2.0 GNU LGPLv2.1+ Apache 2.0
Formato container Container Docker appc, Container Docker Container Linux (LXC) Container Linux (LXC)
Piattaforma supportata Linux, Windows, macOS, Microsoft Azure, Amazon Web Services (AWS) Linux, Windows, macOS Linux Linux
Ultima release Aprile 2017 Febbraio 2017 Gennaio 2017 Marzo 2017
Patch del kernel di Linux necessario No No No No
Linguaggio di programmazione Go Go C, Python 3, Shell, Lua Go
  Linux-VServer OpenVZ runC
Tecnologie di virtualizzazione A livello di sistema operativo A livello di sistema operativo, sull’Hypervisor A livello di sistema operativo
Container full-system No
Container per app No No
Licenza GNU GPL v.2 GNU GPL v.2 Apache 2.0
Formato container Security Context Virtuozzo Containers OCI Bundle
Piattaforma supportata Linux Linux (solo Virtuozzo Linux, RHEL7) Linux
Ultima release Aprile 2007 Luglio 2016 Marzo 2017
Patch del kernel di Linux necessario Distribuzione indipendente No
Linguaggio di programmazione C C Go

Tecnologia a container su altri sistemi operativi

Il concetto di ripartire le risorse di sistema tramite meccanismi di isolamento e renderle disponibili sullo stesso sistema indipendentemente l’una dall’altra e in processi incapsulati, è comune per diversi sistemi operativi Unix-like. Un esempio simile sono i container di Linux con il termine “jail” nei sistemi BSD e nelle zone introdotte con Solaris 10. Per i sistemi Windows sono disponibili i seguenti concetti di container: Microsoft Drawbridge, WinDocks, Sandboxie, Turbo e VMware ThinApp.

FreeBSD Jail

I cosiddetti jail (dall’inglese: prigioni) rappresentano una delle caratteristiche più caratterizzanti, in termini di sicurezza, del sistema operativo Unix-like FreeBSD. Un jail è un ambiente di chroot avanzato, che allestisce un’istanza completamente virtuale del sistema operativo in una cartella separata e che presenta un elevato grado di isolamento rispetto ai chroot jail su Linux. Ogni jail dispone di una propria struttura di directory. Inoltre vengono limitati lo spazio del processo, gli accessi ai gruppi di utenti, le interfacce di rete e i meccanismi IPC. In questo modo i processi all’interno di un jail non hanno modo di accedere ad altre cartelle o file al di fuori dell’ambiente isolato e di coinvolgere altri processi sul sistema di host. Oltre a ciò, è possibile attribuire a tutti i jail un proprio nome host e un indirizzo IP.

Tramite una propria gestione utente si possono definire per ogni jail gruppi utenti indipendenti, i cui permessi sono limitati all’ambiente jail. In questo modo un utente che all’interno di un jail dispone di ampi permessi non è in grado di eseguire operazioni critiche di sistema al di fuori dell’ambiente virtuale. Ciò impedisce ad un hacker di apportare gravi danni sfruttando un jail compromesso.

Fatto

FreeBSD è una versione libera e open source della Berkeley Software Distribution (BSD), una variante del sistema operativo Unix che è stata sviluppata a partire dal 1977 presso la University of California a Berkeley.

Vantaggi Svantaggi
✔ Ottimizzato per la virtualizzazione full-system ✘ Non viene supportato l’isolamento dei singoli processi (come invece è presente su Docker).
  ✘ La virtualizzazione tramite jail prevede un sistema BSD (NetBSD, FreeBSD e OpenBSD).

Oracle Solaris Zones

Anche su Solaris è possibile allestire diversi ambienti di runtime, protetti l’uno dall’altro, all’interno dell’installazione di un sistema operativo: si tratta delle zone, le quali si ripartiscono il kernel del sistema operativo in comune. In questo processo si distinguono le cosiddette zone globali e le zone non globali.

  • Zone globali: ogni installazione di Solaris contiene una zona globale che funge da sistema operativo standard e che serve per l’amministrazione. Tutti i processi del sistema operano nella zona globale, a patto che non siano state memorizzate nelle zone non globali.
  • Zona non globali: per “zone non globali” si intendono ambienti virtuali separati che vengono realizzati all’interno della zona globale durante un’installazione di Solaris. L’isolamento delle singole zone non globali avviene in maniera analoga a FreeBSD, ovvero sulla base di un chroot jail modificato. Ad ognuna di queste zone viene assegnato un proprio nome host e una scheda di rete virtuale. Parti delle risorse dell’hardware alla base vengono assegnate in maniera fissa o tramite fair-share-scheduling oppure nell’ambito della gestione delle risorse.

Come già altri approcci alla virtualizzazione a livello di sistema operativo, anche le zone di Solaris offrono la possibilità di risparmiare sulle risorse e di realizzare diversi sistemi operativi isolati su un’istanza di sistema in comune.

Vantaggi Svantaggi
✔ L’implementazione nativa delle zone di Solaris permette un utilizzo molto efficiente di ambienti virtuali con un overhead minimale. ✘ L’utilizzo di zone di Solaris prevede la presenza del sistema operativo proprietario Oracle Solaris oppure della sua variante open source OpenSolaris.

Tecnologie a container su Windows

A partire dall’integrazione di un port di Docker nativo nel Windows Server 2016, la tecnologia a container ha fatto il suo ingresso anche nell’universo Microsoft. Il kernel di Windows è stato ampliato con nuove funzionalità in stretta collaborazione con il team di sviluppatori di Docker che operano in maniera simile ai Control Groups e agli spazi dei nomi presenti su Linux, e che permettono così una virtualizzazione efficiente a livello di sistema operativo.

L’engine nativo di Docker per Windows Server 2016 si differenzia in maniera sostanziale dalle applicazioni Docker for Windows e Docker for Mac. Mentre queste ultime permettono l’utilizzo dell’engine di Docker sviluppato per Linux con l’aiuto di una macchina virtuale leggera, la versione di Docker per Windows Server 2016 sfrutta direttamente il kernel di Windows. I classici container di Docker non possono quindi essere eseguiti su Windows Server 2016: al loro posto, però, è stato sviluppato un nuovo formato di container nell’ambito del progetto di Docker, con il nome di WSC (Windows Server Container). Inoltre Microsoft offre una variante di container basata su Hyper-V con la quale è possibile raggiungere un grado di isolamento più elevato.

  • Windows Server Container: con Windows Server Container (WSC) Microsoft offre una tecnologia a container per la piattaforma di Docker grazie alla quale è possibile isolare i processi con funzioni avanzate del kernel di Windows. Come per la tecnologia di Linux, anche i container di Windows Server si ripartiscono il kernel del sistema di host (host di container) alla base.
  • Hyper-V Container: con i container Hyper-V Microsoft offre la possibilità di proteggere ulteriormente istanze di container con l’aiuto di una virtualizzazione classica basata su hypervisor. Per quanto riguarda i container Hyper-V, si tratta di macchine virtuali che, proprio come il container di Windows Server, possono essere comandate tramite la piattaforma di Docker, ma per via del proprio kernel di Windows presentano un grado di isolamento decisamente più elevato.

Ancora prima che Microsoft, in ambito della cooperazione con Docker, avesse implementato tecnologie a container native all’interno del kernel di Windows, numerosi sviluppatori si sono occupati di metodi efficienti di virtualizzazione per i sistemi Windows. Microsoft Drawbridge, WinDocks, Sandboxie, Turbo e VMware ThinApp fanno parte dei progetti più conosciuti in questo contesto.

Microsoft Drawbridge

Con il nome di Drawbridge, Microsoft ha sviluppato il prototipo per una tecnologia di virtualizzazione che si basa sul concetto del Library-OS: ovvero un sistema operativo che nell’ambito di un’applicazione viene applicato come raccolta di librerie. Con Drawbridge le applicazioni vengono eseguite assieme al Library-OS in cosiddetti processi Pico: in questo caso si tratta di container di isolamento basati sul processo con un’interfaccia kernel. Nella documentazione riguardo al container di Windows Server, Microsoft giudica l’esperienza con Drawbridge un input fondamentale per lo sviluppo di tecnologie a container su Windows Server 2016.

WinDocks

WinDocks è una migrazione di Docker per Windows, con la quale è possibile creare e gestire container di app per applicazioni .NET e container di file per server SQL. Diversamente dai container di Windows Server, i quali per ora sono ancora limitati ai sistemi Windows 10 e Windows Server 2016, WinDocks è disponibile anche per sistemi operativi meno recenti come Windows Server 2012, Windows Server 2012 R2 come anche Windows 8 e 8.1. Il software viene offerto come Community Edition gratuita e come prodotto aziendale con assistenza clienti.

Sandboxie

Con l’aiuto di Sandboxie è possibile eseguire applicazioni su Windows in un ambiente isolato, la cosiddetta “sandbox”. In maniera simile alla tecnologia a container, questo procedimento ha l’obiettivo di proteggere il sistema di host alla base e altre applicazioni da attività del programma di un’applicazione isolata. A questo scopo entra in azione il tool, frapponendosi tra applicazione e sistema operativo, per intercettare operazioni di scrittura sul disco rigido e deviarle verso un’area protetta.

Oltre agli accessi ai file, in questo modo si impediscono anche le richieste di scrittura dirette al database del Registry di Windows. Sandboxie è disponibile come versione di base gratuita per tutte le edizioni di Windows recenti, oltre che per XP e Vista. In più l’offerta delle versioni a pagamento include anche una varietà più ampia di funzioni per l’uso privato e commerciale.  

Turbo (ex Spoon)

Turbo è un’alternativa a Docker per Windows con la quale è possibile inserire le applicazioni, comprese di dipendenze, in pacchetti isolati di container come .NET, Java o database come SQL Server o MongoDB. Tuttavia, diversamente dai container di Windows Server, questi non vengono supportati nativamente dal kernel di Windows, ragione per cui, come in Docker for Windows, è necessaria una macchina virtuale per compensare le inconsistenze.

Perciò i container di Turbo operano sullo Spoon Virtual Machine Engine (SVM), che funge da interfaccia per il kernel di Windows. Anche su Turbo lo scambio di applicazioni a container avviene tramite un hub basato su cloud. Nonostante il software sia ben documentato, rispetto a Docker non viene preso molto in considerazione dalla stampa di settore.

VMware ThinApp

VMware ThinApp è un tool per la virtualizzazione di applicazioni in ambiente desktop. Grazie al software è possibile rendere disponibili delle applicazioni su complesse strutture informatiche, senza che si vengano a creare conflitti. A questo scopo vengono infatti impacchettate insieme a tutte le dipendenze in un file EXE o MSI eseguibile e quindi isolate dal sistema operativo alla base e da altre applicazioni.

Il file realizzato tramite ThinApp è eseguibile senza installazione (e quindi senza permessi admin) su qualsiasi sistema Windows; volendo è possibile lavorare anche a partire da un supporto di memoria esterno, come ad esempio un USB Flash drive. ThinApp offre un’alternativa a Docker per la migrazione di applicazioni Legacy oppure per l’isolamento di programmi critici.

Tool