Cos’è LXD? Gestione dei con­te­ni­to­ri con Linux Container Daemon

LXD, “Linux Container Daemon”, è uno strumento di gestione per i container del sistema operativo Linux. È stato svi­lup­pa­to da Canonical, l’azienda dietro Ubuntu Linux; Canonical ha pro­se­gui­to lo sviluppo di LXD fino a oggi e gestisce il progetto.

LXD è una tec­no­lo­gia affine a LXC, i “Linux Con­tai­ners”. LXC è una tec­no­lo­gia di vir­tua­liz­za­zio­ne basata su con­te­ni­to­ri a livello di sistema operativo. Tec­ni­ca­men­te, LXC combina gli spazi dei nomi isolati e i “cgroups” del kernel Linux per creare ambienti isolati per l’ese­cu­zio­ne del codice. Sto­ri­ca­men­te, LXC è stato anche la base per Docker, la tec­no­lo­gia di vir­tua­liz­za­zio­ne am­pia­men­te uti­liz­za­ta.

Uno degli obiettivi fon­da­men­ta­li nello sviluppo di LXD è stato quello di rendere la gestione dei con­te­ni­to­ri LXC tanto pratica quanto lo è per le macchine virtuali. Tuttavia, rispetto all’utilizzo di una macchina virtuale, l’approccio basato su con­te­ni­to­ri fornisce pre­sta­zio­ni più elevate.

Uti­liz­zan­do LXD, i con­te­ni­to­ri del sistema operativo Linux possono essere con­fi­gu­ra­ti e con­trol­la­ti tramite un set di comandi definito. LXD è quindi adatto per l’au­to­ma­zio­ne della gestione di mol­te­pli­ci container e viene uti­liz­za­to nel cloud computing e nei data center.

• Sicurezza: i con­te­ni­to­ri fun­zio­na­no in spazi di nomi (namespace) isolati e possono accedere solo a risorse definite.
• Sca­la­bi­li­tà: LXD consente di gestire singoli con­te­ni­to­ri sul proprio portatile e migliaia in ambienti di­stri­bui­ti.
• Usabilità intuitiva: LXD fornisce un’API semplice e chiara e un client a riga di comando.
• Basato su immagini Linux: LXD funziona con qualsiasi immagine Linux e quindi beneficia delle molte di­stri­bu­zio­ni Linux esistenti.
• Controllo so­fi­sti­ca­to delle risorse: le re­stri­zio­ni sono impostate per un con­te­ni­to­re per CPU, memoria, uso della rete, della memoria di massa e delle risorse del kernel.
• Accesso all’hardware del sistema: se la con­fi­gu­ra­zio­ne lo consente, i con­te­ni­to­ri possono accedere anche a di­spo­si­ti­vi USB, GPU e supporti di ar­chi­via­zio­ne di massa.
• Gestione della rete: con una con­fi­gu­ra­zio­ne apposita si possono creare bridge e tunnel di rete.
• Gestione dello spazio di ar­chi­via­zio­ne di massa: LXD supporta vari back end, pool e volumi di spazio di ar­chi­via­zio­ne.

Il vantaggio prin­ci­pa­le di LXD è quello di con­sen­ti­re la vir­tua­liz­za­zio­ne di un sistema operativo Linux completo sulla base di con­te­ni­to­ri. Così facendo, LXD combina il comfort delle macchine virtuali con le pre­sta­zio­ni dei con­te­ni­to­ri.

A dif­fe­ren­za della maggior parte dei casi d’uso basati su Docker, LXD non si concentra sulla vir­tua­liz­za­zio­ne di una singola ap­pli­ca­zio­ne (“vir­tua­liz­za­zio­ne delle ap­pli­ca­zio­ni”). Piuttosto, un’immagine di sistema Linux serve come base di ogni con­te­ni­to­re LXD (“vir­tua­liz­za­zio­ne del sistema”). Ciò risulta van­tag­gio­so per l’am­mi­ni­stra­to­re, in quanto fornisce l’accesso a un gran numero di di­stri­bu­zio­ni Linux li­be­ra­men­te di­spo­ni­bi­li e permette l’utilizzo di una vasta gamma di strumenti esistenti.

Tuttavia, LXD ha uno svan­tag­gio rispetto ad altre tec­no­lo­gie di vir­tua­liz­za­zio­ne: poiché tutti i con­te­ni­to­ri che girano su un host accedono allo stesso kernel Linux, il demone LXD è di­spo­ni­bi­le solo su Linux. Inoltre, LXD può vir­tua­liz­za­re Linux solo come sistema operativo guest, mentre il client a riga di comando funziona anche su sistemi operativi non Linux.

L’API REST del demone LXD è ac­ces­si­bi­le at­tra­ver­so la rete. Ciò consente di spostare o copiare i con­te­ni­to­ri tra le macchine. Inoltre, LXD supporta la creazione di cluster di macchine che combinano molte unità di calcolo in­di­vi­dua­li in un su­per­com­pu­ter virtuale.

Il com­po­nen­te prin­ci­pa­le di LXD è il demone pri­vi­le­gia­to che dà il nome al sistema host di Linux. Il demone LXD fornisce un’API REST tramite un socket Linux locale. Il demone è ac­ces­si­bi­le anche at­tra­ver­so la rete tramite le im­po­sta­zio­ni di con­fi­gu­ra­zio­ne. In pratica, LXD accede a LXC sotto forma di back end at­tra­ver­so la libreria liblxc e i suoi go binding.

Un client in­te­ra­gi­sce con il demone tramite l’API REST. L’API definisce un lin­guag­gio con il quale si possono creare, con­trol­la­re e mo­di­fi­ca­re i con­te­ni­to­ri. Il client più semplice è la riga di comando ufficiale. Il client a riga di comando fornisce comandi per molte ope­ra­zio­ni comuni e accede in­ter­na­men­te all’API REST.

Per maggiore chiarezza, di seguito vi ri­por­tia­mo alcuni comandi LXD di base. Non con­fon­de­te­vi: il nome della riga di comando LXD è lxc e non lxd. Potete provare i comandi senza dover in­stal­la­re la riga di comando sul vostro sistema, ma sem­pli­ce­men­te usando l’in­ter­fac­cia web del progetto li­nux­con­tai­ners.org.

In linea di principio, LXD si può in­stal­la­re su qualsiasi sistema Linux moderno. Viene uti­liz­za­to sia su computer privati che su piat­ta­for­me di cloud computing e nei data center di­stri­bui­ti. In questo modo, LXD mira prin­ci­pal­men­te a vir­tua­liz­za­re un sistema operativo Linux completo e duraturo nel tempo. LXD è di con­se­guen­za in contrasto con Docker, che si concentra mag­gior­men­te su con­te­ni­to­ri di breve durata che in­cap­su­la­no una singola ap­pli­ca­zio­ne. Di seguito ri­por­tia­mo le parole dello svi­lup­pa­to­re di LXD Stéphane Graber:

Il client a riga di comando fornito è adatto per il controllo di pochi con­te­ni­to­ri; non è perciò pro­get­ta­to per gestire molti container di­stri­bui­ti su più host. In casi simili si uti­liz­za­no i col­le­ga­men­ti alle piat­ta­for­me OpenStack e Open­Ne­bu­la.

I com­po­nen­ti prin­ci­pa­li di LXD sono il già men­zio­na­to demone, l’API REST integrata e il client a riga di comando. Di seguito, esa­mi­ne­re­mo le entità primarie uti­liz­za­te quando si lavora con LXD.

Il con­te­ni­to­re (container in inglese) è l’astra­zio­ne di base fornita da LXD. Un con­te­ni­to­re LXD include le seguenti ca­rat­te­ri­sti­che:

• Un file system Linux
• Im­po­sta­zio­ni di con­fi­gu­ra­zio­ne come limiti delle risorse, variabili d’ambiente, opzioni di sicurezza, ecc.
• Di­spo­si­ti­vi di ar­chi­via­zio­ne di massa e di rete
• Profili di con­fi­gu­ra­zio­ne da cui il con­te­ni­to­re eredita le im­po­sta­zio­ni
• Proprietà generali come l’ar­chi­tet­tu­ra del con­te­ni­to­re, il nome e in­for­ma­zio­ni sulla durata del con­te­ni­to­re
• Stato di ese­cu­zio­ne come il th­rou­gh­put di rete, l’utilizzo della memoria, ecc.

Come è comune con altre tec­no­lo­gie di vir­tua­liz­za­zio­ne, da un con­te­ni­to­re si possono creare snapshots (in italiano: “istan­ta­nee”). Uno snapshot è identico al con­te­ni­to­re sot­to­stan­te. Le istan­ta­nee sono im­mu­ta­bi­li, quindi non si possono mo­di­fi­ca­re; si possono solo ri­no­mi­na­re e can­cel­la­re. Da uno snapshot è possibile ri­pri­sti­na­re lo stato esatto di un con­te­ni­to­re.

Sebbene LXD sia una tec­no­lo­gia basata su con­te­ni­to­ri, per crearli viene uti­liz­za­ta un’immagine di sistema Linux. Per de­fi­ni­zio­ne, ogni con­te­ni­to­re LXD proviene da un’immagine.

Le immagini sono di solito di­stri­bu­zio­ni Linux non mo­di­fi­ca­te, in quanto vengono uti­liz­za­te anche per macchine virtuali o istanze cloud. Un’immagine è iden­ti­fi­ca­ta in modo univoco dal relativo hash SHA256. Per con­sen­ti­re un’as­se­gna­zio­ne più agevole per gli utenti in carne e ossa, è possibile definire un alias per un’immagine.

Le immagini Linux da uti­liz­za­re con LXD sono re­pe­ri­bi­li online da varie fonti. I seguenti server di immagini sono pre­de­fi­ni­ti in LXD:

• ubuntu: fornisce immagini Ubuntu stabili.
• ubuntu-daily: fornisce ogni giorno build di immagini di Ubuntu.
• images: fornisce una varietà di immagini di altre di­stri­bu­zio­ni Linux ed è gestito di­ret­ta­men­te dalla community.

Le immagini scaricate dal demone LXD vengono au­to­ma­ti­ca­men­te me­mo­riz­za­te nella cache in modo che siano di­spo­ni­bi­li per un uso ripetuto senza ritardi. Se non di­ver­sa­men­te con­fi­gu­ra­to, LXD controlla la versione delle immagini scaricate e ricarica le nuove versioni, se ne­ces­sa­rio. Ana­lo­ga­men­te a quanto avviene con il software Vagrant, è possibile uti­liz­za­re LXD per pub­bli­ca­re un con­te­ni­to­re esistente come nuova immagine.

Un profilo LXD raggruppa varie im­po­sta­zio­ni di con­fi­gu­ra­zio­ne del con­te­ni­to­re. Si può applicare un profilo a più con­te­ni­to­ri e più profili a un con­te­ni­to­re. Infine, viene importata la con­fi­gu­ra­zio­ne del con­te­ni­to­re locale. Durante questo processo, i valori di con­fi­gu­ra­zio­ne definiti più volte possono essere so­vra­scrit­ti. In questo modo è facile creare famiglie di con­te­ni­to­ri. LXD viene fornito con due profili già esistenti:

• Il profilo pre­de­fi­ni­to default è applicato au­to­ma­ti­ca­men­te a un con­te­ni­to­re, a meno che non sia spe­ci­fi­ca­to un profilo al­ter­na­ti­vo. Questo profilo include im­po­sta­zio­ni di con­fi­gu­ra­zio­ne di base, come il di­spo­si­ti­vo di rete eth0.
• Il profilo docker viene uti­liz­za­to per con­fi­gu­ra­re un con­te­ni­to­re LXD che include i container Docker. Questo profilo fa sì che il con­te­ni­to­re LXD carichi i moduli del kernel necessari e configuri le im­po­sta­zio­ni del di­spo­si­ti­vo. Inoltre, viene attivata la ni­di­fi­ca­zio­ne dei con­te­ni­to­ri.

LXD è un demone di rete: il client a riga di comando può co­mu­ni­ca­re con diversi server LXD e server di immagini remoti. Con una con­fi­gu­ra­zio­ne apposita, diversi server si possono definire come remotes (in italiano: “remoti”). In questo modo, si possono copiare e spostare i con­te­ni­to­ri esistenti tra server LXD; inoltre, è possibile accedere ai server di immagini tramite remotes. Oltre ai server di immagini già in­tro­dot­ti nel paragrafo “Immagini”, il client a riga di comando dispone già del remote ‘local’, uti­liz­za­to per co­mu­ni­ca­re con il demone locale LXD tramite un socket UNIX.

Oggi esiste un’ampia gamma di tec­no­lo­gie di vir­tua­liz­za­zio­ne che si possono uti­liz­za­re prin­ci­pal­men­te come al­ter­na­ti­ve a LXD. Queste si dif­fe­ren­zia­no per vari criteri e si possono sud­di­vi­de­re ap­pros­si­ma­ti­va­men­te in due grandi gruppi: oltre ai tra­di­zio­na­li strumenti di vir­tua­liz­za­zio­ne basati su macchine virtuali (VM), si sono affermate anche le tec­no­lo­gie basate sui container. LXD si distingue in questo caso e utilizza un approccio ibrido in cui un intero sistema operativo Linux è vir­tua­liz­za­to sulla base di container.

Alcuni strumenti di vir­tua­liz­za­zio­ne ri­chie­do­no Linux come sistema host, mentre altri fun­zio­na­no su tutti i prin­ci­pa­li sistemi operativi. Allo stesso modo, alcuni ambienti di vir­tua­liz­za­zio­ne sup­por­ta­no solo Linux come sistema guest, mentre altri ne sup­por­ta­no, a loro volta, altri com­ple­ta­men­te diversi. Molte tec­no­lo­gie basate su container si con­cen­tra­no prin­ci­pal­men­te sulla vir­tua­liz­za­zio­ne delle ap­pli­ca­zio­ni, mentre le macchine virtuali sono sempre basate su un sistema operativo completo.

Poiché LXD è basato su LXC, è possibile uti­liz­za­re un’in­stal­la­zio­ne LXC “vuota” in al­ter­na­ti­va a LXD. In questo caso, tuttavia, potrebbe derivarne un uso meno con­for­te­vo­le. Dato che non viene uti­liz­za­to nessun demone senza LXD, la vir­tua­liz­za­zio­ne non può essere con­trol­la­ta at­tra­ver­so la rete. Inoltre, manca l’API REST come in­ter­fac­cia uniforme.

Tra i popolari strumenti di vir­tua­liz­za­zio­ne, con­tai­nerd è pro­ba­bil­men­te il più pa­ra­go­na­bi­le a LXD. Così con­tai­nerd funziona anche come demone che fornisce un’API. Come nel caso di LXD, ciò permette di gestire con­te­ni­to­ri at­tra­ver­so la rete. La tec­no­lo­gia è integrata in Docker ed è am­pia­men­te uti­liz­za­ta.

In generale, è con­si­glia­bi­le scegliere la tec­no­lo­gia ap­pro­pria­ta a seconda delle esigenze spe­ci­fi­che. Di seguito una pa­no­ra­mi­ca delle tec­no­lo­gie di vir­tua­liz­za­zio­ne più uti­liz­za­te: