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?

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.

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 IONOS 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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.