EMB_87

EMBEDDED 87 • FEBBRAIO • 2023 55 UNIKERNEL | SOFTWARE zione delle responsabilità. Un’infrastruttura di questo tipo è anche difficile da gestire, poiché sono presenti più server che sono tutti macchine virtuali indipenden- ti. La distribuzione del software in un’architettura di macchine virtuali può essere gestita in due modi: a) Il sistema di compilazione può produrre un’imma- gine completa di una macchina virtuale con softwa- re integrato e la macchina virtuale si riavvia quan- do arriva l’aggiornamento. b) Il sistema di compilazione produce solo l’aggrega- zione dei software, che vengono caricati sui server utilizzando un insieme di script. Entrambi gli approcci richiedono una procedura di configurazione complessa e, a lungo andare, causano incoerenze tra le macchine virtuali. Tuttavia, l’ammi- nistratore ha il controllo completo dell’ambiente e di ogni aspetto del sistema e può configurarlo in base ad esigenze specifiche. Il debug è relativamente semplice, poiché è possibile collegarsi direttamente a una mac- china virtuale. Il concetto alla base dei container è lo stesso delle mac- chine virtuali, ma non richiede la duplicazione delle responsabilità tra le macchine. Invece di caricare un intero sistema operativo per un’applicazione, Docker permette ai container di utilizzare il kernel del sistema operativo host, consentendo al contempo il sideload di librerie e programmi specifici per l’applicazione. Gra- zie alla possibilità di apportare modifiche al container e alla sua immagine, è possibile ottimizzare le librerie e le configurazioni specifiche che l’applicazione utilizzerà. In questo modo si ottiene un incremento delle presta- zioni senza dover eseguire un intero sistema operativo I container sono facili da eseguire sulle macchine di svi- luppo e anche il processo di distribuzione è molto più semplice, poiché è sufficiente caricare i container esi- stenti in un repository e i sistemi di produzione posso- no eseguire il pull della versione aggiornata. L’approc- cio basato sui container ha tuttavia i suoi lati negativi. È necessario adattare il software in modo che possa es- sere utilizzato nei container (containerizzato) e questo può essere complicato, soprattutto con le basi di codice legacy. I container includono molte più configurazioni per l’allocazione delle risorse e numerose funzionalità di interoperabilità, per cui è abbastanza facile configu- rarli in modo non corretto. Unikernel: vantaggi e limiti La fase logica successiva nel passaggio dalle macchine virtuali ai container sono gli unikernel, che aspirano a estendere il concetto di container. Gli unikernel sono di fatto un insieme di librerie binarie predefinite. Non gestiscono l’allocazione delle risorse. L’interoperabili- tà diretta con l’hardware viene gestita dall’hypervisor. Viene eseguito il pushing di tutte le chiamate di siste- ma specifiche di un’applicazione il più vicino possibile all’applicazione stessa. Anche questo processo è gestito dall’hypervisor. L’architettura unikernel punta a com- binare i punti di forza in termini di sicurezza offerti dal partizionamento a livello di macchina virtuale con i vantaggi in termini di maggiore velocità e minore in- gombro attribuiti ai container. La figura 1 mostra le differenze degli approcci delle di- verse architetture. Per i sistemi sicuri, si dovrebbe uti- lizzare un hypervisor di tipo 1 (in cui non è presente un sistema operativo “helper” sottostante), che viene eseguito direttamente sull’hardware e carica le macchi- ne virtuali. Gli hypervisor che si basano su un “sistema operativo host” sottostante rappresentano un compro- messo e creano dei punti deboli all’interno dei sistemi. Gli unikernel hanno costi generali ancora più ridotti rispetto ai container e sono più semplici da utilizzare, il che consente di migliorare le prestazioni. Inoltre, eli- minando l’uso di un kernel nello spazio utilizzato da più utenti e indirizzi, la sicurezza risulta drasticamente migliorata. Esiste tuttavia una serie di problemi associati agli unikernel che ne hanno limitato l’applicazione fino ad oggi. Si tratta degli aspetti seguenti: • Il debug. Poiché un unikernel non include un siste- ma operativo in esecuzione, non è possibile con- nettersi direttamente alla sua shell e per eseguire indagini • La produzione di immagini unikernel è complicata Fig. 1 – Illustrazione delle diverse architetture presentate in questo articolo